Mistakes I made as an engineer, but had to become a manager to see
developing.dev
developing.dev
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 things I needed to learn. Focusing on code is probably a good thing when you are a junior. Leave the higher level problems for a little later down the line.
I've thought about hiring and am interested in doing it and getting good at it because I see that it's very high value, but I don't think it's the right time. There are more important skills and behaviours for me to develop right now.
I try to focus on things 1 or 2 steps ahead of where I currently am, no more. Otherwise it's too far away from reality.
Agreed that junior engineers should focus on code with most time (but not all). If you focus on the low hanging fruit outside of code you can have more impact overall without too much time investment there.
If you're a junior by definition you don't understand how to operate outside of code very well or at all, and you are still learning about operating in code.
Trying to learn multiple skills at the same time is always tricky. Most people struggle to get good at one thing at a time, let alone multiple.
Unless you are already becoming a more independent coder (I.e. 1-2 steps behind this point), stacking non-coding skills on top of that seems like a bad decision unless you are a very quick learner and can juggle multiple new skills.
I've seen so many misguided proactive attempts waste everyones time, create noise, break focus.
If there's low hanging fruit, and you're not in a dysfunctional environment, it will probably give you diarrhea.
For example, you say you got promoted from junior on "sheer volume of work" which is contradictory to focusing on "low hanging fruit outside of code" without "too much time investment".
https://twitter.com/ryanlpeterman/status/1623745298920255489
If a junior knew how to leverage "low hanging fruit outside of code" without "too much time investment" they would basically by definition not be a junior anymore, so I see this as a bit tautological. It seems like wishful thinking rather than something based on reality.
---
I also noticed on your Linkedin that you made Staff in 5yrs, which is extremely fast and likely means you are an exceptional engineer. I'm aiming for a similar trajectory, but I noticed a little while ago (Before I was even working as an eng professionally) that giving advice to people was very difficult. How do you explain that you just "get" things?
For example, my manager told me that he liked the fact that he only had to give me feedback once and then I would implement it. He also noted that weaknesses from my previous performance review became strengths in the next one. This is with only ~3 months between reviews as well.
There are a number of similar behaviour my managers have noted that I believe have been and will continue to be critical for my growth, but how do you teach those kind of things to someone who doesn't operate like that? I don't think you can.
As a mentor, you need to understand that you cannot get everyone to have steller results. Your goal is to provide a lift with your advice so that they are in a better place than they would have been without you.
This became clear to me when I provided the same coaching to two engineers. One grew at a breakneck pace while the other grew more slowly.
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.
The other view I have on this is around trust. Do I need to "focus" on the code if I have people on the team whose job that is? At what level? At a more senior position I shouldn't be looking into the small parts, the more effective use of time is ensuring the larger components are going in the right direction and/or we're not spending time on parts expected to be unused due to a strategic shift coming in. Maybe it's more important to focus on documentation right now, or perhaps it's important to get people working on different things because everyone's fixed on their small problem and not understanding the integration issues we have.
Code is important, but it's important for a reason. Create your artistically beautiful perfect codebase when that's the goal perhaps as a personal project, but businesses have different goals and its focus should be on achieving those.
"Focus" or attention I guess, is a limited resource. Spending it on one thing is not spending it on another. Balance is needed - 0% interest in the code is a big issue, but so is 100%.
For most businesses, still being around and profitable is an implicit, if not stated goal.
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.
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.
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.
I am a professional. I do not need to be reminded about what I have promised to do. Maybe that's why I'm paid good money to do what I do.
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.
It's gonna get much, much harder to find the kind of laid-back company you favor, where you can work on whichever part of the code base you want, when you want. There's much less money sloshing around, and what's there needs to be spent on priority items.
Doing what the company needs done can also mean not taking orders from your PO. Depending on your situation, that could manifest as ignoring them, working around them, convincing them it was all their idea, directly challenging them, or going over their head. Skullduggery. Ass-kissing if necessary. Be a hero or a martyr in the end, but at least end each day with a clear conscience.
None of that being my preference, given the choice. All I expect from a PO is a collaborative relationship where I'm treated as an equal and not some member of the worker underclass who's just there to close tickets.
When the project collapses under its own weight as a consequence of the PO's own choices, is the PO going to take the blame? Is the PO going to help when production goes down? Will they working overtime to fix things? Who suffers? The PO? Not so much.
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 that runs once a year.
Equally, a well architected system will need to balance the needs of any different users, with potentially different goals. In other words, lots of compromises are necessary. The code reflects those compromises. There's a balance, good enough is good enough, time to move on.
I will say though that your attitude is not unique. I have come across many employees, and even one-man-companies that focus exclusively on the code. Often (not always) because code offers the programmer complete control. Unlike co-worker, bosses, employees or customers, it is not messy - perfection is achievable. Dealing with people is messy. Other tasks (like marketing) are vague or immeasurable. Code is simple, objective, doesn't talk back.
Certainly coding well offers an emotional reward. It's a clean game with fixed rules, and performance can be objectively assessed. For many of us it's a safe haven in a very messy world. But unfortunately it's usually just a tool, not the outcome. Someone in the messy outside world has to pay money - and that adds 10x more messiness, which someone has to deal with.
Progressing from junior to senior programmer, then into a business space (like analyst or architect) is really just the understanding, and skills, that come with balancing that messiness with the desire to write code.
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.
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.
>> 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.
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?
I do feel even when scoping large projects that it is difficult to hold on to all of the pieces. I split it into chunks I can reason about and then (sometimes fearfully) return to the bigger picture. By the end of the project I can see all of the mistakes I made fumbling in the dark, but I’m not sure I could have managed more at the time that I did it.
I also feel this way about socializing at work. There’s something maslowian about it, when you are uncertain if you’re going to make it, it feels perilous to join socials. They’ll never fire me for not being social enough, is the message that fires through my brain at least. Though I’m sure social anxiety plays a role here as well.
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 their own. As they approach the top of this level start getting involved in architecture and design.
Senior/level 3 should focus on helping the team to be successful as a whole, mentoring, producing value quickly when needed, and should be able to solve most problems independently including starting a project from scratch or solving complicated performance/technical problems.
Hiring and people problems are engineering manager problems.
Getting to know your coworkers is a good career move for anyone.
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.
It's a real thing and it doesn't help the junior engineer or the business.
Unless you work for free, you are taking.
It's important to explain this kind of thing though, and guide people to when it is and isn't appropriate to ask for help.
I get aggravated when juniors ask me questions right off the bat without researching. It's because they are lazy and want a quick answer and of course submitting to this just leads to more questions more often, which leads to me getting less work done.
This is also bad for them because they don't learn how to figure it out for themselves through google / code research / debugging / etc. Learning how to learn is the essence of growing in the field. I've been dumped into codebases I didn't know before with little to no help, and it sucks; but you certainly learn how to learn.
I think spinning your wheels for a month is the opposite of that. If it takes someone a month to not figure something out, that would be a red flag for me.
A Negative One -- You're a drain on the team and other people have to cover for you. Not so good if you're in space with limited resources.
A Zero -- You're capable and have your own shit covered. Most people in space are a zero.
A Plus One -- You're contributing to the success of the mission and helping others succeed as well.
He talks about arriving on the international space station and just making sure that he was a zero. And taking over as mission commander and on the first couple days, just trying to be a zero because the plus one fancy heroics can come later.
Funny how that works.
If you act in the interests of the business, the leadership of a company will (usually, but not always) reward you for your service to the business. Whether or not this is something you "should" do is up to you, in my opinion. As an IC, you can't make me care about a business. I'm there to get paid and gain career experience, the latter of which sometimes improves the business and sometimes not.
Fact of the matter is that there are a whole lot of people that aren’t necessarily into that, but are great individual contributors, and should just be left to their devices as long as they’re a positive contribution, not just to your codebase, but towards your organisation as a whole.
Edit: Notice I'm not saying this is bad, this is just natural bias towards what benefits yourself. It is just so interesting to see how people who experience that bias shift now sees it as some kind of "insight" rather than just their own bias.
When I was an engineer I used to think this, but now that I'm a manager, I'm not so sure...
If you want to maximize your impact, and make the biggest contribution possible to your company, then yeah, sure, it's absolutely the best use of your time.
But a lot of engineers are trying to contribute to the company in ways that are mutually beneficial to them, and the way that a lot of companies set up interviewing is not. It's a thankless job that takes time away from things that can actually be put a performance review, so only the more selfless engineers will do it.
The article reads a bit like manager-to-engineer advice, but the advice to managers would be: keep track of who is helping out with interviewing, and who is interviewing well, and reward them for it.
Uhhh... ok.
Moving to management is not some inherently transcendental ascendancy into higher enlightenment and purpose, it's a change in responsibilities and goals. It's not for everyone, there are plenty capable of being managers and fully understand the roles but don't want to become them. This article reads like some journey to enlightenment that I think all but a junior engineer would read as pretty naive.
> Over the years, I’ve seen several engineers on other teams become less productive and then leave the company because they weren’t happy. Each time, I didn’t pay attention and stayed focused on my projects.
Yeah, most companies have a very very difficult time understanding the deep intricate knowledge-worker problems their expert knowledge-workers are deeply entailed into & care omg about. Only like 20% of these companies/managers even bother to figure out what the real intricacies are. It's fucked up. Yeah the engineers are distressed. But this is like >80% a problem of orgs not actually knowing wtf the situations really are. I've seen plenty of scrum teams have retro after retro where we identify real challenges, where we do good retroes, but as an engineer, our power to make anyone care at all or give a shit is limited. We can try to talk to someone we want to stay, but 9 times of out of 10, we have nothing to offer, no way to help. Trying to figure out how to make the org responsive or understanding is the challenge.
There is some good advice too, for engineers: Get to know your coworkers. Yeah. Do it. Don't just leave it to the managers & org. Culture never is top down, it's always a net-product. Links have to be forged at all levels. I think this is a huge challenge especially in the new hybrid/remote world.
But importance of some of these things changes as you evolve and gain seniority.
Definitely it is a mistake for a junior developer to obsess over hiring people. This is something you should start paying more attention somewhere around when you become senior dev. As a manager/tech lead I really need help to make hiring decisions but for that help to be valuable it must come from somebody with enough experience and also understanding of the project.
People problems are also best left to your seniors if you are a junior dev. You should pretty much be in observation/learning mode. Be respectful and kind to other people and stay away from drama. Don't try to resolve problems for others -- if you don't yet have experience you are more likely to cause more trouble than solve the problem.
On the other hand getting to know other people is always important, regardless of your level.
Why would you care or think much about hiring as an engineer? You probably would not even be asked to attend interviews. If you vibe with the company and share the vision okay but this is not a matter of perspective.
Why would you NOT be interested in getting to know your coworkers? Why NOT have interesting conversation or a good laugh at lunch? This has nothing to do with beeing an engineer or manager either.
Obsession with code maybe more important for an engineer. Does not mean it was „wrong“.
Because you will eventually have to work with these people and their problems will become your problems, especially if you are seen by management as someone who can fix those issues. Young adults tend to group together and cling to co-workers because they haven't learned to cope with life independently of the situation they find themselves in. I generally like my co-workers, but I have no inclination to spend any independent time with them. It's not that I don't want to make friends at work, it's that I don't want a condition of my friendship to be tied to the workplace. If I'm not seeking that person independently now, then I'm probably not going to do it later after switching jobs.
I've made friends at previous companies who I still see regularly. Not a ton, but some. I have dinner plans with one of them this coming Monday.
Not with that attitude you won't, sure.
But engineers who do care about hiring, take the training seriously, and make themselves available to participate in interview loops, can make a big difference to the team with which they are surrounded.
What about something like hard business tradeoffs? You can never produce the perfect system if it will take so much effort that the system never ships. Your security posture will never be perfect, it just better be good enough to keep you out of the headlines, etc.
But it's the direction the industry is moving in.
True. But somewhat understated / misleading. The difference is, people problems are 10x harder than technology problems. Technology is finite and relatively predictable. People? We're emotional and have lives outside work that of often come to the office. If technology was as erratic as people we'd all be making therapist money ;)
Technology is easy.
People are hard.
Here it is, in case anyone was looking for a good reason to care about people's happiness
If you suspect someone is a 10x engineer, throw them your hardest, seemingly impossible problems, where they can stretch their legs and spend long periods of time in a flow state solving and thinking about the problem and writing large amounts of code with little to block them.
The quickest way to waste your 10x engineer’s potential is throwing them lots of little, bite size problems, that require frequent interruptions and little concentration. They will do this work just fine but they’ll never end up producing a cathedral of code that leaves you in awe.
I originally went to the comments expecting a big flurry of people trashing this saying that the author was really late to the game, but to my surprise this line of thinking is incredibly common here. And it appears that some people are actively pushing back on this. :(
Edit: inter- not intra-
Growing a team will make work for the whole team. And making work for the whole team will produce output from the whole team. And that will lead to more legacy product faster than keeping a lean team.
Very well could be the right choice, but clearly has limits.
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.
This is such a non-article.
I would go even further and say, "all technical problems are really people problems."
Why 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.
I've met plenty of engineers (anecdotally, not a majority, but enough that it's a clear pattern, and strongly correlated with how junior they are) who lump soft skills into a single category represented by broad labels like "charisma" or "schmoozing" or "eloquence". But it's really a very big category of practicable skills.
Things like navigating an org, knowing how to make asks that have a high % of being accepted, writing things for a specific audience and keeping conversations on track are all very important "soft skills" that are completely hidden by the "soft skills" label.
Trying to munge these all together under one label seems counterfactual. Certainly, they're very different sets of skills: the former are social, the latter overtly political.
You are also right that a lot of it can only be approximately taught, because the process of internalizing the skills has a lot to do with figuring out how to work with your own personality.
The more trustworthy and time-efficient way is from coworkers/ mentors/ friends.
Thats it, thats the whole post.
I have two things I’d like to add:
- A mistake you are willing to learn from is not just a mistake. It’s a lesson. It can yield as much reward as you’d like, depending on the effort you spend to reflect and change things.
- Most advice like this, when it comes to things someone learned after moving up a rank in some org chart, is not as portable as we might like to think. Teams are always different shapes. In the end, if business functions are being executed well and if the people doing those things are paid well and happy to stick around, then you’ll find over time it really just doesn’t matter what the process looks like or the permutations of productivity-fu you put on it.
Anyhow, this is a nice article. I enjoy reading stories about career progression like this. I wish I had read more twenty years ago to learn this stuff, I made a lot of “mistakes” then.
Keep it up!