markdown guide
 

I see bugs as a means of improving. Don't get me wrong, it's so incredibly easy to get disheartened by seeing bugs in your code. But it offers the opportunity for you (the developer) to

A) Improve your software.
B) Learn! It gives you the opportunity to learn something new that you didn't before. This is SO important for a dev, especially when it comes to avoiding stagnating/staying in the same position career and knowledge wise.

Both these aspects are super important to a dev's progression. I think there's a real big stigma about bugs, and the whole notion that every dev should write perfect code, but in reality nobody writes perfect code. If a developer berates another developer because of bugs then really, they're in the wrong. Instead I think good software cultures/environments must have an open culture of accepting bugs as a means of improvement; both in terms of the software in question's codebase, and on a personal knowledge/skillset level. Instead of destroying a developer's confidence over a bug, the situation should result in developers sitting down together and fixing any issues together openly, allowing for every party (and the software, of course) to benefit.

 

Great answer! "Bug hunting" is also a great way to learn for a person new to a code base.

 

From the perspective of choosing how and when to work on them, I view bugs as just another requirement that hasn't yet been implemented: it needs to be prioritised, understood, tested, built, etc.

From the perspective of when I'm working on it, it suggests a gap between a developer's understanding and reality (as david karapetyan mentioned above), but my immediate reaction is "why didn't a test pick this up?". So my first response is to look at the testing around the bug to understand whether there's a missing test, or a test that's not replicating reality appropriately.

If this part of the codebase has a history of bugs, then I might think a bit more broadly about how we've modelled this area and work out whether there's a mismatch at a broader level. What is it about this nook of the solution that is a bug magnet? Is there a need to redesign the solution to bring it closer to our current understanding?

I don't work on anything where a software defect could hurt people, thankfully, so I don't believe 0-defect software is a realistic or viable goal for most software development houses. Therefore, I don't beat myself up when I (or others) create defects. I accept errors in my work, try to understand how to find them quickly and reduce their probability, but try not to let the presence of defects impact me significantly.

 

I see bugs as a mismatch between my mental model and what the code is actually doing. I don't think more tests help because most software systems after a certain point are almost impossible to test. Only way to find out if something is broken is to actually run the whole thing.

This is why I'm skeptical of TDD in general. Tests help but it is much better to invest in tools and architectures that make software systems debuggable. My views on this are colored by what I saw in smalltalk environments when I first started programming. I've yet to have a debugging experience that comes close to replicating what is possible in smalltalk. Erlang/elixir/lisp are close second in terms of live debuggability. Everything else falls short in one way or another and is often downright user hostile.

 

Excessive bugs caught in code review reflect an ineffective development process.

Excessive bugs caught in production reflect an ineffective development process AND an ineffective code review process.

I know many of my fellow devs believe bugs are inevitable. And I would agree with that but excessive bugs are a sign of a problem that's worth fixing.

The major problem with bugs is that it takes longer to develop buggy software than it does it develop relatively bug-free software. Steve McConnell does a wonderful job explaining why that is: stevemcconnell.com/articles/softwa...

If you can convince your project stakeholders that it is actually cheaper and faster to take your time, avoid shortcuts, and implement effective quality controls while developing software, your bug counts will plummet. Unfortunately, many people don't want to hear that--so we find ourselves drowning in buggy software.

 

My role is software testing.

On a good day I view a bug as a curiosity. It indicates a new challenge, how do I isolate it to effectively reproduce, how do I find similar issues?

Other days it is an indicator of failure. When you work at eliminating the amount of testing you do for a given release you're bound to choose incorrectly. My preference is to understand why I eliminated a class of testing which would have caught the issue. My concern is that testing that behavior is expected every release with documentation on pass/fail.

Note automation is used and helpful, but if ever test needs to run every release, and releases don't stop just because you're testing, it leaves no time to reduce time.

 

It depend of the bug I think.
When you spend long hours on a code and they don't know and you don't find why, it's not very cool!

But when you find a bug, solve it and learn how the code work, it's very nice!

 

I very much view bugs as a error in a developers thinking and as such should be looked at as an opportunity for improvement.

Classic DEV Post from Apr 4

What's an awesome VS Code extension you recently installed?

I just came across a simple yet awesome VS Code extension tonight care of Elija...

Alan Barr profile image
Technical Product Manager passionate about getting people into homes. Learning new things about technology and software that helps people.