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.

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.

  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

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

That's not to say that some people aren't going to be happier in certain fields than others, or that some subsets of the field fit some mindsets better than others, but software is pretty good work. The article acknowledges this right up front, and then ignores that to dwell on the negatives. It blew my mind a little to see such a negative perspective. If I fix a simple bug in my code, it doesn't bother me much, because I know I sometimes make mistakes. If I find and fix a really interesting subtle thing, then it means I learned something new, and that the product is now in better shape than it was yesterday. If there's a usability issue, it's an opportunity to figure out a new way to do it. And all the while I have the constant positive feedback of knowing that this thing that I built is doing something, I can directly watch it do that thing, and that it's being used by people to get stuff done.

Unless you build everything exactly right the first time, and never have to deal with external changes that mean the software needs to change, you're never going to be free of negative feedback. So you should start looking at why you're letting the negative parts drive your attitude.

EDIT: My own personal idiosyncrasy is that I get very suspicious, maybe even paranoid, about a complex task if everything seems to work right the first time and I don't have a few cycles of negative feedback. I know it's complex, and so I don't expect perfection out of the gate, so a few runs through the "fix one thing, find another issue" washer are oddly reassuring to me. Even though rationally I know that fixing things I knew to test for doesn't mean it's any less likely that there are errors in the things I haven't thought to test.

I'm not a professional coder, but I do a significant amount of hacking and coding for one of my research fields (Computational Economics). I noticed this cycle too--this cycle of focusing on the negatives. It really did bring me down.

I chatted with my adviser, who was married for a number of years to a child psychologist. She recommended to him that every time he accomplishes something small, get up and walk around. Do something small to reward yourself. Then, get back to coding. This inserts a positive stimuli in an otherwise negative feedback loop. The more bugs you solve, the happier you are.

I've found this to be very helpful for me. Hope if helps some of y'all too.

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 realized that not so long ago, I was actually outgoing and cheerful most of the time, but programming has made me more surly and sometimes reactive in an insidious way. With programming you're always dealing with problems, and if you're not solving them in code, or being infuriated by something that you thought would take 30 mins but has blown your entire day, you're dealing with people problems.

"Why isn't this done?", "Why should we pay that much?", "When is it going to be done?", "How long do you think its going to take?", "Why is it going to take that long?", "Can you just squeeze this one thing into the iteration?", "That sounds easy", "Why is this broken?", "Who broke it", "Why can't you just code", "You ask too many questions" ... aaaaaack.

its just this steady barrage of crap you have to deal and you're usually the one saying "no", "we can't do that", "Why do you want to do that?" to where you just become this proxy for negativity even if you don't want to be, because ultimately you're going to be the guy cleaning up the shit when everything explodes because nobody thought to figure out how to do the whole thing properly.

Unless you're working at a real top notch engineering place, where half these questions don't come up or the top brass understand how the whole thing works, it can really mess with your attitude.

When I had that epiphany after the tradeshow, it really freaked me out to realize how professional programming was changing my attitude to people and life, so I don't think I'll be doing 100% development for much longer.

"Dude, you're so lucky to be a master sculptor. Always hanging out with famous models and actors who want nothing more than to strip for you. Your works will be celebrated for more than two thousand years. I wish I could do that."

"Actually being a sculptor is making me pretty miserable."

"Woah, dude. What do you mean?"

"Hour by hour, day after day, I do this. Always searching for pieces of stone that don't belong, always trying to remove the elements that aren't part of my work, rather than being able to focus on the stone that remains. I can never truly build anything, only erode. It's a negative reinforcement feedback loop. I think I'll try watercolors next."

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.

(Step 0 is possibly 'get a bug report')

1. Write a test

2. Watch the test fail

3. Write code

4. Watch the test pass (if fail, goto 3)

5. Make the code pretty

6. Watch the test pass

7. Repeat

Instead of negatives, you're looking for positives. At the end you're rewarded with nicer code than you started with and green lights all the way down.

It's all about how you frame it - why would you frame the activity you spend most of your life doing negatively?

The really bad part of this post is the implication that this mentality (whether one takes the author's negative point of view, or my slightly more positive interpretation) is endemic to software development. It's not. Asking the question, "How can I make this better," ought to be a fundamental part of one's daily routine. Had the author adopted this mentality in general, he might have noticed a flaw in his workflow:

1. Write some code

2. Run the code

3. Get an error message

4. Find the error and back to step 1

There are some critical steps missing. A more appropriate approach would be:

0. Think about what I'm building

1. Write some code

2. Run (Test) the code

3. Get an error (of some sort)

3.5 Think about what might have gone wrong and verify it

4. Go to step zero.

That's right, when you find an error there are two distinct thought processes involved. First you think about what might have gone wrong. This would be the forming a hypothesis step of the scientific method (I've lumped testing into step 3.5 so as not to stray too far from the author's initial workflow, but suffice it to say that testing should be a recursive call to this entire process). Once you've discovered the source of the error, it's time to consider how best to fix it. Yes, more thinking. Only then should one go back to writing production code.

Sadly, I don't think the author's method is that rare. I had a professor who referred to the write/run/test/fix method as the original genetic programming. I think that's a fair statement. The problem with this method is that one ends up with a system that may work, but with no deep understanding of why it works. Absent that understanding, it will be more difficult to improve (fix) the system.

God help the next poor soul (aka the author in six months) to work on the system. Therein lies the negative feedback loop.

I think after being a programmer I have changed my outlook for the better because I realize what's possible instead of being trapped by other people's ideas/mistakes. I see how things are connected and if I changed this or that how it changes our limitations. Anyone can say "What if" very few can "Here's how." And that is really empowering and liberating.

I suppose when I was younger I was negative I wanted everything to be perfect like it couldn't be, but as I matured I see bugs, missing features, bad design as just opportunities and not the end of the world. Being late, bugs, complaining users, whatever it just doesn't bother me.

I'm not tuning them out just choosing to listen to what's really important and cutting through the bull because I expect all of it to happen. We're late ok I'll work a little more realizing I can really only make it about 10% faster, there bugs give me a reproducible test case and I'll fix it, users bitching reach out to them personally and find out what's the real problem.

And just like anything else in life, whether it's programming, football, music, or ditch digging, your attitude is your choice. The difference came when I chose to be positive...and laugh a lot more at all of the irony, bad choices we make, and gotchas that always creep up. Laughing really helps.

The key for me was to document the things that I hated about the job, and avoid them at all costs, but to acknowledge that criticism is something that feeds back into an application improvement process. ie. Don't take it as personal that someone is criticising you/your work. Find methods of improving the communication channel so that you don't spend days/weeks coding only to find "that's not what I wanted! that sucks!"

I'm fortunate to have an ex hacker/programmer as my manager who knows/understands/addresses my needs very well in my current role.

At some point I stopped chasing the higher paycheck, because I recognised that with a higher paycheck comes higher expectations, demands, hardships. Look at it from the employer's perspective - "We could hire 2 graduates at your cost, at that rate we expect you to not make mistakes, and to get twice the amount of work done."

A friend earns almost twice as much as me, with similar years of experience, but he is expected to miss lunch, stay back until midnight, answer calls to China/India on a friday night. No please/thankyou/you're doing a great job. Just "do it".

Keep searching until you find the right role.

If we work in such a way that produces high entropy codebases, hides problems instead of illuminating them, or produce (or have to work with) highly inter-braided (complicated) architecture with no way or occasion in which to improve matters, then it's easier for people to be caught by grudge at their employer, clients, or circumstance. People can be influenced by these bad circumstances to abandon themselves, and in doing so, their resultant ignorant behavior will make their mind mind become dark. This is a most dangerous circumstance for a human being to live in, so the task of the modern programmer is to find out what they have worth living for, to find a good self, and to protect themselves from wrong relationships and from destroying themselves (through loss of simplicity in one's life) such that they can effect their benefit for themselves and the world. Without individual awakening then it doesn't matter what profession they hold, they still can't guide their life properly. So the most important teaching for programmers to save their way of life is that they have to understand properly what life is, how great a teaching it is for us, and just how precious is the opportunity that we have been given through our lives as human beings.

You're not 'focusing on the negatives', you're getting to be wrong, a fantastic opportunity. Most people don't get to be wrong. They persist in their wrongness and swim about in a sea of mediocrity with no sense of personal advancement. To get to be wrong on a regular basis is nothing short of exciting. Sure, others will misunderstand it. Managers and business types will not understand why you simply couldn't do everything flawlessly from the start and they'll try to give you a hard time about it. But it doesn't really matter. No matter how hard they push you, they can't make you think. No one can. It has to be undertaken entirely under your own will. And when you do so and come up with something wrong - you know you are actually guiding yourself to develop rather than stagnate.

Go on, be wrong! And then never be wrong in that way ever again!

For myself personally I feel the positive of making progress, or implementing that new feature, by far over-weighs all the little bits of negativity and frustration of a bug or error. Even if that implementation isnt 100% correct, its still satisfying to see something happening which takes you another step towards the goal. Sure it can be pretty destroying to get stuck on that one main problem for a long time, unable to find a solution and with a million errors being thrown, but then when that problem is solved the positive feeling can be even larger anyway, depending of course.

I find it unrealistic to expect it to be any other way, youre an imperfect human trying to design something so complex, within an environment that has zero tolerances for mistakes. Hell, if you even accidently capitalize a single letter somewhere in thousands of lines of code, the whole things going to fall in a heap.

So I cant say I overly relate to the main attitude of the article, as much as I understand what its saying.

The author of these words seems to miss the fact that all systems that move from one state to another require "negative feedback", but the "negative" in "negative feedback" doesn't have the meaning he's giving it.

The author sees programming as emphasizing the fact that software is usually broken. I see programming as emphasizing the fact that that I can fix it, and once fixed, it remains fixed forever. Compare that to "fixing" relationships, or government, or nearly anything else one can name, all of which respond to your efforts by getting worse.

When viewed this way, programming is (like mathematics) an escape from a world in which efforts to solve problems are either ineffective or make the original problem worse. The fact that the end result might actually be useful to someone is frosting on the cake.

Is it really that different in other professions? Does the doctor always bring good news? Are all of the teacher's students bright chaps? Does the firefighter save each and every life? The lawyer win every case? The financial advisor always make a plus? Are a real estate agents' clients always happy with their sales price? Sure, there are lots of professions where there are rarely any negatives, say, a taxi driver, but is that a rewarding job?

I think this is really about your mindset. I often feel like a sculptor... I start off with something that doesn't look at all like the final product I have in mind, and over time I approximate the final result closer and closer. Error messages or not, to me that's just feedback, just like the sculptors' fingers find roughly hewn spots on the surface. Is the sculptor supposed to get mad at a little rough spot on his sculpture? Of course not, he just chips it away.

The one suggestion I have for programmers who are offended by error messages is to give TDD a try. With TDD, the test failures you get are to be expected: after all, you specifically engineered them to fail in the first place. So you don't have to feel bad about those, and you can revel in the positive feedback you get from a passing test. And if a test fails unexpectedly you can be happy that your safety net has actually done its job! I'm not being facetious: if you see error messages as negative feedback (again, I don't, but maybe you do) then TDD might just give you the positive feedback you've been craving.

Impatient clients with overblown expectations notwithstanding, but you get to pick those :-)

Breaking things and inconveniencing others are a much bigger drag for me. Those are the problems I stay late at work to solve.

This is also highly apparent in social apps (e.g. Facebook, Twitter, Yelp, etc). We encourage negative feedback when we give people a platform to do so. For better or worse, a lot of what we create is simply enabling the insatiable devil inside of people.

It sucks, but most people are unhappy and they will always look for another avenue to vent their frustrations. We just turned it into an easy-to-use textbox that's available 24/7.

You cannot expect people to be positive when the thing you gave them (seemingly, from their perspective) encourages negativity.

All that aside, you can't let people get to you. The world is getting increasingly judgmental and you just have to roll with the punches.

My point is that being an entrepreneur, regardless of your role, is not always easy. Controlling your own destiny means you get the good and the bad; you're never shielded from the stuff that's hard to swallow. While I feel for this particular situation, I don't think other roles in a startup have it any easier.

This theme has been on the tip of my tounge for a long time; in fact, I tell coworkers that I see every item that is in the ticket system, be it a bug or a feature, as a "delta", a change in the system to make it have some characteristic it doesn't have now.

I'll just say that stress management is one of the issues you must face if you're going to be an effective (and happy) developer. It's important to get exercise and take breaks, but it's most important to understand your sources of stress and deal with them. Sometimes you can take action, by say, getting a motorized standing desk and tall monitor arm to avoid pain. There are other sources of stresses that you just have to accept.

People who fix things can have a positive outlook on life, mostly because they improve and make the negatives into positives.

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!

I have to admit though that I never held any other jobs, so I'm very interested in reading about the opinions of those that have.

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.

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

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.

Learning how to let go of failures. Focus on the euphoria of fixing a bug.

Remember that as humans we essentially are very complex machines and perspectives partly determines how we will react to a stimuli.

Finding a bug is good, the worse the better, not finding one means software has bugs you don't know about. Distance yourself. You shouldn't allow one project's problems influence your state of mind, since it can hurt other ‘patients’.

For me, most of the frustration comes not from working as ‘just a’ developer, but from leading projects and interacting with customer. It's exciting to solve higher-level problems, but communication is easy as the ocean.

Chart the number of users on your site throughout the day. The number of times they do X or Y, that your app enabled them to do. Put a big counter on the wall for sales/new users/etc. Make a big deal when milestones are reached.

Bug trackers, user complaints, etc can definitely weigh us down. But hopefully there's some encouragement in the data that we're doing some things really right.

In every job you should be thinking about the quality aspects.

It's just that in programming, the problems can numerous, subtle, and hard to find.

http://blog.vlad1.com/2008/07/21/other-peoples-thoughts-on-p...

[links to a humorous video with NSFW audio commentary]

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.

We programmers live on the borderline between respected professional and prole grunt. Is it Doctor/Lawyer/Software Engineer; or Mechanic/Technician/Software Engineer?

(#)relative.

Competence relies upon willingness to admit mistakes.

http://telepatch.blogspot.com/2008/04/why-being-latency-monk...

in social conversations and in life, it is a virtue to let things pass, to support the joy that comes from simple optimism, from believing in hopes and dreams without practical certainty or probability. it is a virtue to talk about things without knowing the context, without digging into the challenges, the holes, the flawed rationales, the white lies that help us feel better about ourselves, each other, and our journeys through life.

too much of anything is a bad thing. i just assumed everyone had this problem of focusing on the problems and undervaluing progress and success.

Make the compiler responsible for something.

This is nothing new.

Negative reinforcements have arrived! (Great article, BTW)

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

    [1] https://thestrangeloop.com/archive/2011
    [1] https://thestrangeloop.com/archive/2012