Finding Value in One’s Work
Over the years, I’ve seen some accomplished software developers leave their positions to pursue managerial positions or even completely different careers. Because this is often different than what I see from the ‘typical’ software developer, I often ask what led to the change. In some cases, it’s as simple as responding to pressure to take a management role to ‘justify’ their higher salary. In other cases, it’s developers who are tired of learning new things at the pace often required in software development. The most common reasons that I hear from these folks have to do more with boredom or loss of interest in the work itself. These are typically people who are not being sufficiently challenged anymore and often are putting time and effort into something they perceive as having very little or no value.
Some of the lowest points in my career in software development have been when a project or task that I’ve put significant time, energy, and creativity into is terminated or significantly reduced in scope. Although I’ve generally received the same monetary remuneration as I would have for a successful delivered product into getting to that point, the feeling in such cases is more of discouragement than of satisfaction. Although compensated for my time and effort, it still hurts to think that the time and effort have no lasting value.
Cancelled assignments or tasks are not the only source of disillusionment related to not finding value in one’s work. Working on unnecessary tasks or ‘busy work’ can be almost as difficult on a software developer. There always seems to be plenty of truly useful and contributory things to do and this makes it even more difficult to work on things that seem to have much less or no value.
Process
One of the biggest perceived enemies of software development productivity from the perspective of many software developers is onerous process. In Process Kills Developer Passion, James Turner writes, ‘the blind application of process best practises across all development is turning what should be a creative process into chartered accountancy with a side of prison.’ Turner makes a point that I’ve been making to anyone who will listen for the last few years: not all developers are equal and they shouldn’t all be treated exactly the same way. Many projects make the mistake of assuming the ‘least common denominator’ and enforcing processes on everyone to accommodate that ‘least common denominator.’ Turner articulates this more colourfully than I do: ‘companies need to start acknowledging that there is a qualitative difference between developers. Making all of them wear the same weighted yokes to ensure the least among them doesn’t screw up is detrimental to overall morale and efficiency of the whole.’
I think most of us who have worked in the industry for some time do realize that a degree of process is justified and even beneficial. The degree depends on the project, the skills and experience of the developers, and the size of the team. There are many benefits to standardization and code conventions. There are similarly well-advertised benefits to unit testing and other quality processes. That being stated, the best developers can ascertain which processes fit which situations best and which don’t fit certain situations as well.
Meetings
I once was told, ‘It takes a very good meeting to beat having no meeting at all.’ This is often very sage advice. However, I have seen situations where a short, well-run meeting provides tremendous benefit. Most meetings waste peoples’ time, especially if the meeting organizer starts late and ‘fills the time.’ The best meetings start promptly and address only what must be addressed. I’ve worked with people in the same office who will not talk or coordinate unless forced to by a third party and this is often facilitated by a short, informal meeting. Similarly, difficult design decisions and architecture trade-offs can be discussed effectively in meetings. It seems to be the natural tendency of meetings to go long, into the weeds, and become very dissatisfying as they waste developers’ time. Well-run meetings, however, can have the opposite effect: they can help developers have clearer direction and be more efficient in working together as a team.
I previously blogged on one tip for effective software development meetings. Taking notes in a meeting, especially in a way such that participants can see them live as they are taken, has numerous advantages. These include getting everyone on the same page at the same time, documenting major decisions for future reference, and in having material to send those who did not make the meeting.
Not Every Idea Should Be Implemented
Not all ideas are created equal. Developers are often understandably impatient when they are coerced into implementing poor or useless ideas. This can be especially painful when the idea is counterproductive. It is difficult to justify to oneself spending time on something that will almost certainly never be used or, even worse, might make the user experience worse.
Scripting Tedious Tasks
Many developers look for ways to script especially tedious tasks rather than performing the tedious tasks manually even if the time spent writing the script matches the time that would have been spent completing the tasks directly. This is perhaps one of the best examples proving that most developers loathe tedious tasks. There are often many positives to this typical developer reaction to tedious tasks. First, it often turns out that the tasks that we thought we’d only do once need to be implemented again. It may be that the script can be applied to a similar situation or it may be that the script needs to be applied against a new set of input. Second, the act of writing a script provides more value than simply getting a task done; it can lead to improved familiarity with the scripting language and can sometimes provide a nice codification of the problem at hand.
Convention over Configuration (Configuration by Exception)
A major development in the software development industry in recent years has been the rapid adoption of convention over configuration (configuration by exception) in various languages and frameworks. The idea here is that developers need provide configuration information only when the configuration is different than the configuration provided by default (conventional configuration). This saves developers time and tedious effort to provide configuration details for common tasks.
Less Boilerplate Code
Another recent trend in software development is the focus on reduced boilerplate code. Convention over configuration has helped with this. Many of the alternative JVM languages tout less boilerplate code as one of their advantages over Java. For example, some Java developers feel that Groovy’s property support is one of its nicest features. Even Java has embraced reduced boilerplate code in multiple areas. One of the features that make many libraries and frameworks popular is the ability to write and maintain less boilerplate code thanks to the framework or library. In cases where neither language nor framework has reduced the boilerplate code, IDEs and code-generators have been used successfully to implement boilerplate code with less tedium and with less risk. Writing boilerplate code is not only tedious, it can be easier to make mistakes when it must be implemented by hand.
Some Things Are Worth More Than They Appear
One mistake I have made multiple times and seen other developers make is to decide that a particular task is useless or of little value. I’m often correct in my identification of worthless or low-value tasks, but on rare occasions I am surprised when a seemingly useless task provides some real value or a tangible benefit. Observing why this is the case helps me refine my ability to differentiate between worthwhile and worthless tasks. Such situations have also reminded me to keep an open mind on the value of new ideas until I’ve thought carefully about the action and its good and bad ramifications. One of the most important things a software development manager can do is to assign worthwhile tasks to developers and to ensure that they understand the value in all assigned tasks.
Execution Matters
Even an idea with potential for value can lead to no or dramatically reduced value if not implemented correctly. For example, incorrect application of unit tests can dramatically reduce the ratio of value to cost for implementing and using unit tests. Similarly, code reviews and use of code quality tools can provide great value when executed correctly or provide much less value for the cost if executed incorrectly.
Conclusion
Most of us do better work when we enjoy what we do and when we perceive that what we do has value. Worthless or low-value tasks are more likely to be seen as tedious and are more likely to not be done well. Developers will be happier and more motivated when they do not have worthless tasks forced upon them.
Don’t forget to share!
Reference: Software Developers Hate Worthless Tasks from our JCG partner Dustin Marx at the Inspired by Actual Events blog.
