Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be nice to programmers

edu.mkrecny.com

Post reply on HN
Print view View original

81–90 of 178 posts

Re: Be nice to programmers

#81

Post by wreckimnaked »

AerieC wrote: post #49
jerf wrote: post #33

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 "Hoor…

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 negati…

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

Re: Be nice to programmers

#82

Post by daenz »

wvenable wrote: post #78
daenz wrote: post #31

Earlier quoted context omitted.

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/…

I'm sure my error rate is a fraction what it used to be but I'm producing far more code and working on far larger problems. You better hope that areas of improvement on are the ones that scale to larger problems.

The original article was about error rate, that's what I was talking about:

  1. write some code
  2. run the code
  3. get an error message
  4. find the error and back to step 1
  
  Hour by hour, day after day, I do this. Always searching 
  for what's wrong with what I'm creating, rarely thinking
  about what's good about it. It's a negative reinforcement
  feedback loop.
If the error rate was lower, steps 3 and 4 would happen less frequently.

Re: Be nice to programmers

#83

Post by bradleyland »

jerf wrote: post #58
AerieC wrote: post #49

Earlier quoted context omitted.

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 negati…

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…

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.

Re: Be nice to programmers

#84

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

Re: Be nice to programmers

#85

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

Re: Be nice to programmers

#86

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

Re: Be nice to programmers

#87

Post by andyzweb »

lachyg wrote: post #80
jerf wrote: post #58

Earlier quoted context omitted.

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…

> 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

Re: Be nice to programmers

#88

Post by 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.).

Re: Be nice to programmers

#89

Post by pawelwentpawel »

jerf wrote: post #33

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 "Hoor…

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.

Re: Be nice to programmers

#90

Post by indiecore »

jaggederest wrote: post #63

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…

>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
Post reply on HN