"When I'm grumpy, I stop being grumpy and start being awesome instead!" ;)
Fair enough. However, I miss one thing: grumpiness is rarely a natural state of mind, and positive thinking is not the Universal Cure - it may be useful to look for and treat the underlying cause of grumpiness.
This point got me thinking. Public criticism of specific individuals is not something I ever to publicly, but I have been all too quick to compose tweets about things like "wishing that Internet Explorer had a face so I could punch it", or how terrible healthcare is in the US, etc.
It seems obvious in hindsight, but refraining from putting too much negativity in my public streams of information lately has probably not only improved the impression others have of me, but more importantly, made me feel a lot less grumpy myself.
In my efforts to focus on the positive and/or interesting things in my public speech, I find that I'm looking at these things more often in my private time as well. It's a rewarding exercise.
"In my efforts to focus on the positive and/or interesting things in my public speech, I find that I'm looking at these things more often in my private time as well. It's a rewarding exercise."
There are pros of publicly criticising some work (not the author). If it's something common, then everyone involved gets to see a bad example and a better solution. Otherwise you'll have to explain the same thing to a number of people separately costing you even more time and even more criticising. There are just some things where providing a positive example just isn't enough. Some things get broken many times in the same way and the main idea is not "here are better ways", but "this is the really bad example, never do that".
I very much agree with you (and am prone to negative tweets), but also wonder: at what point does it become emotional self-censorship? Are we to only post fun, happy things online? Are we slaves to our personal brand? Is it important that others perceive us better?
Taken too far, this seems like yet another way our online image becomes fractured from our identity. And maybe its better that way. I just detest the feeling of always giving people what they want.
When I was first learning how to code, I was afraid to ask questions in the developer community, for fear that I would be ridiculed as stupid. For some reason I felt like I was bothering or interrupting if I asked a developer a question. Maybe it was some of the people I was around, but a lot of developers are very opinionated and strongly believe that certain things should be a certain way. I think because developers have to defend their way of thinking all the time. They can become guarded and if their ideas are supported, they can develop a sense of pride to a point where they consider others around them incapable. I think some of the grumpiness stems from that. Some developers think they're better than others and everyone else wastes their time.
So let's say an app erases your hard drive if you use it the wrong way, but it is easy to fix with a registry tweak anyone can do. Should we really only drop a personal note to the author instead of warning everyone it sux0rs and having a discussion in public where people can become aware of the problem and work around?
Pointing out problems with things is one of the most useful parts of communicating with others, and this article advocates not allowing it most of the time. Would you read a publication's movie or restaurant reviews if the reviews only ever said good things about the movies? I sure as hell wouldn't, I'd look for one that gave the whole picture.
I definitely think there are times when you have to call things out in public. Your scenario is a perfect example of that. My general point is that I think we can be too quick to do it.
Autocomplete for "why steve jobs was a" gives "Jerk" as first result. Doesn't matter what the world perceives us. There is too little time to keep up with all the shit in the world. If one line email replies, coming to the point in a hour long meeting and ending it in 5 minutes is perceived by the rest as grumpiness, then let's be grumpy. And who says great developers don't have fun. They just don't mix it with work, so you don't get to know.
This isn't about perception or having fun, it's about behaviour having a genuine negative impact on things.
Developers have a tendency to optimise for themselves or for what they perceive as important. Sure curt replies and cutting meetings short may be the right thing to do and often is, but in many instances they're the right thing for the developer rather than for everyone involved.
If these actions result in developers being seen as unapproachable then there are genuine consequences of that - developers will be consulted less (which long term will have a negative impact both on the organisation and on the developer who will ultimately have less influence than they might have), clarifications won't be sought or offered uninvited (which always comes back on developers) and so on.
In of itself any individual action is potentially defensible, but if the overall effect is to deter useful lines of communication within a team, that's going to work out worse for everyone.
Autocomplete for "why steve jobs was a" gives "Jerk" as first result.
That was kind. My first impulse was to see what autocomplete has to offer about blogs and bloggers. Autocomplete for "why bloggers are" gives "not journalists" as first result, whereas "why blog authors" comes up with "ask rhetorical questions". Not to mention the first result for "why blog writers are".
Seriously, let's not use Google autocomplete as an excuse to jump on a meme bandwagon.
There was a post and a discussion not so long ago (can't find it now, no matter how much I try) about how people in our line of work focus on the negative by nature of our work and how we receive negative feedback all the time. At least that discussion was interesting, whereas this post is a typical "don't be such a jerk" post. Not that I necessarily disagree with the content, but this has crossed beyond the "beating the dead horse" territory into that "inflict Peter Jackson gore films on the poor dead horse" place that, ironically, makes me even grumpier.
Sometimes projecting an air of grumpiness is the most socially apropos way to keep people away from you when you need to focus intensely on difficult problems. It's one thing if you're talking to another developer or someone who at least has some sense of the focus that programming requires, but if you work with a fair number of non-technical people it's sometimes not enough to give an academic explanation. It's just in some people's nature to always ask a question in person or on the phone rather than email where it can be dealt with asynchronously. I am very friendly when the time is appropriate, but if it's not, and I allow interruption it is bad for everyone. Sometimes I even feel guilty for explaining that I need the vague and complex bug report in an email rather than casually delivered from my door frame. If, when necessary, I can simply repel people without breaking concentration than it's for the greater good.
How on earth do you get to "it's the most socially appropriate way"?
It's often the easiest and lowest effort for the developer, but what basically amounts to passive aggression is never going to be remotely sociably appropriate.
If you educate people you get a massively better outcome - you don't get interrupted when that's important to you and you're more likely to get valuable and useful interaction when that's acceptable.
Uhh. not to be grumpy, but i read socially apropos as socially relevant and not socially appropriate.
Disclaimer: am biased towards the OP. sometimes grumpiness can keep people away and let your brain/attention free from figuring out having to find the socially appropriate response/action.
About the only thing you can append to socially to describe grumpiness accurately is unappealing.
As I say it's easy for the developer, it gets the result the developer wants but it's optimised purely for the developer and purely for the short term. It's worse for the other party in the short term and it's worse for everyone in the long term.
How is being outwardly aggressive "passive aggression"? It's basically the complete opposite.
Passive aggression would be cheerfully saying "Thanks, that's a great idea, I'll be on it ASAP!", then just ignoring the idiotic request. "Oops, I forgot to tell you, that change we discussed? I looked into it, and it's just not feasible. But I can have another shot, if you still think it's important!". That's passive agression. The whole point is, it's not grumpy (until they call you out, and you start blaming them for making unreasonable requests).
I read it as passive aggressive as generally there is little actual communication, it's more about putting up an air of unapproachability but I accept that may vary from developer to developer.
But regardless, it's anti-social and suboptimal for anyone other than the developer and even then only in the short terms.
When I feel really grumpy, and I manage to catch myself feeling that way, I find the better thing to do is to tell the person that I am busy and stressed. They are much more likely to leave me alone and treat me with respect later when I handle it that way.
Sometimes we all become a steamy kettle, but there are better ways to make friends and influence people.
Grumpiness, at least for me, comes from the frustration of dealing with people who don't understand the ramifications of their change-requests. "Can this app run in offline mode?", "Can you make it run in 128k RAM?", "Your software doesn't work right if I run a butter knife across my motherboard when I start it up!"
What seems like a simple change to them is actually a large change to me, and the pushback/explanation burns through my emotional capital. Without that emotional capital I become grumpy.
I think it is also related to the fact that much of what software developers do is a waste of time. By this I mean that if the app or service was specced correctly the first time (by the end-user or project manager knowing what they wanted) then there wouldn't be so much backtracking or code getting thrown out. All that wasted effort tends to make one question what they're doing with their life and makes them grumpy.
> By this I mean that if the app or service was specced correctly the first time (by the end-user or project manager knowing what they wanted) then there wouldn't be so much backtracking or code getting thrown out.
And if applications were written correctly the first time organisations wouldn't have to waste money on test teams or help desks and users wouldn't have to waste time dealing with application crashes and bugs, if developers could estimate project mangers wouldn't have to waste time replanning and writing exception reports when things overrun.
Until we're all perfect it's really best not to go down that route.
So basically what you're saying is: it's everyone elses fault.
Seems like you need to improve communication in your org. and get more involved with the business side. The common denominator in all the problems you listed is you.
You can't control what other people think or say, but you can control how you respond. I think I learned that from some TV character in anger management classes, but it seemed like a good nugget of wisdom.
I don't think it's a wise idea to get grumpy (particularly visibly grumpy) with people who make unreasonable change requests. They don't do it to be mean, they do it because they are ignorant. So, it's up to you to educate them - try not to be condescending, try to be enlightening. Take them down the rabbit hole and show them what you can do quickly, and what takes time, and why.
When someone asks me to do something, I like to present multiple options to achieve their objectives, highlighting easy ways to do things that may have drawbacks, but take less time, and also fully explaining the time and costs of their intial thoughts.
The key, I think, in working with business people on software is being obviously willing to do some work to achieve their objectives, but also offering a pragmatic, technical point-of-view. Don't leave them room to think you just don't want to do something - express that you are definitely going to do something, but guide them to the right path.
I'm reminded the "Four letter words" from Rework. How many times have you been asked "Can you just get <feature> done. It only has a few parts and should be easy!"
I think it is also related to the fact that much of what software developers do is a waste of time. By this I mean that if the app or service was specced correctly the first time (by the end-user or project manager knowing what they wanted) then there wouldn't be so much backtracking or code getting thrown out. All that wasted effort tends to make one question what they're doing with their life and makes them grumpy.
The problem is that your actual job is different from what the people signing your paychecks and writing your performance reviews tell you it is.
You only think your job is to write code as specified. Really, your job is to make whatever people need to happen, happen. Not what they want, and not what they say they need. And so when you build what they say they want, and it turns out to not be what they actually need, you have to rebuild it differently.
Supposedly "Agile" fixes this when done right, but I get the feeling that doing Agile right is about as hard as finding a true Scotsman. :(
Agile helps because you say yes to everything, but you give people a timeline.
For example:
Sure, Mr./Ms. Project Manager this can work in offline mode, but that story is worth 46368 points. At the current rate of 50 points a week, it will take the team approximately 18.6 years to complete. Do you really want us to start working on it, or should we think of another way to make this work?
To all the 'justified in my bitterness' responses:
Yes, it's hard work being more knowledgeable, productive, smarter, better, than people around you. This is particularly a problem in software development since it takes an intense and often fleeting concentration to be really productive. Interruptions, especially those stemming from the ignorance or poor choices of others, provoke an immediate frustration and bitterness which seems (and probably is) justified.
Being justified, however, doesn't mean it's helpful. When I'm faced with these situations I often find myself analyzing in my head all the reasons that I shouldn't have to deal with this, why the person who brought it up is an idiot, how much better it would be if I could just be left to get things done. None of this thinking is productive, or even gratifying, except in the shallowest sense.
As hard as it is, the appropriate response to ignorance, idiocy, or other negative stimuli is NOT to be negative, but instead focus on positive solutions. Change the system where you can (as close to the source as possible) but don't compound wasted time by spending your energy being bitter about it.
What bothered me most about this essay was one point near the end:
"Ask yourself, 'Am I being grumpy right now?'. If the answer is yes, then stop!"
This is a non-realistic response to an issue of moral with a real underlying cause. What bothers me most about this is that it will only cause further issues with the developer as they cover the problems with the group they are working with. Their proposed solution is what someone would say to someone suffering from depression, 'Just stop being unhappy and cheer up!'.
This does not work, what they suggest will not work and will only further the decline of morale, company culture, and retention of developers. Grumpiness is a symptom of underlying causes within a company.
Yeah, when I read those two sentences, my first inclination was to punch him in the face and say, "You don't know why I'm grumpy; you don't know what I deal with in my personal life; you don't get to make vapid self-help nonsensical context-free prescriptions that amount to magical fairy dust."
So glad someone posted this here. Ricky is an awesome guy! Just met and befriended him at TwilioCON. This is the presentation he did there. It was great. :)
If you are working for me, my expectation is that you will treat everybody (both on my team and not) with professionalism and respect, even if you feel you aren't getting enough respect from others[1].
Even if you are doing that, if you are continually negative and surely (e.g. not quite grouchy, but certainly not pleasant), your tenure on my team will be short[2]. Negativity spreads like a cancer until it destroys morale on a team, and I won't let somebody on my team be the carcinogen, no matter how "amazing" you are at coding.
I take these things very seriously because I've been on teams that self-destructed over them. Even if you are a "10x" developer, if you are making the rest of the team "0.1x" developers, you are not providing me with value. If you are being grouchy, negative, surely or rude because you see yourself as a 10x developer so you are justified in acting however you want, you are welcome to go back to pre-school where that behavior is expected.
1. I also expect others to treat my team with respect and will fight to the death for my team to be respected as such, but, in the end, I have less direct control over that.
2. Of course I will try to resolve the issue through communication and managing (you know, my job if you are on my team). Some people are receptive; some people are not.
Could only upvote once. Well said. There are lot of people who still do not understand the importance of team work and personally for me, it is never cliched. Your line "Even if you are a "10x" developer, if you are making the rest of the team "0.1x" developers, you are not providing me with value" hit the nail on the head.
Sometimes it's out of your control. In a previous job, I worked with a "grumpy" developer who alienated every department we worked with, because he would be rude on the phone, terse in e-mails and generally unpleasant. As a result, the department developed a reputation for being unhelpful, and people communicated with us as little as possible. That definitely had an impact on my performance.
An example: "good" engineer thinks management are a bunch of idiots, leading him to constantly criticize and question decisions. This criticizing is done amongst the team, leading the entire team to question management and, therefore, the direction of the product. Now, instead of doing their best work, they are doing the minimum required to not get fired.
I've seen this happen. The engineer sowing the poison was complaining that management wasn't hiring enough engineers, even though the product was "profitable". He never considered that the analysis had been done that the product would not be any more profitable by cranking out more features and would, in all likelihood, be less profitable.
As a result, other engineers picked up on the meme and significantly reduced their efforts. After all, who is going to give their best efforts if management is just going to be stupid and waste it?
So maybe 0.1x is a bit of an exaggeration, but I can live with that.
I didn't look at the domain name or the author name when I first read it. Ricky Robinett was my boss 2 summers ago. He's really awesome and I've never seen him grumpy before.
It is ok to be grumpy. We are all human beings after all. What is not ok is when you start using your grumpiness against the people you work with. If team morale is down because of your grumpiness, no one really gives a shit how good of a developer you are. It is that simple.
I remember one of those project management training sessions where we were taught
Before you go hiring all those "happy developers" I would suggest searching for "grumpy employee productivity". You can cross reference it with estimates of the GDP affect of various fields.
Your grumpy developers are in the state where they identify the most problems and introduce the least bugs. They also might not be grumpy when not concentrating on your train wrecks.
But not to worry, giving bad management advice is a great way to make us more productive.
You are taking the word "grumpy" literally. In my opinion, the author is talking about a broader issue where you don't add value to a team/project when your attitude (grumpiness or whatever) is not in line with the rest of the team. Sure developers who identify most problems and introduce least bugs are great. But if they do that by constantly putting down others is being "bad grumpy".
Is he? I don't see what else could the author be referring to. Sure some people are definitely just assholes, bad seeds and whatnot, but this are rare enough and it's hardly worth stating the obvious about what to do with them.
So we must be talking about the broader issue of simply disgruntled team members, who, as stated, probably have valid reasons these managers and businesses are just plain ignoring.
Mediocre, complacent and just plain bad employees are easy to keep happy and retain. It's the real talent you have to work hard if you want to earn their respect and trust.
That all said, the article isn't even remotely clear on the problem it's talking about, and realistically it really probably is just a "stating the obvious" post about a non-problem. The discussion on HN on the other hand has much more substance and I feel the grandparent comment is relevant in that context.
What does grumpy mean? I get frustrated with my code. If I'm jamming out or in a bug sesh I have been known to be loud or a bit obnoxious, but it's all in context.
As with most posts like this, context is key. What's appropriate around my friends is not appropriate around my mother and the skill to recognize that is KEY but it's also not one that you're likely to learn from an article if you don't already "get it".
If grumpy just means rude and disrespectful, then you're just an asshole and your profession isn't super relevant.
Pretty useless without a definition of what it meant by "grumpy".
I've been a grumpy developer before because I didn't like my job and was constantly getting asked to work on waste of time projects that ended up getting thrown out, which I knew would happen. I should have fixed my attitude and been a more productive member of the team or quit and given professional feedback in the exit interview that might have helped them.
I've been called a grumpy developer because I pushed back against a culture of unpaid overtime and 60 hour weeks for the developers and 4 hour days for everyone else.
I've been called a grumpy developer because I pointed out technical problems with a proposed project or insisted that someone technical be involved in setting deadlines for the technical portion of a project.
First you need to describe what you mean by grumpy. It's a broad word. I was interested by the headline, developers have to deal with always trying to find problems or potential problems in things and it can colour how you view the world. We do seem more grumpy than average. It turned out be be a bunch of words tacked around the idea of "don't be sad! be happy!". We aren't in kindergarten, if I wanted childish advice without nuance I will go to the self help industry.
Also the advice telling developers not to publicly critique issues they disagree with is insane. The goal is a community striving towards improvement. Your self esteem issues can be handled by learning to ignore online idiots and learning to separate your self worth from your code (and definitely from the software tools you have chosen).
59 comments
[ 3.6 ms ] story [ 119 ms ] threadFair enough. However, I miss one thing: grumpiness is rarely a natural state of mind, and positive thinking is not the Universal Cure - it may be useful to look for and treat the underlying cause of grumpiness.
This point got me thinking. Public criticism of specific individuals is not something I ever to publicly, but I have been all too quick to compose tweets about things like "wishing that Internet Explorer had a face so I could punch it", or how terrible healthcare is in the US, etc.
It seems obvious in hindsight, but refraining from putting too much negativity in my public streams of information lately has probably not only improved the impression others have of me, but more importantly, made me feel a lot less grumpy myself.
In my efforts to focus on the positive and/or interesting things in my public speech, I find that I'm looking at these things more often in my private time as well. It's a rewarding exercise.
I really love that idea. Such a good point.
Taken too far, this seems like yet another way our online image becomes fractured from our identity. And maybe its better that way. I just detest the feeling of always giving people what they want.
To me it highlights a rationale for why this grumpiness may exist in the first place.
Pointing out problems with things is one of the most useful parts of communicating with others, and this article advocates not allowing it most of the time. Would you read a publication's movie or restaurant reviews if the reviews only ever said good things about the movies? I sure as hell wouldn't, I'd look for one that gave the whole picture.
Its one thing to say "Hey guys when you run X, your computer literally catches on fire"
and another to say:
"HAY GUYS, AUTHER X SUX0RS AND THERE APP BLOWS. IT MAKES YOUR COMPUTER EXPLODE LOL"
I know I'm guilty of this sort of thing sometimes.
Anyway, I don't think the author is saying you can't criticize at all, just be critical in constructive ways.
Developers have a tendency to optimise for themselves or for what they perceive as important. Sure curt replies and cutting meetings short may be the right thing to do and often is, but in many instances they're the right thing for the developer rather than for everyone involved.
If these actions result in developers being seen as unapproachable then there are genuine consequences of that - developers will be consulted less (which long term will have a negative impact both on the organisation and on the developer who will ultimately have less influence than they might have), clarifications won't be sought or offered uninvited (which always comes back on developers) and so on.
In of itself any individual action is potentially defensible, but if the overall effect is to deter useful lines of communication within a team, that's going to work out worse for everyone.
That was kind. My first impulse was to see what autocomplete has to offer about blogs and bloggers. Autocomplete for "why bloggers are" gives "not journalists" as first result, whereas "why blog authors" comes up with "ask rhetorical questions". Not to mention the first result for "why blog writers are".
Seriously, let's not use Google autocomplete as an excuse to jump on a meme bandwagon.
There was a post and a discussion not so long ago (can't find it now, no matter how much I try) about how people in our line of work focus on the negative by nature of our work and how we receive negative feedback all the time. At least that discussion was interesting, whereas this post is a typical "don't be such a jerk" post. Not that I necessarily disagree with the content, but this has crossed beyond the "beating the dead horse" territory into that "inflict Peter Jackson gore films on the poor dead horse" place that, ironically, makes me even grumpier.
EDIT: Thanks to @mrdazm for providing the link to the "Be nice to developers" discussion: http://news.ycombinator.com/item?id=4631607
It's often the easiest and lowest effort for the developer, but what basically amounts to passive aggression is never going to be remotely sociably appropriate.
If you educate people you get a massively better outcome - you don't get interrupted when that's important to you and you're more likely to get valuable and useful interaction when that's acceptable.
As I say it's easy for the developer, it gets the result the developer wants but it's optimised purely for the developer and purely for the short term. It's worse for the other party in the short term and it's worse for everyone in the long term.
How is being outwardly aggressive "passive aggression"? It's basically the complete opposite.
Passive aggression would be cheerfully saying "Thanks, that's a great idea, I'll be on it ASAP!", then just ignoring the idiotic request. "Oops, I forgot to tell you, that change we discussed? I looked into it, and it's just not feasible. But I can have another shot, if you still think it's important!". That's passive agression. The whole point is, it's not grumpy (until they call you out, and you start blaming them for making unreasonable requests).
But regardless, it's anti-social and suboptimal for anyone other than the developer and even then only in the short terms.
Sometimes we all become a steamy kettle, but there are better ways to make friends and influence people.
What seems like a simple change to them is actually a large change to me, and the pushback/explanation burns through my emotional capital. Without that emotional capital I become grumpy.
I think it is also related to the fact that much of what software developers do is a waste of time. By this I mean that if the app or service was specced correctly the first time (by the end-user or project manager knowing what they wanted) then there wouldn't be so much backtracking or code getting thrown out. All that wasted effort tends to make one question what they're doing with their life and makes them grumpy.
And if applications were written correctly the first time organisations wouldn't have to waste money on test teams or help desks and users wouldn't have to waste time dealing with application crashes and bugs, if developers could estimate project mangers wouldn't have to waste time replanning and writing exception reports when things overrun.
Until we're all perfect it's really best not to go down that route.
Seems like you need to improve communication in your org. and get more involved with the business side. The common denominator in all the problems you listed is you.
I don't think it's a wise idea to get grumpy (particularly visibly grumpy) with people who make unreasonable change requests. They don't do it to be mean, they do it because they are ignorant. So, it's up to you to educate them - try not to be condescending, try to be enlightening. Take them down the rabbit hole and show them what you can do quickly, and what takes time, and why.
When someone asks me to do something, I like to present multiple options to achieve their objectives, highlighting easy ways to do things that may have drawbacks, but take less time, and also fully explaining the time and costs of their intial thoughts.
The key, I think, in working with business people on software is being obviously willing to do some work to achieve their objectives, but also offering a pragmatic, technical point-of-view. Don't leave them room to think you just don't want to do something - express that you are definitely going to do something, but guide them to the right path.
Customer: "Your site went down right in the middle of an edit I was making."
Me: "Argh! That sucks! You're probably really frustrated right now. Let's see what we can do to get the bottom of it."
Just showing a little empathy can go a long way .
Can it be done offline? Yes.
Can it be made to run in 128k? Yes.
Can it be made to work in the exciting breadknife/motherboard interface market? Yes.
"The question you need to ask", I tell them, "is not can it be done -- but by when, for how much, with what disruptions?"
So far ... so good.
Those two sentences nail almost all fo them.
The problem is that your actual job is different from what the people signing your paychecks and writing your performance reviews tell you it is.
You only think your job is to write code as specified. Really, your job is to make whatever people need to happen, happen. Not what they want, and not what they say they need. And so when you build what they say they want, and it turns out to not be what they actually need, you have to rebuild it differently.
Supposedly "Agile" fixes this when done right, but I get the feeling that doing Agile right is about as hard as finding a true Scotsman. :(
For example:
Sure, Mr./Ms. Project Manager this can work in offline mode, but that story is worth 46368 points. At the current rate of 50 points a week, it will take the team approximately 18.6 years to complete. Do you really want us to start working on it, or should we think of another way to make this work?
Yes, it's hard work being more knowledgeable, productive, smarter, better, than people around you. This is particularly a problem in software development since it takes an intense and often fleeting concentration to be really productive. Interruptions, especially those stemming from the ignorance or poor choices of others, provoke an immediate frustration and bitterness which seems (and probably is) justified.
Being justified, however, doesn't mean it's helpful. When I'm faced with these situations I often find myself analyzing in my head all the reasons that I shouldn't have to deal with this, why the person who brought it up is an idiot, how much better it would be if I could just be left to get things done. None of this thinking is productive, or even gratifying, except in the shallowest sense.
As hard as it is, the appropriate response to ignorance, idiocy, or other negative stimuli is NOT to be negative, but instead focus on positive solutions. Change the system where you can (as close to the source as possible) but don't compound wasted time by spending your energy being bitter about it.
What bothered me most about this essay was one point near the end: "Ask yourself, 'Am I being grumpy right now?'. If the answer is yes, then stop!"
This is a non-realistic response to an issue of moral with a real underlying cause. What bothers me most about this is that it will only cause further issues with the developer as they cover the problems with the group they are working with. Their proposed solution is what someone would say to someone suffering from depression, 'Just stop being unhappy and cheer up!'.
This does not work, what they suggest will not work and will only further the decline of morale, company culture, and retention of developers. Grumpiness is a symptom of underlying causes within a company.
Even if you are doing that, if you are continually negative and surely (e.g. not quite grouchy, but certainly not pleasant), your tenure on my team will be short[2]. Negativity spreads like a cancer until it destroys morale on a team, and I won't let somebody on my team be the carcinogen, no matter how "amazing" you are at coding.
I take these things very seriously because I've been on teams that self-destructed over them. Even if you are a "10x" developer, if you are making the rest of the team "0.1x" developers, you are not providing me with value. If you are being grouchy, negative, surely or rude because you see yourself as a 10x developer so you are justified in acting however you want, you are welcome to go back to pre-school where that behavior is expected.
1. I also expect others to treat my team with respect and will fight to the death for my team to be respected as such, but, in the end, I have less direct control over that.
2. Of course I will try to resolve the issue through communication and managing (you know, my job if you are on my team). Some people are receptive; some people are not.
I've seen this happen. The engineer sowing the poison was complaining that management wasn't hiring enough engineers, even though the product was "profitable". He never considered that the analysis had been done that the product would not be any more profitable by cranking out more features and would, in all likelihood, be less profitable.
As a result, other engineers picked up on the meme and significantly reduced their efforts. After all, who is going to give their best efforts if management is just going to be stupid and waste it?
So maybe 0.1x is a bit of an exaggeration, but I can live with that.
I remember one of those project management training sessions where we were taught
T E A M = Together Everyone Achieves More
Your grumpy developers are in the state where they identify the most problems and introduce the least bugs. They also might not be grumpy when not concentrating on your train wrecks.
But not to worry, giving bad management advice is a great way to make us more productive.
So we must be talking about the broader issue of simply disgruntled team members, who, as stated, probably have valid reasons these managers and businesses are just plain ignoring.
Mediocre, complacent and just plain bad employees are easy to keep happy and retain. It's the real talent you have to work hard if you want to earn their respect and trust.
That all said, the article isn't even remotely clear on the problem it's talking about, and realistically it really probably is just a "stating the obvious" post about a non-problem. The discussion on HN on the other hand has much more substance and I feel the grandparent comment is relevant in that context.
As with most posts like this, context is key. What's appropriate around my friends is not appropriate around my mother and the skill to recognize that is KEY but it's also not one that you're likely to learn from an article if you don't already "get it".
If grumpy just means rude and disrespectful, then you're just an asshole and your profession isn't super relevant.
I've been a grumpy developer before because I didn't like my job and was constantly getting asked to work on waste of time projects that ended up getting thrown out, which I knew would happen. I should have fixed my attitude and been a more productive member of the team or quit and given professional feedback in the exit interview that might have helped them.
I've been called a grumpy developer because I pushed back against a culture of unpaid overtime and 60 hour weeks for the developers and 4 hour days for everyone else.
I've been called a grumpy developer because I pointed out technical problems with a proposed project or insisted that someone technical be involved in setting deadlines for the technical portion of a project.
First you need to describe what you mean by grumpy. It's a broad word. I was interested by the headline, developers have to deal with always trying to find problems or potential problems in things and it can colour how you view the world. We do seem more grumpy than average. It turned out be be a bunch of words tacked around the idea of "don't be sad! be happy!". We aren't in kindergarten, if I wanted childish advice without nuance I will go to the self help industry.
Also the advice telling developers not to publicly critique issues they disagree with is insane. The goal is a community striving towards improvement. Your self esteem issues can be handled by learning to ignore online idiots and learning to separate your self worth from your code (and definitely from the software tools you have chosen).