131–140 of 216 posts
> The easiest way is to actively work to make a high-profile project successful. This is more or less what you ought to be doing anyway, just as part of your ordinary job this involves you getting a chance to work on it in the first place. why would you in particular be getting to work on those projects? you have to first align yourself with VP and become their bitch. someone who they can trust. you should always fol…
I like this truth. Talent is mostly a zero-sum game against your time. You can’t be great at playing politics unless you have the time in your role to focus on that, and software engineers are paid to be code mules.
A lot of the frustration I typically hear in this camp is something like “well I shipped a huge refactor that cleaned up all the code, why does no one appreciate that?” One particular interaction that got me thinking was a few years ago listening to an acquaintance telling me how he spent months meticulously cleaning up the data pipeline and making it perfect, and how no one appreciated this work. Like, as an enginee…
Agreed. I have always thought about refactoring as developer responsibility. If it needs to be done do it while working on real feature and update deadlines accordingly. That way it is way easier to justify it because you talk about it only with technical people. In long run it makes code base way better. This results in easier maintenance and faster development of new features.
is true but may be irrelevant. Your hierarchy may have the correct understanding: that this better code base will be irrelevant because the company would then be out of business (because you spent your hours on the wrong obsession). Or will be irrelevant because this product line will change to use an entirely different protocol. Or this engineering group will be working on a different product and different code base. Etc.
I feel that it's fine to do small refactors when they help YOU understand the issue you are working on. Anything beyond that does NOT go without saying. Anything beyond that may well be hours you are wasting on a non-existent issue. In theory worthwhile but the company / your engineering group does not live in theory
Now, ideally, when you discuss refactoring with your manager, they have an understanding they can share - so you can understand. And this will make it easier for the individual contributor to work this way and not that way.
A lot of the frustration I typically hear in this camp is something like “well I shipped a huge refactor that cleaned up all the code, why does no one appreciate that?” One particular interaction that got me thinking was a few years ago listening to an acquaintance telling me how he spent months meticulously cleaning up the data pipeline and making it perfect, and how no one appreciated this work. Like, as an enginee…
If your managers think that, and don't understand the value of refactors, you've already lost. You can try explaining it to them, but if this is how they perceive that type of work, it's a sign that you're working at a company that doesn't understand software engineering.
Of course, new features have to be built, and bugs have to be fixed. Those are always priorities. But refactors are just as important for keeping the software in a maintainable state, precisely because they enable new features to be built faster, more efficiently, and in a more robust way.
IMO the best you can do: - Ship often to prod (don’t do theoretical work). - Ship wins (as defined by generally acceptable metrics.) - Have someone in management or a PM who is good at selling your wins Even here, though, you will run into problems. There is always a new VP or leader looking to make an impact. Because you maintain the current systems your team is engaging in WrongThink and new VP has shiny new RightT…
> Ship often to prod (don’t do theoretical work). > New VP can make promises of future, theoretical riches that you can’t compete with Why is theoretical work advantageous to the VP when he does it but disadvantageous to you when you do it?
> The easiest way is to actively work to make a high-profile project successful. This is more or less what you ought to be doing anyway, just as part of your ordinary job this involves you getting a chance to work on it in the first place. why would you in particular be getting to work on those projects? you have to first align yourself with VP and become their bitch. someone who they can trust. you should always fol…
You should consider finding a career coach, professional therapist. This level of pessimism can't be healthy.
Earlier quoted context omitted.
> Ship often to prod (don’t do theoretical work). > New VP can make promises of future, theoretical riches that you can’t compete with Why is theoretical work advantageous to the VP when he does it but disadvantageous to you when you do it?
because thats their job description and not yours
That's not an issue of losing political battles, that's an issue of you getting fired very rapidly.
This advice is entirely premised on the idea that you can choose to do theoretical work if you want to, but that it will be a bad idea.
Earlier quoted context omitted.
Can you demonstrate, or show how that would work (serious question)
Sure. Let's take that idea: > reduce vectors for bugs (which are always based on misunderstandings) Is that really impossible to measure? (For cheap that is. Cheap measure, cheap estimate, cheap confidence). Is that really impossible to monitor? Grab a random sample of 100 fixed bugs in the past 2 years. Go through them one by one. How many do you really seriously think would have been avoided? If it's not much more…
Although to be clear, the estimates will "this is where we think that we will be saving money"
followed by a review (in 12 months time) that will be "this is what we think is the result, but it will include improvements from other vectors, such as better communication from business"
I shouldn't need to promote and sell my ideas to anyone. I'm paid to provide my skills and ideas, and if the people around me don't find them valuable, that's on them. I'd rather move on to places that do value them, than engage in politics.
> Some program of work will be funded whether you do this or not. However, if you don’t do this, you have no control over what that program is.
Why would I want control over that?
I share my technical opinion, and it's up to the team or higher-ups to decide which direction to go in. Besides, who says that my opinion is correct, anyway? It should be held to the same level of scrutiny as anyone else's.
This idea that engineers should constantly push for their ideas to be implemented, and to take on projects with the highest visibility, is incredibly toxic. It leads to a culture of obsession over KPIs, OKRs, and other pointless metrics, where people prioritize work that looks good on their record when it's time for a promotion, rather than doing work that has a positive impact on the product, no matter how small. It's all a theater, and I refuse to have any part in it.
IMO the best you can do: - Ship often to prod (don’t do theoretical work). - Ship wins (as defined by generally acceptable metrics.) - Have someone in management or a PM who is good at selling your wins Even here, though, you will run into problems. There is always a new VP or leader looking to make an impact. Because you maintain the current systems your team is engaging in WrongThink and new VP has shiny new RightT…
> Ship often to prod (don’t do theoretical work). > New VP can make promises of future, theoretical riches that you can’t compete with Why is theoretical work advantageous to the VP when he does it but disadvantageous to you when you do it?