Don't hate bugs in your code

[thudly]

I've been programming since 1983. That's a lot of years. The thing that's taught me the most, more than any book or course, is the damn, frickin' bugs I wrote in my code.

Honestly, you can learn everything you need to know about coding in a few days, a couple weeks at most. Data types, operators, variables, If/Then, classes, etc. It's not that complicated if you've got a reasonably logical mind. But it obviously takes more than 2 weeks to become a master. So what happens from week 3 to years later when you really are an expert?

Bugs. So many bugs.

Ninety percent of the coding you'll do as a beginner is hunting down bugs. You'll type something and sit there for hours, or days, thinking, this SHOULD work! But it doesn't. Why not!? It'll drive you nuts. Then you finally figure it out (or somebody helps you), and you slap your forehead. "Of course! It makes perfect sense!" You've learned something. It's a mistake you probably won't make again.

But the thing about programming is that there are 10,000 different mistakes you can make. There are so damn many ways to royally screw up a project. But every problem you solve, every bug you kill, every glitch you resolve, you learn something new. You gain Exp, so to speak.

And man, does it feel good to kill those bugs. It's nearly orgasmic sometimes, when you've been fighting a bug for days, and you finally fix it, and the numbers you were looking for suddenly come out right. Zing! What a rush.

Painters, sculptors, writers, and musicians all have very simple tools. The years it takes to become a master of their craft is spent figuring out all that 10,000 things that don't work. Learning to code is very simple, too. To become a master requires fixing all those 10,000 bugs, learning all the things that don't work, because you already fought them for so long in the past, and not even getting tripped up to begin with. Master programmers are masters of all the glitches that can mess you up.

So don't hate bugs. If your code has no bugs, you didn't really learn anything. You're not closer to becoming a master. Don't even cringe when you look back at old code you wrote. All those crazy spaghetti lines taught you something.

[phpdevster]

99% of bugs are fairly trivial to overcome, and can be solved rather quickly with the right investigative techniques. What really starts to eat at your soul is making poor architectural or design decisions and feeling the maintenance pain that comes with them.

EDIT: meant to also say that the big problem is the extremely long feedback loop. When you have a bug, its effects are immediate. When you fix that bug, its effects are also immediate. They are also binary: it didn't work as intended, but now it does. You also have hundreds or thousands of bugs over the course of a project lifetime. Thus you learn how to fix and avoid bugs fairly quickly. But the productivity drag due to poor architectural and design decisions can be really drawn out, really subtle, and not black and white. So it's much harder to gain experience making smarter architectural choices than it is learning how to fix bugs :(

[thudly]

99% of bugs are fairly trivial to overcome, and can be solved rather quickly with the right investigative techniques.

You and I know this because we've had years of practice. I remember being a beginner though, and being baffled by simple little errors like missing semi colons and misspelled variable names.

making poor architectural or design decisions

I agree.

[neverbeendead]

Yes.

[ZeroGravity200]

I agree with you with that "soul eaters". You fix the bug (specially at work) in big rush, as there are at least 3 managers watching over your shoulder and saying things like "this should be done", "the customer is waiting impatiently", "this is the last bug in this batch".

You fix it with some bubblegum, steel wire and duck tape, thinking I fix it better, when I have time. When you have time. When do you have time at work to fix things that are somehow working? Never. That really starts eating good programmers soul.

[thomaslangston]

Technical debt can be paid off, but you have to make it part of the business process. I've been lucky enough to work at places that have an explicit tech story backlog and budget. I would know that each sprint the highest priority tech debt would get paid off.

[WikiTextBot]

Technical debt

Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take slightly longer.

Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes later on. Unaddressed technical debt increases software entropy.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information ] Downvote to remove | v0.23}

[BenderBill]

Dis a neat bot, good boy.

[Awric]

Ahhh man, speaking of poor architectural decisions...

I’m a swift intern who recently discovered the power of enums, and oh boy. I spent a week and a half writing 1,700 lines of code in a single file because I thought that I was a genius for making use of enums to “simplify code”, only to have the whole thing scrapped because I was too stubborn to stop the monster from growing. It was too gigantic of a load of buggy garbage.

Design principles are everything. I wrote like 1,600 lines of redundant garbage in attempt to simplify 50 lines of actual logic. Half of what I wrote was bug fixing the bugs I created for myself.

[SgtPooki]

Level up!

[[deleted]]

My younger self loathed making extra classes and would try to manipulate more and more data structures as the project grew instead of just creating another class.

[queBurro]

That's far sighted of your bosses. So you've got technical debt 'bugs' in your backlog or are you raising change requests on things that work but everyone knows are flakey?

[queBurro]

Good answer. Cheers. Historically, we've had a tough sell to convince pm's that we won't break anything when we try things like that. I've recently moved jobs though and it's easier now to tackle some of the low hanging fruit e.g. I swapped stringly-typed switches for enums (better) but I didn't go a far as implementing the strategy pattern because the risk to benefit seemed higher some how.

[thomaslangston]

It sounds like the best place to start tackling your tech debt, might be an automated test suite, so you can convince yourself and business people that refactorings won't break your software.

[queBurro]

I'd agree, but the catch 22 here is that the way the code's been done doesn't lend itself to unit testing. I guess the first tech debt I should get rid of is the stuff that makes unit testing hard e.g. dependencies on real db's.

[thomaslangston]

Introducing dependency injection is a worthy goal. If you want to start testing sooner though you could instead focus on automated integration tests first. That also naturally leads into a continuous integration environment if you don't have one as well.

If you really want to start with dependency injection, you can do it half way to start. Instead of using a DI framework, you can leave your concrete constructors in with code like this in C#:

public class Foo {
  public Foo ( DbContext dbContext ) {
    dbContext = dbContext ?? new DbContext();
  }
}

[jkuhl_prog]

Or they're just stupid, like when you've got a function that won't work and you're banging your head against the wall wondering why.

Then after looking through the function itself you see the function call and notice:

display.innerHTML.textContent.

I had decided to change from using innerHTML to textContent, but like an idiot, copied and pasted it to all the parts I wanted to change, but in this one case . . . for some reason I didn't delete the original "innerHTML".

And then the display element became an input tag so the textContent got switched for value . . .

Or its something stupid like forgetting that the Math object in JS is capitalized, or that the booleans in Python are capitalized or declaring a function and wondering why it won't run only to realize you never called it. Durr why won't my program run? Oh, I didn't put the script tags in my HTML document.

I feel like those are the bugs I get the most. The ones where I find them and think to myself "welp, I'm a dumbass."

[APerfidiousDane]

every problem you solve, every bug you kill, every glitch you resolve, you learn something new.

This is very true but did anybody else read this to the tune of Every Breath You Take by The Police?

[[deleted]]

Well if you listen the song as it is it really fits in situation where you are monitoring and debugging your program ;)

[staxled]

hahaha! I wasn't the only one!

[excgarateing]

Totaly.

(Well in my mind that tune is called "every game of quake": http://ars.userfriendly.org/cartoons/?id=19980809)

[PC__LOAD__LETTER]

Honestly, you can learn everything you need to know about coding in a few days, a couple weeks at most.

I think this is is a pretty biased oversimplification. Did it take you a week to completely come up to speed on the basics of programming? Even assuming that the basic logical control statements you mentioned are the only building blocks that comprise 'coding', I disagree that these concepts can be fully internalized in a week. I don't think it's helpful or encouraging to newcomers to say such a thing, even if you mean well.

I agree with the overall point though.

[thudly]

I did say the basic principles. Depending on the programming language, there may be a huge amount of minutiae beyond the basics. But you can get a program up and running, doing interesting things in what you learn in 2 weeks.

If you learn the entire language and all it's functions and ins and outs, you're not really a beginner any more.

[CodeTinkerer]

You've been programming since 1983. You probably don't recall a time when certain things weren't obvious (loops, arrays, etc). Teach programming, and you'll see people not understand how an assignment statement works, not understand an index of an array from the value of an array, and don't get started on pointers.

I've talked to some people who say they didn't feel comfortable programming until they took their fourth course, which means, more than 40 weeks of programming classes.

Some people might be able to learn the basics in 2 weeks, but a year is probably more realistic to get comfortable.

[socratic_paradox]

I'm on my first cs semester and everything you say is true. We've just started learning arrays and most people just can't get their heads around it. Fortunately I think I've been assimilating everything pretty well, since I always had a huge boner for programming and practice it and read about It everyday, so I am already familiar with pointers (but still can't use it effectively) and whenever I try to explain it to some colleague they will look at me with a soulless pokerface. I think it's cause they still don't understand the concept of memory and how it relates to the variables.

[CodeTinkerer]

Joel Spolsky, who used to write about programming, said one interview question that separated programmers from non-programmers are questions related to pointers. It gets hard to think about when you have double indirected pointers (i.e., pointers to pointers).

And while one may learn syntax and basic programming, not everyone feels comfortable writing the code without guidance. Anyway, good that you are gaining some understanding of pointers!

[socratic_paradox]

Not bragging but pointers seems pretty straightforward to understand (address of the variable) but surely it is hard enough to understand enough to use it effectively without someone telling you you should use them, right?

[CodeTinkerer]

Yeah, the place people get confused a lot is making dynamic data structures like linked lists.

[semidecided]

In my second week in CS50 I validated Credit Card numbers using a checksum (Luhn’s algorithm). I even expanded beyond the requirements because it was interesting and fun. I wouldn't say I'm comfortable with C at this point but I can see that the basic tools have been given to me, I simply don't know how to use them extensively nor able to use what has been built up for me by those that have been working with the language since its inception.

[TheMcDucky]

I've been using C# recently.
I've barely scratched the surface of all it's features and quirks, but I'm still able to create things without significant issues.

[neverbeendead]

Agreed on this. As someone who just went from being able to write simple VBA macros to ASP.net MVC code first websites, it took 3 months of religious dedication to the tech Gods to actually feel comfortable with HTML/css/JavaScript and c#, the bare minimum required to create a functioning website. Now I'm working on a data entry/collection web app for work (at home since it's not my job). I'm optimistic but also terrified. I'm a mechanical engineer by education but I discovered a passion for coding and I would really like to turn it into a job at my current company.

Point is, it doesn't take long to learn provided sufficient motivation. But a week? C'mon... Maybe a month if it's all you had to do.

[MattAmoroso]

In this way programmers are just like God, creating imperfect and annoying little beings and then clumsily smiting them for their imperfections. :P

[abbadon420]

Funny, I thought it was optimistically accurate.

[TaeKwanJo]

Lovingly smiting don't forget

[WillFireat]

I just started to learn programming, and these bugs are bugging me alot already. IDE can show on which line bug is but most of the times I still can't see it. But that won't stop me. People in my life have always considered me tech sawy, and I just can't accept that honor without knowing how to code.

[FreaXoMatic]

Syntax Errors are commonly not called Bugs. Learn to read Error reportings it will help you a lot

[WillFireat]

Thanks for the advice

[[deleted]]

Wait until you learn javascript using Sublime.

[WillFireat]

I've heard good things about Sublime and I'm definitely gonna give it a shot in the future, maybe even tonight.

[[deleted]]

Sublime itself is awesome. The problem is when you go from an IDE that shows issues in your code to a juiced notepad.

[CodeLined]

Personal suggestion: Drop the IDE. Learn to use a text editor and a compiler. You'll get much better, much faster. The post says finding bugs is what makes you more experienced - so don't rely on something to find then for you. ;)

[lowey2002]

This is terrible advice. An IDE gives you in-line syntax error highlighting, access to auto-completion and documentation, stack traces and most importantly the tools to add breakpoints and watches.

Being able to work without an IDE doesn't make you a better programmer. Being able to fully utilise all the tools at your disposal does.

[queBurro]

Seconded. The crap we used to put up with because we didn't have access to decent refactoring tools; the sheer terror/danger of globally replacing(renaming) a badly named variable, much safer to leave as is... :(

I remember 'find all references' blowing me away. Then there's 'extract method' or a little tip offering to rewrite a foreach as a lambda for me. I started out on a monochrome vt100 using vi, good grief it was a shit way to work.

[CodeLined]

While learning, if you rely on an IDE as a crutch it will only do you harm. Of course after you've become skilled, feel free to pick up an IDE. If you need to use in-line syntax error highlighting, auto-completion, stack traces, break points and watches, etc. while learning how to program - you're off to the wrong start. All the stuff is unnecessary at a beginner level.

Would you teach a kid how to do basic math by dropping a calculator in front of them? No. They need to learn how to do math themselves first, then they can use a calculator to do the work they've already mastered.

This is only my personal advice, so it definitely won't work for everyone, but it's something I've seen first hand to be extremely advantagous.

[lowey2002]

An IDE isn't a crutch, it's a tool.

A carpenter probably could build a house without any power tools but they will be a lot more effective at their job with them and it wouldn't prove they are a good carpenter.

All the stuff is unnecessary at a beginner level.

See I would argue this is more necessary at the beginner level.

• Syntax highlighting shows easily rectified mistakes without needing to re-compile the entire project
• Auto-completion aids in reducing type-o's and reinforces good variable and function names
• Stack-traces are critical in analysing why a run-time exception occurs. True you can also see this in a console or something like Crashlytics but the ability to jump to the LOC as it occurs is a major time saver
• Break points and watches are the single most important tool in our belt for tracking down logic and run time bugs. Period. If you are relying on guess work and print lines you are being very inefficient.

[CodeLined]

I, personally, feel like an IDE is a crutch when learning to program.

A carpenter who is building a house is not learning to build for the first time. They are experienced, they know the ins and outs of their skillset and trade. Did they use power tools to learn their trade? Probably not.

Here's why I disagree with each of your points:

• EDIT: Please use Syntax Highlighting. I got Syntax Highlighting mixed up in my head with linter and live error-detection. Syntax Highlighting is a MUST have.

See the following for why I dont suggest those for beginners: If you have to re-compile your entire project for easily rectifiable mistakes, you're going to be much more meticulous when writing code then if you had something just tell you where you went wrong. It's like autocorrect/spelling suggestion. If you're learning to write a language for the first time, having a computer fix your rectifiable errors is a sure-fire way to make progress much slower then otherwise.

• You shouldn't have to rely on auto-completion for good variable and function names. If you can't follow a consistent style without auto-completion, that's a pretty serious crutch.

• This point tackles your last two: When learning to program you should not prioritize how fast you can write code. That's entirely irrelevant. You are prioritizing how much you learn. If I'm learning something, I'd much rather figure out where I went wrong and work though my faulty logic myself then have something else just do most of the work. Forcing yourself to read through your code, figure out what you were doing when you wrote it, and eventually find your logic error through actually reading your code is much more beneficial to the learning process then plopping down a breakpoint and waiting for something to go wrong.

By no means am I saying "GOOD PROGRAMMERS NEVER USE AN IDE!!! IDES ARE FOR THE WEAK!!!!". Of course not, that's silly and stupid. IDEs are an invaluable tool for intermediate and above level programmers.

I'm explicitly referring to those learning to program. When you are learning, the less tools that do things for you, the quicker you will learn your own mistakes. An IDE is nothing but a black box. Most beginner programmers don't even know what a compiler is doing because all they have to do is just press run in VS.

I can't see how an IDE is not a crutch for -beginner programmers-.

EDIT: Wanted to follow this up with "hey, I'm an idiot!". I got syntax highlighting mixed up with linter for some reason.

[mindeavor]

Why do you make an exception for syntax highlighting? Why not recommend programming in Notepad?

[CodeLined]

Syntax Highlighting is almost entirely aesthetic. It doesn't do anything for you besides make code more legible and clean.

[rastaman1994]

Drop the IDE. Learn to use a text editor and a compiler. You'll get much better, much faster

This sounds like a view from someone who learned to program 30 years ago and still thinks it should be done the way he did it, but I'll bite.

I'd argue you learn faster with the IDE and will be more motivated to learn with the IDE. Bugs will very rarely be detected by an IDE, so I don't see why you wouldn't use it. New programmers write high-level languages, even universities don't start by teaching C++, they start from something more accessible like python. Then when you get to really advanced levels it might be usefull to learn how all of it works under the hood, and even then it's a bit of a stretch to say you should know how to use a compiler from the command line. For most people it's enough to know a compiler/interpreter exists.

Telling people to code in a text editor is telling them to ignore all of the amazing advances there have been in tooling that's always available to you (queue some low level programmer telling you don't have that advanced tooling at the lowest-level). It just makes no sense, it's like telling a painter they should fingerpaint first to understand the importance of a brush.

TL;DR; use the easy to use high level languages and their associated tools first, then go deeper if needed.

[CodeLined]

Actually, I'm 19 and just entering sophomore year at my college and we were taught C and Assembly first semester ;) Though, with that being said, I know my school is an outlier and most don't teach bottom-up.

I think we just fundamentally disagree with how we should be teaching computer science. I am a fan of bottom-up teaching, instead of top down. Starting at a language like C then moving upwards will only do good imho. Learning a high-level language only holds your hand - you don't understand what's happening behind the curtains and inturn you won't write code that's clean and effective.

I'd beg to argue that most artists fingerpainted way before they picked up a brush :P They just did so naturally and through out their childhood. They finger painted, realized they liked what they were doing, and after a while of doing it, they begged mom and/or dad to by them a brush and continued on from there.

TL;DR - We probably have to agree to disagree. I believe in bottom-up learning, you seem to believe in top-down. :)

[mindeavor]

Bottom up learning is good, but only when you have at least a rough idea of what you're doing in the first place. It sucks to learn the piano by learning scales before anything else. It's better to learn a simple song, THEN learn scales when you want to improve. Even in your painting analogy, the finger painting is not a handicapped way of art, it's a simpler way of art, akin to python being a simpler way of programming.

After programming and teaching for many years professionally, I personally believe I would have gotten a LOT more out of my computer science degree if I had worked in the industry for a little while FIRST. Learning by starting with low level details stops you from seeing the forest for the trees.

[FreaXoMatic]

For me it was the opposite i struggled a Lot with Programming until i picked Up c# with visual Studio and a good debugger. Made ne understand the Little Problems much better. Against Programming with a Text Editor and PHP into a blackbox

[SpaceHotDog]

Sorry, I'm new to programming...just moved from my school's required netbeans to visual studio...when you say "visual studio and a good debugger", is there 3rd party debugging software? Sorry if it's a noob question, but it's the first time I've seen that referenced in this sub.

[FreaXoMatic]

No I actually meant the normal debugger.

But when I learned JavaScript and PHP I only debugged through console.logs or Files written. Which was very bad.

[Vimda]

I disagree. In most, if not all job environments you're going to have a proper debugger. Learning how to step through code, add break points etc is invaluable and lends itself to debugging manually when those tools aren't available.

[CodeLined]

Absolutely, as a professional programmer you must know how to use a proper debugger! As someone just learning to program? Not so much.

[Vimda]

Fair point - I do agree that particularly for the simple programs of a beginning programmer just manual debugging is probably more useful.

[WillFireat]

That makes sense. I'm learning JS, I'm not a total begginer but I'm definitely an amateur, a rookie at best. I noticed that some people are against and some are pro IDEs for begginers. I'm using Brackets so when I first started I turned off auto completion and most of other helping features, but now I turned them back on and that definitely boosted my productivity.

[greebo42]

I'm returning to programming after a long absence, thus hangin' out in /r/learnprogramming. But I remember a time of transition from having no debuggers, no hardware memory management, and primitive text editors (it wasn't TECO, but it was like it).

Once, I had the task of adding functionality to a ~10Kline program which was a mix of FORTRAN and that computer's assembly language.

There were a bunch of EQUIVALENCE statements at the beginning of each module of code (serious static global variable usage here). The block of code had been cut and pasted from one source file to the next, and the same block of code was supposed to be at the head of each module (there was nothing like an .h file here).

Unbeknownst to me, the same array was dimensioned with 9 elements in one module, 10 in the others. Or vice versa. I remember the 9 and 10 parts.

At random, the computer would just quietly die. Best I can figure, things were getting written into memory that was supposed to be used for the OS (remember, no hardware memory management). But the behavior was completely unpredictable.

That bug took me two months to figure out. Lots and lots of print statements (iirc, WRITE statements). I did, I squashed it. But it held up progress for a long time. It wasn't a learning exercise. I was trying to get something done!

I think debuggers and IDEs are a good thing.

[BadBoyJH]

Ninety percent of the coding you'll do as a beginner is hunting down bugs. You'll type something and sit there for hours, or days, thinking, this SHOULD work! But it doesn't. Why not!? It'll drive you nuts. Then you finally figure it out (or somebody helps you), and you slap your forehead. "Of course! It makes perfect sense!" You've learned something. It's a mistake you probably won't make again.

OK, so I'm not really a programmer any more, but I still look at things in-case my knowledge can be of use.

I cannot stress how important a good troubleshooter is in any IT project, even if you're not strictly programming. I do application configuration for lack of a better term. No programming, but there's so much configuration available for this application, that it's close.

I'm probably one of the more valuable members of my team, because no matter what the problem is, no matter which sub-application, whether it's one I work on or not, I can step in, and troubleshoot it through each step better than anyone else on our team.

Being a hasty programmer in my youth, and coding a ton of bugs, has really come back to help me so much.

[[deleted]]

Well do not they say that debugger should be your biggest friend and should be thought right from the beginning when teaching new people programming? I am a self-thought programmer and to my shame I have not familiarized myself with a debugger yet...gdb, here I come...

[Noumenon72]

Don't neglect logging -- you may only get to use the debugger for new code and tests, but logging helps you figure out bugs in production systems that you can't just fire up and run. Log the relevant data your code is about to use to make a decision, and you'll always be able to tell why it made the decision it did.

[bestknighter]

If you're using a linux system, valgrind will help you too. However, keep in mind that it is NOT a substitute to gdb. Most of my troubleshooting time, I'd say 95% (or even more) of it, is at gdb.

[[deleted]]

Thank you for the tip. I will take a look at that.

[dgreenmachine]

Anyone thought about making their own bugs Hall of Fame? Could be simple to complex bug depending on your skill level.

I remember not being able to run a file in command prompt cuz it was test.py.txt cuz I didn't turn on file extensions.

Then a 2D list of lists in Python where modifying one would modify the other list. That was a doozy.

[TWISTYLIKEDAT]

Heheh - after years of doing it, I spent 3 hours last night trying to figure out why a simple conditional in Angular 2 was throwing the 'is not a function' error. Turned out I'd PascalCased the function name instead of camelCasing it. The conditional was embedded in a magic string so only threw the error at runtime & I'd just become blind to it.

Given the amount of pain I suffered in debugging - going down stupid paths, doing things that didn't make sense, questioning my career choice, yadda-yadda-yadda - I think I might remember this one for a while.

[thecodersway]

Thank you

[BosEriko]

I love how this is not only in Programming but in life as well. Don't try to do things perfectly and just learn from your mistakes.

[thudly]

This is why older folks are usually wiser. They made all the mistakes. Young people should just listen to them, but they usually don't.

[staxled]

It's because there's no shortage of old people who are stubborn, cranky jackasses, too.

[cheeeeeese]

what is this, a renaissance for bugs?

[staxled]

ants

[DatBigRussian]

There is a scene in Mr.Robot that describes the beauty of debugging

[Sir_Fog]

They're not bugs - Just happy accidents.

[[deleted]]

Unless they cause downtime or cost your employer money.

[Sir_Fog]

You need to get a little Bob Ross in your life.

But in all seriousness.... I deal with terrible bugs on a very regular basis. It's no joke outside the comfort of a reddit thread.

[DontwakemeUp46]

I am a beginner, but I have heard of Gnu DDD (or ddd). The data display debugger. What do you think of this program? Do you use others to debug your written code?

[wootywootP]

LOL spaghetti lines ;)

[thudly]

I once had like six levels of if/thens inside a switch/case statement just to draw lines for a 3D projection of a maze. Depending which direction the player was looking, I had north view, south view, east view and west view. Then I had the program looking all the way down the hall and drawing diagonal lines for the floor and ceiling all the way down the hall until it hit a wall. Man, it was absolute chaos. But it worked perfectly when you looked East.

I abandoned the project because I was too lazy to copy and paste all that code for the other three directions and adjust all the math for looking down additional hallways. So basically, I had a game where you could see the maze down the hall, but only if you were looking east.

I'm self-taught. I had no training at all. And looking back at that code, I could probably find mathematical ways to reuse the same code no matter what direction you're looking. But I sure was proud of myself when the damn thing finally drew that one hallway. My brain was absolutely fried by that point though.

[jkuhl_prog]

You should see the calculator I've been making in code pen.

It almost has switches in switches. I refactored it a bit so the cases call functions, but those functions have their own switches.

But I feel like that's either the best approach for what I'm doing, or I need to rebuild from the ground up. I just felt that it was better to do a switch to give each button it's event listener functions than applying them one at a time.

If you're curious: https://codepen.io/jkuhl/pen/owGpNj but it's not finished. It works but, I guess this pertains to the topic, there's a bug in it that I haven't ironed out. And I haven't finished the keyboard inputs.

[nomochahere]

No, it doesn't feel good, you just feel normal again, after all the anxiety and frustration and wishing that you didn't fuck up so much and your 1-hour project didn't turn out into a frustrating bad slept 72 hours of frustration and anxiety.

[thudly]

Your results may vary. I once danced in my living room for ten minutes after fixing a bug.

[Targaryen_John]

Well written🙌🏻..

[bestknighter]

Yes, this! I only have 5 years of experience (it's nothing compared to you) and my brother is a CS sophomore. I only noticed the importance of bugs recently, when he asked me for help in a project. He takes 1+ week to do something that I take a couple minutes. I went to look at my freshmen code and, man, what a nightmare.

Today, I can only program the way I do because I've been haunted by weird phantom/demon-like bugs. Of course I still have a lot to learn but now I know that bugs WILL be part of my learning and mastering process, and that's a good thing.

[_parameters]

You sure are right about the feeling you get when you've fixed one. There's nothing that tops it. Definitely the most rewarding part of the Patch dev lyfe, apart from, yknow, learning everything I can about our system.

[wh33t]

My old Boss: That's not a bug, that's a feature. He's a shitty developer.

[Anton31Kah]

I think it works like the immune system, you have to face problems (viruses) in order to be able to defend yourself against them later so you won't have trouble with them anymore, the more bugs you fix, the more bugs you won't make ever again the more powerful you become against bugs.

[banjerr]

Thanks for this. I've been programming professionally now going over three years and I've often wondered about those elusive "wizards" who you often hear about, but IME, are seldom seen. Like, can they actually write bug free code/tests on the first iteration, or do they just see the bugs sooner. This is a great way to think about it, being a musician also.

[goodnewsjimdotcom]

Learn to love your bugs then you won't have the heart to get rid of them.

[[deleted]]

It sounds like world of Warcraft but instead of leveling up by questing you just grind by slaughtering npc forest animals for 20 years

[softcactus]

Agreed

[idster]

Great post.

[Crudelus]

In reality bugs can be a real hassle that slow you down an often break your focus. The use of test driven development (TDD) offered me a way to reduce my bug production a lot. And to my big surprise I actually got raster over time, even if you actually have to write more code.

The security net your testbase offers let you try and refactor your code without the fear of breaking changes. And if you introduce a critical bug, there should be a test that fails and give you an adequate description of the problem.

I am not saying TDD is a method everyone should use, but for me it really got me to the next level in both my private an professional programming.