411–420 of 425 posts
Earlier quoted context omitted.
It is also possible to arrive safely at your destination via reckless driving.
It is equally incorrect to assume that someone who speaks "without a duty of care to the truth" is saying something true or false, if given no other information.
Earlier quoted context omitted.
I can justify it quite easily. Take it away and see what happens.
Devs: "Overworked? Too many disparate responsibilities? Not being able to write enough code? No team cohesion? This is a systemic failure of leadership, start interviewing for other positions." Devs: "We, as software developers, are underappreciated! People only pay attention to us when things go wrong!" Also Devs: "Managers are so useless lmao"
Earlier quoted context omitted.
> Startups with managers 33% more likely to develop product innovations If the upside of managers is only 33%, they're probably not worth the added complexity/friction/expense !
Maybe you are misunderstanding? This number would be the holy grail of any company. Unfortunately the claim made is pure nonsense :)
(it's worse in a company as it's the shareholders who earn +30%, not you)
Earlier quoted context omitted.
This is interesting. What, in your opinion, should the core definition be (if anything)? And how is that eroded when tasked to an engineering manager vs. a project manager? One of the major issues I have with the article is they lean heavily on the "creative work can't be managed like manufacturing widgets" train of thought. It feels to me that they define developers as artists when the article is about engineering.…
I think Software Development is far more creative than you give it credit. Let me list a few realities of modern software development: 1) You give a spec to ten different engineers. You'll get ten wildly different solutions, from decisions within a single programming language, to different programming languages, to microservices and serverless. 2) So: make the spec more specific to reduce the variability. Now an engi…
What you've really illustrated is that software is hard. Engineering is hard. The distinction is that other engineering disciplines have had a much longer time to codify good practice. I bet if you went into, say steam engine design in the mid-1800s, it would feel a lot more creative than today. For a variety of reasons, software development is not nearly as good at implementing standards and to go into all of them would be a digression. However, I think the distinction that we disagree on is that it's due to anything inherently different in software. I'd make the case that software is easier in some respects (e.g., it doesn't display wear out failure modes) and harder in others (e.g., it tends to have more interface failures). I'm saying it feels more creative because it's less well managed. If you've ever worked in a heavily regulated sector like safety-critical software, it definitively feels less creative than a CRUD web-app development effort for this very reason.
I personally think part of the issue is that EM becomes a career-track that can start immediately out of school. It's similar to the change in MBA programs. The better MBA schools used to require that you have worked in industry for about a decade before even applying; now it seems like most schools offer a management track without necessarily having any experience. The result is a self-selection for people who want to manage without necessarily having a concrete understanding of what they are managing.
Earlier quoted context omitted.
> there are actually lots of people who think that ORMs were a mistake and lots of people who think that using them is always a no-brainer. This doesn’t mean that both groups are right though.
I would argue that neither group is right. Both are myopic and only see things from a limited perspective.
This is such a tired take. It's part of a steady stream of commentary that reads something like "non-engineering-role X is bullshit." Here, we see engineers reduce the contributions of such common roles as: Product Manger, Program/Project Manager, Scrum Master, Marketer, CEO, etc., as fungible or run by the biggest boogeyman of all, the dreaded MBA. These arguments most typically result from not an inability, but an…
Instead of an ad-hominem attack against a strawman, can you actually address the points made by these people you're labeling as professionally immature and unwilling to understand these non-engineering roles? Can you actually provide anything that illustrates your point at all? Just calling us all immature children does nothing to change my mind; it only makes me think you're defensive because you know deep down that…
And sorry, unlike a program you’re writing, you don’t have any say in how the logic works (or doesn’t). The rules are set and you’re in the system. You might be able to find some variations in other companies.
Earlier quoted context omitted.
My best experiences with managers were ones that did that. Just let me work and help me if I need it. I'll reach out if I do.
That's not a manager, that's a secretary, which is my point. Engineering groups don't need managers, they need lead engineers and clerical staff, similar to a group of lawyers or doctors.
The point of my question is to make people stop and think about the chesterton's fence of why is that position there. For example your janitor example. Extremely well defined position. Most people do not want it (including yourself).
Earlier quoted context omitted.
The MBA is for people who want to skip right to "being in charge" without having to learn how to actually do anything first. The scary part is, if you went to a selective enough school, it kinda works. The Ivy League undergrad -> elite MBA -> management consulting -> C-suite pipeline is especially frightening.
My issue with the converse is that being a good engineer and understanding how to do things doesn't necessarily make you a good manager. I've worked in plenty of orgs where they don't treat leadership as a skill unto itself and assume just because you're a good engineer, you'll be good at managing an engineering team.
The worst in my opinion is finance-- it's like driving using the rear view mirror. No business has ever succeeded or failed because their accounting was really tip top.
Earlier quoted context omitted.
My issue with the converse is that being a good engineer and understanding how to do things doesn't necessarily make you a good manager. I've worked in plenty of orgs where they don't treat leadership as a skill unto itself and assume just because you're a good engineer, you'll be good at managing an engineering team.
I think if you have to pick a base for leadership, doing the thing you're managing other people in is probably the best. The worst in my opinion is finance-- it's like driving using the rear view mirror. No business has ever succeeded or failed because their accounting was really tip top.
People would laugh at the idea of a good leader being thrust into a SWE role based solely on their leadership skills. Yet we often think transitioning from a SWE to a leader is just picked up. I'm asserting that they are different skillsets. Will being a good developer help lead a team of SWE? Absolutely, but that alone doesn't provide the requisite knowledge and skills to perform a manager role, but we often think that's the bulk of what's necessary.