Looking forward to the sequel: "Mistakes I made as a manager, but had to go back to engineering to see"
Mistakes I made as an engineer, but had to become a manager to see
91–100 of 109 posts
Re: Mistakes I made as an engineer, but had to become a manager to see
#92Earlier quoted context omitted.
> Code should always be focused on; it should be constantly rewritten, Your PO: I've noticed you've been rewriting a lot of methods in the code base. Can you please tell me which stories on the board this sprint those rewrites are attached to? We need to focus on sprint work, and as we established as a team last PI Planning meeting, the emphasis this quarter is on shipping features from the Customer Experience epic.…
It's funny people tolerate this kind of stuff. I'd be out the door immediately, and I have been before. You don't have to work for companies that do this kind of insanity.
Let me tell you, it’s so frustrating to having to catch engineers veering from one fun thing to the next, it feels like being a kindergartener constantly trying to prevent a handful of kids from killing themselves with the next fucking thing they see.
There is a reason we’ve decided what to work on. We have customers and a runway to consider, and targets we promised investors to reach. I also would like to work on fun stuff instead of fixing those bugs! That seems to be something you only understand later in your career though.
Re: Mistakes I made as an engineer, but had to become a manager to see
#93Earlier quoted context omitted.
Then again, if I had been given a cent every time I had to tell a member of my team "please, do the job we pay you for before doing the thing you find fun but have no actual business value" I would be a rich man by now.
A programming manager told me once that his job consisted of, every day, visiting every programmer on the team, and asking them about what they were working on. He'd then gently nudge them back onto what they were supposed to be working on.
It must suck having to work with people who need to be “nudged” to do their jobs, every day.
Re: Mistakes I made as an engineer, but had to become a manager to see
#94Earlier quoted context omitted.
> Focusing on code is probably a good thing when you are a junior. I've seen what happens when people stop focusing on code. It's a timebomb for institutions. Code should always be focused on; it should be constantly rewritten, taking the lessons into account from previous iterations.
Your opinion is not uncommon, but alas it is wrong (in most cases.) In most businesses, code is a tool to get to the desired outcome, not the desired outcome itself. Like most tools it is most valuable when being used to create the outcome, not being endlessly perfected. Good enough is good enough. Perfect is a waste. Again, context matters. The code that runs a million times a day is more important than the report t…
It's just a very junior opinion in my mind. I haven't really cared deeply about re-writing code or different ways of doing the same thing for a number of years, and I think of it more as maturing, even though some junior could probably come in and make the same amount as me because my work history and connections are weak or volatile.
Unless you're operating at a particular scale or with specific constraints, the main important thing is passably meeting acceptance criteria accurately enough to check a box and say you did it in some period of time that you probably agreed to. That's all the business cares about, therefore that's my job. I've never once met a customer/user in my course of employment, therefore they only matter as much as the company defines and empowers my success as closely tied to it. I'd love a job like that, it would be a change, but that seems to be scarce, and until then I'll just chip away on this dashboard only imagining at a distance what the impact of my work could be.
Re: Mistakes I made as an engineer, but had to become a manager to see
#95Earlier quoted context omitted.
> Focusing on code is probably a good thing when you are a junior. I've seen what happens when people stop focusing on code. It's a timebomb for institutions. Code should always be focused on; it should be constantly rewritten, taking the lessons into account from previous iterations.
Your opinion is not uncommon, but alas it is wrong (in most cases.) In most businesses, code is a tool to get to the desired outcome, not the desired outcome itself. Like most tools it is most valuable when being used to create the outcome, not being endlessly perfected. Good enough is good enough. Perfect is a waste. Again, context matters. The code that runs a million times a day is more important than the report t…
The code is not always about the code but mindset, culture and attitude.
Usually what happens is the attitude carries throughout.
E.g. when developers start saying that optimisations don't matter they get into the habit of never doing it until it breaks. At that point it's too costly to fix and spirals out of control.
Why not just get into the good habit of writing good code that might cost a bit more upfront but will settle down and be a positive impact going forward?
Is good code just for the outcome?
Your statement neglects that developers are humans. If you have a new hire and they look at the code and have to spend forever understanding it - is that not a cost? Or perhaps they'd look for the next job just based on how much it annoys them.
It's the same as not cleaning your house or office. The desk is just a tool so you can get your outcome. Let's leave it right? Let's also not mind if rats watch you do your work!
Being a perfectionist is bad and for that I agree but that's not code specific. I don't get the concern. Surely people also spend too much time on things like presentations that might not impact the outcome. It's all just human nature and not developer specific.
Re: Mistakes I made as an engineer, but had to become a manager to see
#96Earlier quoted context omitted.
Your opinion is not uncommon, but alas it is wrong (in most cases.) In most businesses, code is a tool to get to the desired outcome, not the desired outcome itself. Like most tools it is most valuable when being used to create the outcome, not being endlessly perfected. Good enough is good enough. Perfect is a waste. Again, context matters. The code that runs a million times a day is more important than the report t…
The code is not always about the code but mindset, culture and attitude. Usually what happens is the attitude carries throughout. E.g. when developers start saying that optimisations don't matter they get into the habit of never doing it until it breaks. At that point it's too costly to fix and spirals out of control. Why not just get into the good habit of writing good code that might cost a bit more upfront but wil…
I think the key point was this line;
>> it should be constantly rewritten
There's nothing wrong with writing good code. Ideally it should be good the first time, not the 3rd or 4th time. If you are writing code in a well architected system, using consistent techniques and styling, then it's not a mess, but it doesn't need to be perfect.Good enough implies good.
To follow your cleaning analogy, there's some cleaning to do regularly (maintainence etc) but you don't raze the building and rebuild every 5 years just because a new kind of brick comes out.
Re: Mistakes I made as an engineer, but had to become a manager to see
#97Earlier quoted context omitted.
The code is not always about the code but mindset, culture and attitude. Usually what happens is the attitude carries throughout. E.g. when developers start saying that optimisations don't matter they get into the habit of never doing it until it breaks. At that point it's too costly to fix and spirals out of control. Why not just get into the good habit of writing good code that might cost a bit more upfront but wil…
I think the key point was this line; >> it should be constantly rewritten There's nothing wrong with writing good code. Ideally it should be good the first time, not the 3rd or 4th time. If you are writing code in a well architected system, using consistent techniques and styling, then it's not a mess, but it doesn't need to be perfect.Good enough implies good. To follow your cleaning analogy, there's some cleaning t…
>> you don't raze the building and rebuild every 5 years just because a new kind of brick comes out.
Say those organisations that have brand new offices all the time and move staff into it? Say those people that do home renovations? It does happen. For whatever reason. And no 1 says it has be rewritten completely. So the same applies. Whether you've upgraded your PC, replaced your monitor, your clothes or anything like that you don't "need to" to do whatever task but you do.
I get back to the point of why single out developers for any of it?
I'm not defending developers in particular. It's just human nature. Getting a new logo that looks 90% the same for millions is likely 100% worse than rewriting some part of the code.
What's the justification to rebrand, get a new logo, new name, change the font a little, etc? There's no need to get a new website either is there? Do you 1st go out and get data that a new website will attract more customers before doing it?
Re: Mistakes I made as an engineer, but had to become a manager to see
#98Earlier quoted context omitted.
You need focus on other parts though, you can have the most beautiful codebase with the most efficient algorithms, the highest coverage and the most extensible yet simple and elegant architecture but if you're not solving the business problems someone's going to eat your lunch with a hacked together excel sheet. The other view I have on this is around trust. Do I need to "focus" on the code if I have people on the te…
> businesses have different goals and its focus should be on achieving those For most businesses, still being around and profitable is an implicit, if not stated goal.
Yes, this is different than "have a clean codebase".
I'd say that companies have more specific goals than making money - it's usually making money in a particular field. There are then strategic goals, set semi regularly by the leadership, which are the level I'm generally talking about.
You should have that concept of making money in mind though, as it helps guide what to prioritise. I've seen engineers spend thousands and thousands of pounds of their time (more if you consider the opportunity cost) to lower some bill by under a hundred a month - a large upfront cost with years before it'll pay back.
Re: Mistakes I made as an engineer, but had to become a manager to see
#99Earlier quoted context omitted.
A programming manager told me once that his job consisted of, every day, visiting every programmer on the team, and asking them about what they were working on. He'd then gently nudge them back onto what they were supposed to be working on.
It must suck having to work with people who need to be “nudged” to do their jobs, every day.
It’s very much part of the job at any organisation.
At any level, you have in front of you people with a lot on their plate, competing interests and different prioritisation abilities and it’s your role as a manager to give them enough information for them to prioritise adequately.
It might be straightforwardly reminding a developer that right now we really have to ship this feature or it might be subtly making a manager understand than it would be in their interest in the upcoming reorg if they were seen as a strong asset in solving a specific issue even it’s not directly part of their KPI and explicite goals.
Re: Mistakes I made as an engineer, but had to become a manager to see
#100Good, concise memo.
Notably, none of these top mistakes are technical mistakes.
The implication seems to be that the person in the manager’s role is critical.
I mean, if they don’t even let the team know they’re bringing in another person to the team, then good luck.