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.
Be nice to programmers
121–130 of 178 posts
Re: Be nice to programmers
#122Earlier quoted context omitted.
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 expe…
>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 Even the smartest people I know write imperfect/buggy code, especially the first time around. If you don't take it personally - as you shouldn't - I don't see the issue.
I don't understand the issue either. A compiler warning or exception report is immediate and precise feedback. What could be easier to deal with impartially?
The bigger picture of course is that criticism, whether it comes from other humans, machines, or oneself, is the only way to improve anything. If you want to create anything worthwhile you have to have some mechanism to improve. Why would we want to bury our heads in the sand just so that we never have to hear a critique?
I suppose you could get a rote job on an assembly line and spend your free time watching TV and you'd never have to hear another complaint, but that sounds like an absolutely miserable life to me.
Re: Be nice to programmers
#123Earlier quoted context omitted.
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 expe…
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 ana…
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.
Re: Be nice to programmers
#124The 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 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.
Re: Be nice to programmers
#125Among 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…
Maybe it's just me but I've always seen these things as positive feedback loops. I write a failing test so that I have a guide as to what to do next. I fix a bug so that my app does a better job for my user. I'm not sure where his negative attitude comes from, maybe he likes to believe he can write perfect software and takes it at as a personal failure when he gets a bug report? Personally I find coding therapeutic, at the end of every day I know that the product I'm working is a little bit better than it was yesterday.
Re: Be nice to programmers
#126The 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…
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 :)
Re: Be nice to programmers
#127The 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…
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.
Re: Be nice to programmers
#128Earlier quoted context omitted.
>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 Even the smartest people I know write imperfect/buggy code, especially the first time around. If you don't take it personally - as you shouldn't - I don't see the issue.
I don't understand the issue either. A compiler warning or exception report is immediate and precise feedback. What could be easier to deal with impartially? The bigger picture of course is that criticism, whether it comes from other humans, machines, or oneself, is the only way to improve anything. If you want to create anything worthwhile you have to have some mechanism to improve. Why would we want to bury our hea…
Yes, feedback is helpful and you shouldn't take criticism personally. No disagreement. But feedback that's mostly focused on small problems is draining and criticism is draining. If that's not the case for you, awesome. It's the case for some people. Try to empathize with them. The article articulates that draining feeling and I find that pretty insightful and useful.
Re: Be nice to programmers
#129This 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 t…
>if you are running into bugs that take you 4+ hours to resolve, you simply have not been programming long enough.
Firefox had a memory leak that took years to track down and eliminate, so according to your logic Firefox does not have any employees that have been programming long enough.
Re: Be nice to programmers
#130Earlier quoted context omitted.
I know, but I think the way you were talking about it brought "what it means to be a programmer" into line with working as a programmer generally. He's talking about how a pessimistic feeling about being a programmer arises. But I think you're essentially saying: just avoid that problem and it'll work out. That train has left the station. You say "no need to be a pessimist" but I don't think that's what's going on at…
You have really made me think with this comment. I will have to come back later to address it properly.
For the record, it's clear to me that you're speaking from a sincere desire to share what's worked for you (including a bunch of sound strategies for addressing problems as they arise) with other people. That's super cool. I just want to defend the idea that there's more to breaking the bigger cycle of drain/burnout described here than choosing to think positively.