Is your inner geek feeling a bit stressed out?
In our preliminary release of Developer Productivity Report – Part 1: Developer Timesheet, we asked 1000+ developers how they spend their work week, and got some pretty clear estimates… (SPOILER ALERT: Did you know that the average developers spends only 3 hours per day writing code?)
In Part 2 of our ongoing survey on what makes developers tick (hint: it would rock more if you added your experiences too!), we take a peak into the things that stress out devs, and keep them up at night.To get some valuable perspective on the matter, we’ve invited Martijn “The Diabolical Developer” Verburg, Java community leader, speaker and CTO at TeamSparq, to share his thoughts on Developer Stress. So, let’s get started.
“Usually I sleep like a baby”
The good news is that the most common response to What keeps you up at night? was “Nothing. I sleep like a baby”. But it was followed very closely by some aspects of development that warrant a deeper look.
The following 5 stressors were listed as the top things keeping developers up at night.
Making deadlines – 25.00%
Application performance issues – 24.10%
Is my code good enough? – 23.70%
What new stuff do I need to learn? – 23.50%
Did I do X in the best way – 22.50%
Developers are quite concerned that their code is correct, innovative and following best practices. It would seem that training and continuing education is also an important factor that gets a lot of thought. What can companies and teams do to make sure devs are able to feel confident about their code, level of expertise and understanding of best practices?
We asked Martijn Verburg to comment on each of these five stressors, as only a “Diabolical Developer” could ;-)
Extended Interview with Guest Geek Martijn Verburg
ZT: Hey Martijn, thanks for being here with us.
MV: It’s a pleasure. I was just thinking to myself, “Hmm, I’ve got sooo much extra time these days, I wonder if anyone wants to interview me!”
ZT: Wow, really?
MV: Nah, I’m totally slammed actually.
ZT: Nice one. So Martijn, as a simple marketing droid I was surprised to see that developers are primarily concerned about Making Deadlines. Isn’t that something The Suits should be worrying about more?
MV: Managing deadlines is something that a lot of developers feel that they cannot learn or is out of their control (e.g. Their manager tells them what the deadline is). However, managing deadlines is a skill that can definitely be learned! For example, developers can learn to:
- Scope work into manageable (e.g. 1 day) chunks
- Define what _done_ means (95% is not _done_)
- Factor in contingencies
- Communicate risks and issues to stakeholders
- Learn to prototype ideas to keep the overall project flowing
There are a number of tools to assist you in managing the scope and communication around deadlines, but always remember, “Whatever they tell you, it’s a people problem”, so developers should look at their communication and expectation setting first.
ZT: I think that developers can definitely take steps to empower themselves a bit more in this process. Can you recommend any specific tools tools or techniques for managing deadlines better?
MV: Absolutely. For example:
- Simple Lean/Kanban style planning with sticky notes and a whiteboard
- Electronic versions of the above (e.g. Atlassian’s Greenhopper)
- BDD style tests with an electronic wallboard (therefore the whole business can see exactly where progress is at)
- A publicly shareable issue tracker that tracks timings (e.g. Atlassian’s JIRA)
ZT: I’m sure devs will find that helpful. Next, why do you think Performance Issues would rank so highly on the list of developer stress?
MV: Performance and performance tuning is terrifying for most developers because they have no idea where to start. Modern software applications are so complex that it can feel like finding a needle in a haystack. However, performance and performance tuning is actually a _science_, not an art and definitely not guesswork. Kirk Pepperdine (one of Java’s foremost expert in this field) always hammers home the point “Measure, don’t guess”.
By following the sort of scientific methodology that Kirk and others like him teach, you can systematically track down and fix performance issues as well as learning to bake performance in right from the beginning. There is a host of tooling that can assist in this area as well, but it’s the methodology that’s truly important. I can highly recommend Kirk’s course (www.kodewerk.com – he runs courses worldwide, not just in Crete, so drop him a line).
ZT: Have you ever been asked if you think your Code is Beautiful (or simply “good enough”)?
MV: This is a question that all developers secretly fear. The fact is you can’t definitively state what good code is! The Softwarecraftsmanship folks will beg to differ here ;-). Define what Clean Code is! At the end of the day there are many differing opinions on what defines ‘good code’. However, I’d suggest that there are some clear traits of what is commonly perceived as good code:
- It’s broken up into small classes/methods/blocks each that perform one thing and one thing well
- Some level of interface is used so alternative implementations can be used
- The code is easy to test against
- You can ascertain by the naming used in the code, what the code is used for, e.g. it’s problem domain
- Common language pitfalls are avoided – type1, the sorts of things that static code analysers warn you against
- Common language pitfalls are avoided – type2, the sorts of things you pick up in Josh Bloch’s “Effective Java” title.
- There’s more, the list is fairly long.
So my advice is to try to follow the better practices out there (note I avoid using ‘best practices’, horribly overloaded term), make sure that you’re using the static code analysis tools, try to practice TDD and above all else get a 2nd pair of eyes on the code, preferably via Pair programming to begin with.
ZT: Is it fair to suggest that when devs worry about their code being good enough, it might speak to their next concern about Learning New Stuff?
MV: There’s always the fear of being left behind, can you as a developer guess what’s going to be big next? If your technology CV is out of date you might struggle to find that next job!
Take a deep breathe and relax. Most new technologies are simply short lived fads and it’s impossible to keep up with everything!
There’s no way a developer can stay up to date with the latest Java libraries, learn Scala, pick up Clojure, hack some iOS, and then deploy all that to the cloud on a NoSQL distributed grid environment. See what I mean?
The trick is to identify trends. Cloud is a trend, so you should learn about the principles behind it, but don’t sweat if you haven’t learned to deploy to the 5+ different Java cloud providers out there today. Functional programming is a trend, so learn _why_ (hint – Multi-core processors and concurrency) it is and see if it’s something that you need to learn about now or whether you can wait a few years. The same goes for any new craze you read about or hear at a conference.
At the end of the day, our industry spends a lot of time re-inventing the wheel, and we have memories like goldfish :-). For example, some of the older hands are certainly chuckling away at this new functional fad, they were doing it over 20 years ago…
ZT: I think it’s fair to say that any professional will be concerned about doing X in the “Best Practices” way. You mentioned above that you dislike how “best practices” is poorly used. As a long-time coder yourself, how do developers feel about this?
MV: This is definitely related to developer concerns over “beautiful code”, but I’m going to assume this is more of a fear at the macro design level. Developers can fear that if they chose the wrong web framework or picked the wrong app server or designed the n-tier architecture wrong that they’re doomed.
A common problem here is that developers aren’t standing on the shoulders of Giants, most problems are not actually that unique and there is a wealth of free advice on sites like programmers.stackexchange.com, on mailing lists, in books, at conferences and of course at your local user groups.
Another common problem is in the prototyping space, not enough developers prototype the risky parts of their projects soon enough. Are you worried for example that JBoss might not support AMQP? Well, spend a day upfront proving that it does or doesn’t!
ZT: Dude/Sir, thanks a lot. It’s always a pleasure to chat with you Martijn. I know we’ll see you speak (along with Kirk Pepperdine and others) at Geekout 2012 in Tallinn June 14-15, but before then the ZeroTurnaround team will be speaking and exhibiting (and drinking beer) in Madrid for Spring I/O Feb 16-17, London for QCon London March 7-9, and Krakow, Poland March 19-21 at 33rd Degree. Hope to catch up with you, and our dear readers there!