Having the mindset that the mere existence of bugs constitutes a personal or professional failure is probably very unhealthy. Is this something developers experience? I've never felt bad about a bug before. I just go and fix it. No pain, just gain.
Breaking things and inconveniencing others are a much bigger drag for me. Those are the problems I stay late at work to solve.
It's not that "that the mere existence of bugs constitutes a personal or professional failure".
Rather, in order to debug I have to go into negative mode. It's a mindset where I'm mentally combing over something, trying to illuminate everything that's wrong with it.
It's not even that important that it's your code. Focusing primarly on the good aspects of something is a healthier mental model - but not one that will get your code debugged.
I have a very intelligent friend who try as he might cannot learn programming. He has interests all over the academic board and teaches two unrelated courses. I think I understand now why he cannot. He's an eternal optimist. I tell him he's selectively ADD about programming, but maybe he's just allergic to the negativity of it all.
This brings up an interesting concept. All great creators (artists, programmers, woodworkers, hairdressers, etc) tend to be more pessimistic than optimistic. If you attitude is "Wow this program I wrote is totally awesome, I deserve a pat on the back", then you'll never improve upon your program and you'll end up never improving your skills and will end up a rosh katan[1]. You have to be the kind of person who sees each of your creation in a constant state of less than perfect in order for you to act upon making it better.
Interestingly enough, people on the other end of the spectrum (sales people, executives, marketing people, etc) have to be the opposite. You can't have any doubts about the awesomeness of the product. Doing so would be counterproductive.
Instead of submitting yet another bug report, you should totally submit a "bug" that is nothing but positive feedback.
A truly good product will have fans sending in messages and talking about the things they love -- make sure these comments make it to the developers too!
Yah, but you always get that one person who no matter how good the product is can find a way to rip it apart. It's really sad :(. However the person who wrote this is most likely a "bug fixer", I know a lot of programmers who's day is
* Make something
* Meet about making something
* Make something else
* Go home
It sounds like a plateau, where he's not getting noticeably better from the mistakes he's making (so that he's not making them as much with each chunk of code he writes). Maybe this happens when you're close to your full potential?
I think part of progress is a continual taking on of new and harder challenges - new technologies, advanced features etc - so your error rate should be fairly constant
Programming always gets more difficult. I'm a much better developer than I was 10 years ago and I don't make the same design or development mistakes. But instead of writing perfect code, I'm working on larger and more difficult problems. In fact I'm now responsible for so many more platforms, systems, and programs that I probably spend more time dealing with problems than ever before.
I guess my take on it is different. The things that I've found to be the source of bugs/problems for me are areas that can scale to larger problems. Things like component communication, algorithm edge cases, typos, poor memory management, etc. For me, the error rate slowly goes down, because I've learned to compensate for my weaknesses. Maybe your (and his) weaknesses are not as portable to other and larger problems/systems?
I'm sure my error rate is a fraction what it used to be but I'm producing far more code and working on far larger problems. You better hope that areas of improvement on are the ones that scale to larger problems.
The original article was about error rate, that's what I was talking about:
1. write some code
2. run the code
3. get an error message
4. find the error and back to step 1
Hour by hour, day after day, I do this. Always searching
for what's wrong with what I'm creating, rarely thinking
about what's good about it. It's a negative reinforcement
feedback loop.
If the error rate was lower, steps 3 and 4 would happen less frequently.
My original point was that #1 doesn't stay static -- if it did, then I'd be writing perfect code right now. Instead the code you write gets harder.
Even then, I don't think the author intended you to take that so literally. That's an easy way to describe the problem to someone who isn't a programmer. The negative feedback loop is much longer and more complicated than that.
I think one way to help fix this negative feedback loop is to use the advice of the Harvard Business Review's article "How Customers Can Rally Your Troops" (src: http://hbr.org/2011/06/how-customers-can-rally-your-troops/a... ). The premise is that consistently showing your employees proof of the positive effects your organization's products produce for end-users can drastically improve motivation. I just linked to the abstract, but the full article goes into the dramatic effects this technique had on a university fundraising call center (a job with constant negative reinforcement).
Positive feedback is definitely important. As developers, we very frequently hear about things that have gone wrong but we're only rarely told about how what we did resulted in success for the company.
functional programmers get to express their ideas as code
imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas
just look at the research[1] coming out of the <del>Clojure</del> functional programming community - especially Datomic. once you learn how to get your defect rate under control, you have time to explore crazy awesome new ideas
You don't have to convince me of OOP's faults; Clojure is my favorite language. But I write code for a living, mostly in OOP because that's where the jobs are, and I do not write very many bugs caused by OOP's poor design. I write bugs when the business is ill-defined, or when I misunderstand how a library's APIs are supposed to work, or when I'm careless and don't consider "what do I do if this function returns false"; all stuff that will come up in FP as likely as it will in OOP.
Languages like Haskell show this tendency too, e.g. Oleg's work[1] (which includes research with lisps) although he also does awesome stuff with imperative languages too.
functional programmers get to express their ideas as code
imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas
Stop drinking the cool-aid. Functional programming solves a lot of typing errors (if the given language has stronger typing than an imperative language) and makes composition easier in some cases (if the language is lazy).
But: an algorithmic error is still an algorithmic error, an incorrectly designed data structure is still an incorrectly designed data structure. No matter what language you use.
In addition to that, you get back a different set of problems: e.g. you have to reason about when something gets evaluated in a lazy regime in order for your program's heap not to blow up, and the translation to machine code is often not nearly as simple as an imperative language, which makes it harder to optimize functional programs.
Apparently, I come off to some people as very pessimistic. I don't feel pessimistic but, as I programmer, I'm trained to focus on all the things that can go wrong and consider all the edge cases. This is a useful skill but can also be perceived as very negative even if that's not what I intend. Unfortunately, it's a skill that is also hard to turn off and ironically it's worse if I'm actually enthusiastic about something.
Indeed. Or go work on software for manned space vehicles, or medical devices, or huge financial institutions, or anywhere where the consequence of bugs is "people die" or "national security is compromised" or "society collapses" or the like.
I wonder if you couldn't formulate a rule to the effect of the more serious the task you are working on, the less you can afford to be optimistic. When Serious Things are on the line, you have to be a pessimist, because you have to find and root out all the possible weird failure cases before they bite you. When all that's on the line is a comment on someone's photo of their lunch, optimism is a more sustainable philosophy.
Something that struck me from your comment is that yes, there are more serious repercussions than others. The problem here is that the pressure and feedback from those repercussions is relative, and knowing this makes it especially difficult to accept tons of negativity. If a bug caused someone to die, and this was preventable (i.e. obviously your fault) then yes, you should feel horrible. Most of our jobs though, involve loss of money, not loss of life. The pressure to fulfill these tasks is therefore completely constructed. Success or positive feedback is simply that the people paying you continue to make money, the status quo continues.
Being optimistic or pessimistic isn't quite relevant when people's lives are on the line, I think it's more about being _realistic_. Everything can fail, and everyone makes mistakes. This is reality. When people can die, there is much more impetus to pay (time and money) for everything to be triple-checked and triple-redundant.
But in pretty typical software development, that money and time isn't there. And the feeling of knowing you could have done better, if only given a chance, is horrible and eats away at your resolve. Then you wonder, "well perhaps I'm not fighting strongly enough," or "People are coding for space shuttles, and I can't even get this page to load!"
I believe it's a human right that your individual problems are no greater than another's, because it's relative. If you feel about it strongly enough, then it's valid. Saying it's not because people's lives aren't at risk is invalidating the human right of pursuit of happiness.
It is a different mindset when you are writing code and thinking 'Did I cover all the cases?' instead of 'What can go wrong?' For me, thinking about all the cases is a positive and fun thinking process, not a negative one focused on what can go wrong.
how do you create good and worthwhile things if you do not try and make them better? how will you make them better without finding the elements that can be improved and improving them? maybe this is part of the engineering mindset, the ability to approach the world with "how can I make this better" and not be depressed and overwhelmed.
I used to get super frustrated and depressed when people edited my writing/prose. each comment was some way in which I sucked. then I compared, side by side, my early drafts with finished works. now I'm not frustrated or depressed when people find problems with my writing! or my code.
I think that people need to realize that a developer is someone that simply builds the solution to a problem no matter what that problem may be (ease of use, a new business etc.) If you use that train of thought it only makes to focus on all of the things that do not work to successfully achieve the goal of finding the thing that does. So regardless of how good their code is the developer has to have the mindset of first fixing all the bad to deliver a working solution.
My partner and I just had our first iOS game approved. We had to ship without a bunch of features we had planned for (e.g. non-English localizations) simply because we ran out of time. During the final stages of the project, we thought we'd like to do something like a web-comic, to share the human story behind the development of the game. Now that the game is approved and we're reviewing our notes and drawing the comic (it can be loaded dynamically into the game as a slideshow, and it will also go into our facebook page/company blog at http://noisytyping.com), our view has shifted from 'we could have done better' to being very pleased about the whole journey: how we started out, what challenges we faced (automating level-generation was one) and how we managed to stick to our plan and ship it. Without the postmortem, we'd probably never be motivated to make a game again.
I can identify with some of what the author has saying, as I've struggled with a pessimistic attitude throughout most of my adolescent and adult life. However much of it was formed long before I learned to code. I've recently been working to be more optimistic as I think it can be learned.
However, I suspect pessimists tend to make good programmers rather than programming causing someone to become more pessimistic.
If you're interested in understanding some of the psychology between Optimism and Pessimism, I recommend reading Learned Optimism by Martin Selligman. http://amzn.com/1400078393
"However, I suspect pessimists tend to make good programmers..."
It might also be that pessimism could limit programmers' capabilities by making them afraid to take on ambitious problems. Being somewhere in the middle of the spectrum might make someone a better programmer than being either too optimistic or too pessimistic.
There is nothing intrinsically negative about anything said here, just neutral things viewed in an extremely negative lens. Here's the exact same set of steps making up the "normal workflow", but framed as a positive feedback loop:
1. write some code
2. run the code
3. get further than you did before (perhaps with a new error message)
4. decide what's next and go back to step 1
I don't think negativity is intrinsic to the profession. I get to build things every day. I get to fix problems. That's an incredibly satisfying and positive thing.
That reminds me of an old story about how different people can look at the same job in different ways:
A man came across three masons who were working at chipping chunks of granite from large blocks. The first seemed unhappy at his job, chipping away and frequently looking at his watch. When the man asked what it was that he was doing, the first mason responded, rather curtly, "I’m hammering this stupid rock, and I can't wait 'til 5 when I can go home."
A second mason, seemingly more interested in his work, was hammering diligently and when asked what it was that he was doing, answered, "Well, I'm molding this block of rock so that it can be used with others to construct a wall. It's not bad work, but I'll sure be glad when it's done."
A third mason was hammering at his block fervently, taking time to stand back and admire his work. He chipped off small pieces until he was satisfied that it was the best he could do. When he was questioned about his work he stopped, gazed skyward and proudly proclaimed, "I'm building a cathedral!"
It's an old story that probably pre-dates programming and I've seen it several times in different places. I have no idea what the actual origin is. I just searched the web for "I'm building a cathedral" and used the wording I found here:
But this isn't what the piece describes. The author is talking about the _feedback_ one receives while doing work. Take the 3rd mason and start giving him a list of what's wrong with the work he's doing every day until the cathedral is built, and see what happens. This stonemason example, while touching and certainly applicable to some situations, is just too far removed from the reality of what many programmers experience to be relevant here.
I was addressing what the parent comment (from peeters) insightfully observed about the original article's four-step workflow description: getting to the next bug and fixing it could either be thought of negatively ("damn, I have another bug in my code") or positively ("I've solved this problem and made some forward progress"). Whether you find this negative or positive is a function of your mental state.
This is analogous to the mason's iterative workflow: noticing that his stone doesn't yet fit quite right and chipping a bit more off the side until it fits perfectly.
During development, most of our daily feedback comes from the code itself, not from people yelling at us about how broken it is (although that does happen sometimes).
The author explicitly says that fixing bugs feels good. But the point (as I see it) is that the workflow often obscures the larger positive goals of the endeavor and tends to burn people out, and that's a net negative. You can argue that it shouldn't, but I don't think you can argue that it doesn't.
Everyone wants to be that 3rd happy mason. But that story doesn't tell you how to do that, it just suggests that it's a better way. Saying that it's just a function of your mental state is tautological.
The story tells you explicitly. Don't stare at your watch, think about the product vision.
Every day I go to work to fend off spies who want to steal your data. Protecting the powerless, defending your freedom! I will never meet you, and I will never even look at the treasure I am defending, and most of time is spent fixing broken configs, but I am doing it for a good cause, and at the end of the month I enjoy my paycheck too.
>Take the 3rd mason and start giving him a list of what's wrong with the work he's doing every day until the cathedral is built, and see what happens
Even the smartest people I know write imperfect/buggy code, especially the first time around. If you don't take it personally - as you shouldn't - I don't see the issue.
I don't understand the issue either. A compiler warning or exception report is immediate and precise feedback. What could be easier to deal with impartially?
The bigger picture of course is that criticism, whether it comes from other humans, machines, or oneself, is the only way to improve anything. If you want to create anything worthwhile you have to have some mechanism to improve. Why would we want to bury our heads in the sand just so that we never have to hear a critique?
I suppose you could get a rote job on an assembly line and spend your free time watching TV and you'd never have to hear another complaint, but that sounds like an absolutely miserable life to me.
Yes, feedback is helpful and you shouldn't take criticism personally. No disagreement. But feedback that's mostly focused on small problems is draining and criticism is draining. If that's not the case for you, awesome. It's the case for some people. Try to empathize with them. The article articulates that draining feeling and I find that pretty insightful and useful.
I agree. And to add to that let me say something about a boss I once had.
I would pair-program with this guy, and be astonished by his habits. I have had to have a goal of monitoring my anger for as long as I can remember. And I had no idea how much of a disadvantage this was in programming until I programmed with this boss.
After every recompile, the resulting errors/warnings would fuel my anger until I was true frustrated to continue. As you can guess it is hard to get anything done like this.
Where I would get angry and frustrated, my boss would get happy and pumped.
He was excited at an issue/problem, because he liked the challenge, but mostly he loved to learn.
With each error he'd announce how we were about to learn something new.
The punches are pulled in this piece. Not only is the compiler continuously complaining, once you ship code, your customers call in to complain about every conceivable bug and a great deal that weren't conceivable. You can have thousands of happy customers, but you as the developer will hear from the three guys with obscure configurations and bizarre setups encountering bugs. Shipping software is ten seconds of "Hooray", followed immediate by a breakdown of what terrible things are already wrong with the next release.
I'm surprised any of us can hold up under the withering torrent of negativity that is any serious programming job.
I actually don't mean this as a complaint, either. I've adjusted. I've been doing this for 15 years. But I've been sort of stepping back lately and looking at my job from other points of view, especially as I deal with coworkers who aren't so adjusted/adapted, and not only do I now understand where they are coming from, I find myself wondering how adaptation is even possible. It's absurd how negative the interactions are. Keep track someday of your professional interactions and look at how many of them are negative; bug reports, missed deadlines, "we can't do that", etc. Or perhaps, don't, if you've never thought about this before. I sure hope you have an otherwise positive workplace.
But this is true of any "producing" profession. Any time you're creating something and "putting it out there", there's going to be a huge stream of criticism from every direction. Artists, writers, musicians, engineers, carpenters, etc.--all of their work is constantly under scrutiny by "the customer" and/or "the boss".
Even non-producing professions have to deal with constant scrutiny of their performance and negativity. Salespeople might make one sale out of 20 attempts. Anyone in a medical profession is under extreme pressure to not make a mistake (and sometimes things go wrong even when you do everything right).
There are very few professions who don't have to deal with the whole "focusing on the negative" thing (I can't actually think of any). It's pretty much a fact of life that if you want quality, you have to systematically eliminate your weak spots.
You make great points, and I agree with everything except: systematically eliminate your weak spots.
Sometimes that is what you need to do. But sometimes you are better off further enhancing your strengths to real excellence rather than bringing up your weaknesses to an acceptable level.
Sometimes you can really sell your strengths, the things that make you stand out, and then work around the weaknesses by focusing on projects where they don't matter or by hiring an assistant/partner that can handle the areas you are weak in.
There is not a discrete "brokenness" to things like art or music. What you ship works or it doesn't work. Nobody knows or cares about the mountains you moved to produce what you did, they only care about the parts that don't work.
Some industries are absolutely comparable, but a much smaller number than I think you're implying.
Salespeople make the sale sometimes. A doctor sees someone walk back in for their checkup who couldn't walk a week ago. A technical support person often says goodbye to a cheerful happy customer. Musicians may have to deal with criticism in the papers, but if they delist their phone number it's because of the fans, generally, not the critics. Actually that goes for almost all the creative industries.
Developers have very little positive to go off of, and few professions have customers as discerning and grumpy as compilers.
I wouldn't claim it's utterly unique, and everybody's got their own problems. But I don't think it's healthy or a good idea to ignore the problems we face because some people sometimes in some particular way have things even worse.
And if you're a programmer, sometimes you fix the big bug that a huge sale depends on, and sometimes you create a feature that your customers love.
And, I take it you've never ever been in sales.
What many companies do is put everyone's name on a board, and everyone's sales are complete public knowledge. Every time you make a sale, you walk up the board and add another tick to your column. It's a way to shame people into not being the worst salesperson in the company. And at the end of the month/quarter, you start all over again. My closest friend as well as my cousin went through this process, and quit after a couple of years of having their self-esteem completely trampled upon.
> Developers have very little positive to go off of
I don't know that I agree. Red, Green, Refactor. That continuous moment of hitting green. Every time you solve that problem. Every time you strike a bug off the list. There are so many measurable accomplishments programmers make.
This is one of those cases where I wish we could all walk a mile in each other's shoes.
I can program. I am not "a" programmer. I've written a Ruby Gem or two, and I've even had some (very) small contributions accepted to widely used gems. I am really a project manager, but I recongize the value of understanding the tools that are used to build the projects I oversee.
I can sell. I am not "a" salesman. I'm a good listener. I'm able to establish positive relationships relatively quickly. After meetings, I receive positive feedback from customers We're a small company, so I often end up sitting in on sales meetings. I find it's valuable to have a first-hand view in what customer objections are.
I've walked a mile in both sets of shoes. I can tell you, unquestionably, that both careers can be equally frustrating. It's easy to center your world view around your own challenges, but to believe that yours are unique and more important than others crosses the line to narcissism.
Sales people have it plenty rough. Not only are they constantly hammered by objections from customers, but any time they take those items back to the development team, they're met with similar apprehension about adding to the backlog.
> But I don't think it's healthy or a good idea to ignore the problems we face because some people sometimes in some particular way have things even worse.
Who suggested that we ignore the problems? The important part about recognizing someone else's challenges is that we should seek to support each other in both directions.
You think this:
"Developers have very little positive to go off of, and few professions have customers as discerning and grumpy as compilers."
Yet you mentioned this example:
"A doctor sees someone walk back in for their checkup who couldn't walk a week ago."
Is not seeing a product in action, one that possibly effects millions of lives (to be more realistic lets say 1000s, hell even a few dozen should be satisfying) in a positive way not very satisfying? I doctor helping a patient might not be as personal, but when I think about software I right the people who are using it and enjoying it are not far from my mind.
Unfortunately, many developers don't get a lot of opportunities to see their product in action. If you work on some public-facing service like Google or Facebook, you'll get to see your code being used. But if you work on a product that big companies deploy on their internal networks to improve their productivity, you won't see much of it.
Not really. I have been developer of VoIP application for about one an a half year and our clients only call us when they have a problem. Conectivity problems, delays in the audio when doing calls (due codec errors), problems with NAT, problems with the voice mails, etc... If everything is fine you just see no errors on logs and a beautiful graph expressing the increase of number of calls every month. Anything else.
Same when I was working generating telephonic bills for the clients. You will only have feedback if something went wrong.
Is that satisfaying? For my its enough; if the work have been done fine and the clients are reporting (almost) any error, I'm happy with that.
I couldn't disagree with you more, it seems to come from a pervasive cynicism that is day in day out grind of defect-finding in the programming industry.
How you can you casually claim technical support person has a more positive work environment than a programmer because sometimes a customer is happy when their problem is solved? What about all the customers who are irrationally angry even when you do your best to solve their problem? What about the problems you have no power to solve but have to take the heat for? What about the general prevailing attitude of frustration and discontent that characterizes the average person reaching out to support?
I don't understand how anyone could for one second say this is preferable to seeing a compiler error. There's no negative emotion inherent in a bug you discover. The fact that you are looking for flaws and fixing them is "negative" in a technical sense, but I find it bizarre to compare it so unfavorably to real negative human emotion directed at you. Even when other people are critiquing your work or sending you bug reports, there tends to be less emotion and more constructive feedback than you get in a service industry.
And what of citing "creative industries" and then drawing a sharp contrast to developers. Software engineering is extremely creative. The positive feedback from development is primarily the joy of creating working software. I've been doing this 20 years and it's still a thrill. Furthermore, I get plenty of positive feedback for my work. Obviously it's not on the scale of the insane hours I've spent in the trenches obsessing over minute details, but that's fine, I can take a compliment and find it gratifying even if it's shallow and uninformed of the true scope of my work.
I think there is definitely something about programming that leads to a pedantic mindset that could be offputting to others, but I think it's nonsense that it leads you to be inherently negative. Programming for me is empowering, attention to detail is just how I hone that power.
You should draw a clear line between those professions. All of them are "producing" professions, but the first group (artists, writers, musicians) do not have to maintain the technical responsibility that the latter (engineers, carpenters, programmers) has to.
This _technical responsibility_ brings a lot of the "negative" said on the article; actually, that's not "negative" it is "not good enough".
I reckon it depends on the size of the company you work for too. Obviously there will be always some errors and problems but there is also quite a lot of thinking and creative work to be done. Especially if the team is not massive and you take part in decision making process. Not exactly the "turn this coffee into code" type of job.
My friend working in a oil industry/software company (quite big) told me once - here you only get noticed when you manage to screw up something.
I'm not a sysadmin but I ended up looking after the office network and you are 100% right about this. Not only that, by the time you know someone has a problem, they're already annoyed, at you, for no good reason. More often than not, it's their own fault.
The other day someone was complaining that the internet was slow (it was), turned out they were syncing dropbox, backblaze and icloud, saturating the network. I understand now why sysadmins lock down everything where they can :)
The sysadmin cycle of life is to get hired then spend several years fixing, consolidating and automating until someone decides they don't need to keep paying a sysadmin "for nothing".
Thats kinda true actually :-) I am actually a coder by heart and moved now into a sys admin job. I kinda like it because once everything is nicely automated I did my work :-)
> I find myself wondering how adaptation is even possible.
I've been doing this job for 7 years now, and I've wondering along these lines a lot more lately, because I honestly do like what I'm doing and I plan do it for another 7-10-20 years. My current best answer is "don't take anything personal".
Yes, the latest bug will always be something that would risk taking us all one step closer to Armageddon, or so the clients/non-IT-colleagues would like to make us programmers think, but whenever I'm put into this position ("the world is crushing! do something!") I try to chill it down before taking action.
Also, there are always, always harder things in life than being a programmer, I try to remind me of this whenever I can. Just this summer I went out to help my grandma' pick up plumes during a weekend. A peasant, she's in her mid 80s now, she hasn't had a day of "vacation" or "paid holiday" since she married grandpa', 60+ years ago. One of her biggest regrets that she's experiencing right now is that she hasn't the physical strength anymore to work as much as she did for each day of her adult life.
This is one reason I'd much rather be discovery-oriented than goal-oriented.
If you look at all of these as just part of achieving your goal, then all of these are negatives. The compiler prevents you from achieving things, your bug reports remind you how you haven't achieved them, every missed deadline makes you wonder if you'll ever achieve them, and your customers don't appreciate it when you do achieve them.
But if you look at all of this as a process of discovering what customers want and how to accomplish that, all of those negatives become positives. Your compiler error tells you early about something that would've become a problem later on. Your bug report reminds you of a case you haven't handled, some subtlety of the problem that you're just now learning about. Your missed deadlines mean that you didn't know enough about the project to estimate accurately before, so now you have more information about its true scope. And your unhappy customers will tell you ways in which you can improve.
Try working in support for a while. Customers only call when something isn't working the way they expect, and since documentation is usually and afterthought among development teams, figuring out what is really possible with the software is often difficult. When you do identify bugs, you often have to go back to the customer to tell them it's not going to be fixed - and take the abuse that comes with those messages. Let's not even talk about non-technical salespeople who may not really know what the product is capable of and either tell customers wrong things or outright lie about what the product can do to make a sale. At which point, once again, the problems end up in the laps of support engineers.
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.
> 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.
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.
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.
>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.
This is extremely true. I love the phase where you are just building putting pieces together, solving interesting problems. Then QA comes in and tears your shit apart, gives extremely unhelpful advice and generally just kick over your sandcastle.
I get what he's saying, but I think he answered it himself, when he questioned if he was being overly dramatic. He is being really over-dramatic.
I would love to hear about any occupation where the negatives aren't run into in a similar way that he describes programming.
That being said, the one thing that I dislike about programmers in general is that I think we believe we sound smarter if we figure out ways how an idea won't work. It's annoying when you come up with a new idea, and all you hear is a litany of reasons why it won't work.
The most important lesson I learned was soon after I had moved to the Valley, and I gave a suggestion to one of the senior engineers. Instead of shooting it down immediately like others loved doing, he simply said something like "Okay, I'm not sold on it but give it a shot." I had been prepared for a lengthy argument over why my idea was good, and I was taken aback at his immediate open-mindedness. It's something I've taken to heart since then.
I'm not sure that specifying how things won't work is done to appear superior rather than giving feedback. There probably isn't enough time in a day to try everything and if you can save some time by pointing out why something won't work off the bat it's probably a good thing.
As with everything though, it kind of comes down to how you communicate that something won't work.
It also comes down to being right about it. It's often much easier to write something off ("that won't work"), than to accurately assess the reasons why it may not work, and possibly be part of modifying it so that it will. That difference is also subtle (just as subtle as the presentation in many cases), but also very important.
The mindset between engineers looking at new ideas and resolving old ones are different. A good engineer with foresight can see when an idea or proposal is good but at the same time he's thinking of the challenges it poses. I know I do this daily and the linked post is actually pretty hard hitting for me.
When I was looking for new work everywhere I applied I looked at how beneficial it was for me but that was always balanced with questions about how it will shape my career and if it will take me to a place I want to see myself in 5 years or will it put me 5 years behind my ultimate career goals? No matter what company or person I talked to I managed to find the reasons why it might not be beneficial to me.
I spoke with my girlfriend a lot during this search. At one point she got fed up with me and said to "shut up and stop being so negative". It sort of offended me because in a sense I didn't feel that I was being negative but rather "just looking at it from all angles". The coder mindset reaches into our daily lives where we start weighing the pros and cons of every decision to figure if it is worth the effort instead of just enjoying things.
Of course, I may not be typical. I live in an area with very few hackers and engineers so its hard to compare myself outside of these forums.
I like this point. In one company I was told a couple of times that things I suggested couldn't be done. I got a raise by going off and making a proof of concept that it could be done.
With that said, identifying challenges that need to be overcome ahead of time can be a useful step in planning as long as its not always seen as a reason to do a full stop on thinking about the concept.
The same plight is shared by any creative person. If programming makes you miserable, you're doing it wrong. The feeling of sublime satisfaction when something finally runs and does what you expect far outclasses any transient misery inflicted by the terse crowing of the compiler.
Any path worth walking is fraught with forks that lead you through brambles and strife before returning to the main road. The painter seeks the one perfect brush stroke that comes next; the carpenter seeks the perfect arrangement of nails and dead trees. If there weren't a thousand thousand ways to do it wrong, it wouldn't feel so wonderful when you finally got it right.
177 comments
[ 3.1 ms ] story [ 243 ms ] threadBreaking things and inconveniencing others are a much bigger drag for me. Those are the problems I stay late at work to solve.
Rather, in order to debug I have to go into negative mode. It's a mindset where I'm mentally combing over something, trying to illuminate everything that's wrong with it.
It's not even that important that it's your code. Focusing primarly on the good aspects of something is a healthier mental model - but not one that will get your code debugged.
Interestingly enough, people on the other end of the spectrum (sales people, executives, marketing people, etc) have to be the opposite. You can't have any doubts about the awesomeness of the product. Doing so would be counterproductive.
[1]http://www.danappleman.com/index.php?p=31
Optimists see bug reports as a way to improve things. Optimists bet on early tech because they see a bright future ahead (rails 0.9? ios 2.0?).
Being pessimistic will only feed your ulcer...
A truly good product will have fans sending in messages and talking about the things they love -- make sure these comments make it to the developers too!
* Make something * Meet about making something * Make something else * Go home
And they never see or hear about bugs :)
I think part of progress is a continual taking on of new and harder challenges - new technologies, advanced features etc - so your error rate should be fairly constant
Even then, I don't think the author intended you to take that so literally. That's an easy way to describe the problem to someone who isn't a programmer. The negative feedback loop is much longer and more complicated than that.
functional programmers get to express their ideas as code
imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas
just look at the research[1] coming out of the <del>Clojure</del> functional programming community - especially Datomic. once you learn how to get your defect rate under control, you have time to explore crazy awesome new ideas
editedhttp://clojure.org/rationale
http://www.dustingetz.com/2011/05/05/how-to-become-an-expert...
http://www.dustingetz.com/2012/10/07/java-sucks-because-idio...
[1]: http://okmij.org/ftp/
Stop drinking the cool-aid. Functional programming solves a lot of typing errors (if the given language has stronger typing than an imperative language) and makes composition easier in some cases (if the language is lazy).
But: an algorithmic error is still an algorithmic error, an incorrectly designed data structure is still an incorrectly designed data structure. No matter what language you use.
In addition to that, you get back a different set of problems: e.g. you have to reason about when something gets evaluated in a lazy regime in order for your program's heap not to blow up, and the translation to machine code is often not nearly as simple as an imperative language, which makes it harder to optimize functional programs.
(Ps. I love functional programming.)
The flaw is in us. Our ideas are malformed and flawed. Simply expressing ideas is not enough.
(#)relative.
I wonder if you couldn't formulate a rule to the effect of the more serious the task you are working on, the less you can afford to be optimistic. When Serious Things are on the line, you have to be a pessimist, because you have to find and root out all the possible weird failure cases before they bite you. When all that's on the line is a comment on someone's photo of their lunch, optimism is a more sustainable philosophy.
Being optimistic or pessimistic isn't quite relevant when people's lives are on the line, I think it's more about being _realistic_. Everything can fail, and everyone makes mistakes. This is reality. When people can die, there is much more impetus to pay (time and money) for everything to be triple-checked and triple-redundant.
But in pretty typical software development, that money and time isn't there. And the feeling of knowing you could have done better, if only given a chance, is horrible and eats away at your resolve. Then you wonder, "well perhaps I'm not fighting strongly enough," or "People are coding for space shuttles, and I can't even get this page to load!"
I believe it's a human right that your individual problems are no greater than another's, because it's relative. If you feel about it strongly enough, then it's valid. Saying it's not because people's lives aren't at risk is invalidating the human right of pursuit of happiness.
I used to get super frustrated and depressed when people edited my writing/prose. each comment was some way in which I sucked. then I compared, side by side, my early drafts with finished works. now I'm not frustrated or depressed when people find problems with my writing! or my code.
My partner and I just had our first iOS game approved. We had to ship without a bunch of features we had planned for (e.g. non-English localizations) simply because we ran out of time. During the final stages of the project, we thought we'd like to do something like a web-comic, to share the human story behind the development of the game. Now that the game is approved and we're reviewing our notes and drawing the comic (it can be loaded dynamically into the game as a slideshow, and it will also go into our facebook page/company blog at http://noisytyping.com), our view has shifted from 'we could have done better' to being very pleased about the whole journey: how we started out, what challenges we faced (automating level-generation was one) and how we managed to stick to our plan and ship it. Without the postmortem, we'd probably never be motivated to make a game again.
However, I suspect pessimists tend to make good programmers rather than programming causing someone to become more pessimistic.
If you're interested in understanding some of the psychology between Optimism and Pessimism, I recommend reading Learned Optimism by Martin Selligman. http://amzn.com/1400078393
It might also be that pessimism could limit programmers' capabilities by making them afraid to take on ambitious problems. Being somewhere in the middle of the spectrum might make someone a better programmer than being either too optimistic or too pessimistic.
A man came across three masons who were working at chipping chunks of granite from large blocks. The first seemed unhappy at his job, chipping away and frequently looking at his watch. When the man asked what it was that he was doing, the first mason responded, rather curtly, "I’m hammering this stupid rock, and I can't wait 'til 5 when I can go home."
A second mason, seemingly more interested in his work, was hammering diligently and when asked what it was that he was doing, answered, "Well, I'm molding this block of rock so that it can be used with others to construct a wall. It's not bad work, but I'll sure be glad when it's done."
A third mason was hammering at his block fervently, taking time to stand back and admire his work. He chipped off small pieces until he was satisfied that it was the best he could do. When he was questioned about his work he stopped, gazed skyward and proudly proclaimed, "I'm building a cathedral!"
http://bestpracticesforbusiness.com/2010/05/07/purpose-in-mo...
This is analogous to the mason's iterative workflow: noticing that his stone doesn't yet fit quite right and chipping a bit more off the side until it fits perfectly.
During development, most of our daily feedback comes from the code itself, not from people yelling at us about how broken it is (although that does happen sometimes).
Everyone wants to be that 3rd happy mason. But that story doesn't tell you how to do that, it just suggests that it's a better way. Saying that it's just a function of your mental state is tautological.
Every day I go to work to fend off spies who want to steal your data. Protecting the powerless, defending your freedom! I will never meet you, and I will never even look at the treasure I am defending, and most of time is spent fixing broken configs, but I am doing it for a good cause, and at the end of the month I enjoy my paycheck too.
Even the smartest people I know write imperfect/buggy code, especially the first time around. If you don't take it personally - as you shouldn't - I don't see the issue.
The bigger picture of course is that criticism, whether it comes from other humans, machines, or oneself, is the only way to improve anything. If you want to create anything worthwhile you have to have some mechanism to improve. Why would we want to bury our heads in the sand just so that we never have to hear a critique?
I suppose you could get a rote job on an assembly line and spend your free time watching TV and you'd never have to hear another complaint, but that sounds like an absolutely miserable life to me.
I would pair-program with this guy, and be astonished by his habits. I have had to have a goal of monitoring my anger for as long as I can remember. And I had no idea how much of a disadvantage this was in programming until I programmed with this boss.
After every recompile, the resulting errors/warnings would fuel my anger until I was true frustrated to continue. As you can guess it is hard to get anything done like this.
Where I would get angry and frustrated, my boss would get happy and pumped.
He was excited at an issue/problem, because he liked the challenge, but mostly he loved to learn.
With each error he'd announce how we were about to learn something new.
It changed my world
I'm surprised any of us can hold up under the withering torrent of negativity that is any serious programming job.
I actually don't mean this as a complaint, either. I've adjusted. I've been doing this for 15 years. But I've been sort of stepping back lately and looking at my job from other points of view, especially as I deal with coworkers who aren't so adjusted/adapted, and not only do I now understand where they are coming from, I find myself wondering how adaptation is even possible. It's absurd how negative the interactions are. Keep track someday of your professional interactions and look at how many of them are negative; bug reports, missed deadlines, "we can't do that", etc. Or perhaps, don't, if you've never thought about this before. I sure hope you have an otherwise positive workplace.
But for me, it is a matter of not caring about the bugs but enjoying fixing them.
Even non-producing professions have to deal with constant scrutiny of their performance and negativity. Salespeople might make one sale out of 20 attempts. Anyone in a medical profession is under extreme pressure to not make a mistake (and sometimes things go wrong even when you do everything right).
There are very few professions who don't have to deal with the whole "focusing on the negative" thing (I can't actually think of any). It's pretty much a fact of life that if you want quality, you have to systematically eliminate your weak spots.
Sometimes that is what you need to do. But sometimes you are better off further enhancing your strengths to real excellence rather than bringing up your weaknesses to an acceptable level.
Sometimes you can really sell your strengths, the things that make you stand out, and then work around the weaknesses by focusing on projects where they don't matter or by hiring an assistant/partner that can handle the areas you are weak in.
Some industries are absolutely comparable, but a much smaller number than I think you're implying.
Developers have very little positive to go off of, and few professions have customers as discerning and grumpy as compilers.
I wouldn't claim it's utterly unique, and everybody's got their own problems. But I don't think it's healthy or a good idea to ignore the problems we face because some people sometimes in some particular way have things even worse.
And, I take it you've never ever been in sales.
What many companies do is put everyone's name on a board, and everyone's sales are complete public knowledge. Every time you make a sale, you walk up the board and add another tick to your column. It's a way to shame people into not being the worst salesperson in the company. And at the end of the month/quarter, you start all over again. My closest friend as well as my cousin went through this process, and quit after a couple of years of having their self-esteem completely trampled upon.
I don't know that I agree. Red, Green, Refactor. That continuous moment of hitting green. Every time you solve that problem. Every time you strike a bug off the list. There are so many measurable accomplishments programmers make.
that is such a good feel
I can program. I am not "a" programmer. I've written a Ruby Gem or two, and I've even had some (very) small contributions accepted to widely used gems. I am really a project manager, but I recongize the value of understanding the tools that are used to build the projects I oversee.
I can sell. I am not "a" salesman. I'm a good listener. I'm able to establish positive relationships relatively quickly. After meetings, I receive positive feedback from customers We're a small company, so I often end up sitting in on sales meetings. I find it's valuable to have a first-hand view in what customer objections are.
I've walked a mile in both sets of shoes. I can tell you, unquestionably, that both careers can be equally frustrating. It's easy to center your world view around your own challenges, but to believe that yours are unique and more important than others crosses the line to narcissism.
Sales people have it plenty rough. Not only are they constantly hammered by objections from customers, but any time they take those items back to the development team, they're met with similar apprehension about adding to the backlog.
> But I don't think it's healthy or a good idea to ignore the problems we face because some people sometimes in some particular way have things even worse.
Who suggested that we ignore the problems? The important part about recognizing someone else's challenges is that we should seek to support each other in both directions.
Yet you mentioned this example: "A doctor sees someone walk back in for their checkup who couldn't walk a week ago."
Is not seeing a product in action, one that possibly effects millions of lives (to be more realistic lets say 1000s, hell even a few dozen should be satisfying) in a positive way not very satisfying? I doctor helping a patient might not be as personal, but when I think about software I right the people who are using it and enjoying it are not far from my mind.
Same when I was working generating telephonic bills for the clients. You will only have feedback if something went wrong.
Is that satisfaying? For my its enough; if the work have been done fine and the clients are reporting (almost) any error, I'm happy with that.
How you can you casually claim technical support person has a more positive work environment than a programmer because sometimes a customer is happy when their problem is solved? What about all the customers who are irrationally angry even when you do your best to solve their problem? What about the problems you have no power to solve but have to take the heat for? What about the general prevailing attitude of frustration and discontent that characterizes the average person reaching out to support?
I don't understand how anyone could for one second say this is preferable to seeing a compiler error. There's no negative emotion inherent in a bug you discover. The fact that you are looking for flaws and fixing them is "negative" in a technical sense, but I find it bizarre to compare it so unfavorably to real negative human emotion directed at you. Even when other people are critiquing your work or sending you bug reports, there tends to be less emotion and more constructive feedback than you get in a service industry.
And what of citing "creative industries" and then drawing a sharp contrast to developers. Software engineering is extremely creative. The positive feedback from development is primarily the joy of creating working software. I've been doing this 20 years and it's still a thrill. Furthermore, I get plenty of positive feedback for my work. Obviously it's not on the scale of the insane hours I've spent in the trenches obsessing over minute details, but that's fine, I can take a compliment and find it gratifying even if it's shallow and uninformed of the true scope of my work.
I think there is definitely something about programming that leads to a pedantic mindset that could be offputting to others, but I think it's nonsense that it leads you to be inherently negative. Programming for me is empowering, attention to detail is just how I hone that power.
You should draw a clear line between those professions. All of them are "producing" professions, but the first group (artists, writers, musicians) do not have to maintain the technical responsibility that the latter (engineers, carpenters, programmers) has to.
This _technical responsibility_ brings a lot of the "negative" said on the article; actually, that's not "negative" it is "not good enough".
13 years in the industry here.
Your ability to relate to, and communicate with, people in the real world (in depth) will degrade over time.
My friend working in a oil industry/software company (quite big) told me once - here you only get noticed when you manage to screw up something.
Do you know when your sysadmins are doing the job right? When you don't notice.
The only possible way for a sysadmin to get noticed is to screw up.
The other day someone was complaining that the internet was slow (it was), turned out they were syncing dropbox, backblaze and icloud, saturating the network. I understand now why sysadmins lock down everything where they can :)
"The lifecycle blah-blah-blah for the infrastructure team," he said "Is simple. They rack the server and that's it. I mean, what else is there to do?"
Which was ha-ha funny at first. Then I realized he was _serious_. And most of his minions were nodding their heads in agreement.
I've been doing this job for 7 years now, and I've wondering along these lines a lot more lately, because I honestly do like what I'm doing and I plan do it for another 7-10-20 years. My current best answer is "don't take anything personal".
Yes, the latest bug will always be something that would risk taking us all one step closer to Armageddon, or so the clients/non-IT-colleagues would like to make us programmers think, but whenever I'm put into this position ("the world is crushing! do something!") I try to chill it down before taking action.
Also, there are always, always harder things in life than being a programmer, I try to remind me of this whenever I can. Just this summer I went out to help my grandma' pick up plumes during a weekend. A peasant, she's in her mid 80s now, she hasn't had a day of "vacation" or "paid holiday" since she married grandpa', 60+ years ago. One of her biggest regrets that she's experiencing right now is that she hasn't the physical strength anymore to work as much as she did for each day of her adult life.
If you look at all of these as just part of achieving your goal, then all of these are negatives. The compiler prevents you from achieving things, your bug reports remind you how you haven't achieved them, every missed deadline makes you wonder if you'll ever achieve them, and your customers don't appreciate it when you do achieve them.
But if you look at all of this as a process of discovering what customers want and how to accomplish that, all of those negatives become positives. Your compiler error tells you early about something that would've become a problem later on. Your bug report reminds you of a case you haven't handled, some subtlety of the problem that you're just now learning about. Your missed deadlines mean that you didn't know enough about the project to estimate accurately before, so now you have more information about its true scope. And your unhappy customers will tell you ways in which you can improve.
Same facts, wildly different interpretations.
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.
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).
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?
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.
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.
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.
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.
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.
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.
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.
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" :)
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.
I would love to hear about any occupation where the negatives aren't run into in a similar way that he describes programming.
That being said, the one thing that I dislike about programmers in general is that I think we believe we sound smarter if we figure out ways how an idea won't work. It's annoying when you come up with a new idea, and all you hear is a litany of reasons why it won't work.
The most important lesson I learned was soon after I had moved to the Valley, and I gave a suggestion to one of the senior engineers. Instead of shooting it down immediately like others loved doing, he simply said something like "Okay, I'm not sold on it but give it a shot." I had been prepared for a lengthy argument over why my idea was good, and I was taken aback at his immediate open-mindedness. It's something I've taken to heart since then.
When I was looking for new work everywhere I applied I looked at how beneficial it was for me but that was always balanced with questions about how it will shape my career and if it will take me to a place I want to see myself in 5 years or will it put me 5 years behind my ultimate career goals? No matter what company or person I talked to I managed to find the reasons why it might not be beneficial to me.
I spoke with my girlfriend a lot during this search. At one point she got fed up with me and said to "shut up and stop being so negative". It sort of offended me because in a sense I didn't feel that I was being negative but rather "just looking at it from all angles". The coder mindset reaches into our daily lives where we start weighing the pros and cons of every decision to figure if it is worth the effort instead of just enjoying things.
Of course, I may not be typical. I live in an area with very few hackers and engineers so its hard to compare myself outside of these forums.
With that said, identifying challenges that need to be overcome ahead of time can be a useful step in planning as long as its not always seen as a reason to do a full stop on thinking about the concept.
This blog post is really silly. Writing software is refining something over time. You take a lump of clay and gradually shape it into what you need.
If you get all broken up about a bug or whatever, you should probably try to get some perspective.
Competence relies upon willingness to admit mistakes.
Any path worth walking is fraught with forks that lead you through brambles and strife before returning to the main road. The painter seeks the one perfect brush stroke that comes next; the carpenter seeks the perfect arrangement of nails and dead trees. If there weren't a thousand thousand ways to do it wrong, it wouldn't feel so wonderful when you finally got it right.
This is a feature, not a bug.