4 ms·

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

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

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.