It really doesn’t take much to keep developers happy – fast machines, a steady supply of (good) caffeine, interesting work on moderately new technology, comfy chairs, managers that leave well enough alone…Joel Spolsky‘s Field Guide to Developers anyone? Google appears to be nerdvana but I swear Rob Walling is channeling Scott Adams with his Nine Things Developers Want More Than Money (via Erik’s Linkblog from Friday). Seriously, there are more than a few great quotes in there that make me think I’ve worked with him before (anyone else smell some similarities?)
There is abundant goodness but I wanted to highlight a few bits. First regarding challenges:
Faced with the right type of challenge many developers will not stop until it’s fixed, especially if it requires a particularly creative solution. Faced with the wrong type of challenge and they’re back on instant messenger describing the toast.
I’ll never forget an experience I had a few years back, right around this time of year. It was the Wednesday before Thanksgiving and another developer and I were grinding through an issue. As was the custom at the time, after lunch the manager came around and told everyone they could head home. We nodded politely. About an hour later he came back to remind us about the early dismissal. An hour later he came over and all but ordered us to leave (we did…but not before fixing the problem).
A recent experience with a large web retailer’s customer support reminded me of the importance of having a voice but Rob really nails it:
When a developer speaks, someone should listen. When several developers are saying the same thing, someone should listen and act…quickly.
Nothing is quite as frustrating as *knowing* something is wrong, saying so and being ignored. I’m not sure what happens during the management lobotomy but many of them forget how to listen (that’s assuming any of them ever possessed that particular skill). Marriage tip – listen. It sure would have saved me some grief over the years.
When I was in school I was really naive – I assumed that people were judged on results not by how closely they followed some silly process. Boy was I wrong. So many companies value process over people to point where:
When I got my next full-time job it felt like I was dragging 50-pound weights. For every page I wanted to build I had to call a meeting with six people. Any change to the database required three approvals. It was nuts, and applications took 5x longer to build. Talk about frustrating.
Frustrating is an understatement. I’m amazed how far some companies take this and I have to wonder what would happen to a certain class of employees if meetings were reduced and we actually, you know, empowered folks to do real work. Yeah, that’ll never fly.
So I didn’t bother to actually take the quiz (take a look at Joel’s too) but I’d be curious to know how your company scores… Great post from a blog I’ll have to check back on!
I began my collegiate career as a Chemistry major – the shinny new chem center combined with the fact that a degree in Computer Science required more than a minor in math got me thinking that mixing known carcinogens was as good a way as any to spend four years. But then I hit O chem and the powers that be reduced the math content significantly so off I went to the land of compilers. Needless to say, I took a rather, ahh unique, path through the major and while the finer points of circuit design have been lost to the ether, bits of my chemistry training still stick. For some reason, I still remember when the concepts of entropy and enthalpy were introduced during that first year chem class…
Needless to say, I was taken in by Neal Ford‘s Entropic Software post. Neal uses an interesting example to discuss the similarities between the technical definitions of entropy and information to support his central tenant that “software breeds entropy”. He continues by comparing the design of Unix and it’s history of “mini languages” to Windows and its (I’ll say it – clunky) approach to interoperating (I couldn’t help but think of Martin Fowler’s keynote from RailsConf along with his discussion of DSLs). The moral of the story? Keep it simple…ah you know the rest.
The nature of the universe is towards disorder (told you I remembered something from that chem class) and I have to agree with Neal that software tends towards complexity. Some of this is our fault – for whatever reason people in this line of work reallllly like complexity (often for it’s own sake) but the ephemeral nature of software doesn’t help (c’mon how many of us have added just “one more feature” since it wouldn’t be _that_ hard). Though he doesn’t explicitly mention it (until the comments) part of why Rails rocks is that it adheres so strongly to the principle of simplicity.
While I certainly don’t know *what* technology will be the king in five years (even if I did I’d keep it quiet until I was able to write the definitive book on the subject) it is clear that Rails has had a major impact on how we write software. As I mentioned in my JavaOne recap, everyone is trying to “prove” that their approach is just as easy as Rails (or they try point out how it isn’t enterprisey enough). Neal’s dead right – software wants to be complex and it takes a concentrated effort by engaged developers to do that. Let’s hope more of us are inspired by the diligence of the Rails team towards this end.