181–190 of 316 posts
We’re obsessed with technical talent but we hire managers at random after asking a couple of behavioral questions they’ve heard a thousand times.
The underlying principle I've been using to understand this is, no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well. The opportunity cost of talented software engineers is much too high in general. This applies regardless of actual talent and does not guarantee results. I've seen mediocre SWEs with inflated egos jump ar…
> no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well So is everyone developing advertising at google is a second rate engineer?
Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. - Not involving your current team in decis…
As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.
If someone hasn't taken the time to learn the tools their team uses, they will be a burden to the rest of the team. They don't need to become an expert, just experienced enough so they don't cause problems for others on the team.
Earlier quoted context omitted.
IDK. If you're in one of these too-small-high-pressure teams, and then all these extra "resources" get poured in... It can go quite badly too. IMO, engineers themselves are sometimes responsible by leaning on "we need more resources."
I think engineers often say "we need more resources" but mean "we need to have hired more resources two years ago".
Sure, there's lots of startups burning the midnight oil to finish that MVP. But especially on more mature teams, it's incredibly easy to lose focus when doing software and spend several days on shitty features that don't really matter at all to customers, but are being prioritised due to inertia or capricious management.
Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compar…
Depending on your outlook, character and experiences, the magnitude of the results can make it worth your while; there's certain objectives that you can't hit without massive throughput (and waste). And reducing or keeping under control the amount of waste in a large scale project can also be incredibly satisfying.
Earlier quoted context omitted.
- Manager: How long would it take to migrate from A to let's say B? - Me: What do we want to accomplish from the migration? I'm assuming cost reduction? - Manager: Yeah, the guys at B are much cheaper. - Me: Ok, give me until EOD Friday to do some investigation. - Manager: EOD Thursday would be better, don't need a full roadmap, just enough for an ROI. I'll flip over the CEO's spreadsheet that she's using for the cal…
Hah if only managers were that grown up too. I’ve tried those conversations. Firstly, that Friday deadline likely would have been fine, it was just a power play. Secondly, when the manager said “yep” to dropping the feature, you’ll still be expected to make progress. (Of course most of the time they try to make you do double the work. A quick “yep” wouldn’t happen IRL)
Earlier quoted context omitted.
As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.
Yes, git can be complex. It's also a requirement for modern software development. It is well documented, and not esoteric. If someone hasn't taken the time to learn the tools their team uses, they will be a burden to the rest of the team. They don't need to become an expert, just experienced enough so they don't cause problems for others on the team.
How does your company handle this? How do you give the people the time/resources to learn those tools?
> Stop estimating. This! It's more or less impossible to correctly estimate how long it will take to develop anything but the most basic pieces of software, and even then you can't be sure. I've had so managers who just don't get that there are so many unknown variables in the software development process. No matter what estimate you give, you cannot win. Estimate short, but it takes longer? Then you are accused of n…
Give three estimates. One if everything goes well, the most optimistically you can imagine. One representing the most likely path. And one representing the worst-case scenario. Let your manager digest from there. If you have a bad manager (e.g. they would just use the best-case scenario estimate and ignore the others), average the estimates, 1 part best case, 1 part worst case and 4 parts normal case. Then try to mak…
So anyways myself and others started pushing back and refusing to give estimates and instead just saying "it will be ready when its ready" and when pushed giving super vague time frames like "a few months". He did not like that.
So I took step two and moved to a new job.
I get the pain expressed here, it's real, and the problems are REALLY HARD to solve. Any one of these is multifaceted and cannot be solved by "management" alone. Asking VPs to code a feature every quarter is both unrealistic and silly. Complaining about too many managers, meetings and processes is common and fair, but not to say "if you have painful process fix it with this different, equally strict and brittle process" is naive to the point of funny. Saying "estimation is hard so don't do it" an incomplete answer, and railing against smaller teams or realigning people broadcasts "I don't really think about budgets, emerging needs or things above writing code".
So much of this can be addressed within the team; you can promote streamlined process that does enough to align without prescribing, you can add some consistency in who does what work to build more durable teams and form a consistent mission, you can estimate in effort not time. The author seems to think the ideal is achieving stasis and maintaining it; to me this is impossible and actually sounds like hell.