Are you a software developer? Has your career flat-lined? Are you relegated to the back of the pack when it comes to assignments? Are you picked last when it comes to new projects? Have other developers stopped coming by and asking your advice? Has your manager stopped concurring with you for future work planning?
If you answered any of those questions with ‘yes’, then read on.
You may have developed some career-limiting habits without knowing about it.
1. Over promising – under delivering
Estimating effort in a software project is problematic at best and complete fantasy at worst. Some methodologies try to mitigate this, such as agile. But there are still times when a critical fix or change has to be delivered in a bound timeframe. In that case, when the manager needs an estimate, that estimate also encapsulates an implied promise, even though it is called an ‘estimate’.
As developers mature in their craft and environment, the accuracy of estimates generally improves. However, some developers habitually underestimate how long it will take them to implement a given fix or change.
I have worked with team members who, when asked how long a particular ticket would take to resolve, would say with certainty that it could be done in 4 hours. Then, 2 days, later I am in their office asking why that 4-hour change is still not complete.
When you, as a developer (or as a manager for that matter), miss the estimation mark regularly, you are falling into the habit of “over promising – under delivering”. It could be that you simply ‘shoot from the hip’ and make estimates without really considering needs to be done. It could also be that habitually bad estimates are a sign you have a fundamental lack of understanding about the project, tools or environment. Either case is bad and will erode your credibility and the perception your team members have of you.
If you struggle with small change estimate accuracy, start doing some light weight tracking in a notebook or spreadsheet (if you don’t have a tool that does it for you) for those types of estimates. Use the data you collect to give you better insight as to how accurate you really are. Once you have a few data points, you can start comparing estimated to actual delivery time. Try to answer the “why did I think it would only take that long” questions. Then use what you discover to adjust your future estimates.
2. “My way or the highway”
Experienced developers have standard ways of architecting and implementing software. This shows itself in the way they organize code, name elements, test or use language idiom among other things. These are all good and are what make an experienced developer deliver quickly with higher quality in most cases.
I have seen cases in my experience where a ‘my way or the highway’ developer will go into an existing code body and completely violate the architecture and coding standards to implement a feature because it’s not their way.
The career limiting aspect comes in when that developer will ONLY do projects that way. Developers like this only function well in their little worlds. Since most companies have projects that need to be maintained (that you didn’t write), you will always end up writing code outside of ‘your way’. This behavior frustrates the team, confuses future maintainers, creates contention and generally adds to the chaos with little to no actual benefit to the project itself.
3. Tool worship
The modern software development environment has a wide array of excellent tools to make work go faster, and at higher quality. The capabilities of today’s IDE’s (integrated development environment), compilers, languages, editors, debuggers, frameworks and DEVOPS tools are must have for any professional developer.
Tools are a necessary force multiplier in our industry. Mastery of a tool set for your environment is prudent and a productivity enhancer. I once had a developer on my team who was an Emacs wizard. It was a real show to watch him edit and refactor code with Emacs because he was so adroit with its interface and shortcuts. However, when you have that level of mastery you tend to want to use that tool for everything. You have heard that old saying: “When all you have is a hammer, everything looks like a nail”.
The problem is when we get so used to one thing and stick with it to the detriment of learning new ways and methods. When we stick with only one tool, regardless of the circumstance, we artificially limit our ability to solve problems with more advanced or idiomatic ways with other tools. And that is the career limiting aspect of tool worship. The software tools at our disposal today are evolving at a rapid pace. And by sticking with the tools you are comfortable with you forgo the personal career growth that comes with learning new tools and the commensurate skills.
Would you trust a car mechanic who tried to solve every car repair with just a wrench or just a screwdriver? Of course not. There are many repairs that need way different tools. Neither should you be a developer that only has mastery of one tool.
Conclusion
A little introspection on a regular basis, and some heart to heart discussions with those who know you best, can illuminate these or other career-limiting habits you have picked up. Knowledge is the first step towards change and improvement.