Thinking about Senior Engineers

What makes a person a Senior Software Engineer? Is it their technical knowledge? The amount of languages, libraries or development techniques they know? Or maybe it’s just an indicator of the number of years experience they have?

In so many cases, you become a Senior engineer through a combination of these reasons. The best “Senior” engineers I’ve worked with have got there because of their attitude and not their aptitude.

Having the technical knowledge is, of course, important. But it might not play as big a part in your career as you think. I want to work with smart people who have a great depth of technical knowledge. Smart people come up with great (simple) solutions to complex problems. Yet what sets the great engineers apart from the world-class is the way they apply their knowledge.

The best engineers display a sense of maturity when working with others. And these are the people I want to work with. If people want to work with you, you’ll do well in your career.

People will want to work with you because of your attitude. Or to be precise, because of the way they perceive your attitude.

Mature engineers recognise that they have skills and knowledge that others don’t. They spend time teaching others these skills. They think about the bus-factor impact to the team. Less mature engineers use this specialist knowledge to maintain a niche for themselves.

The way they pass on information also signals an engineers maturity. The best recognise that they were a beginner once and are forgiving of the mistakes made by the student.

Mature engineers recognise that they are also fallible. They recognise that the code they write is open to criticism from all. The way they react also shows their maturity. It can be hard to take criticism from others and mature engineers will take the feedback and use it to improve the solution.

Giving feedback is also a skill. Mature engineers focus on critiquing the code and not the person who wrote it. Having empathy for another persons context and environment can help explain things you see in the code. Once you understand the context, you can also get to a better solution. Knowing that one-size doesn’t fit all is also a key trait of mature engineers.

The best engineers also focus on the solution to the problems, rather than the problem itself. They apply this principle when they find mistakes, focussing on the fix rather than revelling in the problem.

And this doesn’t just apply to code. If there are problems with the environment or team, a mature engineer will suggest things to try to improve the situation.

In most corporate environments, this can sometimes means dealing with political situations. Learning to manage relationships across the business is a skill that mature engineers develop. They do this by paying attention to their audience and tailoring their language to suit.

A lot of this comes down to understanding the affect that the language used has on an individual or group. What you say, is not the same thing that the person hears. Understanding another persons filter and the impact this has on your message is key to gaining their respect. This is particularly true when having difficult conversations or when in conflict.

I’m not the only one that believes that your attitude is important if you want to become a respected individual contributor.

“On being a senior engineer” by John Allspaw describes in more details some of the attributes of mature engineers. This blog post promoted me to reflect on my understanding of senior engineers. And in turn to write his post.

In John’s piece, he describes attributes of mature engineers, and the impact they have on an organisation. He includes the “10 Commandments of Egoless Programming” from Jerry Weinberg’s book The Psychology of Computer Programming. This short, punchy list is a great place to start for anyone aiming to be a senior or mature engineer. I haven’t read the book yet, but I’ve added it to my list.

So, take care with the way you act. Don’t be the elusive coder in the corner, and drop the ego. Becoming a senior engineer is more than knowing the technical side. You need to understand that the most effective engineers know how to work with people. If you can achieve this, then people will want to work with you. And if you can do this, then you’re well on your way to becoming a Senior Engineer.

Creative Commons image courtesy of Ian Britton (

You can keep your bug-tracker, just use it less!

I recently published an article on my blog titled “You don’t need a bug tracker”. This article was also syndicated on DZone. Following the publication I received some feedback on it’s contents. I’d like to take this opportunity to clear up a few things.

The title

I’m aware that the title is inflammatory. It’s also a little disingenuous. Of course, our development teams use issue trackers. Like source control, any good development team will use an issue tracker. Ours in Jira (although some teams are experimenting with Trello).

So if I’m now saying that good development teams use issue trackers, why did I suggest that everyone else should drop them?

I didn’t, well not really. That wasn’t the point of the article. If you read it through, you’ll see that I’m asking you to fix or close issues as they’re reported. What I don’t think teams should do is allow the defects to build up.

We don’t record all the defects we fix, if we fix them as part of the build then there’s no real need to track them. If the bug reappears, then it’s a new defect.

I chose the title to grab attention. There’s so much written about software development that it can be hard to grab someones attention. “You don’t need a bug-tracker” is a way of starting a conversation.


One of the other points raised was my suggestion that you fix defects immediately. I was asked what “immediately” meant in this context. In reality, what I’m suggesting is that at the next opportunity, you fix the defect.

And the next opportunity should be sooner rather than later. If you’re half-way through working on a feature, the next opportunity might be once you’re done with this feature. The cost of context switching might harm you more than the existence of the defect.

I’m not advocating that you should always drop everything to fix the defect. I do think you should do is ensure that you address the defect before starting any new features (This is one of steps in “The Joel Test”).

Another question was about defects that you know will appear in the future – for example a leap year bug. Should you address them now? In my opinion, yes. Other things with compete for your attention between now and the time the defect surface. Which will mean it’s likely you’ll forget about it. If you know about it, just deal with it.

Trusting you to do the right thing

Another question asked was how as an individual contributor do you know what is the most important thing for the users or company. I believe that it’s your job as a software developer to understand why you’re building the product. Not knowing the next most important thing suggests you don’t know the product as well as you could. If this is the case, dedicate a little more time to understanding your customers and product.

I think that this question relates to another – “How does my manager know what I’m working on, and ensure it’s the best use of my time?”. Measuring performance of developers and testers through bug-count metrics is harmful to an organisation. It creates the wrong environment where delivering customer value comes second to internal metrics. Instead, focus on showing your manager the value you’ve delivered to your users and stakeholders. If something excites your customers it should excite your manager.

We’ll do it later

Finally, I was asked what was so bad about letting defects pile up if you resolve to fixing them a later time.

If you can guarantee that you’ll get this time then this might be an option. In the teams I’ve worked in, I’ve found that I can’t ever guarantee anything like this happening. Defects also have a habit of evolving or calcifying over time. You might find it easier just to address it as soon as you find it.

If you find yourself with “spare” time on a project, there’s nothing wrong with fixing some of your “won’t fix” issues. Just don’t commit to doing it, because it’s likely you won’t get chance.

The road to zero defects

Recently, I’ve taken the lead for a new team and we’re aiming to develop projects using a “Zero Defects” methodology.

This is not a new concept to the team, they already ensure that there are no known defects for a story before pushing to production. What we need to address is how we deal with issues found after we’ve deployed a feature to production.

Over the coming months, I’ll be blogging about the experiments we run to try and achieve this. I’ll write about the things that work for us, and also the things that don’t.

So, you don’t need to drop you bug tracker. You might find yourself using it less though.

Creative Commons image courtesy of Anxo Resúa (

You don’t need a bug-tracker

Creative Commons image courtesy of tk-link ( Creative Commons image courtesy of tk-link (

If you’re writing software, chances are you use some sort of issue tracking tool. Or to be more precise, you most likely have a bug tracker. Jira, Bugzilla, heck, even an Excel spreadsheet. If you’re diligent every time you find a bug you’ll create a ticket in the tool. Most bug-tracking tools will guide you to add a severity and assign a priority. The aim of classifying a defect in this way is to help you know what to work on next. In most systems, the two aren’t related. This means you can create defects with “Critical” severity, assigned a “Low priority”.

In every organisation I’ve worked the process has been the same. And in every case, the number of issues in the bug tracker has grown and grown.

This is wrong. I believe that you don’t need your bug-tracker.

What is a defect

Throughout this piece I use the terms “bug” and “defect” interchangeably. In my mind, a “defect” is:

“Any situation where the functionality doesn’t meet the expectations of an actor interacting with the system.”

Reducing waste

Lean engineering is the process of improving efficiency in a system by eliminating waste. In a system, waste is anything which has a negative effect on productivity. Defects are often classified as one of the 7 wastes of lean software engineering.

Why? Well, maintaining a list of defects takes time. First there’s the time required to capture every issue that’s found. Then you need to classify it, prioritise it and finally plan when to fix it. Teams usually address this by holding regular bug triage sessions. In these sessions, the team will make decisions on severities and priorities. These are then used to influence the planning for the fixes.

During the triage session, them team may find issues which they disagree on. One common disagreement can be whether the defect is actually new functionality. In this situation, the right thing to do is convert this bug to a story and prioritise it.

The time spent on this triaging is time wasted by the team. A weekly bug triage meeting is not unheard of for some teams. It seems strange to spend time arguing about a low priority bug when you could just spend the time fixing it instead.

Measuring quality

If you’re stock-piling your defects rather than fixing them then someone will use them as a measure of quality. The more defects you have, the lower the quality. What’s more, I’ve seen these measures used as quality gates. Statements such as “A release to production can contain no P1 issues” are common. I can work with that rule – I’ll just make my issues P2 instead. Sorted.

The metrics can also show whether the software is gaining or losing “quality”. If the number of defects is raising, is it because the software is of a lower quality? Or is it because we’re putting a bigger focus on testing? Just looking at the metric is dangerous.

False hope

The defects you’re tracking might be causing you’re customers more harm than you realise. This is especially true if you’re working in a transparent environment.

If you add an open defect to your tracker then you give people who look at it false hope that you’ll address the issue.

When looking at what to do next, low priority bugs usually lose out to new feature. You can see why this is the case. If the issue isn’t that severe then the resolution can wait. If you have misjudged that severity then your customers will tell you. At this stage, you can revise the severity and address the issue then. If your customers remain quiet then you might have got away with it.

Except this isn’t the case. By leaving the ticket open you give your customers false hope that you will fix it. Whilst the ticket is open, customers will think that you will addressing it soon. So they’ll remain quiet waiting for the fix.

If you’re not going to fix something, close the ticket and let the customer know. At least that way, you’re not setting expectations that you can’t live up to. Closing the ticket may trigger a conversation with the customer. Any chance to further understand your customers is a good one.

Address defects immediately

Bug-tracking tools are necessary when you find defects quicker than you resolve them. If the rates are roughly equal then you don’t need a tracker. You will need something to show what you don’t plan to fix, but this could be as simple as a list of issues.

Priorities no longer matter. Severities are only used to influence how you communicate to your stakeholders.

So how do you reach this situation? The answer, it turns out, is pretty simple. When someone finds a bug – address it immediately. Do the triage there and then to work out what your response needs to be. In most cases you have a simple choice to make:

  • Drop everything a fix the bug
  • Decide you’re never going to address it and close the issue.

Apply the fix

This is the response that I prefer to choose. Knowing that something is wrong in the systems I work on is uncomfortable for me.

It’s easiest to fix an defect as soon as it’s found. The code you’ll be working with will be closest to one where you found the issue. The functionality will also be close. Both of these things should make the issue easier to reproduce and fix.

Once you’ve reproduced the defect, figure out the best way to test for it. Write the test case. The best way might be a unit test, or it could be a manual check. Either way, you need to know that you can reproduce the issue and how to check that you’ve fixed it.

Fix it. Test it. Release it. Unreleased fixed defects, like any unreleased code, is also waste in your system.

Close the issue

Closing the issue at this point may sound a little drastic. After all, there’s a chance that when work slackens off you can address the issue. But let’s face reality, it’s rare that you get the chance. If you don’t address the defect now, you never will. That bug will sit on your backlog forever. As soon as this happens, you’ll have to deal with the bug-tracking accounting.

The value of storing bugs in the hope of fixing them in the future diminishes as time passes. Software evolves and the bug reported will evolve. In the best case, changes in the application will mean that the bug is no longer relevant. New functionality means that the bug is no longer present. Refactoring might remove the defect as a side-effect. Either way, the tracked bug no longer exists.

In the worst case the bug evolves and spawns other bugs as the application evolves. What started out as a low priority defect could have now mutated into a bigger problem.

There is a third case. Neither of these things could happen and the bug will just continue to exist. Remember I talked about “false hope”?

So, close the issue and add it to the pile of stuff you know about but “Won’t Fix”.

The unspoken third option

There is a third option and it troubles me more than the others. In some cases, the defect raised might actually describe a new feature. In this situation, you should move the issue to the product backlog.

Now this sounds like the defect tracking accounting I spoke about earlier. How is this different?

It’s not, which is what troubles me. In essence, you’re doing the accounting again, converting defects into stories to deliver later. Be careful with your use of this option. You must communicate well with the person who raised the issue. It is your responsibility to ensure that they know understand what you’ve done.

That said, the same rule applies to stories as defects. If you don’t plan to ever build the new functionality then close the issue. Closing the issue signals that you don’t see the functionality as necessary. Remember – you don’t want to create false hope.

When this works, and when it doesn’t

A Zero-Bug policy won’t work for every team . It relies on some development practices to be effective. It’s also key to understand that it’s not always as black and white as I’ve laid out here.

You will still have conversations of “defect” v “feature”. The key thing is to spot when they’re happening and bring them to a decision. Time spent debating this is time wasted. Time that you could spend fixing the issue.

There is a need for the team to be using a continuous delivery system to rollout changes. As I’ve mentioned, fixed defects that aren’t available to customers are waste. Using continuous deployment, each fix will result in a deployment to production. This means that you don’t need to track what’s fixed where.

A zero-bug policy doesn’t work well when you think of testing as role rather than an activity. Here, there is a channel of communication needed between the testers and developers. As time passes between the fixes, there is a need for tracking the defects. Where this is the case, it is only a matter of time before the number of tracked defects become a measure for quality.

Where testing is an activity the feedback loops are often tighter. The need for a tracking tool to assist communication is no longer valuable.

My current team has a engineer with a test specialism (software engineer in test). Our engineers test in pairs, meaning that we’re often able to apply a fix as soon as we find a problem.

Drop the bug-tracker

So, drop your bug-tracking tool.

Or at least stop stock-piling defects that you don’t plan to fix. If you find a defect, make the decision – Fix it or Close it.