Hacker News Reader

But this is true of any "producing" profession. Any time you're creating something and "putting it out there", there's going to be a huge stream of criticism from every direction. Artists, writers, musicians, engineers, carpenters, etc.--all of their work is constantly under scrutiny by "the customer" and/or "the boss".

Even non-producing professions have to deal with constant scrutiny of their performance and negativity. Salespeople might make one sale out of 20 attempts. Anyone in a medical profession is under extreme pressure to not make a mistake (and sometimes things go wrong even when you do everything right).

There are very few professions who don't have to deal with the whole "focusing on the negative" thing (I can't actually think of any). It's pretty much a fact of life that if you want quality, you have to systematically eliminate your weak spots.

You make great points, and I agree with everything except: systematically eliminate your weak spots.

Sometimes that is what you need to do. But sometimes you are better off further enhancing your strengths to real excellence rather than bringing up your weaknesses to an acceptable level.

Sometimes you can really sell your strengths, the things that make you stand out, and then work around the weaknesses by focusing on projects where they don't matter or by hiring an assistant/partner that can handle the areas you are weak in.

There is not a discrete "brokenness" to things like art or music. What you ship works or it doesn't work. Nobody knows or cares about the mountains you moved to produce what you did, they only care about the parts that don't work.

Some industries are absolutely comparable, but a much smaller number than I think you're implying.

Ahem. http://www.psdisasters.com/

That would be the definition of 'doesn't work' I think.

Salespeople make the sale sometimes. A doctor sees someone walk back in for their checkup who couldn't walk a week ago. A technical support person often says goodbye to a cheerful happy customer. Musicians may have to deal with criticism in the papers, but if they delist their phone number it's because of the fans, generally, not the critics. Actually that goes for almost all the creative industries.

Developers have very little positive to go off of, and few professions have customers as discerning and grumpy as compilers.

I wouldn't claim it's utterly unique, and everybody's got their own problems. But I don't think it's healthy or a good idea to ignore the problems we face because some people sometimes in some particular way have things even worse.

And if you're a programmer, sometimes you fix the big bug that a huge sale depends on, and sometimes you create a feature that your customers love.

And, I take it you've never ever been in sales.

What many companies do is put everyone's name on a board, and everyone's sales are complete public knowledge. Every time you make a sale, you walk up the board and add another tick to your column. It's a way to shame people into not being the worst salesperson in the company. And at the end of the month/quarter, you start all over again. My closest friend as well as my cousin went through this process, and quit after a couple of years of having their self-esteem completely trampled upon.

> Developers have very little positive to go off of

I don't know that I agree. Red, Green, Refactor. That continuous moment of hitting green. Every time you solve that problem. Every time you strike a bug off the list. There are so many measurable accomplishments programmers make.

>that feel when you go from red to green.

that is such a good feel

This is one of those cases where I wish we could all walk a mile in each other's shoes.

I can program. I am not "a" programmer. I've written a Ruby Gem or two, and I've even had some (very) small contributions accepted to widely used gems. I am really a project manager, but I recongize the value of understanding the tools that are used to build the projects I oversee.

I can sell. I am not "a" salesman. I'm a good listener. I'm able to establish positive relationships relatively quickly. After meetings, I receive positive feedback from customers We're a small company, so I often end up sitting in on sales meetings. I find it's valuable to have a first-hand view in what customer objections are.

I've walked a mile in both sets of shoes. I can tell you, unquestionably, that both careers can be equally frustrating. It's easy to center your world view around your own challenges, but to believe that yours are unique and more important than others crosses the line to narcissism.

Sales people have it plenty rough. Not only are they constantly hammered by objections from customers, but any time they take those items back to the development team, they're met with similar apprehension about adding to the backlog.

> But I don't think it's healthy or a good idea to ignore the problems we face because some people sometimes in some particular way have things even worse.

Who suggested that we ignore the problems? The important part about recognizing someone else's challenges is that we should seek to support each other in both directions.

You think this: "Developers have very little positive to go off of, and few professions have customers as discerning and grumpy as compilers."

Yet you mentioned this example: "A doctor sees someone walk back in for their checkup who couldn't walk a week ago."

Is not seeing a product in action, one that possibly effects millions of lives (to be more realistic lets say 1000s, hell even a few dozen should be satisfying) in a positive way not very satisfying? I doctor helping a patient might not be as personal, but when I think about software I right the people who are using it and enjoying it are not far from my mind.

Unfortunately, many developers don't get a lot of opportunities to see their product in action. If you work on some public-facing service like Google or Facebook, you'll get to see your code being used. But if you work on a product that big companies deploy on their internal networks to improve their productivity, you won't see much of it.

You can walk over to someone else's cubicle can't you?

Not really. I have been developer of VoIP application for about one an a half year and our clients only call us when they have a problem. Conectivity problems, delays in the audio when doing calls (due codec errors), problems with NAT, problems with the voice mails, etc... If everything is fine you just see no errors on logs and a beautiful graph expressing the increase of number of calls every month. Anything else.

Same when I was working generating telephonic bills for the clients. You will only have feedback if something went wrong.

Is that satisfaying? For my its enough; if the work have been done fine and the clients are reporting (almost) any error, I'm happy with that.

VOIP is the best! When your clients have a problem, they can't call you!

I couldn't disagree with you more, it seems to come from a pervasive cynicism that is day in day out grind of defect-finding in the programming industry.

How you can you casually claim technical support person has a more positive work environment than a programmer because sometimes a customer is happy when their problem is solved? What about all the customers who are irrationally angry even when you do your best to solve their problem? What about the problems you have no power to solve but have to take the heat for? What about the general prevailing attitude of frustration and discontent that characterizes the average person reaching out to support?

I don't understand how anyone could for one second say this is preferable to seeing a compiler error. There's no negative emotion inherent in a bug you discover. The fact that you are looking for flaws and fixing them is "negative" in a technical sense, but I find it bizarre to compare it so unfavorably to real negative human emotion directed at you. Even when other people are critiquing your work or sending you bug reports, there tends to be less emotion and more constructive feedback than you get in a service industry.

And what of citing "creative industries" and then drawing a sharp contrast to developers. Software engineering is extremely creative. The positive feedback from development is primarily the joy of creating working software. I've been doing this 20 years and it's still a thrill. Furthermore, I get plenty of positive feedback for my work. Obviously it's not on the scale of the insane hours I've spent in the trenches obsessing over minute details, but that's fine, I can take a compliment and find it gratifying even if it's shallow and uninformed of the true scope of my work.

I think there is definitely something about programming that leads to a pedantic mindset that could be offputting to others, but I think it's nonsense that it leads you to be inherently negative. Programming for me is empowering, attention to detail is just how I hone that power.

> Artists, writers, musicians, engineers, carpenters

You should draw a clear line between those professions. All of them are "producing" professions, but the first group (artists, writers, musicians) do not have to maintain the technical responsibility that the latter (engineers, carpenters, programmers) has to.

This _technical responsibility_ brings a lot of the "negative" said on the article; actually, that's not "negative" it is "not good enough".

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.

I'm not a sysadmin but I ended up looking after the office network and you are 100% right about this. Not only that, by the time you know someone has a problem, they're already annoyed, at you, for no good reason. More often than not, it's their own fault.

The other day someone was complaining that the internet was slow (it was), turned out they were syncing dropbox, backblaze and icloud, saturating the network. I understand now why sysadmins lock down everything where they can :)

The sysadmin cycle of life is to get hired then spend several years fixing, consolidating and automating until someone decides they don't need to keep paying a sysadmin "for nothing".

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

There was a post recently comparing that to "the carpets are just naturally clean all the time, so we laid off the cleaning staff".

You ain't kidding. I found myself, a system administrator, in a large conference room, full of developers, meeting chaired by the head of development.

"The lifecycle blah-blah-blah for the infrastructure team," he said "Is simple. They rack the server and that's it. I mean, what else is there to do?"

Which was ha-ha funny at first. Then I realized he was _serious_. And most of his minions were nodding their heads in agreement.

Sysadmins are the offensive linemen of the tech world.

A conpetent BOFH has many offensive lines always at the ready, indeed.

Thats kinda true actually :-) I am actually a coder by heart and moved now into a sys admin job. I kinda like it because once everything is nicely automated I did my work :-)

This is one reason I'd much rather be discovery-oriented than goal-oriented.

If you look at all of these as just part of achieving your goal, then all of these are negatives. The compiler prevents you from achieving things, your bug reports remind you how you haven't achieved them, every missed deadline makes you wonder if you'll ever achieve them, and your customers don't appreciate it when you do achieve them.

But if you look at all of this as a process of discovering what customers want and how to accomplish that, all of those negatives become positives. Your compiler error tells you early about something that would've become a problem later on. Your bug report reminds you of a case you haven't handled, some subtlety of the problem that you're just now learning about. Your missed deadlines mean that you didn't know enough about the project to estimate accurately before, so now you have more information about its true scope. And your unhappy customers will tell you ways in which you can improve.

Same facts, wildly different interpretations.

I reckon it depends on the size of the company you work for too. Obviously there will be always some errors and problems but there is also quite a lot of thinking and creative work to be done. Especially if the team is not massive and you take part in decision making process. Not exactly the "turn this coffee into code" type of job.

My friend working in a oil industry/software company (quite big) told me once - here you only get noticed when you manage to screw up something.

> I find myself wondering how adaptation is even possible.

I've been doing this job for 7 years now, and I've wondering along these lines a lot more lately, because I honestly do like what I'm doing and I plan do it for another 7-10-20 years. My current best answer is "don't take anything personal".

Yes, the latest bug will always be something that would risk taking us all one step closer to Armageddon, or so the clients/non-IT-colleagues would like to make us programmers think, but whenever I'm put into this position ("the world is crushing! do something!") I try to chill it down before taking action.

Also, there are always, always harder things in life than being a programmer, I try to remind me of this whenever I can. Just this summer I went out to help my grandma' pick up plumes during a weekend. A peasant, she's in her mid 80s now, she hasn't had a day of "vacation" or "paid holiday" since she married grandpa', 60+ years ago. One of her biggest regrets that she's experiencing right now is that she hasn't the physical strength anymore to work as much as she did for each day of her adult life.

Humans can adapt to almost anything.

But for me, it is a matter of not caring about the bugs but enjoying fixing them.

I agree; the punches are pulled.

13 years in the industry here.

Your ability to relate to, and communicate with, people in the real world (in depth) will degrade over time.

Try working in support for a while. Customers only call when something isn't working the way they expect, and since documentation is usually and afterthought among development teams, figuring out what is really possible with the software is often difficult. When you do identify bugs, you often have to go back to the customer to tell them it's not going to be fixed - and take the abuse that comes with those messages. Let's not even talk about non-technical salespeople who may not really know what the product is capable of and either tell customers wrong things or outright lie about what the product can do to make a sale. At which point, once again, the problems end up in the laps of support engineers.