> Now, if you are running into bugs that take you 4+ hours to resolve, you simply have not been programming long enough.

I'm sorry, but that statement is untrue; there is no generalization for the term "bug". They can be as simple as "your borders on this web page are misaligned" to a subtle memory leak that can only be reproduced on a small fraction of users' systems. Or maybe the bug is a fundamental design flaw that requires rethinking the entire project (oops).

Now how often do you run into these subtle memory leaks? How often do you run into fundamental design flaws? Once, twice a year?

If it happens so rarely, which for most developers I believe it does, why would you allow it to get you so jaded? Why would it be apart of your daily concerns or something you felt you needed to prepare for?

This depends heavily on the legacy of the codebase you are working with, I imagine. I'm thankful that I (nearly?) never run into serious design flaws, because the people that built this code before me did a really good job. I could easily imagine a worst-case scenario where the code you're maintaining was written by a stream of interns, implementing requirements written by committee, over the space of a dozen years. Fundamental design flaws might be so ingrained, and the codebase so large, that you could not easily refactor it into something nicer.

This is true, but if you are working on such a large code base, and you like the company you work for, you will be working on it for a long time. You will become familiar with the coding style (or lack of style) of the original programmers, and you will be able to recognize their mistakes quicker over time.

Rewriting it is always on option, maybe not the correct one, but it is an option. But probably better is to figure out how to rewrite it in pieces.

If you are working with a legacy coldfusion or php code base, god help you. But there are still ways to abstract the original code to allow you to implement a more gradual/iterative code rewrite strat.

Sounds like you've never been tasked with working on a huge base of code you'd never seen before. If all I ever did was work on code I wrote, I could see myself thinking like you do.

This is not the case for a lot of people. Maybe in this HN startup bubble, but not in the "real world" of software engineering.

That is a good point, but I do have the perspective you talk about. I started out at a web shop for 4 years, so I'd spend a lot of time in other peoples code. I then moved on to a nice little SaaS company with a 10 year old code base which had a bunch of legacy code that I had to deal with when first starting out. I had to pick up a variety of languages that I had not used professionally before. I have spent 4 years there and am leaving at the end of this week to start my first company.

But my belief is the same, the solution to the problems described in the article is time/experience, not the adoption of some pessimistic mindset. You will run into bugs when working in other peoples code, as a result you will learn not to make those mistakes. Over time you will get quicker at identifying similar bugs and will be able to resolve them quicker each time as well.

The most common answer to any CS question that you are asked in college is "It depends". So how do you resolve these nasty legacy code bugs? Well, it depends. Is this code reused a lot in other places? Is this critical functionality to the user? Once you determine how important the buggy code is, you can decide whether to solve it with a hack or a well thought out solution.

Don't sweat the bugs, don't become a Debby Downer, fix them as they rise, and keep building cool shit.

One of my first jobs was just debugging some awful legacy software. Let's just say I got a lot of negative feedback.

>if you are running into bugs that take you 4+ hours to resolve, you simply have not been programming long enough.

Firefox had a memory leak that took years to track down and eliminate, so according to your logic Firefox does not have any employees that have been programming long enough.

Well, I was speaking generally when I wrote that. I probably should have put in the word frequently to be more specific. I did not mean to imply that one day you will reach a point where you will never battle with a bug for over 4 hours again! But in my defense, I did write run into bugs and not bug.

Well, sure, but everything in life is a "phase." A whole career might be a phase. But that's not the point. This post clarifies a vague problem. It's great that you've avoided that. Good for you! Seriously. But to say that he hasn't "discovered what it means to be a programmer" isn't helpful:

Someone doesn't feel amazing about being a programmer. Programming is amazing. Therefore that person is not (yet) a programmer.

And the "(yet)" is unimportant here, because a negative feedback loop is exactly what gets in the way of experiencing the amazing part.

The point isn't really to define what a programmer is, it's to define a problem that many people who work as programmers experience, and how that contrasts with other people's expectations.

I think I may have misrepresented myself. I have not avoided the buggy hell described above. I have lived through it. My point is, his problems are temporary and expected for anyone that cares to better themselves. So it is perfectly natural for him to be upset about it, and his emotions are valid.

What is dangerous is he is currently leaning towards the idea that to be a good programmer you must be pessimistic, always afraid of the all the crazy unknowns that might happen. This is wrong, there are techniques to avoid these problems that will naturally become part of his programming style over time. No need to be a pessimist, no need to be afraid. Just keep on plugging away and one day he will wake up and think, its weird that programming does not feel like I'm pushing a rock up a hill anymore.

Edit: Also I never said he was not a programmer, I said he didn't yet understand what it means to be one. We all go through this, and he will realize it eventually. I just hope he doesn't end up as jaded as his article assumes he will.

I know, but I think the way you were talking about it brought "what it means to be a programmer" into line with working as a programmer generally. He's talking about how a pessimistic feeling about being a programmer arises. But I think you're essentially saying: just avoid that problem and it'll work out. That train has left the station.

You say "no need to be a pessimist" but I don't think that's what's going on at all. If you encountered a bug in a program, you wouldn't say "oh, program, don't be so pessimistic, just keep running and you'll be fine!" He's diagnosing the problem, not declaring that it's insurmountable on a case-by-case basis. I don't think that's dangerous, I think it's appropriate. When you see the feedback loop more clearly, you can deal with it. Ok, that might mean pushing through to a better place (if one believes that will work for everyone, as it has worked for you) or it might mean finding a different career.

I just don't think your description of waking up one day and feeling that things have gotten easier squares with what a lot of us experience. Things do not always get much easier just because you keep going, or because you try one thing after another. Sometimes the work gets much more rewarding, for some people, but you can also burn out before you reach 10,000 hours, and it's not reasonable to say that people should simply figure out how not to burn out. To pin that all on a pessimistic attitude is trivializing a non-trivial problem.

You have really made me think with this comment. I will have to come back later to address it properly.

For the record, it's clear to me that you're speaking from a sincere desire to share what's worked for you (including a bunch of sound strategies for addressing problems as they arise) with other people. That's super cool. I just want to defend the idea that there's more to breaking the bigger cycle of drain/burnout described here than choosing to think positively.

I'd like to start off by saying thanks for for holding my feet to the fire on this one. It has forced me to rethink what I have written which is almost always a good thing, and in this case I believe it to be good.

What you have made clear to me is that I made a mistake in my interpretation of the OPs post. I had incorrectly assumed that he believed that to become a good programmer that you had to be pessimistic.

What he actually said was (not quoted) in order to be a good programmer he needed to adopt a certain mindset, which was to focus on the negatives. He believes this mindset is slowly making him unhappy because it is constantly reminding him of all the mistakes he made throughout the day, every work day, of every year.

I did overgeneralize his problem, and that was my mistake. I still contend that his problem is temporary and that he should not worry about it as it is a natural part of growing as a developer.

After reading his post a second time I realized something. He doesn't just think of tracking down bugs as focusing on the negatives, but he considers the bugs to be an actual list of his failures. Any bug to him is a failure at any point in development. No wonder he is upset. What is a bug to you? To me a bug in the wild is a huge, huge embarrassment. I feel just awful when one sneaks by. But a bug caught in development is nothing more than a logical typo. If you are a writer and you publish an article incorrectly switching you're with your, or their with there, you would feel dumb. But if it happened while you are burning through your first draft? Is this a failure? No just a minor mistake that you can resolve relatively quickly.

The solution to feeling bad about bugs is not to think positively about bugs, but simply not to worry about them. They will happen, you will catch them, and you will get better. I'd like to elaborate more on how doing nothing will fix the problem. I will probably do so tomorrow even though these comments will probably be dead. Thanks for going back and forth with me, it was fun.

> This guy has not discovered what it means to be a programmer, he is simply in a phase of his programming life.

Very well put. I see so many posts here that I roll my eyes over. This is not to put them down, may be it has to do with the fact that we as programmers don't talk about our "feelings" :)

I'm glad you liked the comment :), but I do think it is good that he has shared his feelings. Whatever you can do to gain new perspectives and grow should be done. My hope is that after writing this article that he reads through all these comments and realizes his future is much brighter than he currently believes it to be. And that all the frustrations that he is experiencing are temporary and will quite quickly go away.