Edit: inter- not intra-
Mistakes I made as an engineer, but had to become a manager to see
51–60 of 109 posts
Re: Mistakes I made as an engineer, but had to become a manager to see
#52Re: Mistakes I made as an engineer, but had to become a manager to see
#53Earlier 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.
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…
For most businesses, still being around and profitable is an implicit, if not stated goal.
Re: Mistakes I made as an engineer, but had to become a manager to see
#54Why all the stuff about hiring? As an engineer, hiring isn't even your job. You may end up participating in the interview process and offering feedback, but ultimately you're not making the hiring decisions unless you're a manager anyway, so ignoring hiring isn't really a mistake you make as an engineer.
Re: Mistakes I made as an engineer, but had to become a manager to see
#55Re: Mistakes I made as an engineer, but had to become a manager to see
#56A more interesting question is, are these actually mistakes or just part of the journey from a junior engineer to manager? People problems and building relationships with your co-workers are things that I have realized are important over the last couple of years (Haven't done any hiring yet). In saying that, I'm not sure it would have been wise to focus on these things earlier than I did. There were too many other th…
> 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 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. Please refrain from needless refactoring not accounted for in your sprint work.
Re: Mistakes I made as an engineer, but had to become a manager to see
#57I think of all of these problems as being the managers problem and not the engineers problems. Maybe a better title is "10X Manager tasks, I wasn't aware of as an engineer". To help engineers maximize their career I tell Junior/Level 1 engineers focus on becoming net productive, meaning providing more value than you take. Midlevel/Level 2 engineers should becoming independent and solving lot's of their problems on th…
> I tell Junior/Level 1 engineers focus on becoming net productive, meaning providing more value than you take. This feels like it could backfire, by encouraging people to ask less questions. It's easy to provide more value than you take if you never take.
Re: Mistakes I made as an engineer, but had to become a manager to see
#58Re: Mistakes I made as an engineer, but had to become a manager to see
#59Earlier quoted context omitted.
The take is your salary, in my experience. I'm not sure what you mean about questions.
It seems obvious - if you scare a junior engineer they will sit in their office and build an abomination to avoid asking a simple question that could be answered in 3 minutes. It's a real thing and it doesn't help the junior engineer or the business.
Re: Mistakes I made as an engineer, but had to become a manager to see
#60Earlier 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.
> 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.…