Abstract
If you’re in charge of a team of software developers—and I hope this isn’t going to shock you—it’s important to keep them happy.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
It’s true: science says so. See “Software developers, moods, emotions, and performance,” Graziotin, Wang & Abrahamsson— https://arxiv.org/pdf/1405.4422.pdf
- 2.
According to Department of Labor statistics from 2016— https://www.bls.gov/news.release/tenure.t06.htm
- 3.
- 4.
Although to be fair, some developers would prefer to listen to music while they code rather than sit in silence, so you’re going to have that problem with those ones anyway.
- 5.
I’ve never known anyone who was at the top of their game at 2pm. That post-lunch lull has always seemed to me to be the best time to schedule those tiresome-but-necessary meetings, because there’s no hope of getting anything done that requires actual concentration until the brain wakes up from its siesta.
- 6.
See Chapter 3.
- 7.
Two sorts that are particularly painful are the ones with a stakeholder where you have to explain that a deadline will not be met because the team can’t be coerced into working any faster, and the ones with a reluctant team member where you have to try to convince them to work longer hours because you know the entire company might genuinely go bust if they don’t, but you don’t want to burden them with that knowledge in case it completely freaks them out.
- 8.
In other words, doing something very similar to what happens in the QA process for new features as described in Chapter 5.
- 9.
Note, developers often fall into the trap of assuming that all bugs must be fixed. In actual fact, as ugly as it may feel, often it makes more commercial sense to ignore a low-impact bug and focus instead on shipping new features. The prioritization of fixing bugs vs. building features should be done by a Product Owner, or someone in a similar role, on a case-by-case basis.
- 10.
This database could be as simple as a spreadsheet, or a wall of Post-it notes.
- 11.
I actually did some research into this. Back in 2016 I surveyed 67 professional software developers, and asked them whether they thought the last code base they inherited was good, ok, or bad. Among developers who self-identified as senior, and therefore would be expected to have the most refined aesthetic sense, less than 4% thought the last code base they had inherited was good. You can read up on my findings at https://blog.makersacademy.com/code-awful-a216921dacba .
- 12.
I once came across a small company where the technical team had convinced the (non-technical) CEO that it was imperative for them to rewrite from scratch the same product three times in three years. They spent so much time rewriting that they never managed to add any new features. Because their core product was free to use, it meant they never managed to build any of the “premium” features they could actually make money off, and the company inevitably went bust.
- 13.
Modular code is also good for other reasons—see Chapter 5.
- 14.
You can read their justification at: https://redditblog.com/2008/06/17/reddit-goes-open-source/
- 15.
- 16.
See the previous chapter.
- 17.
You can force a set-in-their-ways coder to adopt something new and let them do a half-assed job with it, forever trying to bend it back towards what’s familiar to them and giving rise to some Moreau-ean hybrid abomination that’s the very worst of every world. Take my word for it, but don’t ask me to talk about it, because what I’ve seen gives me the shivers every time I think back to it.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2017 Patrick Gleeson
About this chapter
Cite this chapter
Gleeson, P. (2017). Keeping Coders Happy. In: Working with Coders. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-2701-5_9
Download citation
DOI: https://doi.org/10.1007/978-1-4842-2701-5_9
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-2700-8
Online ISBN: 978-1-4842-2701-5
eBook Packages: Business and ManagementApress Access BooksBusiness and Management (R0)