Mistakes I made as an engineer, but had to become a manager to see(developing.dev)
developing.dev
Mistakes I made as an engineer, but had to become a manager to see
https://www.developing.dev/p/3-mistakes-i-made-as-an-engineer
108 comments
> 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.
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 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.
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.
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.
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.
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.
>> 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.
>> 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?
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?
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.
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.
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 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%.
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%.
> 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.
For most businesses, still being around and profitable is an implicit, if not stated goal.
This is a forum for VC backed startups. We sell dollars for 90 cents here but we’ll make up for it in scale
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.
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.
> 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. Please refrain from needless refactoring not accounted for in your sprint work.
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.
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.
I’m sure some people would find this overbearing, but to me this sounds like an exceptional manager.
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.
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.
My manager does not have to do this with me. We meet once a week where I update him on my progress for the projects assigned to me, or decide which next project I should take on. If anything impacts my ability to deliver, or if anything is unclear in terms of scope or priorities I talk to him on Slack to resolve it.
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.
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.
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.
What insanity? Being asked by your PO to work on the actual stuff your team has agreed to work on in the sprint planning , you know the stuff that management thinks will actually happen? If you don't tolerate this, it's certainly better for both sides to depart.
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.
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.
At any company, your job is to do what the company needs done and that is rarely your choice.
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.
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.
> At any company, your job is to do what the company needs done and that is rarely your choice.
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.
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.
> 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.
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.
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.
I disagree you can do that without much time investment. The time investment is in learning, not executing.
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.
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 disagree - I think juniors should pay attention - but actively moving outside their role is almost always more trouble than worth.
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.
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.
Taking a peek at your Twitter and Linkedin, I'm honestly not sure how useful this advice is for most people and whether it's based on reality, or what you wish happened.
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.
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.
My promotion from junior to mid-level definitely came from sheer volume of work. I think I could have dialed that back a bit and been more tactical with better results.
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.
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.
This resonates with me on multiple levels.
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.
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.
I 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 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.
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.
Yeah, I sort of had the same impression. Imagine as a junior engineer having the following conversation with your manager:
"Guess what? Yesterday I managed to triple my productivity going forward!"
"Great! How did you do that?"
"I hired two more engineers as good as me!"
"You did what?"
"Of course I had to pay them more than my own salary. Finding engineers as good as me who also work as cheaply as I do is basically impossible, I have no idea how you did it. I guess that's why you make the big bucks!"
Not sure if you've read Chris Hadfield's book (Astronaut's Guide to Life On Earth) but he talks about a similar system. In his words you can be one of three team members:
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.
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.
I really like the way you categorized different SWE levels. Thank you for the insights!
> 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.
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.
I should have added more detail but I was attempting to be brief. I meant that a junior engineer should focus on learning how to do the basics of their job so that they can provide features that help our group meet business objectives. A large part of getting there will be needing mentorship and asking lots of questions. The context is that often juniors need so much hand holding that the cost of their mentors time is more expensive than the value of the feature being produced. I wasn’t even considering their salary.
I don't think the implication is that the junior engineer should be carefully calculating their coworker's hourly rates and estimating the dollar value of what your slack DM to them will cost the company. Just that you do a good enough job that your work brings in more money than your salary costs.
An employee spinning their wheels getting nowhere for a month because they didn't ask a question that someone more experienced could answer in 5 minutes is not a good tradeoff.
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.
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.
>An employee spinning their wheels getting nowhere for a month
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.
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.
Agreed there is a balance. I wrote a little about when and how to ask questions as a junior engineer - https://twitter.com/ryanlpeterman/status/1628803643171557376
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.
It's a real thing and it doesn't help the junior engineer or the business.
Which would not be contributing value to the company. I think his point was that a junior should learn that just working blindly like that is not always the right thing either.
"When I was an engineer I focused on work that improved my career, but then I became a manager and realized that my engineers actually should work to improve my career!"
Funny how that works.
Funny how that works.
Depends on what you’re looking for in an engineer. I consider the author’s learnings to be relatively obvious, of course and engineer that “gets to know their colleagues” is doing great.
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.
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.
Making the team stronger often doesn't make your career better though. This guy says he didn't and he got promoted to manager anyway, and now suddenly he wants the people under him to make his team stronger rather than focus on their career like he did. That smells like a corporate climber who just started to eye his next promotion rather than a new insight.
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.
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.
I just want to say that the usual interpretation of "individual contributors" is not that they work alone. Almost by definition a Senior and especially a Staff+ engineer gets to deal with a lot of other engineers, hardly working by him/herself. The more you go up the IC ladder the more your job becomes influencing the technical direction of your team/org. It's a very social job.
I agree it's easy to see it that way as an IC (I thought the same!). I think the more senior you become the more you will view impact from the lens of your team/org, even as an IC
I'd say the higher you move up in management, the more and more your own goals should represent the business's goals. A lot of ICs don't really care about the business, however, and I think this is where promotions are used as a tool to get them to care.
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.
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.
This is why every time I take a management, I regret it. I don't care about any business and I'm beginning to suspect I'm incapable of caring about any aspect of the job other than the wellbeing of the people on my team.
Although, the more senior you become the more you also understand about using the best tool for the job. And burning away engineers time to do management tasks is not that.
There is a strong bias to focus on things that helps yourself, that is only natural. So IC's will focus too much on things that improve their career, managers will focus too much on things that improve their career, directors will focus too much on things that improve their career etc.
> Hiring well is one of the best uses of your time
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.
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.
Investing in 'hiring well' is worth it for the skill, sticking around in 'hiring' is probably not unless you're using it to swing some cool free international trips. There's a lot of value in knowing exactly how you'll be judged at your next job interview.
I think of the hiring loops that I am a part of as paid interview practice.
Couldn't agree more. For a long time, I'd be one of the last people to quit when a shitty manager was brought onboard. I'd give them their due time. Other senior engineers saw the writing on the wall and jumped ship. So far they've always been better off for leaving than me for sticking around.
So basically the mistakes were mostly not solving management problems as an engineer?
Uhhh... ok.
Uhhh... ok.
On the one hand: 100%. Agreed. Engineers experience enormous cognitive dissonance because companies & managers don't understand the very real problems they face. This article both say it, but under the title of being a mistake of engineers:
> 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.
> 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.
Yea, I don't get it. Perhaps if while you're an engineer you think management shouldn't be doing these sorts of things you had some mistaken perspective.
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.
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.
Also my observations.
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.
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.
I’ve been fortunate to work with the same core group on engineers and qa for more than a decade. Managers come and go, but we all get along well, enjoy our work, have great benefits, and are compensated well enough that none of us have felt like moving on. However, we recently got a new manager who is a pain in the ass. Fridays are normally no meeting days (this comes from much higher up), but he scheduled a 1 hour meeting this morning that he managed to drag into 3.5 hours. I pretty much have done nothing else today because I’ve been brain dead after that long meeting. For the first time in years, a number of us are talking about moving on. It is amazing how bad an effect a manager can have on a team.
This seems like the kind of thing you could take to your skip-level or even higher in the management chain. A single new manager causing multiple long-serving employees to become disgruntled should be a bright red flag to a competent leadership team.
Unfortunately, we can’t do that. Not everyone on the team is white, but enough are that if we complained about the new manager it would most likely come off as racism. Better to find a new job first and then let HR know of our concerns in the exit interview.
I dont get it.
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“.
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“.
Why?
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.
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.
> 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.
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.
I did not state anything about „problems“. Not sure what you refer to.
Because as you become more senior as an IC, your personal growth is directly related with your ability to influence others and deliver through others. What’s best way to do it than to ensure you bring and groom the right talent.
It's pretty obvious: thinking about hiring is important because you want smart and effective coworkers on your team. If engineers are not interviewing potential engineers, big problems can occur. Basically, you wind up with people who don't know what they're doing technically, but happen to "interview well." It takes a long time to fire someone. In the meantime, you got a big mess to deal with.
> Why would you care or think much about hiring as an engineer? You probably would not even be asked to attend interviews
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.
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.
These seem almost a bit simplistic?
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.
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.
Yea, it’s from a pretty green manager it seems. Not great advice to engineers.
This is reinforcing the idea that all ICs eventually become managers, or that managers are just more advanced versions of ICs. Egocentric.
But it's the direction the industry is moving in.
But it's the direction the industry is moving in.
> For that reason, people problems are just as important as problems with the code itself.
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.
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.
The article contains way too few mistakes. I suspect there's a whole series coming.
> Having motivated, happy teammates is critical to getting things done.
Here it is, in case anyone was looking for a good reason to care about people's happiness
Here it is, in case anyone was looking for a good reason to care about people's happiness
...will we see this followed up with "mistakes I made as a manager, but had to become an executive to see"? ;)
Hahah also good clickbait. Maybe one day if I'm lucky
Looking forward to the sequel: "Mistakes I made as a manager, but had to go back to engineering to see"
For a 10x engineer, heads down coding is the best state you can get them into.
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.
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.
Most of the things that make you a more “senior engineer” are not getting better at writing code. It’s a social endeavour and you’re a bigger lever when you grow outside that small circle.
Created a temp account to say please let there be others that cringed when reading this thinking that it was insanely obvious.
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. :(
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. :(
I like this post but is it really only about "people skills"? Of course a manager would have more of an interpersonal focus because that's their job; ICs need to focus on their job as well (while being personable enough obviously). I'm all for interpersonal skills but think this post falls short a quite a bit for helping out engineers/ICs.
Edit: inter- not intra-
Edit: inter- not intra-
I agree with the social stuff but it doesn’t have to be drinking alcohol and forced fun. Just grabbing coffee every day, organise some board games, low key stuff is good too. I can see why the party oriented social events can put off shy / religious / parents etc.
But you can get to know people without that and make connections.
The hiring point is... Nuanced. Heavily.
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.
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.
Good, 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.
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.
Like everything in life, striking the right balance makes the whole difference. Exactly how the balance is weighted is different for varying situations. Your unique “formula” is your secret to success.
I also have more appreciation for having to make decisions I know will be derided. I feel bad for some of my derision when I was an IC. Not for all of them but definitely some.
Tldr: people problems are problems, having a good team is important, socialising is important.
This is such a non-article.
This is such a non-article.
> People problems are as important as “real” problems
I would go even further and say, "all technical problems are really people problems."
I would go even further and say, "all technical problems are really people problems."
tl;dr Play the game. Watercooler politics mean more than your code when it comes down to who gets promoted.
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.
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.
It's not just about getting promoted. It's much easier to get things done when you work well with the people on your team. And the more influence you have because of those connections, the more influence you have on hiring decisions. Keeping a bad team member from joining your team is huge.
Agree ,but do not think you have to become a manager to see those mistakes.
Technical skills are teachable to a coachable person, soft skills not so much
Soft skills are also teachable to a coachable person. I've seen it in action. However, far fewer people are receptive to coaching on soft skills because fewer people understand what "soft skills" are and why they matter.
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.
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.
I think "soft skills" disguises what these skills generally are and their importance in the context of an organization.
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.
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.
Right. The "soft skills" that make you popular and likeable with your peers are seriously disjoint from the "soft skills" that show you're in tune with management's (possibly unstated) priorities and know how to navigate them and know where the actual decision-making power centers are (and aren't). Sometimes, these skills are antagonistic to each other.
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.
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.
Where can I learn more about these practical, important, or less thought about "soft skills" (like ZephyrBlu's interesting examples) more effectively? I feel like I've encountered these points (e.g. writing for a specific audience) through separate online posts at disparate times. But, is there a definitive, more comprehensive resource detailing all of these soft skills and more? I realize that I'm basically looking for a career panacea, so maybe it doesn't exist. Even if it existed, should I even spend my time reading it—as someone very early in their career—versus actually making the mistakes myself, learning from it, and internalizing it?
Through self improvement literature! The problem is there’s a lot of bad self improvement literature out there.
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.
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.
Well, through the small fraction of self-improvement literature (or courses) that isn't garbage. But it will take lots of time and energy to discern which is which.
The more trustworthy and time-efficient way is from coworkers/ mentors/ friends.
The more trustworthy and time-efficient way is from coworkers/ mentors/ friends.
Understanding why soft skills matter is teachable to a coachable person. But not without a coach and when it comes to soft skills there is a general reluctance towards providing soft skill coaching, with a prevailing attitude, as seen in the first comment, that anyone who "wasn't born" with soft skills is unteachable, leaving few willing to try to be the coach.
I'd go a step further and say that there will be times when you can sit across the table from a grown adult and explain to them the behind the scenes details of the performance review process, explain that you want them to do X Y and Z so you can build a case to get them promoted this year, just to have them tell you to fuck off because X isn't coding, Y is boring, and Z is below their skill level. "But please still promo me ASAP."
Technical skills are not really teachable much unless its a full time job.
Some people don't have the aptitude (for either.)
Progressing into adulthood will make you see further. Hang on.
Management shoild be automated.
TLDR: Give a shit about your coworkers.
Thats it, thats the whole post.
Thats it, thats the whole post.
I’ve trained hundreds of people across many roles for thirty years.
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!
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!
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.