81–90 of 228 posts
I've struggled with this recently. I feel like advancement requires getting credit for the idea itself, otherwise you're just implementing other people's designs. But ideating (will actually good ideas) is pretty tough.
Earlier quoted context omitted.
But that's kinda the beauty of it. If you get laid off from one of these places the next place doesn't know that you took 300k home to do jack, all they know is you worked for a super prestigious company for 10 years and you can plausibly make up the rest about what you actually did there.
> you can plausibly make up the rest about what you actually did there. I would never do this, and if you would do this I wouldn't want to work with you. Maybe I'm a sucker, but I sleep alright.
That works really well if you're a contractor/job-hopper and can actually walk away. Otherwise, someone who doesn't understand the code will be asked to make modifications and you, the original author, will be called back in to rescue the thing when it has turned into a dilapidated mess.
The problem the OP is having is not failing to please his boss, but working for a boss that isn't technical and has no idea what is happening. Those bosses are generally terrible for your career and if you have one, you should just quit.
> this fact is a trap for competent but unagentic engineers Is “unagentic engineer” a euphemism for human/not-AI? Unfortunately for companies whose engineers work this way, they’re on a one-way trip to expensive cloud bills, data breaches, and frustrated customers. A good amount of that “never done,” work is: - Patching security vulnerabilities - Fixing mistakes made due to lack of planning/testing - reducing costs d…
Of course you're right. But that's the point of the article. Companies, departments and teams operate on a spectrum from reality-centred to status-centred. In a reality-centred culture all the things you mentioned matter. Reality-centred management understands this, manages it, and rewards it. Reality-centred cultures are better at medium/long-term planning and at handling issues rationally. In a status-centred cultu…
> Status cultures don't necessarily implode.
True! And they're often not a great place for developers to work (unless you want to join in and become a manager and leave development behind).
Earlier quoted context omitted.
But that's kinda the beauty of it. If you get laid off from one of these places the next place doesn't know that you took 300k home to do jack, all they know is you worked for a super prestigious company for 10 years and you can plausibly make up the rest about what you actually did there.
> you can plausibly make up the rest about what you actually did there. I would never do this, and if you would do this I wouldn't want to work with you. Maybe I'm a sucker, but I sleep alright.
I don't disagree with the article, but after working in big tech, two HN startups, a couple unicorns and others, in two continents, I don't really find this too actionable. In the last ten years (and even in the 20-people HN startups), the day to day work of engineers has become so incredibly specialised and divorced from the needs of decision-makers and the customers that there is almost nothing I can do to influenc…
So you’re saying the only time you were satisfied with your work is when you took the role of a product manager who stepped in between the engineers and the rest of the company and had all their contributions filtered through your ego? Yea, that sounds pretty satisfying…
Not sure how important delivery was to the company, but it's nice when your personal goals match those of the company.
Earlier quoted context omitted.
> you can plausibly make up the rest about what you actually did there. I would never do this, and if you would do this I wouldn't want to work with you. Maybe I'm a sucker, but I sleep alright.
It's not like the parent would have accomplished nothing in the 10 years. I think they are just talking about framing it in language palatable to the interviewer across the table.
> In large tech companies, this fact is a trap for competent but unagentic engineers. They see an infinite queue of tasks that they’re capable of doing, and they start delivering a stream of marginal improvements to a particular subsystem. From their perspective, it feels like they’re crushing it. After all, they’re putting out work at their top speed: no downtime, no waiting on other teams. But they’re not doing the…
The trope that ICs are incapable of understanding and balancing business interests against their wishlist of work items is just a cope that incompetent management chains tell themselves, because they need to believe that there’s something that they’re providing to the team that it won’t get elsewhere. The fact of the matter is that understanding your project in depth does not cause myopia. Big tech is fat with managers who provide absolutely nothing to their teams, other than filling a management req which was conjured up out of thin air. The best teams have technical leadership and work relatively autonomously.
While I generally agree with this, I’d add one thing: to understand what your managers want, you really need to understand the business. At the highest level, how does your company make money, or at least think it’s going to make money? What other things does the company value? It’s surprising how often I find developers who don’t know, either because they aren’t curious, are too busy to learn, or (surprisingly commo…
I think it's fair to think of yourself as a carpenter. Devs talk a lot about this being a craft. You build to spec but point out problems when the spec is not possible or silly. It's the business's jobs to know how to explain the business and their needs. If they can't explain it, they probably don't understand it. If they do understand it but can't explain it, they probably need to work on their soft skills. You're…
Is this sentiment the reason why a lot of "engineers" will provide terrible quality in code / tests (lack thereof) / documentation / etc.? If all that matters that someone at the top sees it and is happy about it at this specific moment in time, why bother writing code that can last and doesn't leave behind an absolute unmaintainable ball of mud? We don't need gold plating and yet billions could be saved by having in…
More and more you run into people who simply don't care about craft and quality. I can already hear the chorus of people that will scream "I'm not paid enough to care" or "it's just a job for some people", and those things are often true; but, nonetheless, people used to take much greater care in their craft even when they were paid less. There was a sense that, even if it was just a job, it should be done well. A ce…
I think people used to care more when there were less BS involved in the software development process. Nowadays you get: scrum masters, product managers, product owners, engineering managers, daily standups, refinements, "getting things done", "shipping impact", "10x engineer", "red-carpet engineers from FAANG", and CEOs that want X or Y for yesterday. So, yeah, in that kind of environment, I couldn't care less about anything. I just do it for the money.
All my craftsmanship goes into my personal projects.