3 ms·

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 r

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.

Tyrannosaurs 14y ago
> 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.
gearoidoc 14y ago
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.
andrewljohnson 14y ago
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.
- drumdance 14y ago
  I've found that when someone is grumpy/angry (i.e. a customer who is pissed off), the best way to disarm it is to just empathize a little. Example: 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 .
  - mingmecca 14y ago
    I agree. Giving empathy generally evokes the empathy of the recipient, forming a positive feedback loop.
jacques_chester 14y ago
I tell all my clients that the answer to all requests, modulo certain impossibilities such as solving the TSP, is "yes". 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.
- nahname 14y ago
  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!" Those two sentences nail almost all fo them.
tbrownaw 14y ago
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. :(
- a_c_s 14y ago
  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?

Tyrannosaurs 14y ago

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

gearoidoc 14y ago

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.

andrewljohnson 14y ago

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.

drumdance 14y ago
I've found that when someone is grumpy/angry (i.e. a customer who is pissed off), the best way to disarm it is to just empathize a little. Example: 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 .
- mingmecca 14y ago
  I agree. Giving empathy generally evokes the empathy of the recipient, forming a positive feedback loop.

jacques_chester 14y ago

I tell all my clients that the answer to all requests, modulo certain impossibilities such as solving the TSP, is "yes". 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.

nahname 14y ago
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!" Those two sentences nail almost all fo them.

tbrownaw 14y ago

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

a_c_s 14y ago
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?