4 ms·

This guy has not discovered what it means to be a programmer, he is simply in a phase of his programming life. Chasing down bugs all the time? Why? I don't d

by Sakes 14y ago

This guy has not discovered what it means to be a programmer, he is simply in a phase of his programming life. Chasing down bugs all the time? Why? I don't do this, and when I run across a bug it is usually a quick fix and not a big deal. The goal is not to write it perfectly without bugs. The goal is to release it perfectly without bugs, and to do this all you have to do is test your code often as you make changes to it. (alt tab || cmd tab is your best friend) Now, if you are running into bugs that take you 4+ hours to resolve, you simply have not been programming long enough. Over time these will be trivial issues for you. What is amazing about being a programmer is the ability to create amazing things. Being a programmer is not awesome because writing conditionals and for loops are badass.

mikegerwitz 14y ago
> 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).
- Sakes 14y ago
  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?
  - gknoy 14y ago
    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.
    - Sakes 14y ago
      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.
irishcoffee 14y ago
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.
- Sakes 14y ago
  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.
- mamoswined 14y ago
  One of my first jobs was just debugging some awful legacy software. Let's just say I got a lot of negative feedback.
wam 14y ago
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.
- Sakes 14y ago
  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.
  - wam 14y ago
    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.
abc_lisper 14y ago
> 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" :)
- Sakes 14y ago
  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.
hollerith 14y ago
>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.
- Sakes 14y ago
  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.

by Sakes 14y ago

mikegerwitz 14y ago

> 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).

Sakes 14y ago
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?
- gknoy 14y ago
  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.
  - Sakes 14y ago
    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.

irishcoffee 14y ago

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.

Sakes 14y ago
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.
mamoswined 14y ago
One of my first jobs was just debugging some awful legacy software. Let's just say I got a lot of negative feedback.

wam 14y ago

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.

Sakes 14y ago
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.
- wam 14y ago
  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.

abc_lisper 14y ago

> 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" :)

Sakes 14y ago
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.

hollerith 14y ago

>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.

Sakes 14y ago
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.