6 ms·

* Zero career direction and zero technical speciality for devs * Underestimation of difficulty whether through cynicism (burn the devs) or cluelessness * Inad

* Zero career direction and zero technical speciality for devs * Underestimation of difficulty whether through cynicism (burn the devs) or cluelessness * Inadequate training and expectation devs can just piggy back learning technology x from scratch whilst writing production software using it * Trying to use one off contracts as a way of building resellable products * Insistence that all devs time must be billable and trying to defy gravity in ignoring skills rot etc. through lack of investment in training * Expectation that devs can be swapped between technologies without problems * Swapping people in and out of projects as if this will not affect progress * Deliberate hoarding of information as a means of disempowering devs All of this inevitably leads to a bunch of pissed off devs. The ones that are happy to eat it become the golden boys and get promotions. Those that point out the bullshit leave once they can and are replaced with the desperate at the bottom who sooner or later arrive at the same position of wanting to leave once they realise what's going on. I think tech can be pretty miserable if you are not in the upper echelon of lucky types that can score a position at a Google, Facebook etc. Oh and a couple more: * Give no feedback unless things go wrong * Treat your highly educated, intelligent and motivated devs like children by misusing agile in order to micromanage them

FooHentai 9y ago
>Insistence that all devs time must be billable That one can hit all areas of ICT real bad when the company is a managed service provider, leading to a 'Chefs kitchen/Plumber's bathroom' where the company provides great outsource ICT services offering to its clients, but runs an absolute shitshow for it's own systems because they're chronically under resourced (you can't bill it, so don't spend time on it). That has extra interesting results when such a company tries to spin up and sell services which it's built/hosting/maintaining/developing itself.
- Boothroid 9y ago
  Hadn't heard that one before, interesting observation.
  - FooHentai 9y ago
    A lot of non-tech companies treat IT as a cost center and that can lead to short sighted decisions that cost them a lot in the long run (or more accurately, they fail to realize benefits that were available to them with appropriate investment). But it seems counter intuitive that this effect can be worse for some tech companies, where a major part of their business involves convincing clients to treat their tech as more than just a cost center. Like, you have an entire staff compliment of developers, architects, PMs, engineers and customer service staff, and your own entire ICT practice is a disaster? HOW? I ended up having to draw people's attention to it by pointing out 'this is your single biggest client, and receives the least attention of them all'. Loops into the old 'eat your own dog food' wisdom, but from an angle that seems to often get missed.
    - gaius 9y ago
      Well you could be like IBM which sells remote working solutions but has banned it for their own staff. Or maybe that was HP, or both.
      - patrickking 9y ago
        That was a slimy downsizing measure. IBM doesn't have to pay severance if their remote workers quit on their own rather than come in 9 to 5.
    - BrandoElFollito 9y ago
      Because of this mindset, companies who decided to outsource IT as an obvious cost optimization realized how their company actually runs. Specifically that there are huge off-the-record operations (outside of the ticket system). The more VIP the problem is, the less tickets. And suddenly, the people supporting them (particularly if they were outsourced but stayed in the company as contractors, and were pissed off) had one sentence "open a ticket". Doesn't matter if this is the CEO asking, or something "urgent", ticket it is. And the gates to hell opened. Source : me not being IT anymore (huge company) but strongly advocating against the outsourcing (pointing to the above), and then taking a backseat and watching the world burn with popcorn in hand.
- mathattack 9y ago
  This last point is universal in companies that bill hourly.
- ghostly_s 9y ago
  I think I get what you mean by 'Chefs kitchen/Plumber's bathroom', but I've never heard either colloquialism before and can't find anything on Google, either. What's the origin of these terms?
  - dantheman0207 9y ago
    "Too many chefs in the kitchen" is the first one. Not sure about the second, but probably the same kinda thing.
    - elijahwright 9y ago
      There is a required reference here to "Too Many Cooks". Thanks, Adult Swim!
  - cpeterso 9y ago
    Based on the context, something like "the cobbler's children have no shoes" meaning they are too busy doing paid work for others to the same work for themselves. https://english.stackexchange.com/questions/159004/the-cobblers-children-have-no-shoes#159040 https://english.stackexchange.com/questions/159004/the-cobbl...
  - lfowles 9y ago
    I don't think it's related to too many chef's in the kitchen. More a reference to chefs having a spotless kitchen at their day job, but a messy kitchen at home. Likewise for plumbers.
pestkranker 9y ago
> * Trying to use one off contracts as a way of building resellable products Can you tell me why? Sometimes, asking a client for 50k instead of 80k with a "spin-off" agreement can pay to both parties. The client can get long-term support with new features without the need to pay for it.
- slumberlust 9y ago
  Sometimes it can work. More often it starts innocently and mutually as you describe, but it very quickly becomes a game of firefighting and drains innovation within the product line. Next thing you know, you're selling based on roadmap features and don't have control over your own product anymore.
- Boothroid 9y ago
  I agree that sounds like a reasonable approach - but in my working life it's always been seen as this fantastic wheeze of 'let's charge one customer to build something and then go off and sell it to everyone else!'. It seems like a great idea, but the usual story is that either making it generic burns up days that would otherwise be spent meeting the specific customer's requirements, thereby ensuring a worse product, or you stay on track with the customer's requirements and ditch the idea of making it generic as soon as days get tight. This is one of the things that always makes me groan, along with 'and you can learn x technology along the way!' >:|
  - dvtv75 9y ago
    Out of the blue, I was once expected to set up a recording studio and learn the electrical engineering side of things 'along the way! You've got the afternoon, in addition to your normal duties.' My background is in CS, not physics or engineering, so you can imagine how that went - and of course, the manager wasn't to blame.
- cmiles74 9y ago
  In my experience, often the product ends up being molded to fit the particular client (it's custom software, after all) and then the cost of altering it for other clients is perceived as too steep. Or you end up with a bunch of similar, incompatible projects.
FractalNerve 9y ago
> * Give no feedback unless things go wrong > * Treat your highly educated, intelligent and motivated devs like children by misusing agile in order to micromanage them These two points made me cry. I suffered my very first burn-out due to that and although having a higher degree in computer science and love towards programming this really made me feel like a piece of shit. I have the feeling that it's really hopeless and it wants me to make the change to IT-Consulting instead of software-engineering.
- Boothroid 9y ago
  Oh dear, I'm really sorry for touching a nerve! I think management often have zero insight into how much many devs care about their work. Not all - I'm sure there are plenty with a thick skin and/or that care little beyond getting paid - but some of us are only capable of delivering our best given the right conditions. Lack of feedback is one of the most serious red flags I would say, and shows either the company is seriously dysfunctional, or that they absolutely do not give a shit about your progress. At that point the job should become just a paycheck until something better comes along. The funny thing is when they expect you to do your best work despite not keeping up their side of the bargain!
  - auserperson 9y ago
    That is very true for me. A lot of managers don't understand my motivation at work, they don't understand that what actually keeps me going is the love for technology and for software engineering. That is being able to learn and develop interesting things, to research, to create, that motivates me. I can't bother on corporate politics. I don't care on going up the corporate ladder (I'm already in a top engineering position, I don't want to stop doing coding to become some sort of manager/architect/VP/etc).
- dajohnson89 9y ago
  Unless you're doing your own thing, consulting is often way worse.
- 0xfeba 9y ago
  Also hits a nerve for me. Our mgmt just shuffles devs around from fire to fire without really just sticking the same devs to a single project until it's done. Then we get questioned why projects are not done. And don't get my started on our new Agile process. We have scrum meetings for our scrum meetings. We have mgmt. popping in the project level scrum meetings to tell us what is and isn't scrummy enough to talk about during the meetings. And I moved to this company after thinking my last company didn't have it together. Man, I was wrong. No one writes comments here, or any tests. We just "make it work". Pay is awesome though...
Boothroid 9y ago
Unfortunately I've just thought of another - moaning about time estimations - even after these have been pared down to the absolute minimum with the expectation of putting in extra hours on the side to meet the deadline! Good to get this stuff of the chest sometimes.
- shados 9y ago
  oh that one drives me insane. "This will take 40 hours" (I hate estimating in hours for individual tasks as there's no way to average the overrages with the ones that went under estimate). "Thats too much, can you do it in 20?" "No, 40 is already underestimating imo" "Well, it won't fit in the project plan at 40" "Sorry, that's really as fast as it can" "Well, lets put 20 and either make up the time or just go over" (wtf?)
vmattos 9y ago
> * Give no feedback unless things go wrong As a DevOps engineer, I feel it all the time (and not only from managers)
- justin_oaks 9y ago
  Ah, the realities of supporting IT infrastructure. When things go right, management wonders why they even pay you. When things go wrong, management wonders why they even pay you.
technofire 9y ago
> All of this inevitably leads to a bunch of pissed off devs. The ones that are happy to eat it become the golden boys and get promotions. The question asks about behavior that management repeatedly makes. If management repeatedly makes these mistakes, then the mistakes should become expectations, so one should simply accept them and understand that they are part of the game being played. If they are expected behaviors, being "pissed" about them simply is foolish. Of course, by "accept them" I don't mean one should never try to influence or change the situation, but reacting emotionally rather than rationally is silly. Even if there are no upward-feedback or 360 review procedures in place at the workplace, one can articulate these concerns more diplomatically (less offensively) and send out an email requesting that they be considered. One can even illustrate and trace through how such mistakes have impacted recent projects. It seems to me that the ones "happy to eat it" simply understand that others have limitations and make mistakes and will try to make the best of the situation. It sounds to me like such people indeed deserve the promotions more than people who bring anger to bear on their work.
- Boothroid 9y ago
  That sounds a bit like you are suggesting excusing bad behaviour, or blaming the victim. If someone warns you they are going to hit you before they hit you, does it make it hurt any less? Also when eating it means 60 hour weeks to make up for terrible managers (all the while collecting their substantial pay packets) I'm quite happy to walk out the door and let then find someone else to be abused. Passed a telephone interview today, got a f2f next week, hopefully onwards and upwards soon.
- justin_oaks 9y ago
  > one should simply accept them and understand that they are part of the game being played. If they are expected behaviors, being "pissed" about them simply is foolish. Does this apply to athletes who are upset when referees seem to be consistently favoring their competitors? Does it apply to people living under an oppressive government? Does it apply to a person who is being verbally abused by a spouse? Sure it'd be great if these people could seek to improve their situation through rational means, or perhaps just accept it if they can't change it, but humans and emotions don't work that way. > reacting emotionally rather than rationally is silly Humans are emotional creatures. Expecting humans, even yourself, to act rationally shows a misunderstanding of human psychology and behavior.
deleted 9y ago
[deleted]
- zoner 9y ago
  Not really. It's about changing requirements. You gather requirements along the way, for example: the volume slider should increase/decrease volume. Then you choose the programming language and framework to implement this, while communicating this with the management. Micromanagement will tell you which programming language / framework to use without knowing anything about it.
nashashmi 9y ago
To be fair, these managing behaviors happen in other areas like civil engineering consultancies. In fact, it happens so frequently, I really don't know what a "correct" managing behavior looks like.
blablabla123 9y ago
> * Inadequate training and expectation devs can just piggy back learning technology x from scratch whilst writing production software using it Yeah that's funny, believe it or not - I prefer the exact opposite. At my last jobs I had a hard time diving into new technologies unless I knew them completely. Thus I think synchronization is an important thing...

FooHentai 9y ago

>Insistence that all devs time must be billable That one can hit all areas of ICT real bad when the company is a managed service provider, leading to a 'Chefs kitchen/Plumber's bathroom' where the company provides great outsource ICT services offering to its clients, but runs an absolute shitshow for it's own systems because they're chronically under resourced (you can't bill it, so don't spend time on it). That has extra interesting results when such a company tries to spin up and sell services which it's built/hosting/maintaining/developing itself.

Boothroid 9y ago
Hadn't heard that one before, interesting observation.
- FooHentai 9y ago
  A lot of non-tech companies treat IT as a cost center and that can lead to short sighted decisions that cost them a lot in the long run (or more accurately, they fail to realize benefits that were available to them with appropriate investment). But it seems counter intuitive that this effect can be worse for some tech companies, where a major part of their business involves convincing clients to treat their tech as more than just a cost center. Like, you have an entire staff compliment of developers, architects, PMs, engineers and customer service staff, and your own entire ICT practice is a disaster? HOW? I ended up having to draw people's attention to it by pointing out 'this is your single biggest client, and receives the least attention of them all'. Loops into the old 'eat your own dog food' wisdom, but from an angle that seems to often get missed.
  - gaius 9y ago
    Well you could be like IBM which sells remote working solutions but has banned it for their own staff. Or maybe that was HP, or both.
    - patrickking 9y ago
      That was a slimy downsizing measure. IBM doesn't have to pay severance if their remote workers quit on their own rather than come in 9 to 5.
  - BrandoElFollito 9y ago
    Because of this mindset, companies who decided to outsource IT as an obvious cost optimization realized how their company actually runs. Specifically that there are huge off-the-record operations (outside of the ticket system). The more VIP the problem is, the less tickets. And suddenly, the people supporting them (particularly if they were outsourced but stayed in the company as contractors, and were pissed off) had one sentence "open a ticket". Doesn't matter if this is the CEO asking, or something "urgent", ticket it is. And the gates to hell opened. Source : me not being IT anymore (huge company) but strongly advocating against the outsourcing (pointing to the above), and then taking a backseat and watching the world burn with popcorn in hand.
mathattack 9y ago
This last point is universal in companies that bill hourly.
ghostly_s 9y ago
I think I get what you mean by 'Chefs kitchen/Plumber's bathroom', but I've never heard either colloquialism before and can't find anything on Google, either. What's the origin of these terms?
- dantheman0207 9y ago
  "Too many chefs in the kitchen" is the first one. Not sure about the second, but probably the same kinda thing.
  - elijahwright 9y ago
    There is a required reference here to "Too Many Cooks". Thanks, Adult Swim!
- cpeterso 9y ago
  Based on the context, something like "the cobbler's children have no shoes" meaning they are too busy doing paid work for others to the same work for themselves. https://english.stackexchange.com/questions/159004/the-cobblers-children-have-no-shoes#159040 https://english.stackexchange.com/questions/159004/the-cobbl...
- lfowles 9y ago
  I don't think it's related to too many chef's in the kitchen. More a reference to chefs having a spotless kitchen at their day job, but a messy kitchen at home. Likewise for plumbers.

pestkranker 9y ago

> * Trying to use one off contracts as a way of building resellable products Can you tell me why? Sometimes, asking a client for 50k instead of 80k with a "spin-off" agreement can pay to both parties. The client can get long-term support with new features without the need to pay for it.

slumberlust 9y ago
Sometimes it can work. More often it starts innocently and mutually as you describe, but it very quickly becomes a game of firefighting and drains innovation within the product line. Next thing you know, you're selling based on roadmap features and don't have control over your own product anymore.
Boothroid 9y ago
I agree that sounds like a reasonable approach - but in my working life it's always been seen as this fantastic wheeze of 'let's charge one customer to build something and then go off and sell it to everyone else!'. It seems like a great idea, but the usual story is that either making it generic burns up days that would otherwise be spent meeting the specific customer's requirements, thereby ensuring a worse product, or you stay on track with the customer's requirements and ditch the idea of making it generic as soon as days get tight. This is one of the things that always makes me groan, along with 'and you can learn x technology along the way!' >:|
- dvtv75 9y ago
  Out of the blue, I was once expected to set up a recording studio and learn the electrical engineering side of things 'along the way! You've got the afternoon, in addition to your normal duties.' My background is in CS, not physics or engineering, so you can imagine how that went - and of course, the manager wasn't to blame.
cmiles74 9y ago
In my experience, often the product ends up being molded to fit the particular client (it's custom software, after all) and then the cost of altering it for other clients is perceived as too steep. Or you end up with a bunch of similar, incompatible projects.

FractalNerve 9y ago

> * Give no feedback unless things go wrong > * Treat your highly educated, intelligent and motivated devs like children by misusing agile in order to micromanage them These two points made me cry. I suffered my very first burn-out due to that and although having a higher degree in computer science and love towards programming this really made me feel like a piece of shit. I have the feeling that it's really hopeless and it wants me to make the change to IT-Consulting instead of software-engineering.

Boothroid 9y ago
Oh dear, I'm really sorry for touching a nerve! I think management often have zero insight into how much many devs care about their work. Not all - I'm sure there are plenty with a thick skin and/or that care little beyond getting paid - but some of us are only capable of delivering our best given the right conditions. Lack of feedback is one of the most serious red flags I would say, and shows either the company is seriously dysfunctional, or that they absolutely do not give a shit about your progress. At that point the job should become just a paycheck until something better comes along. The funny thing is when they expect you to do your best work despite not keeping up their side of the bargain!
- auserperson 9y ago
  That is very true for me. A lot of managers don't understand my motivation at work, they don't understand that what actually keeps me going is the love for technology and for software engineering. That is being able to learn and develop interesting things, to research, to create, that motivates me. I can't bother on corporate politics. I don't care on going up the corporate ladder (I'm already in a top engineering position, I don't want to stop doing coding to become some sort of manager/architect/VP/etc).
dajohnson89 9y ago
Unless you're doing your own thing, consulting is often way worse.
0xfeba 9y ago
Also hits a nerve for me. Our mgmt just shuffles devs around from fire to fire without really just sticking the same devs to a single project until it's done. Then we get questioned why projects are not done. And don't get my started on our new Agile process. We have scrum meetings for our scrum meetings. We have mgmt. popping in the project level scrum meetings to tell us what is and isn't scrummy enough to talk about during the meetings. And I moved to this company after thinking my last company didn't have it together. Man, I was wrong. No one writes comments here, or any tests. We just "make it work". Pay is awesome though...

Boothroid 9y ago

Unfortunately I've just thought of another - moaning about time estimations - even after these have been pared down to the absolute minimum with the expectation of putting in extra hours on the side to meet the deadline! Good to get this stuff of the chest sometimes.

shados 9y ago
oh that one drives me insane. "This will take 40 hours" (I hate estimating in hours for individual tasks as there's no way to average the overrages with the ones that went under estimate). "Thats too much, can you do it in 20?" "No, 40 is already underestimating imo" "Well, it won't fit in the project plan at 40" "Sorry, that's really as fast as it can" "Well, lets put 20 and either make up the time or just go over" (wtf?)

vmattos 9y ago

> * Give no feedback unless things go wrong As a DevOps engineer, I feel it all the time (and not only from managers)

justin_oaks 9y ago
Ah, the realities of supporting IT infrastructure. When things go right, management wonders why they even pay you. When things go wrong, management wonders why they even pay you.

technofire 9y ago

> All of this inevitably leads to a bunch of pissed off devs. The ones that are happy to eat it become the golden boys and get promotions. The question asks about behavior that management repeatedly makes. If management repeatedly makes these mistakes, then the mistakes should become expectations, so one should simply accept them and understand that they are part of the game being played. If they are expected behaviors, being "pissed" about them simply is foolish. Of course, by "accept them" I don't mean one should never try to influence or change the situation, but reacting emotionally rather than rationally is silly. Even if there are no upward-feedback or 360 review procedures in place at the workplace, one can articulate these concerns more diplomatically (less offensively) and send out an email requesting that they be considered. One can even illustrate and trace through how such mistakes have impacted recent projects. It seems to me that the ones "happy to eat it" simply understand that others have limitations and make mistakes and will try to make the best of the situation. It sounds to me like such people indeed deserve the promotions more than people who bring anger to bear on their work.

Boothroid 9y ago
That sounds a bit like you are suggesting excusing bad behaviour, or blaming the victim. If someone warns you they are going to hit you before they hit you, does it make it hurt any less? Also when eating it means 60 hour weeks to make up for terrible managers (all the while collecting their substantial pay packets) I'm quite happy to walk out the door and let then find someone else to be abused. Passed a telephone interview today, got a f2f next week, hopefully onwards and upwards soon.
justin_oaks 9y ago
> one should simply accept them and understand that they are part of the game being played. If they are expected behaviors, being "pissed" about them simply is foolish. Does this apply to athletes who are upset when referees seem to be consistently favoring their competitors? Does it apply to people living under an oppressive government? Does it apply to a person who is being verbally abused by a spouse? Sure it'd be great if these people could seek to improve their situation through rational means, or perhaps just accept it if they can't change it, but humans and emotions don't work that way. > reacting emotionally rather than rationally is silly Humans are emotional creatures. Expecting humans, even yourself, to act rationally shows a misunderstanding of human psychology and behavior.

deleted 9y ago

[deleted]

zoner 9y ago
Not really. It's about changing requirements. You gather requirements along the way, for example: the volume slider should increase/decrease volume. Then you choose the programming language and framework to implement this, while communicating this with the management. Micromanagement will tell you which programming language / framework to use without knowing anything about it.

nashashmi 9y ago

To be fair, these managing behaviors happen in other areas like civil engineering consultancies. In fact, it happens so frequently, I really don't know what a "correct" managing behavior looks like.

blablabla123 9y ago

> * Inadequate training and expectation devs can just piggy back learning technology x from scratch whilst writing production software using it Yeah that's funny, believe it or not - I prefer the exact opposite. At my last jobs I had a hard time diving into new technologies unless I knew them completely. Thus I think synchronization is an important thing...