3 ms·

I've worked in cubicles and open space plans as well as remotely as a junior. It seems self-evident to me but maybe those who haven't experienced the various en

by slily 3y ago

I've worked in cubicles and open space plans as well as remotely as a junior. It seems self-evident to me but maybe those who haven't experienced the various environments do not realize that in person it is much easier to ask a random question to a senior. You can poke them and have a small discussion that would flood a chatroom and take much longer to develop remotely, without feeling like you may be inconveniencing them or the rest of the team since you cannot see if they are busy, or you can follow them to the coffee machine and discuss issues that are not urgent but could use their input instead of just notifying them over chat at a random time that may or may not be convenient. Working remotely I found myself constantly wasting time trying to figure things out on my own because I don't know if people are even online/active (spread out across the globe, another issue common with remote), if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes) If you want juniors to learn anything in a reasonable amount of time you have to give a bit of a shit and invest more time solely towards that especially in remote environments, seems that people just expect juniors to take the lead and force their way in though which isn't my style at all and if there isn't a common agreement and people are all just doing their thing it can come off as presumptuous to be bugging people left and right for the first months. Yes part of the problem is company culture not properly adapting to the environment, but I also haven't seen any change in the way we deal with communication since the Corona and of course seniors don't care because they got their job security.

grumpy_coder 3y ago
As the person you kept interrupting and following to the coffee pot, I much prefer this new way of working. To be clear, labelled as an 'IC' I have zero interest in training you. You will job hop at the first opportunity, and never lift a finger to help me in the future.
- slily 3y ago
  With that attitude yes I'm not surprised that people would be tempted to jump ship.
x86x87 3y ago
Hard disagree with random questions. If it's easy to ask a random question you're just going to keep asking random questions. How about you write down that question and try to formulate the answer or a strategy for finding the answer? Here is a workflow I made all people I mentor go through: 1) what is the problem? 2) why is this a problem? 3) what are you actually seeing? 4) what have you tried to solve it? What are the results?
- slily 3y ago
  "Random questions" doesn't mean questions without any thought put into them. It just means anything helpful from workflow or environment related questions to code style or processes that are not documented or easy to find. vs. wasting time trying to find things that don't exist or reinventing the wheel, which is more tempting to do when you can't see what your coworkers are doing and don't want to risk offending people who have no interest in passing on knowledge, like a sibling of your comment.
- jewayne 3y ago
  Allowing a noob to spin their wheels for too long isn't just wasteful, it sets the exact wrong tone. The goal is not to "figure everything out for yourself". It's to GET THINGS DONE.
bloopernova 3y ago
If your team penalizes you for "asking questions and looking like an idiot" then the team culture is poor. Nobody knows everything. Everyone makes mistakes. The team should help those people but they need to ask. Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job. Because we try to think as a team, we do better and have less interpersonal clashes. I still complain about things each dev does, that's natural, but our team does pretty well together.
- slily 3y ago
  > Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job. That's easier to do when you're more or less on "equal footing", but if you're a junior, it can take months to years to develop knowledge that seniors don't (depending on several factors). That's the problem, it takes much longer to reach a point where you have knowledge that is equivalent to that of seniors if the culture doesn't lend itself to frequent and high-quality communication and you have to learn about internal tools, processes, code bases and such largely solo. If you share a physical space with seniors you'll at least have some common downtime like a coffee or water break to "bother" them and it can save minutes to hours of tedium each time. So either you end up being "that guy always asking stupid questions in the chat and interrupting my work" or you spend a lot of time spinning your wheels pointlessly for months/years on end. The first approach leads to unhelpful and delayed responses and the latter makes you so inefficient that you favor lower quality work so that you can actually deliver something.
- theideaofcoffee 3y ago
  This is such an important point I don’t think it can be overstated. Psychological safety is one of the key things to have a well-functioning culture and it’s one of those cultural things that I’ve tried desperately change in past positions. It’s hard, and in one place, almost impossible save for eliminating a few key people who hold onto that mindset and clean house a little bit. There is no growth, no team cohesion in an environment where you’re berated for asking seemingly stupid or dumb questions. But I think people become numb and indoctrinated to it because “well, I had to endure this when I was learning” is such a demoralizing and abusive stance and nobody wants to change. Things work so much better when everyone has a chance to pitch in, even if some ideas are dumb, just having the option is miles ahead of whatever bullshit people can justify from the “old way”. Part of the process to change I’ve found is just leading by example. I’ll intentionally ask stupid questions that I know raise the ire of my similarly-leveled coworkers just to make the point to the more junior people that “hey, this staff-level guy is asking this, I might be able to too”. Junior people will gradually start to get the picture and ignore the rantings and ravings and toxicity of the debbie-downwers and the sticks-in-the-mud.
extr 3y ago
Well said. I am currently working my way through an unfamiliar codebase and even as a mid-career developer, I find it intimidating and inconvenient to continually ask for help over slack for "basic questions". People say the answer is to go deep and gain expertise, but in my experience you need to reach a certain escape velocity with the codebase before that kind of spelunking becomes valuable learning experiences and not just a confusing and messy waste of time. You need either: * Documentation that is up to date and answers not just technical details but the "why" behind the architecture. Something that shows you where to focus and where the frontier is. * Defined, limited scope (at first). Scoping yourself to the entire codebase is a good way to become an expert in nothing. You need a foothold where you can gain expertise and give yourself a jumping off point to adjacent areas. The latter is easier to accomplish than convincing everyone to write pages of docs that don't exist.
no_wizard 3y ago
Hate to bang the same drum over and over, however this very much sounds like a culture problem, based on > if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes) Sounds like the company lacks good culture, process and guidelines on expected patterns of communication and behavior. There should be an onboarding buddy when things are implemented well. Its not your fault, at all. Its the company. Its not inherent to remote work though

by slily 3y ago

grumpy_coder 3y ago

As the person you kept interrupting and following to the coffee pot, I much prefer this new way of working. To be clear, labelled as an 'IC' I have zero interest in training you. You will job hop at the first opportunity, and never lift a finger to help me in the future.

slily 3y ago
With that attitude yes I'm not surprised that people would be tempted to jump ship.

x86x87 3y ago

Hard disagree with random questions. If it's easy to ask a random question you're just going to keep asking random questions. How about you write down that question and try to formulate the answer or a strategy for finding the answer? Here is a workflow I made all people I mentor go through: 1) what is the problem? 2) why is this a problem? 3) what are you actually seeing? 4) what have you tried to solve it? What are the results?

slily 3y ago
"Random questions" doesn't mean questions without any thought put into them. It just means anything helpful from workflow or environment related questions to code style or processes that are not documented or easy to find. vs. wasting time trying to find things that don't exist or reinventing the wheel, which is more tempting to do when you can't see what your coworkers are doing and don't want to risk offending people who have no interest in passing on knowledge, like a sibling of your comment.
jewayne 3y ago
Allowing a noob to spin their wheels for too long isn't just wasteful, it sets the exact wrong tone. The goal is not to "figure everything out for yourself". It's to GET THINGS DONE.

bloopernova 3y ago

If your team penalizes you for "asking questions and looking like an idiot" then the team culture is poor. Nobody knows everything. Everyone makes mistakes. The team should help those people but they need to ask. Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job. Because we try to think as a team, we do better and have less interpersonal clashes. I still complain about things each dev does, that's natural, but our team does pretty well together.

slily 3y ago
> Today I was looking in the wrong devtools tab for a token value. Because we've worked hard making our team a safe place in which to ask questions, I felt comfortable asking what I was missing. Heck it's give and take, I know way more DevOps and Linux-y stuff, the devs know more about their job. That's easier to do when you're more or less on "equal footing", but if you're a junior, it can take months to years to develop knowledge that seniors don't (depending on several factors). That's the problem, it takes much longer to reach a point where you have knowledge that is equivalent to that of seniors if the culture doesn't lend itself to frequent and high-quality communication and you have to learn about internal tools, processes, code bases and such largely solo. If you share a physical space with seniors you'll at least have some common downtime like a coffee or water break to "bother" them and it can save minutes to hours of tedium each time. So either you end up being "that guy always asking stupid questions in the chat and interrupting my work" or you spend a lot of time spinning your wheels pointlessly for months/years on end. The first approach leads to unhelpful and delayed responses and the latter makes you so inefficient that you favor lower quality work so that you can actually deliver something.
theideaofcoffee 3y ago
This is such an important point I don’t think it can be overstated. Psychological safety is one of the key things to have a well-functioning culture and it’s one of those cultural things that I’ve tried desperately change in past positions. It’s hard, and in one place, almost impossible save for eliminating a few key people who hold onto that mindset and clean house a little bit. There is no growth, no team cohesion in an environment where you’re berated for asking seemingly stupid or dumb questions. But I think people become numb and indoctrinated to it because “well, I had to endure this when I was learning” is such a demoralizing and abusive stance and nobody wants to change. Things work so much better when everyone has a chance to pitch in, even if some ideas are dumb, just having the option is miles ahead of whatever bullshit people can justify from the “old way”. Part of the process to change I’ve found is just leading by example. I’ll intentionally ask stupid questions that I know raise the ire of my similarly-leveled coworkers just to make the point to the more junior people that “hey, this staff-level guy is asking this, I might be able to too”. Junior people will gradually start to get the picture and ignore the rantings and ravings and toxicity of the debbie-downwers and the sticks-in-the-mud.

extr 3y ago

Well said. I am currently working my way through an unfamiliar codebase and even as a mid-career developer, I find it intimidating and inconvenient to continually ask for help over slack for "basic questions". People say the answer is to go deep and gain expertise, but in my experience you need to reach a certain escape velocity with the codebase before that kind of spelunking becomes valuable learning experiences and not just a confusing and messy waste of time. You need either: * Documentation that is up to date and answers not just technical details but the "why" behind the architecture. Something that shows you where to focus and where the frontier is. * Defined, limited scope (at first). Scoping yourself to the entire codebase is a good way to become an expert in nothing. You need a foothold where you can gain expertise and give yourself a jumping off point to adjacent areas. The latter is easier to accomplish than convincing everyone to write pages of docs that don't exist.

no_wizard 3y ago

Hate to bang the same drum over and over, however this very much sounds like a culture problem, based on > if they are online I don't know if they have something more important to deal with at the moment, it is more difficult to extract information from seniors who are poor communicators - as good as they may be as ICs, most of my seniors will assume I should know every undocumented internal mess and it makes asking for more details intimidating. And I don't want to look like an idiot in writing! (lol, but I do feel that way sometimes) Sounds like the company lacks good culture, process and guidelines on expected patterns of communication and behavior. There should be an onboarding buddy when things are implemented well. Its not your fault, at all. Its the company. Its not inherent to remote work though