Tag Archives: career limiting

General IT, Personal Growth, Software Development, Teams

3 more career limiting habits of software developers

Leave a comment

So you as a software developer didn’t have any of the career-limiting habits from my previous post. Great! Congratulations! You’re totally good and on your way to career growth and unlimited success.

But wait, there’s more.

There are many other habits that can severely mitigate your career growth. So here are three more.

1. Lack of thorough testing

So you have completed a feature and think it’s good to go. Your code is committed. You are feeling good about meeting your deadline. The QA folks are unleashed.

Then it happens. Thirty minutes later a problem is found. Oops.

Many times, I have had developers come into my office, proclaiming that a feature or bug fix was completed, tested and ready do go. Then, when external validation started, something was found within just a few minutes.

Granted we all miss things on occasion. But, if this situation happens too many times in your code, you might be forming the habit of lack of thorough testing.

There are many reasons this occurs. Everything from time pressure to just plain laziness can contribute to this. Sometimes it’s a lack of environmental understanding or unclear requirements. Regardless of the origin, this habit will severely curtail future career opportunities.

You can overcome this by using TDD, BDD or similar methodologies where appropriate. Thinking “testing first” can help you identify and code for those issues up front. Even if your organization doesn’t make formal use of test-driven development methodologies, you should still spend some time thinking through all the ways your code could fail and make sure you handle or document each one. Making that a habit will reduce the chance of an embarrassing situation with your boss or QA just minutes after you pronounce something done.

2. Lack of communication

For an application that is larger than one person can manage, there is a natural migration to particular areas of expertise by the team members.  Alice knows the database interface, Bob knows the CSS and front end, Sarah knows the business logic, Arun knows the device drivers and so on.

We all build silos of information and expertise. This is good and helps us provide value to the organization.

The career limiting aspect occurs when we withhold knowledge (either implicitly or explicitly) that could help other team members. The lack of free flow of information across developers reduces productivity, increases the odds that defects are found late and reduces overall department effectiveness.

If you become known as the person who “knew that last week” but didn’t bother to share with the team, you will become a pariah. The team members who could have benefited from that information will grow to resent you and begin to exclude you, exacerbating the problem of team effectiveness.

It’s a good habit to err on the side of too much communication as opposed to not enough. In the end, you will make the team more productive and be seen as a better team player and better example. It’s a karma-enhancing habit if you believe in karma. 🙂

3. Being a “One trick Pony“

Software tools and technology move at a rapid pace. The hot technical tools and trends of a few years ago become the archeological artifacts of tomorrow.

Back in my high school days, I was pretty good at BASIC.

Guess what. Nobody cares.

If I still relied exclusively on my ability to do BASIC for employment, if I had made it my ‘one trick’, I would have starved long ago.

I moved on to other more mainstream technologies over time such as FORTRAN, C, Perl, Python, PHP and the like.

If you, as a developer, acquire the reputation of being able to only do one thing, it will, over time, severely limit your opportunities.

Think about how technology has changed in just the last 10 years, then extrapolate that out over the next 20 or 30 years. We all better be embracing change. In the future, the most important skill could be the ability to learn new things.

Over a 40 or 50 year, career time span it is imperative to stay relevant. The saying goes “Adapt or Die”.

If you become a ‘one trick pony’ you will be limited in the opportunities that are available to you.

Conclusion

Hopefully, none of these describe you. However, if you have any of these tendencies, now is the time to change your habits so you can reap the future benefits.

 

 

 

 

Development, Personal Growth, Software Development

3 career limiting habits of software developers

Leave a comment

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.

An important capability for any developer, regardless of experience level, is a certain level of adaptability. It will serve you, your teammates  and the company well.

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.