DEV Community: Rollbar

Who Owns Developer Productivity?

Nick Hodges — Tue, 19 Apr 2022 20:35:24 +0000

Developer Productivity has always been a hot topic. For a long time, it was hard to define because it really couldn’t be measured. Lately, thanks to various code hosting platforms providing API access to git repositories, we can start tracking team and even individual performance metrics. (Though I’d strongly recommend against tracking individual developers’ metrics for reason that can be discussed elsewhere …)

So how do you measure how your developers are performing?

Well, it’s actually pretty simple. But it’s not easy. It’s simple because all you have to do is two things:

Get developers to code more efficiently
Get developers to not code more efficiently

There are tons of tools out there that help with the first, but not so many to help with the second. (The second does sound a little weird – basically it’s the notion of improving the process of things that developers do that don’t involve coding...)

Highly productive developers are hard to come by and expensive to train and retain, and so you want to ensure that your team is firing on all cylinders. But how do you do that?

Well, here are a few general ideas I have about how to make developers more productive.

Ensure that they have the best and fastest hardware. If a faster processor on a computer saves a developer five minutes a day, that is 1000 minutes a year, or 16.67 hours. At $100 an hour (probably cheap!) that's $1600 a year. A good machine is easily worth it.
Give them a peaceful environment. The best is individual offices, but if that isn’t possible (and you should try to make it possible in any way you can) then wherever your team ends up, at least have the ethos of being quiet and leaving people alone.
Give developers whatever chair, keyboard, mouse, and other peripherals that they want. Include noise canceling headphones in the list of things you’ll provide.
Engender a culture of excellence. Don’t put up with hacks or sloppy work. Design things and do things the right way every time. Fend off technical debt like a lioness defending her cubs.

Those are just a few of the things that can help improve the productivity of your team. These things are important, and you should do them, whatever your position in your organization.

But perhaps even more importantly, who is responsible for making sure a development team is a finely tuned machine?

It’s that second question that I’m really interested in.

For many years, Google has tackled the issue of Developer Productivity by forming a team focused on what it calls Engineering Productivity. The idea is that if they have a team to focus on making their developers more productive, that team will more than pay for itself in increased value delivered by those developers.

This sounds reasonable – and really great if you are a developer. I love the idea of someone spending their whole day making my life easier.

Historically, only large companies like Google have been able to realize the benefits of a dedicated developer experience team. However, more and more, smaller development teams are seeing the benefits as well, and there has been a rise in popularity of the “Developer Experience Engineer” (DXE).

Obviously if you have a DXE or a DXE team, they will own the process of improving developer productivity, right?

But what if, for whatever reason, you don’t have a Developer Experience entity?

Maybe the Software Development Manager is responsible for developer productivity. After all, they are the ones in charge of getting things done, and they are thus very interested in developers working more efficiently and effectively. If they don’t take an interest in such things, then no one will. Maybe they should be in the business of ensuring that the team has everything they want and need in order to be as effective as possible.

Or maybe the developers themselves are responsible for their own productivity. Maybe a professional developer should make it a point of pride to be as productive as possible, advocating for the tools, environment, and processes that make them do their best work.

Or maybe, just maybe, all these people combine to take on the responsibility. That seems to make the most sense to me. Everyone in the whole software development process is responsible to ensure that the whole team is firing on all cylinders. Developers should be very open about saying what they need to be more productive. Managers should be fighting for budget, process changes, and anything else that developers need to get better work done. DXE engineers should dedicate themselves to finding all the newest and latest software and hardware that will help things move along.

In other words, it takes a team to make the development process more efficient and effective.

Rollballers’ Hub is LIVE

Brian Morris — Fri, 08 Apr 2022 17:18:42 +0000

Rollballers’ Hub is LIVE

Rollbar is thrilled to announce the launch of Rollballers’ Hub, an exciting new program built to reward our customers!

Joining our hub is an easy way to learn additional tips&tricks of using Rollbar, share your own best practices, mingle with other Rollballers, and shape the Rollbar product roadmap while unlocking gifts and swags for your activites.

Participate in challenges, surveys, beta programs, and other fun and exciting activities.
Earn points and badges for every activity you complete and climb the leaderboard.
Get rewards like Amazon gift cards a private user group, exclusive Rollbar swags, or even a Nintendo Switch.

Join The Hub

Happy Coding

The Changing Value of Development Speed

Nick Hodges — Wed, 06 Apr 2022 13:45:03 +0000

An Interesting Poll

I recently asked this question on LinkedIn:

The reason that I asked this question is somewhat interesting.

A Trip to the Past

Back in a previous life, I worked at Borland. For those of you who don’t remember, Borland was at one time a pretty famous software company, competing directly with the Microsoft Languages and Office divisions. Borland is probably most famous for their C++ and Delphi products. In the nineties, they built a beautiful building in Scotts Valley, CA. Their end (as signified where the link above goes) is a story for another day, but suffice it to say that at one point, Borland was on the tips of people's tongues much like Microsoft is today.

Anyhow, Borland had an enormously successful product called JBuilder, the first commercial Java development tool. On the R&D team for JBuilder was a developer – let’s call him Jack – who was notorious for being two things: slow and immensely good. He took a long time to get things done, but his code was, for all intents and purposes, bug-free.

Members of the QA team would try to find bugs in what Jack wrote, but it was very difficult to do. A QA Engineer would consider it a badge of honor to spot a bug in code that Jack wrote.

Sure, he was slow, but as I said, the downstream cost of Jack’s code was very low. Bugs are expensive and time spent fixing bugs is time spent not creating new features. Jack spent a very small amount of time fixing bugs because he didn’t write them in the first place.

Now I give full kudos to Jack’s manager who recognized the immense value of what he could do. It would be very easy for a manager to focus on the “slow” part and not realize the value in the “almost no bugs” part. The total cost of ownership over Jack’s code was actually much lower than his teammates who, while great and faster developers, couldn’t match his level of initial quality.

Back to the Question

Which brings us back to the question I asked.

I asked the question because Jack had recently come to mind in a discussion, and it got me thinking. In today’s development environment, I’m not at all sure that Jack’s unique skill would be as valuable as it once was.

Jack coded in a very different environment than developers today. JBuilder was shipped once a year or so. There were periodic bug fix updates, but new features were generally only delivered annually. The software development process was basically Waterfall – product managers would define requirements, the team would architect and build the features, QA would test, formal beta tests would be run, and the product would ship in one big, grand release.

Now the second half of that equation – all the testing – was pretty time consuming and thus expensive. Having a developer that minimized those costs was very valuable.

But in today’s world, those costs are not as high as they used to be. The advent of CI/CD and a SaaS software solution drastically reduces the cost of a bug.

In the old way, a bug would frequently linger in code for weeks or even months before being discovered. As we all know, the larger the distance between keyboard and bug discovery, the more expensive the fix. The longer the time, the lower the chances that the developer will remember anything about the code she wrote that caused the bug.

But with modern tools like Rollbar, a developer can usually find out about a bug in his code in minutes or even seconds. If a bug is found that fast, the code is still fresh in the developer’s mind, and fixing the bug can be quick and painless. Rollbar can even pinpoint the exact line of code that caused the error.

Fast Feedback and Rapid Response

Now if the feedback loop for a bug is measured in minutes, then I think developers should be encouraged to truly “move fast and not worry about breaking things.” Developers like Jack are still valuable, I suppose, but being slow actually can become a liability. His high-quality code saves a lot of downstream time when you release annually, but when features can be released at any time, and when feedback loops are measured in minutes, a fast developer can often get more done in the same or less time.

For instance, say Jack takes two weeks to develop a feature that our faster developer (let’s call her Sara) can finish in one week. Sure, Jack’s code is flawless, but Sara’s code is pretty good, and she only needs three days to see and fix bugs as the code is tested under a feature flag with beta testers. That means Sara is able to produce what Jack produces with two days to spare.

Changing Development Process

Development processes have changed. Debugging has changed. Tools that monitor and report on errors (think Rollbar!) can make feedback loops much, much faster than those in the world Jack coded it. We now live in a world where bugs have a much lower cost than they had in the past. Given all that, it would seem that Sara is actually more valuable than Jack.

Poll Results

So if that’s true, why the results of the poll? Why don’t people want more Saras and fewer Jacks by almost two to one?

I think there are two reasons. One, many people still aren’t rapid continuous deployment, so the benefits aren’t there for them. And two – teams probably don’t realize the fact that Sara can be more productive than Jack. It is counterintuitive, and not completely obvious until you consider it thoroughly (or just read this article!)

Wrapping up

While productive developers who produce quality code are always a necessity, the actual way that they arrive at that near perfect code changes. Tools and a different mindset about reporting bugs can make “move fast and break things” the order of the day.

Reduce Debugging Time With Rollbar

Nick Hodges — Mon, 14 Mar 2022 13:54:27 +0000

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?

I like the second scenario better, don’t you? The customers never see the errors (much less complain about it) since Rollbar backed out the buggy feature before anyone could even know it was there. No middle-of-the-night scrambling. No deep, involved bug hunt, as Rollbar easily pointed the way right to the problem.

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.

Get A Free Rollbar Account

Brian Morris — Mon, 28 Feb 2022 01:18:07 +0000

Start your FREE Rollbar account today. Rollbar gives you 25k free events per month. Easy and quick installation. Connect Slack, Jira, Trello & more.

Rollbar featured in Silicon Angle

Brian Morris — Wed, 09 Feb 2022 18:37:26 +0000

Rollbar announces real-time adaptive alerts feature for developers. See Article

“Adaptive Alerts is the next generation of trendline alerting in Rollbar,” said Brian Rue, co-founder and chief executive at Rollbar. “Compared to the previous generation, which Rollbar customers know as the 10^nth Occurrence and High Occurrence Rate, Adaptive Alerts sends 86% fewer notifications, thanks to automatically adjusting thresholds, and a broader exception-level view that effectively detects application-level trends.”

Rollbar is constantly improving and with our free account anyone can access 25k errors every month forever. It's our way of helping all developers. Weather you are working with a few friends brainstorming new ideas or an entire enterprise Rollbar fits anywhere. We will find where, when and how bugs got into your code; All this information brought to you in 1 second, seriously 1 second!

Happy Coding

Who else is going to DevWeek Oakland 2022?

Brian Morris — Mon, 07 Feb 2022 03:26:20 +0000

Rollbar is a sponsor of Developer Week Oakland Feb 7-9, 2022. Checkout our speaking session with Nick Hodges, Developer Advocate at Rollbar he will uncover the 4 main insights that are transforming the ways we approach debugging to help return more productive time to developers. Happy coding and stay connected I will give a recap after the event.

Nick Hodges talk The Changing Nature of Debugging will be Feb 8th @ 2-2:25 PM PST

First 50 get a free ticket- Join Here