
Be nice to programmers - mkrecny
http://edu.mkrecny.com/thoughts/be-nice-to-programmers
======
jerf
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.

~~~
dsr_
Ha. I'm a sysadmin.

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.

~~~
incision
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".

~~~
shasta
No, that's a good sysadmin. Bad sys admins are indispensable.

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

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

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

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

~~~
greenyoda
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!"

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

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

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

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

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

[1]<http://www.danappleman.com/index.php?p=31>

~~~
herval
"I deserve a pat in the back" is not an optimistic attitude... It's self-
indulging, that's all.

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

~~~
GimbalLock
I definitely agree with you on this. Optimism and arrogance are vastly
different.

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

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.

~~~
jgh
I agree with you. I feel like this article is pretty melodramatic. I've been a
(professional) programmer for the better part of 10 years and I've had my
share of ups and downs, but this job is definitely a very, very good one. The
sheer amount of freedom we get from a) the good pay and b) the fact that
programmers are so in-demand right now that companies bend over backward for
us really can't be matched in many other jobs.

The lamenting in this article is from somebody with very little perspective on
what most people have to do just to survive.

~~~
subsystem
I think these are two different things. It can still be a nice job to have,
even if the process is broken. Writing reliable code is hard, probably harder
than it should be. Just look at the amount of software with security holes[0]
and/or performance issues.

[0] <http://www.exploit-db.com/>

------
tomrod
It's times like these I'm thankful for a life lesson I was taught about 4
years ago.

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.

~~~
btilly
I do this with things like Hacker News.

The challenge lies in getting motivated to go from the reward back to the
work. :-)

------
kranner
Taking the time to do postmortems can help.

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.

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

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.

~~~
Evbn
Need more quality time walking, talking, and talking to people.

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

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

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

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

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

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

------
jaggederest
For me, this cycle is a different one:

(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?

~~~
indiecore
>6\. Watch the test pass 7\. Send it to QA. 8\. Everything is wrong and this
isn't what they asked for (it is but that's not what they MEANT) 9\. Goto 3

~~~
jaggederest
No, you GOTO 1, and write new tests that match better. Just because you have a
dysfunctional organization that doesn't let QA and development talk doesn't
mean that's how it has to be.

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

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.

------
gpcz
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...](http://hbr.org/2011/06/how-customers-can-rally-your-troops/ar/1)
). 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).

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

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

------
chubbard
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!

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.

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

~~~
dubcanada
He can't be that intelligent if he is externally optimistic about everything.
Part of being smart makes you aware of the negatives of everything.

~~~
swalsh
Sometimes I feel like people are starting to go out of their way to make it
onto the "Shit HN Says" Twitter stream.

------
erode
This is awfully melodramatic drivel. If you don't like what you are doing then
stop doing it.

------
scheff
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!").

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.

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

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.

------
otakucode
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?

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!

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

------
AD-Edge
Interesting post

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.

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

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.

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

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

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

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

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

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.

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

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.

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

------
PaulHoule
I'm sad I can only give this one vote.

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.

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

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

------
redbeard0x0a
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!

~~~
dubcanada
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

And they never see or hear about bugs :)

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

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

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.

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

This is a feature, not a bug.

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

~~~
greenyoda
"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.

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

------
dacilselig
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:

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.

------
goblin89
Same a doctor could say, I guess—they look for problems in order to help. Too
bad they don't have unit tests.

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.

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

------
dowskitest
I think this is one area where dashboards can help. Chart the metrics that are
important to your organization, and prominently display them.

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.

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

------
grg999
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?

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.

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

[http://blog.vlad1.com/2008/07/21/other-peoples-thoughts-
on-p...](http://blog.vlad1.com/2008/07/21/other-peoples-thoughts-on-
programming/)

[links to a humorous video with NSFW audio commentary]

------
mratzloff
<http://cdn.memegenerator.net/instances/400x/28066871.jpg>

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.

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

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

------
praptak
Try your hand at security and come back to appreciate the optimism and
positivity(#) pervading the programming world.

(#)relative.

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

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

------
j_baker
I think this is true of any profession. Just in case anyone on HN hasn't heard
of the Dunning-Kruger effect yet:
<http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect>

Competence relies upon willingness to admit mistakes.

------
hollerith
Another writer who reports adverse effects from the critical / judgmental /
negative thinking required to create good software:

[http://telepatch.blogspot.com/2008/04/why-being-latency-
monk...](http://telepatch.blogspot.com/2008/04/why-being-latency-monkey-makes-
you-want.html)

~~~
cryowaffle
Hey, I know the telepatch guys.

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

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.

------
daenz
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?

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

~~~
daenz
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?

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

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

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

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

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

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

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

Make the compiler responsible for something.

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

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

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

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

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

------
nollidge
This is price of making things people care about.

------
gearoidoc
Negative people think negatively.

This is nothing new.

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

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

------
lucian303
And that's just the code, never-mind the people you have to deal with!

Negative reinforcements have arrived! (Great article, BTW)

------
dustingetz
TLDR: write better code

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
    

edited

~~~
MatthewPhillips
Most bugs have nothing to do with the code being imperative.

~~~
dustingetz
<http://www.infoq.com/presentations/Simple-Made-Easy> (this is so fundamental
to this topic that it is required watching to even have an opinion on this
subject)

<http://clojure.org/rationale>

[http://www.dustingetz.com/2011/05/05/how-to-become-an-
expert...](http://www.dustingetz.com/2011/05/05/how-to-become-an-expert-
swegr.html)

[http://www.dustingetz.com/2012/10/07/java-sucks-because-
idio...](http://www.dustingetz.com/2012/10/07/java-sucks-because-idiomatic-
java-is-bad-code.html)

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

