A developer’s life is not simple. Developers need to contend with adding new software features, quickly, from different customers, while keeping up with technology. And do some support work in the middle. And, also meetings.
However, the road to improvement through this complex situation can be a strange one. It sometimes starts with these suggestions, heard around in recent retrospectives:
- We need to increase the sprint size. Let’s do the math: If the sprint is two weeks, doubling it will mean one less retrospective and planning sessions. We can spend the rest of the time working. Pure win.
- We should write code so other developers understand it. It’s not written for business people. Product people don’t need to understand the code they look at. Testers don’t need to understand the cases we’ve coded. And it’s not called “code” for nothing, you know.
- Every time we add tests, we need to modify our legacy code in order to test it. Every time we do it, we introduce bugs. We should therefore write less unit tests. That’s a logical conclusion, if I’ve ever heard one.
- We missed our estimate on this thing we’ve never done before. We need to get better at estimating. Of course, it will take more time, but at least we’ll have a better number next time. Maybe.
- We don’t have enough testers. And while the testers are indeed the bottleneck, we’ll keep coding towards the next version, because we don’t want to hang around doing nothing.
Some of these I heard many times, and some are more rare (I admit the unit tests one actually rendered me speechless, which is not easy to do). These examples are merely symptoms of the ineffective systems we create for software development.
Developers understand that they are measured by code. Any non-coding tasks for programmers, or non-testing for testers is considered less valuable. Retrospectives, for examples, are more prone to be pushed. While quality is important, it can be deferred because of pressure to work on that next thing.
The systems encourage shortsightedness, and so developers are less interested in the big picture. We can keep our programmers working, but at the expense of overloading the testers the next time around. We won’t invest in long term valuable activities like unit testing, because we’ll put in bugs now. If estimates are valued now, we’ll work more on them, and delay the actual software development.
It’s Not You, It’s Them
Every time I hear this and I think “oh, not again”, or “are you kidding me?” I remind myself:
Nobody teaches this.
Nobody is trained to spot problems and offer options.
Nobody is encouraged to rock the boat with new ideas.
Universities and colleges, don’t teach how to develop professionally. Management schools don’t teach how manage software properly. Companies need train developers, and encourage innovation, but they usually train developers on technical stuff, or classical management theory for the new managers.
When professional development is found, it’s usually by luck – having the environment to grow the professional developer, with permission to experiment and fail, with resources and coaching to direct. And you need the right people in place, and to retain them, because they will become a hot commodity, when they tame the enterprise tiger. (Or become consultants).
Professionalism is Becoming Rare
Professionalism is not about learning one more programming language. Or mastering a new testing technique. Or not even having a retrospective session every two weeks.
It’s understanding how our we impact the business. It’s keeping sight on the big picture, not the day-to-day tasks. It’s continuously learning. It’s about paving the way for the next professionals, creating the environment where they can grow.
Professionals need the right environment to grow. To survive. You can decide to cultivate a professional culture.
If you don’t, someone else sure will.
| Reference: | Help Professional Developers Survive from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
