4 ms·

A more interesting question is, are these actually mistakes or just part of the journey from a junior engineer to manager? People problems and building relatio

A more interesting question is, are these actually mistakes or just part of the journey from a junior engineer to manager? People problems and building relationships with your co-workers are things that I have realized are important over the last couple of years (Haven't done any hiring yet). In saying that, I'm not sure it would have been wise to focus on these things earlier than I did. There were too many other 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.

ryanlpeterman 4y ago
> 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.
- ZephyrBlu 4y ago
  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.
- moonchrome 4y ago
  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.
- ZephyrBlu 4y ago
  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 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.
  - ryanlpeterman 4y ago
    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.
beebmam 4y ago
> 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.
- IanCal 4y ago
  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%.
  - Aeolun 4y ago
    > 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.
    - lovich 4y ago
      This is a forum for VC backed startups. We sell dollars for 90 cents here but we’ll make up for it in scale
willjp 4y ago
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.

ryanlpeterman 4y ago

> 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.

ZephyrBlu 4y ago
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.
moonchrome 4y ago
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.
ZephyrBlu 4y ago
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 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.
- ryanlpeterman 4y ago
  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.

beebmam 4y ago

> 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.

IanCal 4y ago
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%.
- Aeolun 4y ago
  > 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.
  - lovich 4y ago
    This is a forum for VC backed startups. We sell dollars for 90 cents here but we’ll make up for it in scale

willjp 4y ago

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.