9 of 157

In general, excellence is hard to sell.

This problem isn’t limited to Haskell, though we’ll focus on it, because…

This is a Haskell Meetup.
Haskell’s functional approach to programming makes it quick to write correct, elegant, excellent code.
Haskell’s static type system makes refactoring safe, allowing code to stay excellent at scale…

10 of 157

In general, excellence is hard to sell.

This problem isn’t limited to Haskell, though we’ll focus on it, because…

This is a Haskell Meetup.
Haskell’s functional approach to programming makes it quick to write correct, elegant, excellent code.
Haskell’s static type system makes refactoring safe, allowing code to stay excellent at scale…

even when you have bozos like me working on it!

11 of 157

Me at the wrong time of day

12 of 157

Me Anyone at the wrong time of day

13 of 157

An aside...

Don’t call yourself (or another programmer) a “bozo” when talking to business types. We know that even if we’re really good at our jobs, we make mistakes.

We self-deprecate because we’re used to being corrected by our subordinates (computers). “Fix or no compile.”

14 of 157

An aside...

Don’t call yourself (or another programmer) a “bozo” when talking to business types. We know that even if we’re really good at our jobs, we make mistakes.

We self-deprecate because we’re used to being corrected by our subordinates (computers). “Fix or no compile.”

Executives aren’t. They’re constantly told that they’re awesome. Cultural differences, ya know.

15 of 157

An aside...

Don’t call yourself (or another programmer) a “bozo” when talking to business types. We know that even if we’re really good at our jobs, we make mistakes.

We self-deprecate because we’re used to being corrected by our subordinates (computers). “Fix or no compile.”

Executives aren’t. They’re constantly told that they’re awesome. Cultural differences, ya know.

Nix self-deprecation, adopt their baseless smooth, calming confidence.

16 of 157

(a little self-deprecation goes a long way)

17 of 157

Actually, I’m more of a curmudgeon

18 of 157

Actually, I’m more of a curmudgeon

19 of 157

Actually, I’m more of a curmudgeon

I think like this…

20 of 157

Actually, I’m more of a curmudgeon

Nail myNail = null; //momentary idiocy

Shoe myShoe = new Shoe (myNail);

...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hours later (in runtime):

�KingdomLostException

at KingdomVisitorFactory.java:9784

...

Caused by: NullPointerException

HORRIBLE error/failure distance!

21 of 157

Error / failure distance

If the logical fault (error) is far away from the manifestation (failure) then you are in for a looooong debug session.

Lisp’s nil overloading adds conceptual beauty but enables gaping error/failure distances.

22 of 157

Actually, I’m more of a curmudgeon

I think like this…

… so I can’t stand bad code!

23 of 157

Anyway, static typing is very good.

It protects me from a possible 2:00am future bozo self...

… and other bozos, too!

It makes refactoring safe…

… because we’re all bozos when it comes to some other bozo’s code.

With type inference (Haskell, ML, F#) it’s unobtrusive.

24 of 157

Some argue that...

Some argue that static typing mainly catches “stupid” bugs.

Most bugs are stupid. (Find one!)

(get :is-pubic {:is-public true :value 23})

=> nil

25 of 157

Some argue that...

Some argue that static typing mainly catches “stupid” bugs.

Most bugs are stupid. (Find one!)

(get :is-public {:is-public true :value 23})

=> nil

26 of 157

Some argue that...

Some argue that static typing mainly catches “stupid” bugs.

Most bugs are stupid. (Find one two!)

(get :is-public {:is-public true :value 23})

=> true

27 of 157

… but “Haskell is weird”!!

28 of 157

In truth… it’s not that weird.

29 of 157

Productivity

Time invested

2 days

2 wks

3 mth.

1 yr.

5 yrs.

Haskell

“Brand X”

Enterprise Java/C#

30 of 157

Productivity

Time invested

2 days

2 wks

3 mth.

1 yr.

5 yrs.

Haskell

“Brand X”

Enterprise Java/C#

31 of 157

Productivity

Time invested

2 days

2 wks

3 mth.

1 yr.

5 yrs.

Haskell

“Brand X”

Enterprise Java/C#

Few runtime bugs / flowful.

32 of 157

Productivity

Time invested

2 days

2 wks

3 mth.

1 yr.

5 yrs.

Haskell

“Brand X”

Enterprise Java/C#

Few runtime bugs / flowful.
Performant / no “rewrite in Java”.

33 of 157

Productivity

Time invested

2 days

2 wks

3 mth.

1 yr.

5 yrs.

Haskell

“Brand X”

Enterprise Java/C#

Few runtime bugs / flowful.
Performant / no “rewrite in Java”.
Modularity and code reuse.

34 of 157

Productivity

Time invested

2 days

2 wks

3 mth.

1 yr.

5 yrs.

Haskell

“Brand X”

Enterprise Java/C#

Few runtime bugs / flowful.
Performant / no “rewrite in Java”.
Modularity and code reuse.
Interface integrity maintained automatically.

35 of 157

Productivity

Time invested

2 days

2 wks

3 mth.

1 yr.

5 yrs.

Haskell

“Brand X”

Enterprise Java/C#

Few runtime bugs / flowful.
Performant / no “rewrite in Java”.
Modularity and code reuse.
Interface integrity maintained automatically.
Doesn’t tolerate imprecision of thought (code rot).

36 of 157

Anyway, let’s talk FP...

Modern languages provide the option of functional programming. (Yay?)

Even Java has lambdas as of 1.8.

37 of 157

Unfortunately, while...

Modern languages provide the option of functional programming.

THAT’S NOT NEARLY ENOUGH!

Code quality is determined by what people do, not what the language enables.

38 of 157

To know good vs. bad Scala style...

39 of 157

Functional programming is the way forward

Bad news: to reason about arbitrary code is mathematically impossible (Turing’s Halting Problem, Rice’s Theorem).

40 of 157

Functional programming is the way forward

Bad news: to reason about arbitrary code is mathematically impossible (Turing’s Halting Problem, Rice’s Theorem).

Good news: programmers don’t write “arbitrary code”. Their programs exist to solve specific problems, in a low-entropy subspace of “all code”.

41 of 157

Functional programming is the way forward

Bad news: to reason about arbitrary code is mathematically impossible (Turing’s Halting Problem, Rice’s Theorem).

Good news: programmers don’t write “arbitrary code”. Their programs exist to solve specific problems, in a low-entropy subspace of “all code”.

Style Guide: “Don’t write arbitrary code!”

42 of 157

Me Anyone at the wrong time of day

43 of 157

FP is the way forward (2)

Sadly, programs often evolve into high-entropy “arbitrary code”.

Too many cooks.
“Quick fixes” and ill-advised requirements.
Deadline culture (aka “Agile”) leading to lost sight of the bigger picture.

No silver bullet, but simple “building blocks” that compose well are a start.

44 of 157

FP is the way forward (3)

OOP has 23 design patterns and most of them suck.

FP has two design patterns that compose very well.

Noun: immutable data. Easy to create and inspect, won’t change.
Verb: referentially transparent functions. Easy to define correctness and to reproduce results.

Even this separation’s artificial: “verbs” double as “nouns”.

45 of 157

FP is the way forward (4)

Functional programming values reproducibility and favors explicit (“threaded”) state over the implicit kind.

Global state has its negatives, but promiscuously strewn local state (OOP) is often just as bad.

In functional programming, mutability is allowed as an optimization but not the default.

46 of 157

FP is the way forward (5)

-- DON'T DO THIS!! (implicit state)

ctr :: IORef Int

ctr = unsafePerformIO $ newIORef 1

incr :: IO Int

incr = do

x <- readIORef ctr

writeIORef ctr $ x + 1

return x

data Counter = C {get :: Int}

incrExpl :: Counter -> (Int, Counter)

incrExpl c =

let x = get c in

(x, C (x + 1))

-- Explicit state is:

-- * thread/revision safe.

-- * configuration-agnostic.

-- * reproducible.

-- * easier to reason about.

47 of 157

FP is the way forward (6)

Haskell does allow state and mutability with specialized nouns: reference cells like IORef and TVar, and composable stateful actions (IO a, STM a).

getChar :: IO Char -- “IO-capable, returns a Char”

putChar :: Char -> IO ()

λ let echo = do { c <- getChar; putChar c }

echo :: IO ()

48 of 157

FP is the way forward (7)

Haskell doesn’t eliminate state or “side effects”.

It just gives us the tools to manage them, in the type system.

Haskell is possibly the best imperative language.

49 of 157

We suck at selling functional programming (FP)

50 of 157

We suck at selling functional programming (FP)

It’s not actually stateless programming, and selling a negative (“doesn’t have state”) is a losing strategy.

It’s state-aware programming.

In Haskell, compile-time types can tell you:

if a computation involves state changes.
what kind of state (e.g. thread-local, I/O) it can have.

51 of 157

The next ~10 minutes assume Haskell exposure.

If you’re familiar with Haskell, I’ll probably be annoyingly slow.

If you’re not, I’ll be moving fast.

… and then we’ll get back to business.

52 of 157

Let’s review some Haskell types.

Base types like Int, Char, Double, Bool.
Tuple types, e.g. (Int, Char).

(‘c’, 5.5) :: (Char, Double)
… and the nullary (void) tuple type, ().

Parameterized types like [] (“list”) and Map.

e.g. String = [Char], Map String Int.

53 of 157

Let’s review some Haskell types.

Union types (important when reintroducing limited dynamism).

Color = Red | Blue | Green
Maybe a = Just a | Nothing
Either e a = Left e | Right a
JSON = JObj [(String, JSON)] | JArr [JSON]

| JNum Double | JStr String | JBool Bool

| JNull

54 of 157

Let’s review some Haskell types.

Function types, e.g.

length :: [a] -> Int
id :: a -> a
map :: (a -> b) -> [a] -> [b]
(\r -> (chr r, r * 37) :: Int -> (Char, Int)

IO -- a parameterized type.

An a is actually a lazy “thunk” that, if needed, is evaluated to produce an a.
An IO a is an action that, if executed, returns an a.

55 of 157

Let’s review some Haskell types.

A Haskell executable has an action called main of type IO () that is executed.

Haskell provides no “sane” way to turn an IO into a “pure” value, e.g. IO Int into Int. Thus, if a computation is “in IO”, enclosing computations will return IO types.

56 of 157

Let’s review some Haskell types

The IO type is an instance (but not the only one) of the typeclass Monad. A monad is an abstraction that allows us to encode a notion of computational context into our type system.

IO is the ultimately impure monad. IO a means “I can have stateful effects, but I produce an a”.

57 of 157

Some example IO.

getChar :: IO Char

putChar :: Char -> IO ()

getCurrentTime :: IO UTCTime

listDirectory :: FilePath -> IO [FilePath]

catch :: IO a -> (IOError -> IO a) -> IO a

randomIO :: IO Int --actually (Random a) => IO a

return :: a -> IO a --actually more general

bind :: IO a -> (a -> IO b) -> IO b --ditto

58 of 157

I will try to sell Monad.

Craps is a “stateful” game. You roll two dice.

A 2 (“snake eyes”), 3 (“cock eyes”) or 12 (“box cars”) means you lose.
A 7 or 11 (“natural”) means you win.
Any other value becomes your “point”.

You roll the dice again, and repeat, until you roll your point (and win) or a 7 (and lose).

Find two instances of state in this game.

59 of 157

I will try to sell Monad.

Craps is a “stateful” game. You roll two dice.

A 2 (“snake eyes”), 3 (“cock eyes”) or 12 (“box cars”) means you lose.
A 7 or 11 (“natural”) means you win.
Any other value becomes your “point”.

You roll the dice again, and repeat, until you roll your point (and win) or a 7 (and lose).

60 of 157

Haskell can be stateful...

import System.Random

roll :: IO Int

roll = do

x <- randomRIO (1, 6)

y <- randomRIO (1, 6)

return (x + y)

youWin :: IO ()

youWin = putStrLn "You won!"

youLose :: IO ()

youLose = putStrLn "You lose!"

main :: IO ()

�main = do

point <- roll

case point of

p | p `elem` [2, 3, 12] -> youLose

p | p `elem` [7, 11] -> youWin

_ -> loop point

where

loop point = do

r <- roll

if r == point then youWin

else if r == 7 then youLose

else loop point

61 of 157

Haskell can be stateful...

import System.Random

roll :: IO Int

roll = do

x <- randomRIO (1, 6)

y <- randomRIO (1, 6)

return (x + y)

youWin :: IO ()

youWin = putStrLn "You won!"

youLose :: IO ()

youLose = putStrLn "You lose!"

main :: IO ()

�main = do

point <- roll

case point of

p | p `elem` [2, 3, 12] -> youLose

p | p `elem` [7, 11] -> youWin

_ -> loop point

where

loop point = do

r <- roll

if r == point then youWin

else if r == 7 then youLose

else loop point

explicit (threaded) state

implicit state

62 of 157

Haskell can be stateful...

import System.Random

roll :: IO Int

roll = do

x <- randomRIO (1, 6)

y <- randomRIO (1, 6)

return (x + y)

youWin :: IO ()

youWin = putStrLn "You won!"

youLose :: IO ()

youLose = putStrLn "You lose!"

… but we don’t need to do our dice rolling in the IO monad!

We have no guarantee that roll isn’t wiping the DB.

63 of 157

Haskell can be stateful...

… but we don’t need to do our dice rolling in the IO monad!

We have no guarantee that roll isn’t wiping the DB.

That sounds like a ridiculous thing to fear…

...unless you’ve ever worked on a large multi-engineer program.

64 of 157

We don’t need “IO” for the dice.

We were able to use explicit state for the player’s “point” and can do the same for the random number generator.

(State s) a = s -> (a, s) --(in essence)

A “State s a” is a deterministic action (on state of type s) that returns an a. The state is an explicit parameter.

An “IO a” is an IO-capable action that returns an a when executed. State is an implicit parameter.

65 of 157

Replacing IO with (State StdGen)

import System.Random

import Control.Monad.State

d6 :: State StdGen Int

d6 = state $ randomR (1, 6)

roll :: State StdGen Int

roll = do

x <- d6

y <- d6

return $ x + y

data Result = Win | Lose deriving Show

play :: State StdGen Result

play = do

point <- roll

case point of

p | p `elem` [2, 3, 12] -> return Lose

p | p `elem` [7, 11] -> return Win

_ -> loop point

where loop point = do

r <- roll

if r == point then return Win

else if r == 7 then return Lose

else loop point

main :: IO ()

main = do {gen <- newStdGen;

print $ evalState play gen}

66 of 157

The dreaded “M word” (1)

State s a (or, equivalently, (State s) a) has an apparent similarity to IO a.

A State s a is a function, s -> (a, s).
An IO a is “World -> (a, World)”.

(unfortunately, we can’t formalize World; the actual world is too big to fit in memory.)

67 of 157

The dreaded “M word” (2)

State s a has an apparent similarity to IO a. This similarity facilitates code reuse.

roll :: IO Int

roll = do

x <- randomRIO (1, 6)

y <- randomRIO (1, 6)

return (x + y)

roll :: State StdGen Int

roll = do

x <- d6

y <- d6

return (x + y)

68 of 157

The dreaded “M word” (3)

Monad allows us to abstract over “computational context”.

IO a ~ “I may do arbitrary I/O and will produce an a.”
State s a or s -> (a, s) ~ “I produce an a and update explicit/threaded state of type s.”
STM a ~ “I am an STM transaction returning a.”
Either e a ~ “I may return an a, or I might ‘except’ and return an e.”
SecureSandbox a ~ Custom limited-I/O monads.

69 of 157

The dreaded “M word” (4)

This allows for code reuse, because we’ve abstracted over computational context.

rollDieIO :: IO Int

rollDieIO = randomRIO (1, 6)

rollDieState :: State StdGen Int

rollDieState = state $ randomR (1, 6)

sequence :: (Monad m) => [m a] -> m [a] -- e.g. [IO a] => IO [a]

rollDice :: (Monad m) => Int -> m Int -> m [Int]

rollDice n d6 =

sequence (take n (repeat d6))

70 of 157

The dreaded “M word” (5)

Haskell’s radicalism about type discipline and stateful effects is actually about the creation of high-quality, simple components that one can reason about-- even if they were written years ago, or by another author.

71 of 157

The dreaded “M word” (5)

A consequence of forcing state to be included in type signatures (e.g. IO) is that it encourages people to write smaller, more modular functions that avoid state unless they need it.

72 of 157

That’s the pitch (for Monad).

When what you’re selling is of high quality, it’s better to teach (as much as you can) than to sell…

… of course, to fully teach Monad would require another talk or two.

73 of 157

Enough about Monads. Feed us!

74 of 157

Selling Haskell to programmers

Our static typing actually is better.

Java has ArrayList and Runnable; we have [String] and String -> Int.
Java and C++ force us to notate internal types (e.g. for-loop counters) and Haskell doesn’t.

75 of 157

Selling Haskell to programmers (2)

Haskell’s static typing makes safe refactoring possible, even at scale.

Compiler tells you what breaks. No waiting for unit tests to run (and not knowing whether the breakage is even your fault!)
Yes, you still have to test, debug, and document Haskell code, but you get more per unit time.

76 of 157

Selling Haskell to programmers (3)

Actually… debugging sucks, testing sucks somewhat less, and compiling (+ QuickChecking) sucks a whole lot less.

77 of 157

Selling Haskell to programmers (4)

No doubt, dynamic typing test drives extremely well.

78 of 157

Selling Haskell to programmers (4)

No doubt, dynamic typing test drives extremely well.

Clojure is beautiful. Python is easy to learn.

79 of 157

Selling Haskell to programmers (4)

No doubt, dynamic typing test drives extremely well.

Clojure is beautiful. Python is easy to learn.

These are fine languages! But they lack a feature (compile-time typing) that I’d demand if I were building out a 5000+ LoC project.
… for the purposes of my talk, those projects are where my focus is.

80 of 157

Selling Haskell to programmers (5)

Haskell isn’t the only functional programming language.

There’s also Erlang, Common Lisp, Clojure, OCaml, F#, Scala, Swift, Scheme...

81 of 157

Selling Haskell to programmers (5)

Haskell isn’t the only functional programming language.

There’s also Erlang, Common Lisp, Clojure, OCaml, F#, Scala, Swift, Scheme...

… but Haskell is the only major language whose type system can verify the lack of side effects.

82 of 157

Selling Haskell to programmers (5)

Haskell isn’t the only functional programming language.

There’s also Erlang, Common Lisp, Clojure, OCaml, F#, Scala, Swift, Scheme...

… but Haskell is the only major language whose type system can verify the lack of side effects.

factorial :: Int -> Int does not wipe the DB.

83 of 157

Selling Haskell to programmers (6)

Static typing isn’t nearly as restrictive as some fear.

�It’s easier to get the dynamism you want in a static language (see: Write Yourself a Scheme in 48 Hours) than to exclude behaviors that you don’t want in a dynamic one.

84 of 157

Selling Haskell to programmers (6)

Static typing isn’t nearly as restrictive as some fear.

�It’s easier to get the dynamism you want in a static language (see: Write Yourself a Scheme in 48 Hours) than to exclude behaviors that you don’t want in a dynamic one.��There are great programs written in dynlangs, but 99% of programs that “require dynamic typing” are badly designed.

85 of 157

Selling Haskell to programmers (7)

Haskell is fast as hell.

Am I talking about executable performance or the speed of development?

86 of 157

Selling Haskell to programmers (7)

Haskell is fast as hell.

Am I talking about executable performance or the speed of development?

Both! Haskell’s static typing doesn’t slow development by much, and reduced debugging time is huge.

87 of 157

Selling Haskell to programmers (7)

Haskell is fast as hell.

Am I talking about executable performance or the speed of development?

Both! Haskell’s static typing doesn’t slow development by much, and reduced debugging time is huge.

(Okay, full disclosure. Haskell takes some time to learn. After that, it’s fast.)

88 of 157

Productivity

Time invested

2 days

2 wks

3 mth.

1 yr.

5 yrs.

Haskell

“Brand X”

Enterprise Java/C#

89 of 157

Selling Haskell to the Business

90 of 157

Understanding the tribes

Great programmers want to build great systems that run without maintenance, so they can move on to better things.

Bad business people “cut costs” (externalize) and play politics. They can’t grow the pie, so they fight over slices.

91 of 157

Understanding the tribes

Great programmers want to build great systems that run without maintenance, so they can move on to better things.

Bad programmers create incomprehensible systems that only they can maintain, in order to protect their jobs.

Bad business people “cut costs” (externalize) and play politics. They can’t grow the pie, so they fight over slices.

92 of 157

Understanding the tribes

Great programmers want to build great systems that run without maintenance, so they can move on to better things.

Bad programmers create incomprehensible systems that only they can maintain, in order to protect their jobs.

Great business people want excellent processes and companies, in order to generate new wealth.

Bad business people “cut costs” (externalize) and play politics. They can’t grow the pie, so they fight over slices.

93 of 157

Understanding the tribes

Great programmers want to build great systems that run without maintenance, so they can move on to better things.

Bad programmers create incomprehensible systems that only they can maintain, in order to protect their jobs.

Great business people want excellent processes and companies, in order to generate new wealth.

Bad business people “cut costs” (externalize) and play politics. They can’t grow the pie, so they fight over slices.

Sell to these guys (and gals)!

94 of 157

Selling (anything) to the business

Programmers tend to have a tribal condescension toward “the Business”. Drop that. “They” are often as smart as we are, just with different specialities.

I used to think that it was “idiot businessmen” who were responsible for the awfulness of the software industry.

95 of 157

Selling (anything) to the business

Programmers tend to have a tribal condescension toward “the Business”. Drop that. “They” are often as smart as we are, just with different specialities.

I used to think that it was “idiot businessmen” who were responsible for the awfulness of the software industry.

In fact, it’s (often, smart) businessmen listening to idiots.

96 of 157

Selling (anything) to the business (2)

I used to think that it was “idiot businessmen” who were responsible for the awfulness of the software industry.

In fact, it’s (often, smart) businessmen listening to idiots.

Yes, this is good news. It means that there’s room for empathy. We can figure out why this is.

97 of 157

Selling (anything) to the business (3)

Why do smart business people often listen to idiots about technology? Cultural differences.

98 of 157

Selling (anything) to the business (3)

Why do smart business people often listen to idiots about technology? Cultural differences.

Business people think holistically and approximately, by necessity.

99 of 157

Selling (anything) to the business (3)

Why do smart business people often listen to idiots about technology? Cultural differences.

Business people think holistically and approximately, by necessity.
Good technologists think in precise detail, also by necessity.

100 of 157

Selling (anything) to the business (3)

Why do smart business people often listen to idiots about technology? Cultural differences.

Business people think holistically and approximately, by necessity.
Good technologists think in precise detail, also by necessity.
Bad technologists think imprecisely and politically and bridge the cultural gap more easily.

101 of 157

Selling (anything) to the business (3)

Why do smart business people often listen to idiots about technology? Cultural differences.

Business people think holistically and approximately, by necessity.
Good technologists think in precise detail, also by necessity.
Bad technologists think imprecisely and politically and bridge the cultural gap more easily.

Where “story points” and stack ranking (false precision) come from.

102 of 157

Selling (anything) to the business (3)

Why do smart business people often listen to idiots about technology? Cultural differences.

Business people think holistically and approximately, by necessity.
Good technologists think in precise detail, also by necessity.
Bad technologists think imprecisely and politically and bridge the cultural gap more easily.
Haskell crushes imprecision of thought.

103 of 157

Selling (anything) to the business (3)

Why do smart business people often listen to idiots about technology? Cultural differences.

Business people think holistically and approximately, by necessity.
Good technologists think in precise detail, also by necessity.
Bad technologists think imprecisely and politically and bridge the cultural gap more easily.
Haskell crushes imprecision of thought. (Enterprise Java encourages it; just use Object and call it a day.)

104 of 157

Selling (anything) to the business (4)

Focus on shared wants.

Business wants quality products, engineers want quality tools and to write quality code.

Establish positional equality.

Subordinate and you won’t be taken seriously. Dominate and you won’t be liked or trusted.

Teach, don’t sell.

It’s much harder, but if your product is excellence, information is your ally

105 of 157

Selling (anything) to the business (5)

It shouldn’t be that hard! If people can make millions selling crap...

106 of 157

Sand Hill Road gave this guy $25 million in seed funding to “scale up” fecal production.

107 of 157

Selling (anything) to the business (6)

It shouldn’t be that hard! If people can make millions selling crap…

… then we should be able to do OK selling excellence. A good product is an advantage.

108 of 157

Focus on shared wants

Haskell makes code extremely fast, robust and secure, while remaining highly productive for programmers. Its type system allows construction of very reliable programs, to an extent nearly impossible to meet in existing languages (e.g. Java, C++). Its compiler is world-class and its programmers are excellent.

110 of 157

Focus on shared wants

111 of 157

Focus on shared wants (2)

As important as the merit of a language is the quality of the average programmer.

Yes, there are great Java programmers.

112 of 157

Focus on shared wants (2)

As important as the merit of a language is the quality of the average programmer.

Yes, there are great Java programmers. It’s hard as hell to find them.

113 of 157

Focus on shared wants (2)

As important as the merit of a language is the quality of the average programmer.

Yes, there are great Java programmers. It’s hard as hell to find them. Oh, and they’re incredibly expensive.

114 of 157

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$$

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$+

$$$$

Java engineers: price by percentile ability.

Haskell engineers: price by percentile ability.

Haskell engineers seem more expensive.

115 of 157

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$$

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$+

$$$$

Java engineers: price by percentile ability.

Haskell engineers: price by percentile ability.

Haskell engineers seem more expensive… UNLESS you compare apples to apples

116 of 157

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$$

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$+

$$$$

Java engineers: price by percentile ability.

Haskell engineers: price by percentile ability.

Haskell is a smaller, more elite community.

117 of 157

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$$

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$+

$$$$

Java engineers: price by percentile ability.

Haskell engineers: price by percentile ability.

Haskell is a smaller, more elite community.
An engineer familiar with both will be more productive in Haskell.

118 of 157

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$$

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$+

$$$$

Java engineers: price by percentile ability.

Haskell engineers: price by percentile ability.

Haskell is a smaller, more elite community.
An engineer familiar with both will be more productive in Haskell.
Haskell forces you to improve (sometimes, brutally).

119 of 157

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$$

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$+

$$$$

Java engineers: price by percentile ability.

Haskell engineers: price by percentile ability.

Haskell is a smaller, more elite community.
An engineer familiar with both will be more productive in Haskell.
Haskell forces you to improve (sometimes, brutally).
Haskell is designed around the needs of lifelong programmers; enterprise Java is a world where everyone wants to be mgmt. by 30.

120 of 157

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$$

25%

50%

75%

90%

99%

99.9%

$$+

$$$

$$$+

$$$$

Java engineers: price by percentile ability.

Haskell engineers: price by percentile ability.

Haskell is a smaller, more elite community.
An engineer familiar with both will be more productive in Haskell.
Haskell forces you to improve (sometimes, brutally).
Haskell is designed around the needs of lifelong programmers; enterprise Java is a world where everyone wants to be mgmt. by 30.
Decent Java engineers create bidding wars every 2 years, because Java jobs are a dime a dozen.

121 of 157

In case it’s not clear...

The Haskell engineer is a bargain, relative to a comparable Java engineer.

122 of 157

Establish positional equality.

If you position yourself as a subordinate, no one will listen to you.

I’ve seen engineers sink their own initiatives with the “...but it was strictly a weekend project” retreat.

123 of 157

Establish positional equality.

If you position yourself as a subordinate, no one will listen to you.

I’ve seen engineers sink their own initiatives with the “...but it was strictly a weekend project” retreat.

To a businessman skilled at negotiation, that suggests that the project was not important.

124 of 157

Establish positional equality. (2)

If you position yourself as a dominant, no one will trust or like you.

Non-technical people are bad at evaluating technical work and people, but that doesn’t make you smarter.

125 of 157

Establish positional equality. (2)

If you position yourself as a dominant, no one will trust or like you.

Non-technical people are bad at evaluating technical work and people, but that doesn’t make you smarter.

It makes you politically weak against charlatans with better social skills.

126 of 157

Establish positional equality. (3)

Why is there so much mediocrity (SCRUM, enterprise Java) in software?

127 of 157

Establish positional equality. (3)

Why is there so much mediocrity (SCRUM, enterprise Java) in software?

Answer: It’s non-threatening (if expensive) to have 100 mediocre engineers instead of 5 good ones.

128 of 157

Establish positional equality. (3)

Why is there so much mediocrity (SCRUM, enterprise Java) in software?

Answer: It’s non-threatening (if expensive) to have 100 mediocre engineers instead of 5 good ones.

So avoid the tribal “I’m smarter than you” air. Business people aren’t idiots; many trust idiots, but you’ve probably trusted an idiot or two in your life, too.

129 of 157

Establish positional equality. (4)

Represent yourself as an equal, working together toward a shared goal. For Haskell, this could be:

high-performance, scalable software.
attracting a high level of talent to the company.
less time spent on debugging and maintenance.
a fast pace of development (once the language itself is learned).
improved engineer morale.

These are all things that progressive business people want!

130 of 157

Teach!

You’re not just a programmer or an elite problem-solver. If you’re worth your salt, you’re also a teacher.

It’s not enough to build the asset, commit it to version control, and write a few unit tests. Teach people how to use it.

131 of 157

Teach! (2)

If you want to convince someone of something (such as the value of your software) you cannot expect them to do the hard work of convincing themselves.

There is no shortcut. You have to do the legwork and make your case obvious, and the material accessible.

132 of 157

This also means...

(sorry)

133 of 157

The future...

Author: Brian Kammerzelt (http://clayimaging.smugmug.com/)

134 of 157

Some technical history

1950s-1980s: MIT / Bell Labs Culture.

135 of 157

Some technical history

1950s-1980s: MIT / Bell Labs Culture.

Golden Age of R&D (Bell Labs, Xerox PARC).

136 of 157

Some technical history

1950s-1980s: MIT / Bell Labs Culture.

Golden Age of R&D (Bell Labs, Xerox PARC).
Strong on quality / correctness. Invented C, Lisp, Haskell, machine learning, Unix.

137 of 157

Some technical history

1950s-1980s: MIT / Bell Labs Culture.

Golden Age of R&D (Bell Labs, Xerox PARC).
Strong on quality / correctness. Invented C, Lisp, Haskell, machine learning, Unix.
Tightly bound to the military-industrial complex.

138 of 157

Some technical history

1950s-1980s: MIT / Bell Labs Culture.

Golden Age of R&D (Bell Labs, Xerox PARC).
Strong on quality / correctness. Invented C, Lisp, Haskell, machine learning, Unix.
Tightly bound to the military-industrial complex.
Valued age and experience but developed tenure culture.

139 of 157

Some technical history

1950s-1980s: MIT / Bell Labs Culture.

Golden Age of R&D (Bell Labs, Xerox PARC).
Strong on quality / correctness. Invented C, Lisp, Haskell, machine learning, Unix.
Tightly bound to the military-industrial complex.
Valued age and experience but developed tenure culture.
Thought leaders did a poor job of selling society on their importance and their work. (Profs. who hate teaching.)

140 of 157

Some technical history

1950s-1980s: MIT / Bell Labs Culture.

Golden Age of R&D (Bell Labs, Xerox PARC).
Strong on quality / correctness. Invented C, Lisp, Haskell, machine learning, Unix.
Tightly bound to the military-industrial complex.
Valued age and experience but developed tenure culture.
Thought leaders did a poor job of selling society on their importance and their work. (Profs. who hate teaching.)
Fate: Let to wither and die (see: academic job market).

141 of 157

Some technical history (2)