Development time is precious. Developers are highly-skilled and highly-paid, and so naturally you want to make sure that they are as productive as possible. Many organizations are starting to hire Developer Experience Engineers to make sure that their developers are using the best tools and processes possible.
To make developers more productive, the first step is to figure out exactly what developers are actually doing. Then, we need to figure out what we want them to do.
Examining Developer Time
Developers' time can broadly be divided into two areas: Time coding and time not coding. It seems pretty obvious that you want to maximize the amount of time that your developers are coding and reduce the time they are not.
Coding time can actually be broken down further into feature development and maintenance. Feature development – the process of producing new features and value for the customer – is the most desirable thing that a developer can do. Maintenance work – bug fixing – is a bit of a mixed bag. You want your developers to fix bugs, sure, but you don’t want them to have to do it. In other words, bugs are bad and a drag on the team, preventing their coding time from being spent on new feature work.
Non-coding Time
And then there is non-coding time, and it, too, is a mixed bag. Some of it is productive time – code reviews, mentoring, training, creating issues and bug reports, etc. I like to call this meta-coding time. You want meta-coding to happen, but you want it to be as efficient as it can be.
The rest is time well spent – meetings, company events, etc. – but time that you want to minimize as much as is practical. I don’t know a single developer that wouldn’t be pleased with fewer meetings.
So a developer’s time becomes an interesting exercise. You want her coding as much as possible, but on new features and not on bugs, and you want her learning, training, reviewing code, and such – but again, not too much.
So in the end, it seems that you want to maximize new feature time, and minimize non-new feature time (i.e., bug fixing time, meta-coding time, and non-coding time). You don’t want to rush meta-coding time, but you want to do everything you can to minimize it.
Making Developers Productive
Now, much effort has been spent making coding time productive. There are all kinds of tools, IDE features, and other technology to make the process of writing code as efficient as possible. Features like Intellisense have been around for quite a while. Recent innovations such as Copilot from Github are astonishingly useful and productive. (Copilot actually kind of scares me – It is so prescient, like it’s reading my mind…)
Bug-fixing time is especially ripe for improvement. These days, it often involves a lot of investigation such as combing through log files and debugging in an imprecise manner, searching for buried treasure without a map.
Few developers relish maintaining software and fixing bugs. I know some folks who do, but most developers seem to want to write new code and new features. Sure, bug fixing delivers value to the customer, but as discussed above, it’s not time you want to have to spend.
What if there were a way to make bug-fixing more efficient? What if you had a map for your treasure hunt? What if you could be pointed to the exact line of code causing an error?
Would I even ask such questions if I didn’t have an answer?
The Answer
The answer, of course, is Rollbar.
With our AI-driven Error Grouping, we focus on the errors that are most important and impactful, drastically reducing your debugging time by pointing you right to the line of code where the problem is occurring.
Even better, we can notify you of errors immediately, possibly even before your customers see them.
Imagine this scenario:
You have been working on an important new feature. It’s finally ready for beta testing, and so you release it to a select few beta test customers by keeping it behind a feature flag. Those testers use the product, and they find problems. You fix the problems. You test for a significant period of time, and finally you feel confident that all is well, and so you deploy.
However, upon general deployment, a very ugly bug occurs with your customers using the Kanji character set. The problem is that you and your team are sleeping when the error occurs. Customer support starts getting phone calls as customers report the bugs. You count yourself lucky that a customer bothered to report it at all. They aren’t too happy, of course, so you wake everyone up, investigate (which takes a while), realize the severity of the bug, and decide to roll back the deployment, all in the wee hours of the morning.
It takes two days of intense debugging and pouring over log files to see what the issue is, but you fix it and redeploy the new feature successfully. Lots of disruption and grumpy, tired developers, not to mention angry customers that saw the errors.
But if you were a Rollbar customer, things could go more like this:
Everything happens the same, but when the error occurs, Rollbar recognizes it as critical, and automatically rolls back the deployment without waking anyone up at all.
In the morning, your alerts and email let you know what happened. The Rollbar Dashboard shows you the error clearly, including the exact line of code that caused the problem. The correct developer immediately jumps on the issue. It’s soon fixed, and the new feature is redeployed without incident.
No one got woken up, and the feature was redeployed quickly. That’s a win.
Which is the Better Scenario?
Developers want to work on new features. They want to fix bugs that occur, but they don’t want to spend hours searching for the problem.
Rollbar can’t help reduce the number of meetings that a manager calls, but we can reduce the amount of time developers are spending on bug hunting. And less time bug-fixing makes for happier development teams spending more time on things that will deliver value to customers.
