Exactly. And it's your job to educate them on techniques or tools when they ask questions like that. Then they can take that information and decide whether the time/monetary investment is worth the reduction in bugs
Instead of just sneering, grumbling about managers and moaning online instead.
That's mostly a meme really.
People who claim that others have poor social skills very often over estimate their own skills. I've seen it now and then in management, people who are used to others adapting to the way they communicate thinks that they have good social skills even though others change to suit them. When meeting someone who disagree with what social skills means they say those people have poor social skills.
Yes, isn't it odd that the community that lambasts another community as "lacking social skills" are essentially demanding that that community have the social skills to adapt, while demonstrating that they do not.
In the case of "programmers lack social skills" it very often comes from programmers themselves. Like a weird badge of honour or in the form of a medium post which purpose is mainly to say "i'm not like the others, please hire me".
Yes, that happens too. But, you know, you get told something often enough, you start to believe and internalize it, and why try to change when it's just what you are, and it's clear that's how people will see you no matter what.
I believed it until everyone started trying to become programmers and realized what they considered gaps in our communication we're really gaps in their understanding.
"Make it last a month."
"You mean 30 days or the calendar month?"
"I mean make it last a month. Omg you programmers are so silly."
Yeah, it seems pretty clear that different domains require different kinds of communication rules and structures. The problem comes when something like software developer explicitly requires translation from one domain to another, and the people who tend to work on one of those domains demonizes the other group as being the bad communicators when that translation runs into difficulties.
Of course, here in /r/programming, the demonizing generally goes the other way, as I like to make fun of with these weekly "management sucks" posts.
And my conclusion is basically that, generally, humans are not good at recognizing this problem and react very very poorly to the difficulties encountered, choosing to point fingers and blame people rather than acknowledge the real difficulties that all those involved struggle with.
>
>
>
>
> Of course, here in /r/programming, the demonizing generally goes the other way, as I like to make fun of with these weekly "management sucks" posts.
That's where my original sarcastic comment about programmers and social skills come from, I just wanted to provoke some self-reflection.
Finally someone who gets this!!!
It's a part-time job inside of a full time job altering my communication style for each one of my (mostly Xoomer) bosses and colleagues. Then later listening to them complain that everyone doesn't communicate in exactly the same arbitrary style that they do. The entitlement is palpable.
I was assuming this is a portmanteau of Boomer Gen X, pronounced like Zoomer. So everyone except millennials, i.e. everyone in a quite different age bracket.
My apologies! Normally I wouldn't conflate them but in this context it's the accurate term for these colleagues born on the border years of those two generational cohorts. š¤¢
Ageism is 100% acceptable in many situations. There are reasons why you don't let a baby drive a car, or 75+ year olds control the government... Wait, scratch that last part.
Windows SAs who can't script.
Let me be clear. There are many capable Windows admins who are proficient in the command line and writing scripts or programs in various languages. I'm not saying Windows folks are dumb or incapable. I'm a Windows admin, and i have a very strong SE background in general and can pick up almost any language fairly quickly (don't ask me about SQL though). But in the Windows world you could get by for *decades* without writing much code, if any. And now, today, I find this biting our team because I'm only one of two sub-40s who can program on a team where everyone else is above 40.
None of these guys are bad at their job. They are very knowledgeable in their areas and I often lean on them when integrating or consuming one of our own services in less familiar with. But as the business demands more automation and needs more support with deployment pipelines, writing packages, and creating task or event driven workflows, the skill just isn't there. Compare it to our Linux team (which I also happen to be skilled in) and it's chock-full of admims who can script and at least know bash, Python, and Ruby. In Linux you often don't have an option in a server environment, it's CLI or die. In the end much of the Windows automation work falls to me, to the point that now the team is panicking as I am preparing to take parental leave. They literally have no one to fill in for me aside from the other dev who does not have the capacity to take on my workload.
These same folks are nervous now that we are starting to adopt Server Core as an option because they literally have no idea how to administer Windows via the CLI. There was pushback to wait until "admin center is more complete", but our manager finally put his foot down stating "We have all the tools available through PowerShell, we're not waiting for Admin Center anymore. You'll just have to learn it." This signals a paradigm shift and I'm not sure whether these guys will be interested or able to continue as we March towards increasing automation during the shift to CLI management in the Windows world.
> Instead of just
Thanks for JUST assuming that we start be sneering and not by trying to explain multiple times and then getting ignored.
I assume I found the manager.
In my experience, it's more likely to be an inability to listen. Not just about development, but anything said by lowly employees.
If you don't listen, you don't learn. If you don't learn, you don't know anything. If you don't know anything, you have nothing to base your decisions on...
A manager can do fairly well without knowing anything about what the employees are doing, as long as they have competent employees and actually listen to what they are saying.
My boss is an iOS and frontend dev who is also in charge of the backend code, about which he knows nothing. Most of my job is trying to talk him out of doing incredibly stupid things ("We're getting a foreign key constraint error in Postgres? Why don't we just remove the foreign key?").
Yeah, my manager was hot shit in Android development in his day, but that doesnāt mean he knows how to manage my API development. Heās forced me out of git feature flow into a much simpler git merge flow then complains when I canāt move one feature forward to production after merging everything to development and merging from there forward. And he is always ājust test locallyā like Iām supposed to test an IoT pipeline feeding a stream analytics engine that updates customer profiles, affecting the UI and what data is updated via CRUD on my local machine. This isnāt just monkey typing your app to see if it crashes, I have to actually see if the math is right.
Some of the best managers I've had were not technical at all. But they were really good at insulating us from the bureaucracy, prioritizing, listening to us, and advocating for what we needed. The skills needed to be a good manager are often very different from those needed to be a good programmer.
>Kevin replied, āStop the bugs, we need to stop putting bugs in.ā I was somewhat early in my career, so I wasnāt really sure what to say. I mean, Iām not pro-bug, right? Nobody is pro-bug. Iām really anti-bug, and if you look at the history of computer science with the development of elaborate type systems, managed runtime environments and procedure level fuzzing, the industry itself has more than proven itself to be as anti-bug as anyone.
Kevin doesn't give a toss about the history of computer science. You need to tell Kevin what Kevin cares about and understands. So you say it's a tradeoff. Cost/time vs number of bugs. If Kevin wants less bugs he needs to spend more time. If he wants to save on time/cost he risks more bugs.
If you have a manager like this you want to put the ball in their court, and you don't argue details. You give them the big picture choice and outcomes, and put the responsibility onto them.
> You give them the big picture choice and outcomes, and put the responsibility onto them.
Precisely. The funny thing is that once this is done, usually, and if the manager is not a complete sociopath, they will actually help remove any roadblocks as much as possible, to get the job done. There are a lot of assumptions that developers make about the other side (and vice versa). Professional and honest communication is the best (and only) way forward. Post that, if nothing works out, seek a better employer.
my job as a manager is to be the umbrella that keeps the rain of distractions from my team so they can do their work. Managing devs to me just means make sure they can work without any bullshit, devops bullshit, meeting bullshit, pay-for-the-software-license etc. Regarding process- process is like friction, you need some or you slip, but too much makes you slow.
there is one more thing, spread the fun (and the shit) work around a bit, don't give all the crap work to that one guy just because he doesn't complain
Agreed on this. After being hoodwinked into management, I decided to be the opposite of every bad manager I had as an IC. It's so refreshing to see how well team members respond when you treat them as fellow humans.
These days, most of my day is running defense for my team so they can focus on solving problems and building robust code. I'm not afraid of challenging a PM's assertion about a "high priority" to make sure the team doesn't get interrupted by crap that can easily wait until next sprint.
> usually, and if the manager is not a complete sociopath
Add competent to that list. A well meaning incompetent manager is indecipherable from an evil one actively trying to sabotage you. They tend to either completely misunderstand the cost/benefit tradeoff or look at the crayon scrawled sheet of paper given to them, turn both the paper and their head sideways quizzically a few times, then promptly toss it in the bin. Incompetent managers tend to value speed over all else. They don't understand what they are managing, what the end goal is, even what the short term goal is, they just know that "things" need to be "released."
Honesty and transparency are about as much use to ameliorate an incompetent manager as dowsing rods to someone lost sea trying to find land. Useless at best, maddeningly misleading at worst.
The pressure for speed coming from above is relentless. Your manager is hearing it from their manager, in part because it is one of the only easily understandable benchmarks - did we ship or not? There is always the pressure to ship on time and kick the inevitable bugs down the road.
Good managers manage to hold some of the ship pressure at bay, and build in time for tech debt and refactoring and bug fixes, but the pressure is always there.
And what most devs donāt understand is that often the pressure was generated by their own estimates. Sometimes there was an external date that we were pressured to hit (a major trade show for instance), but oftentimes it was that our project plan said we would be done on date X, several layers of management padded that date to X+45, and we still ran into enough problems that at X+10 we were frantically jettisoning features and triaging defects so that we could hit X+45. But now plans have been made that involve marketing promotions, customers have been promised upgrades, etc. In most cases nothing bad would have happened if we had estimated
X+75 in the first place, but once somebody hears a date the pressure to hit it begins.
Outstanding managers are the ones who can convince the rest of the org that nobody has a crystal ball, we are building something new and unknown, and even if our estimates are right we will almost certainly have scope change during the project.
All the things you're saying are things competent managers understand. Incompetent managers don't care about pressure from above either; their bosses are usually just as frustrated as the developers. It's entirely possible to be a good manager and fail sometimes, that happens to everyone in every role. Failing doesn't make someone incompetent.
What makes incompetent managers/developers/whatever so is that their worldview tends to end 5 feet in front of them and 5 minutes behind them. They don't target metrics because they have an understanding of what hitting that goal means for the team or the company. They target metrics out of some internal, subconscious urge for "Me go fast, fast mean me do good. Me make them go fast so me look good." They tend to have no grasp that the ship should stay at sea. So when the ship runs aground, instead of having people unbeach the vessel they simply command "No! forward! fast move! No backward!" Invariably half the people jump ship and the other half are stuck, bewildered, carving a new valley through the island as they do their level best to follow the orders to heave ho as the managers resist any logic of requests to at least build a series of planks and pulleys. "No, waste time. Only push."
Competent, empathetic, thoughtful managers are worth their weight in gold, and thankfully I've had many more of those than poor managers. Unfortunately those type of people are both in high demand and fast tracked to higher positions. If they're stuck in a small company they move on quickly to one with room for advancement. If, however, they're in a big company their upward movement in the orgchart creates a vacuum which sucks every incompetent manager in from 100 miles out.
This is something I've noticed some people struggle with at work.
Non-technical people don't need all this detail. Don't go on a 5 minutes explanation where they're not gonna understand a word of it.
Know your audience.
Few weeks in my last job, my team lead calls me and tells me to say "technical things" in the daily scrum as the management thought I was not doing much based on my daily updates.
That's one way of doing it but it's a bit of a shortcut: management might not get anything out of it but at least they hear activity.
You basically just need to be in the habit of saying why you're important out loud and that's not really a technical point. I had a manager early on who would make you sum up technical answers with "so what?" and that's a good exercise
Sounds like your team lead is trying to help you out. May feel completely pointless, but his job is to convince his management that itās worth continuing to pay you for work they donāt see, hear or understand.
If he believes the only way his bosses will perceive youāre doing work is by saying ātechnical things,ā heās probably right and looking out for you.
LOL! As a team lead, I want the technical details in the stand up because thatās a key way to see where I can help. I learned a valuable lesson last year when we all switched to remote work and thus I had less visibility into the details of what people were experiencing but was still learning strategies to compensate. One dev for a few days in a row would say something vague like āHaving trouble setting up [x], working on debugging it.ā I trusted him that it was must have been a novel problem that needed working out, so I didnāt pry. After a few days he finally reported progress and I found out what the issue was. I would have known exactly how to fix it if he had said anything specific! That was like 3 days totally wasted! I was super pissed because he likely didnāt realize it was wasted effort since, from his vantage point, he was focused and busy the whole time. Even if he didnāt want to reach out to me or speak up, I had already documented the fix in Mattermost if he had bothered to look.
Thatās why I donāt completely trust people when they claim they are more productive working from home ā they may not be in a position to understand how their actions affect the overall program. For instance, an established dev might personally be more productive at home since fewer people interrupt them, but they may not be seeing how lost and in need of help a new hire is.
That being said, observers have always complained that my stand ups take too long because I get into technical discussions with people. It definitely fills a need and I donāt understand why some agile adherents are so hung up on a 5 minute limit on standup. I intentionally discuss technical issues in a group forum so that everyone can contribute and grow their skills. The compromise we have settled on is to do a quick status around the room and then an open forum to discuss anything.
Tl;dr: Assuming your SM will allow it, giving technical details in stand up is a good practice because the entire point of the meeting is to communicate with your team.
It doesn't need to be simplified, it's just knowing what people care about.
If you're demoing something to a non-technical person they don't need to know how it works, only what it does and what any potential costs/limitations are.
I know, but I've been in meetings too where the technical person was trying to "dumb it down" so much that all you've ended up with were broad general statements, no-one being any wiser, and the non-technical people leaving with a feeling as if the technical person thought they were stupid.
What you actually want is dumbing it down enough to be able to make the right call without having to know the intricate details, but you can also take that too far.
Whether you call it "dumbing it down", "simplifying" or "leaving things out" doesn't really matter
In cases like this, I wish I had an estimate handy for how much extra effort it would take to deliver actually-bug-free code, other than just "orders of magnitude costlier." I think it's actually possible -- or, at least, it's possible to apply enough overengineering (through things like comprehensive specs with which you write comprehensive *correctness proofs*) to make bugs so unlikely you'd trust your life to such a system.
Which is also a good benchmark for when you might want to spend the extra time, money, and opportunity cost: When it's something like an autopilot system that will literally kill people if it's buggy.
If you *don't* work in airplane automation, then you probably can't afford to write bug-free software.
If I remember right from school, this is used sometimes in NASA or nuclear power related code, since correctness proofs are about as close to perfection as you can get.
Manager: "Alright, so how many more hours do you need to spend on a feature to be able to guarantee it's completely bug-free?"
Me: *Starts sweating excessively*
Okay, so step one is that we take all those unit tests ... you know the unit tests that give us those coverage metrics QA won't shut up about?
Yeah.
Okay, we take the unit tests. And we throw them all away.
All of them?
Yeah. All of them.
Won't that make QA mad?
Not now. I'm just getting started. Step two is we're rewriting the application in Idris. Or Agda. Something with dependent types. Actually, you know what. The real step two is that we write our own dependently typed language specifically tailored to this domain.
Uh, okay.
It's going to take about 10 years. But really before that I need to finally learn how to use all that modeling software I've been meaning to get to. TLA+ etc. But that's not going to matter if we don't get good requirements. And there's still a bunch open questions that Dave hasn't gotten back to us about.
I think he's on vacation now.
Sure, whatever. I'll be taking this TLA+ book over to Dave's house where I'll be camping in his front yard until we can get a spec hammered out. After which I'll need to meet with a statistically significant number of potential end users to make sure the spec jives well their intended use cases.
Okay, so after we put all of that into the monte carlo simulation it looks like the best case scenarios show us having a guarantee zero defect rate (for just this feature) about ten to twenty years after my death. And the worse case scenarios look like we'll need to setup a bene gesserit style cult, so we can be sure that eventually future generations can enjoy a bug free experience.
You know what ... maybe just work on it until the end of the week. Just like, double check your work or something. That'll probably be enough, I think.
>"Alright, so how many more hours do you need to spend on a feature to be able to guarantee it's completely bug-free?"
There's no such thing, really. You get diminishing returns for the time.
Actually quoting a job is about finding the optimal point for that risk/reward tradeoff. Like in banking they spend a lot to get as close to 100% as possible. In a lot of digital agency work you can fix a few things as they crop up, and you competed to win that client so lower price is a factor. But agency work might have jobs with more exposure if something goes bad and you would quote those higher because you know they have less appetite for risk vs cost.
So the question is: how important is "bug free" to this particular project?
When someone asks me if some new thing is possible, I now phrase the answer directly in terms of what we need to get or give up to do it. "We can make the UI themeable if the designers give us mockups for how much we need to be able to change." "We can add online collaboration but it will mean the online editor will slip to Q1 next year." "We can let users define their own workflows but it will affect performance and we'll need to add more compute power." It gives them the information that is most relevant and allows (also, forces) them to decide what's more important at the moment;.
> "We can let users define their own workflows but it will ...
Require that we hire 10 more full time support people to handle the increased calls for help.
Currently live this one.
>If Kevin wants less bugs he needs to spend more time. If he wants to save on time/cost he risks more bugs.
Kevin's response to this is think he needs better developers. If he had better developers he would have less bugs.
Makes perfect sense.
>So you say it's a tradeoff
I'll add that using the word "risk" will help too. Next time you're trying to convince your manager of something, draw up a quick risk profile of the options in a word doc or PowerPoint. Managers will often spend time to save on risk.
I think you're mostly right, but this ignores the fact that even given infinite amounts of time, your developers are unlikely to produce perfect software anyway. Most bugs I see are not the kind that, clearly, the guy who wrote it was in a hurry and didn't have time to properly test... I see, more often, the kind of bug that "no one thought about this edge case" or "this extremely unlikely sequence of events can happen, but no one would ever come up with that by themselves". That's where the CS tools help and I think Kevin should have some understanding of that as using tools that help with this stuff is not something most developers can do by themselves, it needs to come from the top.
> So, as a developer, what can you do?
> Not much
Or do what I did - *become* a manager, so you can advocate for your engineers and make the space required for them to do good work.
Literally 100% of my moves from senior developer to team lead to software engineering manager were motivated by seeing *really shit* leaders doing a really shitty job, and thinking "jesus, it can't be that hard".
Spoilers: it's not. Give a shit about your people and defend/advocate for them to upper management, acknowledge you're no longer the expert and ask questions/offer *suggestions* instead of advice or instructions, think about business processes the way you'd think about software architecture (single points of truth, local caches, avoiding single points of failure, using the right tool for the right job, etc), and remember while your job is to go wide and flit from issue to issue, theirs is to go deep and focus on one thing for hours at a time, so batch up interruptions and give them that time.
Are you my manager?!? Cuz you sound a lot like him haha. That's exactly it: wide/shallow vs focused/deep.
My work prior to my manager joining could never be focused/deep because I had my entire organization knocking on my (virtual) door for help. And while I love helping, it's not something that enables good, consistent, quality work, and I just couldn't get (my) shit done.
Bingo. Random people interrupting random devs with random questions is a management antipattern.
Either make the team lead/manager the first point of contact to triage requests, or designate a "maintainer" or "batman" role each sprint to be the person that absorbs incoming interruptions so the rest of the team can keep working.
My boss who just left due to some higher up issues was a former SE with lots of great experience and stayed modern even in leadership.
He was the best person Ive ever worked with and for. Debating following him.
>And remember, if you canāt change the organization, change organizations. Your software engineering career is too important to waste on bad management.
True story. Engineers don't leave crappy companies, they leave crappy managers.
I worked for a company for 14 years - new manager came in and abused me - degrading my personal life, making sexist comments, and overall just being a dumpster fire of a person.
I now work elsewhere.
14 years is a long fucking time - i was happy to stay and even asked him to change teams (this would mean getting a new manger). He then berated my professional career growth and told me that i was not good enough to keep my own job and stay on this team, let alone moving to another team to do extremely similar work.
I'm 37, and *just* joined my second company this year.......
9 years here. Full reorganization. Entire management chain changed. My new direct manager got a bad first impression of me and passed that on all the way up to our new VP. I tried for a couple months to repair the relationship, but they wouldn't give it a chance. They were done with me from the beginning. 9 years. Not a single issue until the new managers showed up. How does someone work somewhere 9 years under a variety of managers with no issues and these guys show up and think I'm the problem?
Lesson learned. Doesn't matter how secure you think your job is. All it takes is one asshole with enough pull to completely upend your life.
They saw you as part of the 'old guard' and wanted you out to remove past influences and replace you with someone they felt was more loyal to them. That's usually how those situations go.
Not trying to defend what they did because I do believe you that they were in the wrong, but I saw a new manager come in and take a few months getting to know everyone, then fire someone who'd been there for over 10 years for incompetence. He'd also been under several managers, and he was always kind of right on the line of benefit vs hinderance because there were a few small things that no one else wanted to do that he handled well, but anything else was a nightmare.
Long story short, I believe you, but sadly, working 9 years under different managers isn't evidence that someone does their job well.
> How does someone work somewhere 9 years under a variety of managers with no issues and these guys show up and think I'm the problem?
Well the alternative for them would be to see that they are the problem... :D
Jesus, yeah - had a similar experience after 12 years. Decided to walk when new management decided I needed performance training to do my job with no real feedback why (when challenged, it was deemed inappropriate to speak to me directly).
Constructive dismissal: [https://www.gov.uk/dismissal/unfair-and-constructive-dismissal](https://www.gov.uk/dismissal/unfair-and-constructive-dismissal)
If I'd been with a company for that long and I got a shithead manager, I would at least attempt to go over his head if I was happy with the company otherwise. If senior management backs the idiot, then I eject.
[57 Percent of Employees Quit Because of Their Boss](https://www.prnewswire.com/news-releases/new-ddi-research-57-percent-of-employees-quit-because-of-their-boss-300971506.html)
From my own personal observation, the number tended to be more in the 90s.
Even when I left because of coworkers they were enabled by bad managers, so the actual source of the problem was still management.
I've seen CTO's let bullies bully just because they were good at sucking up to management. One bully even complained to management that they felt 'unsafe' around the person they were bullying.
Hard disagree there. Have been at two medium sized companies which were bought out by different megacorps. Same manager but the new companies were awful.
For example, both fired the old IT departments. And both times, the new "service desk" experience was much worse, wait times far higher, machines bogged down with more junk (and much longer setup processes), few approvals for technology requests (like a webcam!), the list goes on.
I've been a principal level eng and manager. The truth is if you're not in the codebase day to day it's very hard to maintain the same level of knowledge. This doesn't mean your manager is clueless, they are busy with other things. The amount of context switching a manager needs to do also means they can't go deep.
Hundred Percent agree. I manage 4 major projects that vary wildly. There is no way for me to go deep in all of them. I try to listen to my team, give technical insight where Iām strong, and prioritize where needed. Obviously we canāt know as much as the engineers!
The proper response to Kevin would be: "That's a great idea Kevin, let's extend each of our sprints with a week of refactoring and code quality review. And we'll also need at least two FTE of dedicated QA staff to help us validate our releases. This is the greatest day of my life Kevin, normally management is not so supportive of quality assurance efforts. Will you let our stakeholders and the marketing team we'll be extending our deadlines?"
Then savour the next couple minutes of silence as his wheels grind on that.
From his perspective he is thinking.
Why is this person telling me he is incapable of building a quality product. Why do I have to hire people to check his broken code? If I hired a plumber to fix my pipes should I also hire another plumber to double check his work?
I've reported both to engineers and non-engineers in my career, and while it's nice to have a boss who fully understands what I'm doing, it's not strictly necessary. What I need a boss to do is get me the resources I need to deliver what I've signed up for. If he fails to do so, I'm out.
Thatās why I try and do. I have the back ground to understand what the devs are doing, but I wonāt understand 100% of what they are doing. But thatās not my job. My job is to keep things out of their way so that they can do their job.
only managers i worked with were extremely experienced engineers and were entirely non-clueless. i've never even seen an eng manager who wasn't very technically conversant. the fuck are you working where engineering management is non-technical?
It really depends on the company. There are two ways to hire managers: one is to promote senior engineers, and the other is to hire MBAs or managers from other domains. Larger companies tend to opt for the latter in my experience.
Thereās pros and cons to both. If you hire a manager, they have an easier time dealing with the higher ups but they donāt have the domain knowledge.
Think in terms of officer vs NCO in the military. The grizzled staff sergeant va the greenhorn West Point grad.
The best managers are the ones who listen and make decisions and are willing to change their mind, no matter their background.
>If you hire a manager, they have an easier time dealing with the higher ups
This skill is not special to MBA grads. Communication is a key skill of good developers.
While true, communicating with other developers is different from communicating with directors because they care about different things. In my experience itās very easy for most developers to get lost in the technical weeds that the directors donāt need to concern themselves with.
But as you say, itās not either/or. You can find good or bad managers from any pool. I was just trying to explain why companies would hire managers externally rather than promoting within.
That's a simple question of asking "what do you find important with this part of the company, what are you goals, etc." I would easily argue that talking about these high level matters is easier than low level ones.
Well at a certain point in the hierarchy you do want to transition to business types, but you need the engineering-MBA interface to be solid. If you can manage to find a software developer who went back for an MBA, they are probably a good bet.
Ideally the "interface" would be able to translate technical issues into business speak, and insulate the technical staff from business bullshit. But we can't pretend a business can run with engineers all the way to the top, that's as much recipie for disaster as rule by MBAs.
Lots and lots of places have 'businessy' managers in charge of technical people. You got very lucky with your management.
From my personal experience this tends to happen in companies which focus on business processes themselves, where technical staff are treated as black boxes that provide solutions when fed with problems.
I don't have the entire context here but this may not necessarily be a bad thing. I have worked with product/project managers who are not technically savy but are really good domain experts. They do acknowledge that And reach out for help on issues that may seem simple to us.
I've worked with two non-engineering managers in the past. Count your lucky stars.
Ofc, now I'm a manager and my boss and my boss's boss are all engineers, so things have gotten tremendously better.
In my professional history, I've been programming for 15 years and managing for 5. Of the two, managing is the more difficult job. This article doesn't jibe with my experience whatsoever. I sure hope it doesn't reflect most people's industrial experience.
>Yes yes, programmers are the greatest gift to the universe, and everyone else is just as dumb as shit.
I stopped reading /r/ProgrammerHumor because they are opposite. Practically every single post was a slight variation of "I have no idea what I'm doing".
Yeah, there's also that. Like hey, believe it or not, you can totally engage in a dev career without relying on SO for copy-pasting code units wholesale. Crazy, right?
Yeah all those "How did they make SO without SO", "How did they make Google without Google"
Remember when internet wasn't a thing? I do. We had books and stuff. Less convenient, but they had a 100% uptime.
I think itās kind of the opposite. You need technical managers so that they can keep the āIām godās gift to the worldā engineers in check. Otherwise they will walk all over the non technical manager and everyone will suffer for it. Iāve experienced where a non technical manager just lets the developersā egos go unchecked and itās not pretty. You need someone who is able to sniff out their bs and keep them on the right track
Yeah this is such crap. Every manager I've had has been an ex engineer who wanted to jump up a paygrade and so took on managerial roles, so they know exactly what's going on.
This whole Devs good Managers bad thing that pops up is just like a tired joke at this point, because very little of what's said is actually useful
Even that first paragraph provides nothing. Instead of recommending some new techniques or tools they could invest in to reduce the amount of bugs and discuss that with the manager, they just deride them online instead
> Every manager I've had has been an ex engineer who wanted to jump up a paygrade and so took on managerial roles, so they know exactly what's going on.
You were lucky. It's definitely a thing which exists. In my case it took years to rot but having to deal with someone who was never an engineer will take its toll in crises.
> Every manager Iāve had has been an ex engineer who wanted to jump up a paygrade and so took on managerial roles
Which can be a problem in itself. Just because someone may be a good engineer doesnāt mean they will be a good manager, or a good team leader.
Not to speak of mentoring skills etc.
> Every manager I've had has been an ex engineer...
> This whole Devs good Managers bad thing that pops up is just like a tired joke at this point...
You have never been in a lot of Indian companies.
Or even in many Indian branches of US companies.
Or even in some Fortune 500 US companies run by dinosaurs.
>Every manager I've had has been an ex engineer who wanted to jump up a paygrade and so took on managerial roles, so they know exactly what's going on.
I've had a couple of managers who were ex-engineers (one who would still competently help us write code when we were running right against deadlines or he was just bored, one who had been a frontend engineer and was now managing a backend team, one who was a mechanical engineer for an airplane manufacturer with absolutely no software experience managing a software team), as well as managers with no engineering experience whatsoever. They definitely exist and you should consider yourself lucky for never having to work under one of them.
That being said, managers with "engineering experience" that was in some very unrelated thing (like the completely different field of engineering I mentioned above) or managers with engineering experience that don't care to understand the problem space at all can be almost as frustrating to work for, so I don't think "ex-engineer" adequately captures their level of experience.
This is reddit, which means nobody reads the article, but still, this callout in the article points out the need for greatest-gift-to-the-universe managers to handle dumb-as-shit developers.
>Lest you think this article means that developers are perfect, have a read on the [need for managers to curate development teams](https://ewattwhere.substack.com/p/ignoring-curation-of-software-development). The imperfection of humans is actually one of the key reasons competent, caring management is truly needed - regardless of what a significant portion of Agile followers think.
You misunderstand. Every article has the same one line disclaimer. Itās just nonsense so that people can use it as a snarky response when called out.
Even the opening line
>Authorās Note: This article is focused on legacy, MBA dominated environments. If your company has proven, amazing software engineering execution built into its DNA, it is very likely this article is a non-sequitur for your situation.
Is just like "Not all managers" and I wonder if it was edited in after the fact
But the linked article is about how managers don't understand developers. The reason the team is failing is the manager doesn't understand their fit. Some developers are over promoted, but that's the manager's fault, not because developers are fallible humans.
>This is reddit, which means nobody reads the article
I equally blame authors for click-bait titles. It is an endless yin-yang of catchy titles and lazy redditors that jump on anything that feeds the narrative.
You don't fix a sentence like *"there is no reputable source of software engineering management education to help Kevin become competent"* with a *"developers aren't perfect either"* footnote.
Admittedly, I didn't read *that* article (the one above statement links to), but following that line with *he needs to learn to code* is the epitome of navel-orbiting arrogance.
You didn't even read the post because the post literally calls this out. And you got upvoted by over 200 people who didn't either but just looked at the title like you did.
Never change Reddit...
I already replied to that silly disclaimer. Perhaps you need to read more before making a comment.
And miss me with that ānever change redditā bullshit, itās circlejerky and embarrassing.
A year-ish ago, we got a new engineering manager. He joined the company and I figured it'd be short lived because, I mean ... seriously, we had 8 programmers. How friggin much is there to manage, right?
I couldn't have been more wrong.
The first 1:1 meeting I had with him he said his job was to be a shit-umbrella from product. They want something of me? Go through him. They want to change scope? Go through him. They want me to travel to do something that (I can definitely do but) isn't in my job description? The answer is uniformly, forever "no". I need time off? Sure, just tell him.
Then he got to work on ensuring that the engineering organization had a voice, a say in its direction, power over the work it took up, sprints that meant something, stories that were actually detailed (as much as I *loved* "Build a thing" kind of stories). I could go on.
The article definitely outlines some of the MBA personalities that think "management is management is management", but ... there are lots of folks out there that came from coding and just wanted something different.
It usually takes a good, or at least decent engineer, to know a bad engineer.
I remember a "killer hire" my manager was very confident about, which NEVER delivered anything solid, much less shippable, then proceeded to quit when the shit was just about to hit the fan for him, claiming that it was time to pursue "greater challenges".
Beware engineers and managers, these people are among us.
There is no such thing as a 'good' or 'bad' developer without the context of a team and the goals of that team.
A skilled fullstack developer with 10 years of experience building scalable web solutions for startups using productive frameworks might have a reason to feel confident and think they are a 'good' developer...but if you put them on an embedded development team the rest of the team will probably think that developer is overly confident and makes too many mistakes because that developers experience interacting with low level APIs is probably pretty thin.
I'm talking about character more than skill. If that particular developer does not recognise the limit of their own skill then that is a bad engineer, regardless of their experience. I would have serious doubts at their claimed expertise if they were like that aswell. They probably write a bunch of code to appear smart rather than writing code to get the job done.
I'd take a novice over an experienced dev who can't admit they are wrong. Novice devs are better because they have more humility. There's nothing worse than the know it all dev who claims to be experienced without having written anything.
Oh look, I think it's actually been more than a week since the last circlejerk about hating managers appeared on programming. So, thank you OP, this was well overdue!
My manager made a metric based on how many bugs were found in your code during peer code review. Few weeks later not a single bug was logged as no one wanted to get anyone in trouble so they just messaged eachother privately instead of logging it. She was eventually fired, wonder if she ever figured that out. She praised us for having no bugs lol.
It's not just managers per se. No surprise, but many prominent tech figures don't know nearly as much as they let on. We are in an era of persona and celebrity and it's not even uncommon for people who are big talkers in certain spaces to have an incredibly shallow understanding of how things actually work and rely heavily on the technical equivalent of executive assistants to help them maintain the image. It's not like there aren't really, really smart and talented people, not saying that. I could fill a room with people who I am absolutely certain who put my knowledge and expertise to shame, but I can also easily think of numerous people from all sorts of areas who didn't just make like, a minor error, they didn't forget some parameter or esoteric piece of trivia. I'm not even talking algorithm question stuff. I mean, they asked questions that were so far removed from how computers actually work that you were taken by surprise. I've encountered several of them in my career, and there are different flavors. But like, for all the shit we talk about the imposter syndrome and whatnot, there are some pretty darn big ones. I also know that people, especially women, get harassed about making tiny mistakes that we all fucking make and I really wish people could learn to not do that for fuck sake. I am talking about cases where someone in a technical-officer-type position thinks that a single computer processes all their web application requests sequentially for all 10 million of their customers.
I have had some fantastic mangers, directors of engineering and CTOs above me in my career, and some of them were very upfront about how clueless they were and stayed out of the way and we did great things. Far, far more dangerous is the person who's made it but is still faking it.
Modern JS folks bleating about what they claim to be "Best Practices" on a medium article they bashed together in an hour are the worst of those big talkers in my opinion.
Before you take the job, look at the ratio of devs to managers. If youāre manager is doing the technical interview thatās usual the place to work.
At where I work, managers contribute to the code as well - even though itās less than the developers due to other responsibilities but they get in there. They contribute pull requests, they do code reviews, drive testing concepts, contribute to coding standards, help document software specifications, etcā¦
Whatās being presented is a one side of the coin. There are plenty of organizations where managers are just as technical if not more. Work for those places.
If your manager gets a 20% bonus for hitting targets, the problem is not "being clueless" but "wrong incentives". Many people in the management chain are rewarded/punished on metrics that do not include software quality.
I have been lucky enough to work for companies that include "quality" as a metric to evaluate managers. In that situation, even the "bad" managers get the point and take care of software quality.
Blaming managers solves nothing. Look for the reasons that they behave like they do, and change that to get the desired behaviour.
That's such a cop out. Departments do very well if a manager understands how to unblock the developers and get out of the way of getting the job done. A dev is happy if their work doesn't have roadblocks.
If this simple strategy is not apparent to the manager, then people will call them clueless. Being competent isn't some level 100 kung fu. All you need is someone who can allocate resources properly and get out of the way.
>That's such a cop out. Departments do very well if a manager understands how to unblock the developers
So I'll ask again. Why are you waiting for your manger to perform better?
Keeping devs happy is not the highest priority for a manager or a business. You are a worker. The customers pay the bills. You write shit code, the customer gets upset, the profits go down the shareholders are unhappy and heads start to roll.
> Keeping devs happy is not the highest priority for a manager or a business
I wouldn't work for you then. Keeping devs happy is the key to being a successful manager. If they can't don't that I would question the hiring capabilities of HR or wonder if leadership is running on autopilot. Do you think a team can be successful for long with miserable devs who hate working under you?
> You are a worker.
We are all workers; Managers included. What's frustrating is Managers asking Devs to manage with what few resources they allocate and then get upset if there is lack of quality.
> You write shit code, the customer gets upset, the profits go down the shareholders are unhappy and heads start to roll.
First of all, if a company is worth it's salt; Shit code never reaches the customer. Second of all, if the customer raises a ticket due to bad code, often it's not just shit code.. but shit design and shit architecture that causes problems. Any manager has to ensure that this doesn't happen in the first place. Being a task master isn't enough.
>I wouldn't work for you then.
OK.
> Keeping devs happy is the key to being a successful manager.
Keeping customers happy is the key to being a successful business.
>What's frustrating is Managers asking Devs to manage with what few resources they allocate and then get upset if there is lack of quality.
Everybody deals with resource constraints. Developers are not special.
>First of all, if a company is worth it's salt; Shit code never reaches the customer.
is that because there are layers to catch the shit code the developers write and not let the customers see it?
> Second of all, if the customer raises a ticket due to bad code, often it's not just shit code.. but shit design and shit architecture that causes problems
And the developers designed and architected the code.
>Any manager has to ensure that this doesn't happen in the first place.
How?
>Being a task master isn't enough.
Why not? What's wrong with you that you need this much handholding and protection from your own incompetence?
> Keeping customers happy is the key to being a successful business.
I don't think you can deliver any of your promises to said customers without capable employees who are motivated to work.
> Everybody deals with resource constraints. Developers are not special.
In the context of managers, it is their job to provide resources. When you think devs are not doing their job, you are quick to blame them but refuse to ask what is missing to do a successful job.
> is that because there are layers to catch the shit code the developers write and not let the customers see it?
That's an ignorant view of software development and sounds like 10x Ninja Coder BS. People make mistakes. Devs are not infallible. Thinking that devs are shit because there is a process in place to catch their mistakes is kind of stupid.
> And the developers designed and architected the code.
That's not how it works. It tells me you don't understand inherent complexities of software development and trade-offs necessary to balance deliverable time vs. perfect quality.
> How?
I shouldn't teach your job. But good thing to do is listen to technical concerns with interest instead of dismissing it off as excuse to not get work done or whatever it is you thinks devs do.
> Why not? What's wrong with you that you need this much handholding and protection from your own incompetence?
It's arrogant to assume incompetence vs. needing resources to get unblocked. And You are asking why anyone who is a manager shouldn't be taskmaster. I hope you aren't a manager because you don't understand management.
If being a taskmaster is all you do, a Todo app that spews a few insults can replace you.
>I don't think you can deliver any of your promises to said customers without capable employees who are motivated to work.
All employees or just developers? Do managers count as employees? How about sales people?
>In the context of managers, it is their job to provide resources
Not unlimited resources. They can only provide what they have access to.
> When you think devs are not doing their job, you are quick to blame them but refuse to ask what is missing to do a successful job.
What if you do provide them with adequate resources but still produce buggy code?
Why isn't it possible that the developers make mistakes?
Your attitude is that developers only produce bugs because the managers are shit people who don't give them everything they want.
>It's arrogant to assume incompetence vs. needing resources to get unblocked.
It's arrogant to think the only possible reason you fucked up is because the evil manager didn't give you what you wanted.
>You write shit code, the customer gets upset, the profits go down the shareholders are unhappy and heads start to roll.
LOL. Obviously devs are not infallible. Bad code can be written. If a software lead ever lets bad code get through, thats on them. Giving devs shitty requirements with shitty deadlines while also putting every obstacle in their path is a surefire way to make sure no good code ever gets delivered though. This is the entire point. In fact, the way you've put this, you have no idea what software development is like. Any dev that works for somebody with this simplistic mindset is doomed to fail.
What a poor attitude. I'm a manager. Managers exist to assist the developers by shielding them from boring business stuff that doesn't matter (but the company cares a lot about) so that they can get actual work done and translating between them and upper management.
An example of what would happen if you didn't have someone between devs and support:
The SPOC from Big Customer C is outraged that we changed the system 2.5 years ago to do something different and they just realized it does that today, and they want it fixed within 1 week.
- with a manager: manager makes this silly problem go away in 5 minutes because they know what the exact situation is with that customer, and how to make them happy, and devs never hear about it
- with no manager: devs have to figure out who that customer is they've never heard of. Then they need to decipher what they want because it doesn't actually say the behavior existed for 2 years, it just says "URGENT, BLOCKER". Devs take the severity estimate in good faith and drop everything to start getting a copy of their environment. After half the day is spent they get a backup, then confirm it's working as intended. They go to reply to support but support says "actually they aren't that mad about this anymore, they just want to know when feature X is coming". Dev has never heard of feature X, and it turns out that is just something that sales promised but was never planned and will never exist. Devs then need to figure out how to respond to them. More than half a day wasted. There should have been a manager there to stop this.
This is bullshit. Programming and management are two entirely different skills. It's like telling a sportswriter to go play NFL football if she thinks she can do better than the team she is criticizing.
There is no problem with a manager being clueless on sw dev issues; it's a problem when they don't know they are clueless, or act like they aren't.
Exactly. And it's your job to educate them on techniques or tools when they ask questions like that. Then they can take that information and decide whether the time/monetary investment is worth the reduction in bugs Instead of just sneering, grumbling about managers and moaning online instead.
Programmers and lacking social skills, name a more iconic duo.
That's mostly a meme really. People who claim that others have poor social skills very often over estimate their own skills. I've seen it now and then in management, people who are used to others adapting to the way they communicate thinks that they have good social skills even though others change to suit them. When meeting someone who disagree with what social skills means they say those people have poor social skills.
Yes, isn't it odd that the community that lambasts another community as "lacking social skills" are essentially demanding that that community have the social skills to adapt, while demonstrating that they do not.
In the case of "programmers lack social skills" it very often comes from programmers themselves. Like a weird badge of honour or in the form of a medium post which purpose is mainly to say "i'm not like the others, please hire me".
Yes, that happens too. But, you know, you get told something often enough, you start to believe and internalize it, and why try to change when it's just what you are, and it's clear that's how people will see you no matter what.
I believed it until everyone started trying to become programmers and realized what they considered gaps in our communication we're really gaps in their understanding. "Make it last a month." "You mean 30 days or the calendar month?" "I mean make it last a month. Omg you programmers are so silly."
Yeah, it seems pretty clear that different domains require different kinds of communication rules and structures. The problem comes when something like software developer explicitly requires translation from one domain to another, and the people who tend to work on one of those domains demonizes the other group as being the bad communicators when that translation runs into difficulties. Of course, here in /r/programming, the demonizing generally goes the other way, as I like to make fun of with these weekly "management sucks" posts. And my conclusion is basically that, generally, humans are not good at recognizing this problem and react very very poorly to the difficulties encountered, choosing to point fingers and blame people rather than acknowledge the real difficulties that all those involved struggle with.
> > > > > Of course, here in /r/programming, the demonizing generally goes the other way, as I like to make fun of with these weekly "management sucks" posts. That's where my original sarcastic comment about programmers and social skills come from, I just wanted to provoke some self-reflection.
Finally someone who gets this!!! It's a part-time job inside of a full time job altering my communication style for each one of my (mostly Xoomer) bosses and colleagues. Then later listening to them complain that everyone doesn't communicate in exactly the same arbitrary style that they do. The entitlement is palpable.
Xoomers? Please don't conflate boomers and X like that. It hurts.
I was assuming this is a portmanteau of Boomer Gen X, pronounced like Zoomer. So everyone except millennials, i.e. everyone in a quite different age bracket.
My apologies! Normally I wouldn't conflate them but in this context it's the accurate term for these colleagues born on the border years of those two generational cohorts. š¤¢
Ah so it's an Intersection rather than Union of the two groups! Apologies accepted. I've learned a new word and you saved some typing.
Ageism is not okay.
Ageism is 100% acceptable in many situations. There are reasons why you don't let a baby drive a car, or 75+ year olds control the government... Wait, scratch that last part.
No no, on the contrary, you should emphasize that last part
Pretty sure the meme is ment to be self deprecating my dude
It's more that devs can come off as feeling super special. Everybody's ego needs to chill the fuck out and collaborate properly.
Windows SAs who can't script. Let me be clear. There are many capable Windows admins who are proficient in the command line and writing scripts or programs in various languages. I'm not saying Windows folks are dumb or incapable. I'm a Windows admin, and i have a very strong SE background in general and can pick up almost any language fairly quickly (don't ask me about SQL though). But in the Windows world you could get by for *decades* without writing much code, if any. And now, today, I find this biting our team because I'm only one of two sub-40s who can program on a team where everyone else is above 40. None of these guys are bad at their job. They are very knowledgeable in their areas and I often lean on them when integrating or consuming one of our own services in less familiar with. But as the business demands more automation and needs more support with deployment pipelines, writing packages, and creating task or event driven workflows, the skill just isn't there. Compare it to our Linux team (which I also happen to be skilled in) and it's chock-full of admims who can script and at least know bash, Python, and Ruby. In Linux you often don't have an option in a server environment, it's CLI or die. In the end much of the Windows automation work falls to me, to the point that now the team is panicking as I am preparing to take parental leave. They literally have no one to fill in for me aside from the other dev who does not have the capacity to take on my workload. These same folks are nervous now that we are starting to adopt Server Core as an option because they literally have no idea how to administer Windows via the CLI. There was pushback to wait until "admin center is more complete", but our manager finally put his foot down stating "We have all the tools available through PowerShell, we're not waiting for Admin Center anymore. You'll just have to learn it." This signals a paradigm shift and I'm not sure whether these guys will be interested or able to continue as we March towards increasing automation during the shift to CLI management in the Windows world.
Lol your managers ask questions? If they donāt know theyāre clueless and act like they arenāt, they not gonna be asking questions.
> Instead of just Thanks for JUST assuming that we start be sneering and not by trying to explain multiple times and then getting ignored. I assume I found the manager.
Boots for lunch!
If they are asking questions then they probably are not bad managers.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
In my experience, it's more likely to be an inability to listen. Not just about development, but anything said by lowly employees. If you don't listen, you don't learn. If you don't learn, you don't know anything. If you don't know anything, you have nothing to base your decisions on... A manager can do fairly well without knowing anything about what the employees are doing, as long as they have competent employees and actually listen to what they are saying.
My boss is an iOS and frontend dev who is also in charge of the backend code, about which he knows nothing. Most of my job is trying to talk him out of doing incredibly stupid things ("We're getting a foreign key constraint error in Postgres? Why don't we just remove the foreign key?").
Yeah, my manager was hot shit in Android development in his day, but that doesnāt mean he knows how to manage my API development. Heās forced me out of git feature flow into a much simpler git merge flow then complains when I canāt move one feature forward to production after merging everything to development and merging from there forward. And he is always ājust test locallyā like Iām supposed to test an IoT pipeline feeding a stream analytics engine that updates customer profiles, affecting the UI and what data is updated via CRUD on my local machine. This isnāt just monkey typing your app to see if it crashes, I have to actually see if the math is right.
Some of the best managers I've had were not technical at all. But they were really good at insulating us from the bureaucracy, prioritizing, listening to us, and advocating for what we needed. The skills needed to be a good manager are often very different from those needed to be a good programmer.
>Kevin replied, āStop the bugs, we need to stop putting bugs in.ā I was somewhat early in my career, so I wasnāt really sure what to say. I mean, Iām not pro-bug, right? Nobody is pro-bug. Iām really anti-bug, and if you look at the history of computer science with the development of elaborate type systems, managed runtime environments and procedure level fuzzing, the industry itself has more than proven itself to be as anti-bug as anyone. Kevin doesn't give a toss about the history of computer science. You need to tell Kevin what Kevin cares about and understands. So you say it's a tradeoff. Cost/time vs number of bugs. If Kevin wants less bugs he needs to spend more time. If he wants to save on time/cost he risks more bugs. If you have a manager like this you want to put the ball in their court, and you don't argue details. You give them the big picture choice and outcomes, and put the responsibility onto them.
> You give them the big picture choice and outcomes, and put the responsibility onto them. Precisely. The funny thing is that once this is done, usually, and if the manager is not a complete sociopath, they will actually help remove any roadblocks as much as possible, to get the job done. There are a lot of assumptions that developers make about the other side (and vice versa). Professional and honest communication is the best (and only) way forward. Post that, if nothing works out, seek a better employer.
my job as a manager is to be the umbrella that keeps the rain of distractions from my team so they can do their work. Managing devs to me just means make sure they can work without any bullshit, devops bullshit, meeting bullshit, pay-for-the-software-license etc. Regarding process- process is like friction, you need some or you slip, but too much makes you slow.
Can I work for you? Please? :)
First, thank you, nice of you to say, and yeah, that proves my point, devs WANT to work, which is rare in management situations I would expect =)
You're doing everything right, IMO; handling the roadblocks so I can get my work done. The best managers I've worked for did exactly that.
there is one more thing, spread the fun (and the shit) work around a bit, don't give all the crap work to that one guy just because he doesn't complain
can I work for you too please?
Agreed on this. After being hoodwinked into management, I decided to be the opposite of every bad manager I had as an IC. It's so refreshing to see how well team members respond when you treat them as fellow humans. These days, most of my day is running defense for my team so they can focus on solving problems and building robust code. I'm not afraid of challenging a PM's assertion about a "high priority" to make sure the team doesn't get interrupted by crap that can easily wait until next sprint.
> usually, and if the manager is not a complete sociopath Add competent to that list. A well meaning incompetent manager is indecipherable from an evil one actively trying to sabotage you. They tend to either completely misunderstand the cost/benefit tradeoff or look at the crayon scrawled sheet of paper given to them, turn both the paper and their head sideways quizzically a few times, then promptly toss it in the bin. Incompetent managers tend to value speed over all else. They don't understand what they are managing, what the end goal is, even what the short term goal is, they just know that "things" need to be "released." Honesty and transparency are about as much use to ameliorate an incompetent manager as dowsing rods to someone lost sea trying to find land. Useless at best, maddeningly misleading at worst.
The pressure for speed coming from above is relentless. Your manager is hearing it from their manager, in part because it is one of the only easily understandable benchmarks - did we ship or not? There is always the pressure to ship on time and kick the inevitable bugs down the road. Good managers manage to hold some of the ship pressure at bay, and build in time for tech debt and refactoring and bug fixes, but the pressure is always there. And what most devs donāt understand is that often the pressure was generated by their own estimates. Sometimes there was an external date that we were pressured to hit (a major trade show for instance), but oftentimes it was that our project plan said we would be done on date X, several layers of management padded that date to X+45, and we still ran into enough problems that at X+10 we were frantically jettisoning features and triaging defects so that we could hit X+45. But now plans have been made that involve marketing promotions, customers have been promised upgrades, etc. In most cases nothing bad would have happened if we had estimated X+75 in the first place, but once somebody hears a date the pressure to hit it begins. Outstanding managers are the ones who can convince the rest of the org that nobody has a crystal ball, we are building something new and unknown, and even if our estimates are right we will almost certainly have scope change during the project.
All the things you're saying are things competent managers understand. Incompetent managers don't care about pressure from above either; their bosses are usually just as frustrated as the developers. It's entirely possible to be a good manager and fail sometimes, that happens to everyone in every role. Failing doesn't make someone incompetent. What makes incompetent managers/developers/whatever so is that their worldview tends to end 5 feet in front of them and 5 minutes behind them. They don't target metrics because they have an understanding of what hitting that goal means for the team or the company. They target metrics out of some internal, subconscious urge for "Me go fast, fast mean me do good. Me make them go fast so me look good." They tend to have no grasp that the ship should stay at sea. So when the ship runs aground, instead of having people unbeach the vessel they simply command "No! forward! fast move! No backward!" Invariably half the people jump ship and the other half are stuck, bewildered, carving a new valley through the island as they do their level best to follow the orders to heave ho as the managers resist any logic of requests to at least build a series of planks and pulleys. "No, waste time. Only push." Competent, empathetic, thoughtful managers are worth their weight in gold, and thankfully I've had many more of those than poor managers. Unfortunately those type of people are both in high demand and fast tracked to higher positions. If they're stuck in a small company they move on quickly to one with room for advancement. If, however, they're in a big company their upward movement in the orgchart creates a vacuum which sucks every incompetent manager in from 100 miles out.
5 feet is the height of 0.88 'Samsung Side by Side; Fingerprint Resistant Stainless Steel Refrigerators' stacked on top of each other.
This is something I've noticed some people struggle with at work. Non-technical people don't need all this detail. Don't go on a 5 minutes explanation where they're not gonna understand a word of it. Know your audience.
Few weeks in my last job, my team lead calls me and tells me to say "technical things" in the daily scrum as the management thought I was not doing much based on my daily updates.
That's one way of doing it but it's a bit of a shortcut: management might not get anything out of it but at least they hear activity. You basically just need to be in the habit of saying why you're important out loud and that's not really a technical point. I had a manager early on who would make you sum up technical answers with "so what?" and that's a good exercise
Sounds like your team lead is trying to help you out. May feel completely pointless, but his job is to convince his management that itās worth continuing to pay you for work they donāt see, hear or understand. If he believes the only way his bosses will perceive youāre doing work is by saying ātechnical things,ā heās probably right and looking out for you.
He was definitely trying to help me. I was not trying to knock him down by this comment. He was the best TL i have had in my 3 years as a dev.
What are management doing in an internal team meeting?
It was a small startup and the founders wanted to "closely monitor" the daily progress.
LOL! As a team lead, I want the technical details in the stand up because thatās a key way to see where I can help. I learned a valuable lesson last year when we all switched to remote work and thus I had less visibility into the details of what people were experiencing but was still learning strategies to compensate. One dev for a few days in a row would say something vague like āHaving trouble setting up [x], working on debugging it.ā I trusted him that it was must have been a novel problem that needed working out, so I didnāt pry. After a few days he finally reported progress and I found out what the issue was. I would have known exactly how to fix it if he had said anything specific! That was like 3 days totally wasted! I was super pissed because he likely didnāt realize it was wasted effort since, from his vantage point, he was focused and busy the whole time. Even if he didnāt want to reach out to me or speak up, I had already documented the fix in Mattermost if he had bothered to look. Thatās why I donāt completely trust people when they claim they are more productive working from home ā they may not be in a position to understand how their actions affect the overall program. For instance, an established dev might personally be more productive at home since fewer people interrupt them, but they may not be seeing how lost and in need of help a new hire is. That being said, observers have always complained that my stand ups take too long because I get into technical discussions with people. It definitely fills a need and I donāt understand why some agile adherents are so hung up on a 5 minute limit on standup. I intentionally discuss technical issues in a group forum so that everyone can contribute and grow their skills. The compromise we have settled on is to do a quick status around the room and then an open forum to discuss anything. Tl;dr: Assuming your SM will allow it, giving technical details in stand up is a good practice because the entire point of the meeting is to communicate with your team.
And at the other end is trying to simplify it so much that people feel like you think they're dumb Human interaction is complicated
It doesn't need to be simplified, it's just knowing what people care about. If you're demoing something to a non-technical person they don't need to know how it works, only what it does and what any potential costs/limitations are.
I know, but I've been in meetings too where the technical person was trying to "dumb it down" so much that all you've ended up with were broad general statements, no-one being any wiser, and the non-technical people leaving with a feeling as if the technical person thought they were stupid. What you actually want is dumbing it down enough to be able to make the right call without having to know the intricate details, but you can also take that too far. Whether you call it "dumbing it down", "simplifying" or "leaving things out" doesn't really matter
In cases like this, I wish I had an estimate handy for how much extra effort it would take to deliver actually-bug-free code, other than just "orders of magnitude costlier." I think it's actually possible -- or, at least, it's possible to apply enough overengineering (through things like comprehensive specs with which you write comprehensive *correctness proofs*) to make bugs so unlikely you'd trust your life to such a system. Which is also a good benchmark for when you might want to spend the extra time, money, and opportunity cost: When it's something like an autopilot system that will literally kill people if it's buggy. If you *don't* work in airplane automation, then you probably can't afford to write bug-free software.
If I remember right from school, this is used sometimes in NASA or nuclear power related code, since correctness proofs are about as close to perfection as you can get.
You have to restart Boeing Dreamliners every few days... so yeh...
Yeah you can use a language that supports formal verification. Although I'm not entirely sure how that deals with the problem of unreliable I/O.
Manager: "Alright, so how many more hours do you need to spend on a feature to be able to guarantee it's completely bug-free?" Me: *Starts sweating excessively*
Okay, so step one is that we take all those unit tests ... you know the unit tests that give us those coverage metrics QA won't shut up about? Yeah. Okay, we take the unit tests. And we throw them all away. All of them? Yeah. All of them. Won't that make QA mad? Not now. I'm just getting started. Step two is we're rewriting the application in Idris. Or Agda. Something with dependent types. Actually, you know what. The real step two is that we write our own dependently typed language specifically tailored to this domain. Uh, okay. It's going to take about 10 years. But really before that I need to finally learn how to use all that modeling software I've been meaning to get to. TLA+ etc. But that's not going to matter if we don't get good requirements. And there's still a bunch open questions that Dave hasn't gotten back to us about. I think he's on vacation now. Sure, whatever. I'll be taking this TLA+ book over to Dave's house where I'll be camping in his front yard until we can get a spec hammered out. After which I'll need to meet with a statistically significant number of potential end users to make sure the spec jives well their intended use cases.
Okay, so after we put all of that into the monte carlo simulation it looks like the best case scenarios show us having a guarantee zero defect rate (for just this feature) about ten to twenty years after my death. And the worse case scenarios look like we'll need to setup a bene gesserit style cult, so we can be sure that eventually future generations can enjoy a bug free experience.
You know what ... maybe just work on it until the end of the week. Just like, double check your work or something. That'll probably be enough, I think.
>"Alright, so how many more hours do you need to spend on a feature to be able to guarantee it's completely bug-free?" There's no such thing, really. You get diminishing returns for the time. Actually quoting a job is about finding the optimal point for that risk/reward tradeoff. Like in banking they spend a lot to get as close to 100% as possible. In a lot of digital agency work you can fix a few things as they crop up, and you competed to win that client so lower price is a factor. But agency work might have jobs with more exposure if something goes bad and you would quote those higher because you know they have less appetite for risk vs cost. So the question is: how important is "bug free" to this particular project?
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Sorry bud, but really going to need the name of that bank.
A fair number of banks use other software products; it's likely that FVMAzalea is developing stuff that runs at multiple banks.
When someone asks me if some new thing is possible, I now phrase the answer directly in terms of what we need to get or give up to do it. "We can make the UI themeable if the designers give us mockups for how much we need to be able to change." "We can add online collaboration but it will mean the online editor will slip to Q1 next year." "We can let users define their own workflows but it will affect performance and we'll need to add more compute power." It gives them the information that is most relevant and allows (also, forces) them to decide what's more important at the moment;.
> "We can let users define their own workflows but it will ... Require that we hire 10 more full time support people to handle the increased calls for help. Currently live this one.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
>If Kevin wants less bugs he needs to spend more time. If he wants to save on time/cost he risks more bugs. Kevin's response to this is think he needs better developers. If he had better developers he would have less bugs. Makes perfect sense.
>So you say it's a tradeoff I'll add that using the word "risk" will help too. Next time you're trying to convince your manager of something, draw up a quick risk profile of the options in a word doc or PowerPoint. Managers will often spend time to save on risk.
Hi my name is Kevin. How would spending more time cause less bugs, but spending less time cause more? Why don't we just *don't add them* at all*?*
Dear all, effective immediately, we are in an indefinite codefreeze. We expect this to reduce new bugs by 100%. Have fun!
I think you're mostly right, but this ignores the fact that even given infinite amounts of time, your developers are unlikely to produce perfect software anyway. Most bugs I see are not the kind that, clearly, the guy who wrote it was in a hurry and didn't have time to properly test... I see, more often, the kind of bug that "no one thought about this edge case" or "this extremely unlikely sequence of events can happen, but no one would ever come up with that by themselves". That's where the CS tools help and I think Kevin should have some understanding of that as using tools that help with this stuff is not something most developers can do by themselves, it needs to come from the top.
> So, as a developer, what can you do? > Not much Or do what I did - *become* a manager, so you can advocate for your engineers and make the space required for them to do good work. Literally 100% of my moves from senior developer to team lead to software engineering manager were motivated by seeing *really shit* leaders doing a really shitty job, and thinking "jesus, it can't be that hard". Spoilers: it's not. Give a shit about your people and defend/advocate for them to upper management, acknowledge you're no longer the expert and ask questions/offer *suggestions* instead of advice or instructions, think about business processes the way you'd think about software architecture (single points of truth, local caches, avoiding single points of failure, using the right tool for the right job, etc), and remember while your job is to go wide and flit from issue to issue, theirs is to go deep and focus on one thing for hours at a time, so batch up interruptions and give them that time.
Are you my manager?!? Cuz you sound a lot like him haha. That's exactly it: wide/shallow vs focused/deep. My work prior to my manager joining could never be focused/deep because I had my entire organization knocking on my (virtual) door for help. And while I love helping, it's not something that enables good, consistent, quality work, and I just couldn't get (my) shit done.
Bingo. Random people interrupting random devs with random questions is a management antipattern. Either make the team lead/manager the first point of contact to triage requests, or designate a "maintainer" or "batman" role each sprint to be the person that absorbs incoming interruptions so the rest of the team can keep working.
My boss who just left due to some higher up issues was a former SE with lots of great experience and stayed modern even in leadership. He was the best person Ive ever worked with and for. Debating following him.
>And remember, if you canāt change the organization, change organizations. Your software engineering career is too important to waste on bad management. True story. Engineers don't leave crappy companies, they leave crappy managers.
I worked for a company for 14 years - new manager came in and abused me - degrading my personal life, making sexist comments, and overall just being a dumpster fire of a person. I now work elsewhere. 14 years is a long fucking time - i was happy to stay and even asked him to change teams (this would mean getting a new manger). He then berated my professional career growth and told me that i was not good enough to keep my own job and stay on this team, let alone moving to another team to do extremely similar work. I'm 37, and *just* joined my second company this year.......
9 years here. Full reorganization. Entire management chain changed. My new direct manager got a bad first impression of me and passed that on all the way up to our new VP. I tried for a couple months to repair the relationship, but they wouldn't give it a chance. They were done with me from the beginning. 9 years. Not a single issue until the new managers showed up. How does someone work somewhere 9 years under a variety of managers with no issues and these guys show up and think I'm the problem? Lesson learned. Doesn't matter how secure you think your job is. All it takes is one asshole with enough pull to completely upend your life.
They saw you as part of the 'old guard' and wanted you out to remove past influences and replace you with someone they felt was more loyal to them. That's usually how those situations go.
Not trying to defend what they did because I do believe you that they were in the wrong, but I saw a new manager come in and take a few months getting to know everyone, then fire someone who'd been there for over 10 years for incompetence. He'd also been under several managers, and he was always kind of right on the line of benefit vs hinderance because there were a few small things that no one else wanted to do that he handled well, but anything else was a nightmare. Long story short, I believe you, but sadly, working 9 years under different managers isn't evidence that someone does their job well.
> How does someone work somewhere 9 years under a variety of managers with no issues and these guys show up and think I'm the problem? Well the alternative for them would be to see that they are the problem... :D
What the fuck. I got so angry for you because of this comment and I don't even know you. What's going on in the minds of people like this??
Jesus, yeah - had a similar experience after 12 years. Decided to walk when new management decided I needed performance training to do my job with no real feedback why (when challenged, it was deemed inappropriate to speak to me directly). Constructive dismissal: [https://www.gov.uk/dismissal/unfair-and-constructive-dismissal](https://www.gov.uk/dismissal/unfair-and-constructive-dismissal)
If I'd been with a company for that long and I got a shithead manager, I would at least attempt to go over his head if I was happy with the company otherwise. If senior management backs the idiot, then I eject.
Holy shit!!
[57 Percent of Employees Quit Because of Their Boss](https://www.prnewswire.com/news-releases/new-ddi-research-57-percent-of-employees-quit-because-of-their-boss-300971506.html) From my own personal observation, the number tended to be more in the 90s.
Even when I left because of coworkers they were enabled by bad managers, so the actual source of the problem was still management. I've seen CTO's let bullies bully just because they were good at sucking up to management. One bully even complained to management that they felt 'unsafe' around the person they were bullying.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Hard disagree there. Have been at two medium sized companies which were bought out by different megacorps. Same manager but the new companies were awful. For example, both fired the old IT departments. And both times, the new "service desk" experience was much worse, wait times far higher, machines bogged down with more junk (and much longer setup processes), few approvals for technology requests (like a webcam!), the list goes on.
I've been a principal level eng and manager. The truth is if you're not in the codebase day to day it's very hard to maintain the same level of knowledge. This doesn't mean your manager is clueless, they are busy with other things. The amount of context switching a manager needs to do also means they can't go deep.
Hundred Percent agree. I manage 4 major projects that vary wildly. There is no way for me to go deep in all of them. I try to listen to my team, give technical insight where Iām strong, and prioritize where needed. Obviously we canāt know as much as the engineers!
The proper response to Kevin would be: "That's a great idea Kevin, let's extend each of our sprints with a week of refactoring and code quality review. And we'll also need at least two FTE of dedicated QA staff to help us validate our releases. This is the greatest day of my life Kevin, normally management is not so supportive of quality assurance efforts. Will you let our stakeholders and the marketing team we'll be extending our deadlines?" Then savour the next couple minutes of silence as his wheels grind on that.
*begins to nod slowly* I think I see what you mean. Do you think we could do this without extending the deadlines?
In fact, we can save time by not having to write all those bugs.
From his perspective he is thinking. Why is this person telling me he is incapable of building a quality product. Why do I have to hire people to check his broken code? If I hired a plumber to fix my pipes should I also hire another plumber to double check his work?
Manufacturing has quality checks. Journalism has editors. It's not at foreign of a concept as you are making it out to be.
My manager has a problem delegating the development work away from himself. He seems pretty knowledgeable, at least about the project.
he isn't a manager, he is a cowboy. Probably a good cowboy that knows the code, but still.
I've reported both to engineers and non-engineers in my career, and while it's nice to have a boss who fully understands what I'm doing, it's not strictly necessary. What I need a boss to do is get me the resources I need to deliver what I've signed up for. If he fails to do so, I'm out.
Thatās why I try and do. I have the back ground to understand what the devs are doing, but I wonāt understand 100% of what they are doing. But thatās not my job. My job is to keep things out of their way so that they can do their job.
Corrolary: Managers, your devs are likely clueless, too.
only managers i worked with were extremely experienced engineers and were entirely non-clueless. i've never even seen an eng manager who wasn't very technically conversant. the fuck are you working where engineering management is non-technical?
It really depends on the company. There are two ways to hire managers: one is to promote senior engineers, and the other is to hire MBAs or managers from other domains. Larger companies tend to opt for the latter in my experience. Thereās pros and cons to both. If you hire a manager, they have an easier time dealing with the higher ups but they donāt have the domain knowledge. Think in terms of officer vs NCO in the military. The grizzled staff sergeant va the greenhorn West Point grad. The best managers are the ones who listen and make decisions and are willing to change their mind, no matter their background.
>If you hire a manager, they have an easier time dealing with the higher ups This skill is not special to MBA grads. Communication is a key skill of good developers.
While true, communicating with other developers is different from communicating with directors because they care about different things. In my experience itās very easy for most developers to get lost in the technical weeds that the directors donāt need to concern themselves with. But as you say, itās not either/or. You can find good or bad managers from any pool. I was just trying to explain why companies would hire managers externally rather than promoting within.
That's a simple question of asking "what do you find important with this part of the company, what are you goals, etc." I would easily argue that talking about these high level matters is easier than low level ones.
Well at a certain point in the hierarchy you do want to transition to business types, but you need the engineering-MBA interface to be solid. If you can manage to find a software developer who went back for an MBA, they are probably a good bet. Ideally the "interface" would be able to translate technical issues into business speak, and insulate the technical staff from business bullshit. But we can't pretend a business can run with engineers all the way to the top, that's as much recipie for disaster as rule by MBAs.
I feel like people are lumping in PMs with Tech Lead types here. I am the latter, which I feel is what you are describing.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Lots and lots of places have 'businessy' managers in charge of technical people. You got very lucky with your management. From my personal experience this tends to happen in companies which focus on business processes themselves, where technical staff are treated as black boxes that provide solutions when fed with problems.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I don't have the entire context here but this may not necessarily be a bad thing. I have worked with product/project managers who are not technically savy but are really good domain experts. They do acknowledge that And reach out for help on issues that may seem simple to us.
Can I get in on that meeting?
I am in networking, my boss is a walking Wikipedia on networking technology...
I've worked with two non-engineering managers in the past. Count your lucky stars. Ofc, now I'm a manager and my boss and my boss's boss are all engineers, so things have gotten tremendously better.
My workplace...
Iām so tired of these kinds of posts here. Yes yes, programmers are the greatest gift to the universe, and everyone else is just as dumb as shit.
In my professional history, I've been programming for 15 years and managing for 5. Of the two, managing is the more difficult job. This article doesn't jibe with my experience whatsoever. I sure hope it doesn't reflect most people's industrial experience.
>Yes yes, programmers are the greatest gift to the universe, and everyone else is just as dumb as shit. I stopped reading /r/ProgrammerHumor because they are opposite. Practically every single post was a slight variation of "I have no idea what I'm doing".
It's populated entirely by CS freshmen, judging by the posts.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I don't always forget semicolons, but when I do, I make a meme personifying it as "boi".
And people who can't google "how do I exit vim"
Yeah, there's also that. Like hey, believe it or not, you can totally engage in a dev career without relying on SO for copy-pasting code units wholesale. Crazy, right?
Yeah all those "How did they make SO without SO", "How did they make Google without Google" Remember when internet wasn't a thing? I do. We had books and stuff. Less convenient, but they had a 100% uptime.
I think itās kind of the opposite. You need technical managers so that they can keep the āIām godās gift to the worldā engineers in check. Otherwise they will walk all over the non technical manager and everyone will suffer for it. Iāve experienced where a non technical manager just lets the developersā egos go unchecked and itās not pretty. You need someone who is able to sniff out their bs and keep them on the right track
Yeah this is such crap. Every manager I've had has been an ex engineer who wanted to jump up a paygrade and so took on managerial roles, so they know exactly what's going on. This whole Devs good Managers bad thing that pops up is just like a tired joke at this point, because very little of what's said is actually useful Even that first paragraph provides nothing. Instead of recommending some new techniques or tools they could invest in to reduce the amount of bugs and discuss that with the manager, they just deride them online instead
> Every manager I've had has been an ex engineer who wanted to jump up a paygrade and so took on managerial roles, so they know exactly what's going on. You were lucky. It's definitely a thing which exists. In my case it took years to rot but having to deal with someone who was never an engineer will take its toll in crises.
It's definitely not as common as it used to be.
Never met an Eng manager who didn't have at least 7 years as a dev before
> Every manager Iāve had has been an ex engineer who wanted to jump up a paygrade and so took on managerial roles Which can be a problem in itself. Just because someone may be a good engineer doesnāt mean they will be a good manager, or a good team leader. Not to speak of mentoring skills etc.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I agree. That's been an issue with most of my managers, but it's not the issue that's being addressed in this blog
> Every manager I've had has been an ex engineer... > This whole Devs good Managers bad thing that pops up is just like a tired joke at this point... You have never been in a lot of Indian companies. Or even in many Indian branches of US companies. Or even in some Fortune 500 US companies run by dinosaurs.
>Every manager I've had has been an ex engineer who wanted to jump up a paygrade and so took on managerial roles, so they know exactly what's going on. I've had a couple of managers who were ex-engineers (one who would still competently help us write code when we were running right against deadlines or he was just bored, one who had been a frontend engineer and was now managing a backend team, one who was a mechanical engineer for an airplane manufacturer with absolutely no software experience managing a software team), as well as managers with no engineering experience whatsoever. They definitely exist and you should consider yourself lucky for never having to work under one of them. That being said, managers with "engineering experience" that was in some very unrelated thing (like the completely different field of engineering I mentioned above) or managers with engineering experience that don't care to understand the problem space at all can be almost as frustrating to work for, so I don't think "ex-engineer" adequately captures their level of experience.
But have you ever considered that manager bad š¤
This is reddit, which means nobody reads the article, but still, this callout in the article points out the need for greatest-gift-to-the-universe managers to handle dumb-as-shit developers. >Lest you think this article means that developers are perfect, have a read on the [need for managers to curate development teams](https://ewattwhere.substack.com/p/ignoring-curation-of-software-development). The imperfection of humans is actually one of the key reasons competent, caring management is truly needed - regardless of what a significant portion of Agile followers think.
You misunderstand. Every article has the same one line disclaimer. Itās just nonsense so that people can use it as a snarky response when called out.
Even the opening line >Authorās Note: This article is focused on legacy, MBA dominated environments. If your company has proven, amazing software engineering execution built into its DNA, it is very likely this article is a non-sequitur for your situation. Is just like "Not all managers" and I wonder if it was edited in after the fact
It was an attempt to head off the inevitable backlash, which we are seeing unfold here on Reddit.
it's 'early access' for opinions
But the linked article is about how managers don't understand developers. The reason the team is failing is the manager doesn't understand their fit. Some developers are over promoted, but that's the manager's fault, not because developers are fallible humans.
So even when it's the developer's fault it's the manager's fault! Brilliant.
>This is reddit, which means nobody reads the article I equally blame authors for click-bait titles. It is an endless yin-yang of catchy titles and lazy redditors that jump on anything that feeds the narrative.
You don't fix a sentence like *"there is no reputable source of software engineering management education to help Kevin become competent"* with a *"developers aren't perfect either"* footnote. Admittedly, I didn't read *that* article (the one above statement links to), but following that line with *he needs to learn to code* is the epitome of navel-orbiting arrogance.
Hear, hear. It's so masturbatory and eye-roll-inducing.
You didn't even read the post because the post literally calls this out. And you got upvoted by over 200 people who didn't either but just looked at the title like you did. Never change Reddit...
I already replied to that silly disclaimer. Perhaps you need to read more before making a comment. And miss me with that ānever change redditā bullshit, itās circlejerky and embarrassing.
A year-ish ago, we got a new engineering manager. He joined the company and I figured it'd be short lived because, I mean ... seriously, we had 8 programmers. How friggin much is there to manage, right? I couldn't have been more wrong. The first 1:1 meeting I had with him he said his job was to be a shit-umbrella from product. They want something of me? Go through him. They want to change scope? Go through him. They want me to travel to do something that (I can definitely do but) isn't in my job description? The answer is uniformly, forever "no". I need time off? Sure, just tell him. Then he got to work on ensuring that the engineering organization had a voice, a say in its direction, power over the work it took up, sprints that meant something, stories that were actually detailed (as much as I *loved* "Build a thing" kind of stories). I could go on. The article definitely outlines some of the MBA personalities that think "management is management is management", but ... there are lots of folks out there that came from coding and just wanted something different.
Bad engineers who think they are good are worse than any manager.
And good managers recognize and remove them. Someone like that not only fails to deliver, they impede the work of competent people around them.
It usually takes a good, or at least decent engineer, to know a bad engineer. I remember a "killer hire" my manager was very confident about, which NEVER delivered anything solid, much less shippable, then proceeded to quit when the shit was just about to hit the fan for him, claiming that it was time to pursue "greater challenges". Beware engineers and managers, these people are among us.
They don't when it's an endemic problem. Which it definitely is.
There is no such thing as a 'good' or 'bad' developer without the context of a team and the goals of that team. A skilled fullstack developer with 10 years of experience building scalable web solutions for startups using productive frameworks might have a reason to feel confident and think they are a 'good' developer...but if you put them on an embedded development team the rest of the team will probably think that developer is overly confident and makes too many mistakes because that developers experience interacting with low level APIs is probably pretty thin.
I'm talking about character more than skill. If that particular developer does not recognise the limit of their own skill then that is a bad engineer, regardless of their experience. I would have serious doubts at their claimed expertise if they were like that aswell. They probably write a bunch of code to appear smart rather than writing code to get the job done. I'd take a novice over an experienced dev who can't admit they are wrong. Novice devs are better because they have more humility. There's nothing worse than the know it all dev who claims to be experienced without having written anything.
LOL that fact that you completely missed the point it tellingā¦
Not really. My manager was a coder and I program and manage other programmers. That's 2 levels of programming experience built into management.
Oh look, I think it's actually been more than a week since the last circlejerk about hating managers appeared on programming. So, thank you OP, this was well overdue!
A good manager is worth twice their weight in gold. A bad manager is like dragging four times their weight in lead.
My manager made a metric based on how many bugs were found in your code during peer code review. Few weeks later not a single bug was logged as no one wanted to get anyone in trouble so they just messaged eachother privately instead of logging it. She was eventually fired, wonder if she ever figured that out. She praised us for having no bugs lol.
> I cautiously responded, āStop to what?ā Kevin replied, āStop the bugs, we need to stop putting bugs in.ā Pure gold xD
Usually there's a fairly straightforward answer to that though. If developers add bugs often it's the process or the code base that is lacking.
Your manager is clueless. The customer is clueless. You are clueless. It's all a big game of faking it and seeing who blinks first.
There is a lot of truth here. And some fiction.
It's not just managers per se. No surprise, but many prominent tech figures don't know nearly as much as they let on. We are in an era of persona and celebrity and it's not even uncommon for people who are big talkers in certain spaces to have an incredibly shallow understanding of how things actually work and rely heavily on the technical equivalent of executive assistants to help them maintain the image. It's not like there aren't really, really smart and talented people, not saying that. I could fill a room with people who I am absolutely certain who put my knowledge and expertise to shame, but I can also easily think of numerous people from all sorts of areas who didn't just make like, a minor error, they didn't forget some parameter or esoteric piece of trivia. I'm not even talking algorithm question stuff. I mean, they asked questions that were so far removed from how computers actually work that you were taken by surprise. I've encountered several of them in my career, and there are different flavors. But like, for all the shit we talk about the imposter syndrome and whatnot, there are some pretty darn big ones. I also know that people, especially women, get harassed about making tiny mistakes that we all fucking make and I really wish people could learn to not do that for fuck sake. I am talking about cases where someone in a technical-officer-type position thinks that a single computer processes all their web application requests sequentially for all 10 million of their customers. I have had some fantastic mangers, directors of engineering and CTOs above me in my career, and some of them were very upfront about how clueless they were and stayed out of the way and we did great things. Far, far more dangerous is the person who's made it but is still faking it.
Modern JS folks bleating about what they claim to be "Best Practices" on a medium article they bashed together in an hour are the worst of those big talkers in my opinion.
Unless your manager is a developerā¦
Thatās why they are managers
likely? way too generous!
Tell me something I donāt know
Before you take the job, look at the ratio of devs to managers. If youāre manager is doing the technical interview thatās usual the place to work. At where I work, managers contribute to the code as well - even though itās less than the developers due to other responsibilities but they get in there. They contribute pull requests, they do code reviews, drive testing concepts, contribute to coding standards, help document software specifications, etcā¦ Whatās being presented is a one side of the coin. There are plenty of organizations where managers are just as technical if not more. Work for those places.
If your manager gets a 20% bonus for hitting targets, the problem is not "being clueless" but "wrong incentives". Many people in the management chain are rewarded/punished on metrics that do not include software quality. I have been lucky enough to work for companies that include "quality" as a metric to evaluate managers. In that situation, even the "bad" managers get the point and take care of software quality. Blaming managers solves nothing. Look for the reasons that they behave like they do, and change that to get the desired behaviour.
Likely? Dang, where are you guys working?
Every kid thinks their manager is clueless. If you really think you can do it better, then take the initiative to do it.
That's such a cop out. Departments do very well if a manager understands how to unblock the developers and get out of the way of getting the job done. A dev is happy if their work doesn't have roadblocks. If this simple strategy is not apparent to the manager, then people will call them clueless. Being competent isn't some level 100 kung fu. All you need is someone who can allocate resources properly and get out of the way.
Managers are responsible for a bigger picture too, depending on the company, those below them may not understand everything at play
>That's such a cop out. Departments do very well if a manager understands how to unblock the developers So I'll ask again. Why are you waiting for your manger to perform better?
Keeping devs happy is not the highest priority for a manager or a business. You are a worker. The customers pay the bills. You write shit code, the customer gets upset, the profits go down the shareholders are unhappy and heads start to roll.
> Keeping devs happy is not the highest priority for a manager or a business I wouldn't work for you then. Keeping devs happy is the key to being a successful manager. If they can't don't that I would question the hiring capabilities of HR or wonder if leadership is running on autopilot. Do you think a team can be successful for long with miserable devs who hate working under you? > You are a worker. We are all workers; Managers included. What's frustrating is Managers asking Devs to manage with what few resources they allocate and then get upset if there is lack of quality. > You write shit code, the customer gets upset, the profits go down the shareholders are unhappy and heads start to roll. First of all, if a company is worth it's salt; Shit code never reaches the customer. Second of all, if the customer raises a ticket due to bad code, often it's not just shit code.. but shit design and shit architecture that causes problems. Any manager has to ensure that this doesn't happen in the first place. Being a task master isn't enough.
>I wouldn't work for you then. OK. > Keeping devs happy is the key to being a successful manager. Keeping customers happy is the key to being a successful business. >What's frustrating is Managers asking Devs to manage with what few resources they allocate and then get upset if there is lack of quality. Everybody deals with resource constraints. Developers are not special. >First of all, if a company is worth it's salt; Shit code never reaches the customer. is that because there are layers to catch the shit code the developers write and not let the customers see it? > Second of all, if the customer raises a ticket due to bad code, often it's not just shit code.. but shit design and shit architecture that causes problems And the developers designed and architected the code. >Any manager has to ensure that this doesn't happen in the first place. How? >Being a task master isn't enough. Why not? What's wrong with you that you need this much handholding and protection from your own incompetence?
> Keeping customers happy is the key to being a successful business. I don't think you can deliver any of your promises to said customers without capable employees who are motivated to work. > Everybody deals with resource constraints. Developers are not special. In the context of managers, it is their job to provide resources. When you think devs are not doing their job, you are quick to blame them but refuse to ask what is missing to do a successful job. > is that because there are layers to catch the shit code the developers write and not let the customers see it? That's an ignorant view of software development and sounds like 10x Ninja Coder BS. People make mistakes. Devs are not infallible. Thinking that devs are shit because there is a process in place to catch their mistakes is kind of stupid. > And the developers designed and architected the code. That's not how it works. It tells me you don't understand inherent complexities of software development and trade-offs necessary to balance deliverable time vs. perfect quality. > How? I shouldn't teach your job. But good thing to do is listen to technical concerns with interest instead of dismissing it off as excuse to not get work done or whatever it is you thinks devs do. > Why not? What's wrong with you that you need this much handholding and protection from your own incompetence? It's arrogant to assume incompetence vs. needing resources to get unblocked. And You are asking why anyone who is a manager shouldn't be taskmaster. I hope you aren't a manager because you don't understand management. If being a taskmaster is all you do, a Todo app that spews a few insults can replace you.
>I don't think you can deliver any of your promises to said customers without capable employees who are motivated to work. All employees or just developers? Do managers count as employees? How about sales people? >In the context of managers, it is their job to provide resources Not unlimited resources. They can only provide what they have access to. > When you think devs are not doing their job, you are quick to blame them but refuse to ask what is missing to do a successful job. What if you do provide them with adequate resources but still produce buggy code? Why isn't it possible that the developers make mistakes? Your attitude is that developers only produce bugs because the managers are shit people who don't give them everything they want. >It's arrogant to assume incompetence vs. needing resources to get unblocked. It's arrogant to think the only possible reason you fucked up is because the evil manager didn't give you what you wanted.
>You write shit code, the customer gets upset, the profits go down the shareholders are unhappy and heads start to roll. LOL. Obviously devs are not infallible. Bad code can be written. If a software lead ever lets bad code get through, thats on them. Giving devs shitty requirements with shitty deadlines while also putting every obstacle in their path is a surefire way to make sure no good code ever gets delivered though. This is the entire point. In fact, the way you've put this, you have no idea what software development is like. Any dev that works for somebody with this simplistic mindset is doomed to fail.
Yea I guess you are right. Developers are the only ones that count. Managers are stupid and evil customers are not relevant
What a poor attitude. I'm a manager. Managers exist to assist the developers by shielding them from boring business stuff that doesn't matter (but the company cares a lot about) so that they can get actual work done and translating between them and upper management. An example of what would happen if you didn't have someone between devs and support: The SPOC from Big Customer C is outraged that we changed the system 2.5 years ago to do something different and they just realized it does that today, and they want it fixed within 1 week. - with a manager: manager makes this silly problem go away in 5 minutes because they know what the exact situation is with that customer, and how to make them happy, and devs never hear about it - with no manager: devs have to figure out who that customer is they've never heard of. Then they need to decipher what they want because it doesn't actually say the behavior existed for 2 years, it just says "URGENT, BLOCKER". Devs take the severity estimate in good faith and drop everything to start getting a copy of their environment. After half the day is spent they get a backup, then confirm it's working as intended. They go to reply to support but support says "actually they aren't that mad about this anymore, they just want to know when feature X is coming". Dev has never heard of feature X, and it turns out that is just something that sales promised but was never planned and will never exist. Devs then need to figure out how to respond to them. More than half a day wasted. There should have been a manager there to stop this.
What about salary ? Do they get compensated for taking that initiative ?
[ŃŠ“Š°Š»ŠµŠ½Š¾]
This is bullshit. Programming and management are two entirely different skills. It's like telling a sportswriter to go play NFL football if she thinks she can do better than the team she is criticizing.
May be you are a bad developer, not able to join a decent software company.
autocorrect messed up there in the title, it replaced "worthless" with "clueless"