Developer Motivation and Satisfaction

Photo by pdam2

I've been to lots of management trainings, each new company feels the urge to send me to a several days workshop. One of the topics in each of those workshops is employee motivation and satisfaction.

But after years I reckoned developers do not need to be motitvated, they are motivated when they start working - otherwise you wouldn't have hired them, would you? They are actively demotivated. Companies need to stop demotivating them. The Harvard Management Update writes:

Most companies have it all wrong. They don't have to motivate their employees. They have to stop demotivating them. The great majority of employees are quite enthusiastic when they start a new job. But in about 85 percent of companies, our research finds, employees' morale sharply declines after their first six months—and continues to deteriorate for years afterward.

On to job satisfaction which is linked to motivation. The economy is recovering, I get more calls from head hunters. Head hunters are the angst of many IT-managers, because you lose your best to them. Losing a good developer is intrinsically connected to developer statisfaction and motivation. Motivated developers are satisfied. Satisfied developers won't go with head hunters.

There are four stages of developer - and employee - satisfaction:

  1. Satisfied and motivated
  2. Passive, undecided
  3. Passive, will react to headhunters and good offers
  4. Activly seeks a new position

Satisfaction levels can easily fall, there are a myriad of reasons. Maybe the biggest reason being demotivated at your job. If your company demotivates developers, with

  • Technical reasons like no recent hardware, inadequate tools and a frustrating enviroment. I've written about those in 7 Bad Signs not to Work for a Software Company or Startup
  • Micro-Management and drowning creativity
  • Not listening to them
  • From the above quoted article in the Harvard Business Update:

    Excessive levels of required approvals, endless paperwork, insufficient training, failure to communicate, infrequent delegation of authority, and a lack of a credible vision contribute to employees' frustration.

no wonder satisfaction goes out of the door. Sometimes those 4 levels of satisfaction can be seen in public and are general phases in a company live. Everyone moving to Google (1). Then people who get snatched from Yahoo by Google (3). Then people are leaving (4). Amazon has lots of ex-amazoners, people have been leaving Google, and of course Yahoo.

As a developer, in which stage are you? As a manager you should have a clear understanding of the stages in your company and in which one your developers are. Misunderstanding employee satisfaction makes your company vulnerable to head hunters. Stop demotivating!

Clojure vs Scala, Part 2

Photo by PhillipC

There are two languages stirring up the Java World: Clojure and Scala. Clojure a Lisp dialect on the JVM, powerful and pure and the Scala language a tight integration of object and functional programming. Which should you learn? Matt is wondering:

The two leading candidates in the JVM/concurrent/multicore arena seem to be Scala and Clojure. [...] Scala is a multiparadigm language, supporting both object-oriented and functional constructs. It is statically typed, yet offers very nice type inference. Clojure, on the other hand, is a functional Lisp derivative with almost no OO constructs that is dynamically typed. Both are designed to enable concurrent programming. Which one do I choose?


Clojure as the first contender to the Java throne came out of nowhere and conquered the blogosphere in a storm.

Clojure [...] is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. [...] Clojure provides easy access to the Java frameworks [...] Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system.

There is some traction with companies already, FlightCaster who predict flight delays use Clojure for backend code:

The research and data heavy lifting is all in Clojure.

Some obvious reasons that speak for Clojure:

  • Big momentum, mainly in the dynamic language (Ruby) avant-garde and in Lisp circles
  • LISP community
  • STM, software transactional memory, an easy way to share data
  • Very clever immutable datastructures
  • Well thought Seq concept, tightly integrated with Java

Depending on your standpoint there are some downers with Clojure:

  • no objects (might not be a problem for you)
  • hard to read for C tradition developers, this does include the many (), prefix notation and functional programming style in Lisp
  • no Lisp skills in most companies, harder to recruit than Java or Scala

Clojures Java Integration

Although it does not possess objects, astonishingly Clojure has excellent Java integration. This might be because one of the main arguments of Clojure it makes against other Lisp dialects is the Java plattform. So it does make a lot of sense of excellent integration.

  • Java methods as functions in Clojure
    (map (memfn charAt i) ["fred" "ethel" "lucy"] [1 2 3])
  • Collections in Clojure implement Collection
  • Functions implement Callable and Runnable
  • "Core abstractions, like seq, are Java interfaces"
  • "Clojure seq library works on Java Iterables, Strings and arrays"


Scala is the rising star on the JVM. James Strachan, the inventor of Groovy writes: "I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." Though one must admit the Groovy back than is not the Groovy from today. The question remains: What is Scala?

Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application.

The main reasons for using Scala:

  • Big momentum, mainly among Java developers
  • Java community
  • Has objects (might not be a plus for some)
  • Very powerful type system
  • Object oriented and functional integration

Some downers:

  • Functional programming can be difficult to understand for a Java developer
  • The type system is more complex than the Java one (might be a plus for you)
  • Actor concurrency in Scala is nice, STM feels more natural to lots of problems (shared state vs. agents), Akka could help
  • Scala is very powerful, some developers might shoot themselves into the foot

The biggest promise of Scala nevertheless is power and terseness. As I've showed in "Top 5 Things to Know About Constructors in Scala", Scala has much less boilerplate code. This example in Java:

 public class Foo() {
   private Bar bar;
   public Foo(Bar bar) { = bar;
   public Bar getBar() { 
      return bar; 
   public void setBar(Bar bar) { = bar;

can be written in Scala in one line:

class Foo(@BeanProperty var bar:Bar)

Which is important, to a degree that you should drop setter and getters if not needed. I wrote in "Go Ahead: Next Generation Java Programming Style":

If you have simple data holders or data transfer objects, don’t write boiler plate code with getters and setters. I know this is heresy in Java, but just use public fields.

Scalas Java integration

Scala has good, but compared to Clojure a rather basic integration. One can implement Java interfaces in Java, extend Java classes and vise versa. Scala isn't tightly integrated on the API side - only with some in this context clumsy, unneeded Meta-Programming with impliciets. Scala promises Clojure like Collection integration with Java in the future - we'll see. From the Java side things also do not look as nice, Scala classes and traits have lots of ugly named methods, until IDEs know how to deal with this, code completion is spammed by Scala.

As a side note, Groovy has also deeper Java integration that leverages the dynamic nature of Groovy. For example the "as" keyword.
With as closures or maps can easily be coerced to a Java interface. This goes beyond the Scala way of implementing interfaces.

def readable = { it.put("12 34".reverse()); 5 } as Readable

Nice, wish to have this in Scala - the map version if as will be hard to make play nice with static typing.


Andrew Glower wrote last year:

Is Scala or Clojure poised for stardom? Can two languages co-exist as stars or does one invariably outshine the other? If history is any indication, then I’d venture to guess that the answer is that both can’t be stars– just like both Groovy and JRuby aren’t stars. They co-exist and, in truth, divide the market and have followers with strong opinions on both sides. Thus, if I had to guess right now, I’d say that Scala has the edge with some good momentum.

I concur. The conclusion might not be what you want to hear. Draw your own.

Clojure has a lot of appeal to me, it looks so clean, the Java integration has such a pure feel, hard to describe. I do not buy the argument that Lisp is so much more powerful than e.g. Scala - so this doesn't influence me much. And Clojure as a Lisp dialect is way out of the mainstream. It will make it hard to recruit developers - do not listen to people who declare this a non issue. I've been recruiting Java developers for years, and it's hard. It's much harder for Clojure.

Scala isn't as pure as Clojure, not as en vogue. But it is pragmatic and powerful. It has a lot of momentum now and is easily learned by Java developers - at least by those that are open enough. The good ones usually are. The main promise and reason for Scala is how much less lines of code you need than in Java. Less code, less bugs, easier to read - to some extent - and faster to write, leading to higher productivity. Who doesn't need higher productivity with the same safety as Java?

Which should you use in your company? Daniel warns on Stackoverflow, in "Scala vs. Groovy vs. Clojure":

It's also a much more dynamic language than Java, in the sense that the language evolve. From the perspective of the language, that's a good thing. From the perspective of users who plan on having thousands of lines of code written on it, not so.

You need to decide on your own. Which would I use? Scala. Which should you learn? Both obviously.

What is your plan?

The James Iry Java Class

James Iry has posted a mind blowing article on his blog "ONE DIV ZERO" again. He is famous in Scala circles and beyond. As a tribute I present the strangest Java class, the James Iry Class (taken from his article):

public class Foo {
  public Foo foo(){ System.exit(1); return null; }
  public Foo bar() { return bar(); }
  public Foo fooBar() { throw new IllegalArgumentException(); }

7 Bad Signs not to Work for a Software Company or Startup

Photo by mundo resink

There is a job offer, you're on a job hunt or a headhunter calls you. With the ending recession this scenario becomes more likely again. What are signs that you should not sign up with a company?

As someone who did a lot of recruiting and talked to many developers, I've prepared a list of signs that would tell me not to sign up with a company.

  1. No Source Control:
    Source control systems (SCM) are essential to software development. Be it Subversion, Perforce, Git, Mercurial or any other. Without source control integrating the work from different developers and projects is a nightmare. As Joel says in the legendary Joel Test:

    But if you don't have source control, you're going to stress out trying to get programmers to work together.

    There are still companies without SCMs, don't sign up there.

  2. No top tools or only home brewed ones (IDE, Build System, ...):
    Without the right tools, you can't work. Depending on the programming language and enviroment, the company should use an IDE, debuggers, build systems that allow one-stop builds and professional deployments. Without the right tools, software development is a pain. If you're a professional, insist on professional tools.
  3. No business model or not enough money:
    If you interview with a startup, ask them how much money they have and how long it lasts. Do not hire with a company that has less than 6 months of money - they most likely won't make it. The same goes for a company without a business model. No income is high risk. If you're young and like to take risks, it can be a worthwhile journey though (see the y-combinator financing model). It might be fun, and it might be valuable for you, but you have been warned.

    Some further reading, especially when joining a startup, is the excellent article Guy Kawasaki’s 10 Questions to Ask Before You Join a Startup:

    How much money do you have in the bank? This is a simple question. You just want a number. If you’re told that “investors are ready to put in more” or “we have a line of credit,” beware because a promise of money isn’t the same as money.

  4. They don't let you talk to or see developers:
    During many years of recruitment, I've always been astonished how few developers wanted to see their working space and talk to developers. Talking to other developers will enable you too get to know a prospective company. If they do not let you talk to developers, don't go for the job.
  5. High turnover:
    A bad sign is high turnover. There is always a reason for it. Ask people in the industry about the prospective company. Ask during the interview, if the job is new or if you are a replacement. Casually ask developers how long they have been with the company. As Kate Lorenz writes in Six Signs to Run -- Not Walk -- From Your Job:

    After two weeks on the job, you are already halfway to becoming the employee with the most seniority. One of the biggest issues for human resources professionals today is employee retention. You will notice that most of the country's top companies have employees who have been around for years.

    Do not get a job at a company with a high turnover rate. Period.

  6. Hiring is mainly done by HR, not by developers/technical staff:
    If hiring is mainly done by a HR person, there will be lots of developers recruited only by HR. Most of the time, they have no clue about what a good developer looks like. If you want to work with good people - and you should, because it's the best way to learn - do not work for a company that doesn't do recruiting with technical staff. Bonus points for a company that also lets developers interview applicants.
  7. No decent hardware:
    A company should respect their developers. As with good tools, decent hardware helps developers to turn more requirements into working code. Developers therefor should have a decent PC (e.g. dual core 3Ghz, 4/8gb memory) and 2 22/24" screens. Bonus points for Macs. As shown in several studies, the easiest way to gain lots of productivity is two screens. A company that is not interested in the basics of productivity, is not worth working for. They will not respect you.

So - what about you? What are your signs that steer you towards a "No thanks" when interviewing with companies? I'd like to hear.

Thanks to @andreaskaiser @Tungano @mwessendorf @AgileArtem @Devgru @benjaminm @gjmilne for their input.

Update: Great post on 10 Startup Red Flags by Adam MacBeth