Be nice to programmers

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.<p>I'm surprised any of us can hold up under the withering torrent of negativity that is any serious programming job.<p>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 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.<p>I would love to hear about any occupation where the negatives aren't run into in a similar way that he describes programming.<p>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.<p>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.

There is nothing intrinsically negative about <i>anything</i> 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:<p><pre><code> 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 </code></pre> 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.

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.<p>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.<p>[1]<a href="http://www.danappleman.com/index.php?p=31" rel="nofollow">http://www.danappleman.com/index.php?p=31</a>

Among all the non-programmers I've talked to about work, I've never found one who doesn't have to deal with some sort of constant, repetitive negative feedback. Teachers have to deal with some kids that simply won't stop acting out, and who continually perform poorly on assignments (not to mention parents happy to tell them everything that the teacher is doing wrong). The salespeople have countless deals they fail to close. The manager has to make painful decisions about other peoples' livelihoods, and absorb the criticisms coming down from higher up the chain. The artist has to deal with everyone being a critic, and doesn't have the luxury of dealing with things that either work or don't work, it's all subjective. The doctor can't cure everyone. The lawyer can't get justice for everybody. The data-entry clerk peon has to ignore that they're completely replaceable and that they'll probably be replaced by a computer sooner or later. Anyone building anything (not just software) has to deal with the reality that 95% of the time, it's not done yet, and you still have more work to do and things to fix.<p>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 <i>doing something</i>, I can directly <i>watch</i> it do that thing, and that it's being used by people to get stuff done.<p>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.<p>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.

It's times like these I'm thankful for a life lesson I was taught about 4 years ago.<p>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.<p>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.<p>I've found this to be very helpful for me. Hope if helps some of y'all too.

Taking the time to do postmortems can help.<p>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 <a href="http://noisytyping.com" rel="nofollow">http://noisytyping.com</a>), 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 went to a tradeshow for my company a few weeks ago, where I got to just interact with potential customers all day. I had an absolute blast, by the end of the day where the other folks on the team were tired and ready to leave (I was the only developer), I was pumped and already thinking of how to come across even better to clients at the next day of the show. It made me realize how programming has adversely affected my demeanor and way I interact with people.<p>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.<p>"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.<p>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.<p>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.<p>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.

<i>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.</i><p>"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."<p>"Actually being a sculptor is making me pretty miserable."<p>"Woah, dude. What do you mean?"<p>"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."

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

For me, this cycle is a different one:<p>(Step 0 is possibly 'get a bug report')<p>1. Write a test<p>2. Watch the test fail<p>3. Write code<p>4. Watch the test pass (if fail, goto 3)<p>5. Make the code pretty<p>6. Watch the test pass<p>7. Repeat<p>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.<p>It's all about how you frame it - why would you frame the activity you spend most of your life doing negatively?

The question is not "What's wrong with this?" The proper question is "How can I make this better?" He's adopted a negative mindset by choice, whether he realizes it or not. That's not even what really grinds my gears about this post.<p>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:<p>1. Write some code<p>2. Run the code<p>3. Get an error message<p>4. Find the error and back to step 1<p>There are some critical steps missing. A more appropriate approach would be:<p>0. Think about what I'm building<p>1. Write some code<p>2. Run (Test) the code<p>3. Get an error (of some sort)<p>3.5 Think about what might have gone wrong and verify it<p>4. Go to step zero.<p>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.<p>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.<p>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 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: <a href="http://hbr.org/2011/06/how-customers-can-rally-your-troops/ar/1" rel="nofollow">http://hbr.org/2011/06/how-customers-can-rally-your-troops/a...</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).

After being a programmer for 20 years, I never thought of it that way. I think it is one of the better jobs out there, and I've always considered myself fortunate to be able to make a living that way. I will say, however, that spending the last 5 years working as at technology director at a school has been more rewarding, but it is not so much the kind of work I'm doing, but that I really value this school and the work they do. I feel privileged to be a part of it. In fact, the most difficult thing I dealt with in my programming career was not the work of programming, but working for companies where I did not always believe in the product.

Yea I got over that. Shit happens. Don't sweat the small stuff, yada yada yada. Besides when you fix it everyone lights up. It's the closest thing I've seen to a performer doing some amazing stunt with me being the amazing person. Focus on that, and not so much on that it broke. The difference between developers and non-devs is we can fix it, and that's really cool power. This article is almost like Wolverine complaining about his super powers being lame and always having to save the day. YOU'RE WOLVERINE STFU!<p>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.<p>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.<p>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.<p>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.

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 is awfully melodramatic drivel. If you don't like what you are doing then stop doing it.

I've been through this myself. I realised that the problem was me, and the projects that I was working on. I was fortunate enough to be able to step away, then go and find work that IS rewarding (for me it's playing with the front end, where people play with the app and go "ooooh!" and "aaaah!").<p>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!"<p>I'm fortunate to have an ex hacker/programmer as my manager who knows/understands/addresses my needs very well in my current role.<p>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."<p>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".<p>Keep searching until you find the right role.

What we have done and what happens to us all accumulates inside ourselves and becomes the basis of our future consciousness and state of mind. Peoples' minds and consciousnesses are comprised of energy. If we use the example of a lightbulb, the consciousness is most akin to an electrical wave produced by the generator and the mind is most analogous to the light radiated by the bulb.<p>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.

Being wrong is fantastic. You simply have to come to appreciate it. Every time you learn that you are wrong - and this applies for everything in life, not just with programming - you never have to be wrong in that way ever again. Not for the rest of your life, if you can remember, will you be wrong in that particular way. How amazing is that?<p>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.<p>Go on, be wrong! And then never be wrong in that way ever again!

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.

Interesting post<p>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.<p>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.<p>So I cant say I overly relate to the main attitude of the article, as much as I understand what its saying.

A quote from the article: "There's so much about programming that is incredibly satisfying and empowering. But it doesn't change the fact that, for me, programming builds an acutely negative mindset over time."<p>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.<p>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, <i>all of which respond to your efforts by getting worse</i>.<p>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.

I really don't know about this. For every bug I fix, there's a time I run the code after a change and the change does just what it was supposed to do. For every time a client complains about something that doesn't quite work yet, there's a time she told me how happy she is with what does work.<p>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?<p>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.<p>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.<p>Impatient clients with overblown expectations notwithstanding, but you get to pick those :-)

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.<p>Breaking things and inconveniencing others are a much bigger drag for me. Those are the problems I stay late at work to solve.

There's some irony to be found here. More likely than not, someone just like the OP built the bug tracking app that encourages clients/customers/users to give negative feedback and report problems.<p>This is also highly apparent in social apps (e.g. Facebook, Twitter, Yelp, etc). We <i>encourage</i> 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.<p>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.<p>You cannot expect people to be positive when the thing you gave them (seemingly, from their perspective) encourages negativity.<p>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.

Have you ever done fundraising for a startup? To raise 1m - 2m dollars, you will on average talk to between 20 - 40 different investors during the seed round. At least half of these discussions will end with a "no". This is not a good feeling, because this "no" represents someone who has the ability to enable your company, your co-founders, your vision, your dreams, and even your employees to have a future. Being told "no" is incredibly difficult to hear in the early stages of a building a company.<p>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 is exactly why I love test-first development for most (but not all) projects. Instead of code, run, bug.. fix, bug, fix, etc, I get to say "I want to achieve X!" and then strive towards achieving X. Rinse and repeat. A gross simplification but a test-first approach has made me a lot happier.

I'm sad I can only give this one vote.<p>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.<p>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.

I call shenanigans. If focusing on the negatives makes everyone miserable, explain to me why I turn the dial to the Car Talk guys to make me smile.<p>People who fix things can have a positive outlook on life, mostly because they improve and make the negatives into positives.

Instead of submitting yet another bug report, you should totally submit a "bug" that is nothing but positive feedback.<p>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!

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.

It really seems to me that in general programmers have such an good life that they (we) have to find something to complain about. I'm not pointing any fingers, since I often have the same thoughts. There was actually a quite nice article on HN lately (I read it on Sunday, but my google-fu is failing me), something along the likes of "Why wouldn't you want to be a programmer?", which arrived to the same conclusion as I usually do after trying to compare it to many other professions in an unbiased way: overall programming is quite a sweet deal.<p>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.

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.<p>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.<p>This is a feature, not a bug.

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.<p>However, I suspect pessimists tend to make good programmers rather than programming causing someone to become more pessimistic.<p>If you're interested in understanding some of the psychology between Optimism and Pessimism, I recommend reading Learned Optimism by Martin Selligman. <a href="http://amzn.com/1400078393" rel="nofollow">http://amzn.com/1400078393</a>

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

Perhaps it's all about context in terms of how you view how salient the negative feedback is. I can only speak of my experiences but I always found that no matter how frustrated I get while coding, the moment that everything finally functions releases such a dopamine rush that I quickly forget about the frustration. Perhaps two things (probably more) are necessary in order to overcome this negative feedback loop:<p>Learning how to let go of failures. Focus on the euphoria of fixing a bug.<p>Remember that as humans we essentially are very complex machines and perspectives partly determines how we will react to a stimuli.

Same a doctor could say, I guess—they look for problems in order to help. Too bad they don't have unit tests.<p>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’.<p>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.

If you don't like your workflow, change it. It's really as simple as that. If you can't change it, switch to a job where you can. Trying to change how other people perceive you or your job will only make it worse. Just because so many are feeling that they are stuck in a continuously endless loop of negative feedback, doesn't mean its right or the only thing there is. You, and only you, have the power to change your own mindset (for the better or worse). There's nothing that does that for you.

I think this is one area where dashboards can help. Chart the metrics that are important to your organization, and prominently display them.<p>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.<p>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.

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.

It's this way in every job. Every chef should be thinking, "does what I made taste as good as it can?" Every car repairperson should be thinking "am I doing the best job of replacing this brake caliper? Not banging it around, not kinking the brake hose, not getting greasy fingerprints on the rotor?<p>In every job you should be thinking about the quality aspects.<p>It's just that in programming, the problems can numerous, subtle, and hard to find.

On tough days at work, I am often reminded of Vladimir Vukićević's blog post about the "best visual representation that I’ve seen of what a programmer’s job is often like":<p><a href="http://blog.vlad1.com/2008/07/21/other-peoples-thoughts-on-programming/" rel="nofollow">http://blog.vlad1.com/2008/07/21/other-peoples-thoughts-on-p...</a><p>[links to a humorous video with NSFW audio commentary]

<a href="http://cdn.memegenerator.net/instances/400x/28066871.jpg" rel="nofollow">http://cdn.memegenerator.net/instances/400x/28066871.jpg</a><p>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.<p>If you get all broken up about a bug or whatever, you should probably try to get some perspective.

Doctors see sick people more than healthy people. Divorce lawyers get more business than the lawyers for happily-married couples (I guess they can help them with a will.)<p>We programmers live on the borderline between respected professional and prole grunt. Is it Doctor/Lawyer/Software Engineer; or Mechanic/Technician/Software Engineer?

Try your hand at security and come back to appreciate the optimism and positivity(#) pervading the programming world.<p>(#)relative.

I think this is true of any profession. Just in case anyone on HN hasn't heard of the Dunning-Kruger effect yet: <a href="http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect" rel="nofollow">http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect</a><p>Competence relies upon willingness to admit mistakes.

Another writer who reports adverse effects from the critical / judgmental / negative thinking required to create good software:<p><a href="http://telepatch.blogspot.com/2008/04/why-being-latency-monkey-makes-you-want.html" rel="nofollow">http://telepatch.blogspot.com/2008/04/why-being-latency-monk...</a>

the point isn't the criticism coming back. the point is the critical thinking the programmer is doing. the problem is focussing on finding flaws and holes.<p>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.<p>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.

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?

Indeed this is very dramatic. Positive feedback boosts egos, negative feedback gets the work done. If no one ever received negative feedback, we would spend our lives believing we're perfect while doing everything wrong.

Once I heard from an architect(in the original, designer of buildings sense of the word), that he wished he would get as instantaneous feedback of his work, as a developer can from a compiler.

this seems to be largely a matter of personal mindset. i'm a programmer. i've worked in a number of companies, from deeply dysfunctional to wonderful. but invariably, the only thing i ever disliked about my jobs was dealing with company bullshit and unpleasant people. i've never felt any negativity attached to my actual work - i always feel like i'm building something and making forward progress, whether that something is genuinely new code or simply bugfixes.

How about we stop being nice to computers? Put some of the onus on them. We do all of the work, they just crunch the numbers.<p>Make the compiler responsible for something.

Now I get it! My son is a programmer and he's always looking for fourths in me ... Just like his mother :)

I don't think it's useful or accurate to generalize about the subjective experience of programming.

i disagree with the last part being that failing is frustrating... now it could just be me, but that's what i love about programming which is finding and solving puzzles that I've made subconsciously for myself.

it makes you wonder if the real success of companies like google really is in the uplifted, positive, work environment to help pull you out of that negative feedback loop.

lol, nobody gets paid to see the positive things. Everyone else at the company is also being paid to be critical and fix problems (lawyers, finance, HR, CEO, etc.).

This is price of making things people care about.

Negative people think negatively.<p>This is nothing new.

OP here. Thanks for all the great comments. Especially all of the negative ones, validating my thesis ;)

This is extremely true. I love the phase where you are just <i>building</i> 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.

And that's just the code, never-mind the people you have to deal with!<p>Negative reinforcements have arrived! (Great article, BTW)

TLDR: write better code<p>functional programmers get to express their ideas as code<p>imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas<p>just look at the research[1] coming out of the &#60;del&#62;Clojure&#60;/del&#62; 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<p><pre><code> [1] https://thestrangeloop.com/archive/2011 [1] https://thestrangeloop.com/archive/2012 </code></pre> edited