Modern Developers PLEASE STOP Making These 10 MistakesEach Year We Keep Making the Same Mistakes
Developers are great. They solve problems and generate value for companies. Awesome!
So, why are there mistakes which keep happening? Issues that new developers seem to keep coming up when new developers enter the profession.
Here are the themes that keep occurring as we take on new cohorts of developers. These are the mistakes that modern developers keep making.
Not communicating
Late delivery of a ticket? No real problem.
Late delivery of a ticket but you don’t tell anyone? That’s an issue.
This can encompass the “unhappiness” you feel as a gentle flower who doesn't get their wonderful opinions listened to by the rest of the team.
My opinions are great. They’ll see it someday. Right?
Slow feedback loops
When you get a PR comment, why not update your working practices? Then we wouldn’t need to repeat the same comments, which would be nice.
Why not update your attitude too?
Crunch at the end of a sprint
Leaving all of your work until the end of the sprint is not cool, man. Your work becomes rushed, and you don’t pull in further tickets into the sprint.
Just get the work done, where and when you can.
Code before understanding the problem
We all know that type of developer. The one who rushes in to solve the problem before they really understand what they are working to solve. It’s tiresome and their work creates rework and issues for everyone else in the team.
I bet the testers love this approach too.
Optimism
This isn’t about smiling in your stand-up on a Monday morning.
People associate The Secret Developer with glowering. No wonder as I don’t suffer fools gladly.
Over-planning
It might seem like this article is about giving software developers a rough time. Criticizing them for leaving things to the end of the sprint AND for over-planning isn’t fair. Neither is life.
That’s because planning at the expense of delivery isn’t helpful. That isn’t to say we shouldn’t be planning, but we should not be over-planning.
Some of my colleagues seem unable to plan their day properly.
Belief in technology
This isn’t about disbelief in technology and being some sort of Luddite. This is about a near-religious zeal that a particular technology will solve all problems. This is seldom true, so there is no real reason to go on about it all of the time in every technical meeting.
I wonder if my religious belief in TypeScript comes into this.
Emphasis on implementation detail
Giving PR comments about line breaks? Without just using a linter?
Perhaps you should focus on a higher level of abstraction and think about more than just the implementation details.
You know, like giving a good quality solution
Inadequate testing
I’m working in an environment where you’d expect code coverage to be particularly high. Unfortunately, that isn’t usually the case as people have a “this will do” attitude to testing and often skip testing for any code that is not immediately obvious and easy to test.
Why bother?
Tight Coupling
I could put any of the SOLID principles here. However tight coupling means we are not respecting any separation of concerns which also makes work really hard to refactor and improve.
Is reading about and understanding best practices really that hard?
Conclusion
The real shame of this is that all of these things were solved before the turn of the century. If you were working in 2000 you’d know how to solve these issues.
So how come these issues keep coming up time and time again? It’s nonsense.