321–330 of 396 posts
I'll add one that even after 200 comments I don't see: Failure to explain the reason why . Coming down to their developer with a list of tasks without explaining why those tasks are the most important and will lead to company success. You might think startups are small enough that this couldn't happen but that was actually where my worst experience was. The founders are visibly in a meeting with a couple people, mayb…
* 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 an…
> 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 behavio…
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.
* 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 an…
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.
"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?)
Working for a company building heavy hardware, I see the following happen time and time again: * Reorganizing seemingly for the sake of reorganizing. Result: Every time the new organization has settled somewhat and people know who to interact with to make things flow smoothly, everything is upended and back to square one. * Trying to make our products buzzword compliant without understanding the consequences - we've…
My two biggest ones are on this list. * Software is not an assembly line. It is part science part art. We are not interchangeable. You can't take an embedded engineer and hope for good luck on a Node.js project. * Constant reorganization. I worked at a major internet company in the late 90s, early 00s and they literally reorganized every two years. It was usually under the guise of helping communication and fostering…
I always try to explain this. Yes there are best practices, but there is also a ton of creativity that goes into good software dev.
Earlier quoted context omitted.
>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…
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?
* 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 an…
> * Give no feedback unless things go wrong As a DevOps engineer, I feel it all the time (and not only from managers)
* Managers are easily replaceable because they don't have any expertise but people skills. My grandma has those skills, could she take on a manager role? Of course.
* You often get promoted internally to manager. So it's hard for you to move horizontally between different companies since they don't know you. You need to prove yourself again. Plus there is 1 manager job out there versus 10000 dev jobs.
* You get away from coding, far away from product then have to deal with expenses, HR issues, infinite meetings, etc.
I'll add one that even after 200 comments I don't see: Failure to explain the reason why . Coming down to their developer with a list of tasks without explaining why those tasks are the most important and will lead to company success. You might think startups are small enough that this couldn't happen but that was actually where my worst experience was. The founders are visibly in a meeting with a couple people, mayb…
You remind me of Simon Sinek: How leaders inspire action TED Talk.
I'll add one that even after 200 comments I don't see: Failure to explain the reason why . Coming down to their developer with a list of tasks without explaining why those tasks are the most important and will lead to company success. You might think startups are small enough that this couldn't happen but that was actually where my worst experience was. The founders are visibly in a meeting with a couple people, mayb…
What is the problem you're trying to solve?
This is just a different way of asking "Why?" More often than not, this changes the entire conversation. Often this leads to us determining that the task is unnecessary. Sometimes it's that a different approach would be better. Sometimes I do the task with a small modification. Rarely, I perform the task exactly as described.
Earlier quoted context omitted.
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?
"Too many chefs in the kitchen" is the first one. Not sure about the second, but probably the same kinda thing.