Managing Developer Stress
Some years ago I was interviewed by Oliver White at ZeroTurnaround about the topic of developer stress. In their brief survey they ascertained the top 5 developers stresses of the time:
- Making deadlines
- Application performance issues
- Is my code good enough?
- What new stuff do I need to learn?
- Did I do X in the best way?
I wrote back privately to Oliver at the time but thought it would be interesting to rehash the topic here as it covers some of the early Agile thinking at the time and serves as a good reminder.
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% there is not done)
- Factor in contingency
- 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.
Some example tooling that can help:
- Simple Lean/Kanban style planning with sticky notes and a whiteboard
- Electronic versions of the above (e.g. Atlassian’s Greenhopper, Trello, GitHub Issues)
- 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)
Application performance issues
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 (Our CTO and 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’t recommend Kirk’s course enough!
Is my code good enough?
Is my code good enough? 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, 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 of course much 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.
What new stuff do I need to learn?
There’s always the fear of being left behind, can you as a developer guess what’s going to big next? If your technology CV is out of date you might struggle to find that next job!
Take a deep breath 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, deploy that all 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, 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
At the end of the day, our industry is still re-inventing the wheel, 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…
Did I do X in the best way?
This is also 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 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. Worried that Jboss might not support AMQP? Spend a day upfront proving that it does or doesn’t!
Martijn (CEO) and the jClarity Team!