Enjoyment Driven Development
IT market is on the rise, things get digital and thus the demand for developers grows. I see lots of job posts and that’s how a typical one looks like:
- Foosball in the meeting room
- Pension plan
- 30 vacation days
- Gym membership
- Free snacks in the kitchen
That praises everything around the job but not the job itself. Actually, it only adds to that public image of programmers having a lot for doing a little. This can indicate IT management is slacking off — they exploit HR guys (buy this, buy that) instead of setting up IT processes to make developer work pleasant.
Here I present a job post that would attract me, and why.
“We have a large codebase, and it loads in seconds”
Imagine a developer sends a medium-sized pull request. Another developer jumps to review it and wants to try a nicer function implementation or some redesign. It’s hard to do in the head, so they need to actually check out the branch and play around.
And then the reviewer recalls: “Oh but it will take me 15 minutes to switch the branch and reload the code”. What will they do? Nothing — because it’s a pain, and humans usually avoid it. At best they will point to a few bad variable names or typos in the PR and finish. A potential improvement dies and further stuff is at risk of being built on top of bad code.
If there are no processes to discourage things like adding another project to the solution that is already hard to load for an IDE, or writing magical scripts to make things run locally, the code becomes a swamp.
“We have hundreds of unit tests, and they run fast and pass locally”
That also comes from human nature — we tend to conserve the effort. If it is hard and long to run the tests locally, people won’t run them often. And they won’t write many of them or design to have them. TDD won’t be applicable.
If management forces solutions like “just increase timeouts in tests to make them less flaky”, the project is doomed. Also, a few minutes of waiting for the test run is not enough to switch to another assignment but it is an ideal time frame to answer some recruiters on LinkedIn.
“We follow the industry”
By that I don’t mean Hype Driven Development, but rather having processes to regularly update existing tools and frameworks and leverage their new capabilities. No need for bleeding edge things (there’s often not enough guidelines for them), the latest LTS will suffice.
And there should be a similar process for deployment pipelines. It hurts when things compile locally but fail to do so on build servers and one has to redo everything using older syntax. At some point people stop caring about those new features as they don’t want to mess around with ancient build system.
“We regularly address the tech debt”
Tech debt is not automatically a bad thing and sometimes is necessary. But like with credit in the bank, when one takes it, they should have a plan to pay it back. In IT this also means setting up a process for that, e.g. getting rid of a debt’s part each sprint or devoting every Nth sprint entirely to the debt.
Failing to do so brings so called Software Entropy — new features take more and more time to implement. A less obvious outcome is that those guys who still want to do things properly often break deadlines as there is no hope to redo things later. They are often blamed for that, and so they just go, leaving behind a team of demoralized members.
“We give time to learn”
Even if a job promises cool tech (the most important job factor), it doesn’t mean people will be able to learn it. I’ve heard management saying “this X thing is like that Y thing you know, also we have already code using X, just copy it from that repo and be done”. Often that leads to using deprecated APIs, but it also can end up in utilizing wrong tools for tasks and getting into troubles.
Management should spare time for developers to learn every new thing they use, hours or even days. This helps them to exercise learning skills, so important in IT. That’s also an opportunity to set up knowledge sharing in the team — there can be a practice to briefly present new information to others.
If programmers suffer during development, software suffers as well. Create a great technical environment — and maybe there won’t be a need for free candies in the office.
