11 ms·

> Part of the reason it had taken so long is because I put a substantial amount of work into a part of the project that's no longer necessary due to changing re

> Part of the reason it had taken so long is because I put a substantial amount of work into a part of the project that's no longer necessary due to changing requirements, which I don't think I could have forseen. One of the things that I've experienced with new grad junior devs is that there's an adjustment needed to change from academic working to business working. In academia, usually the professor gives an assignment and you have to go off and figure it out, without bothering the professor, no matter what. In business, it's much better to 'bother the professor' regularly and check in affirmatively on whether the assignment has changed, or to tell the manager about challenges that arise to re-plan together. As a junior employee, you're not going to know the full business context of what makes sense, and checking in can save weeks of time that would otherwise be spent off on your own. Not sure if that's the case here, but certainly something you could consider going forwards to prevent similar situations.

bumby 5y ago
Also, related to the OPs comment: >"he says I probably just misinterpreted an offhand comment of hers as a hard requirement." It's sometimes helpful to explicitly reiterate your understanding of tacit/implied direction, especially when in a junior position. For example, a short email of "my understanding is that you want me to do X". A lot of this stuff boils down to communication. In academia, it's not as much of an issue because professors assign well-formulated problems with a definite solution. In business, a lot of the work is fleshing out those details and building a consensus about the right approach. Plus, it creates a trail to CYA (although that shouldn't be your primary goal)
taternuts 5y ago
I often find myself falling into this trap of not reaching out for help quick enough and I've been a dev for a decade. It really is a super bad habit and I've made some strides recently to get better at it.
dazeandconfuse 5y ago
Thanks. I definitely will take that into consideration in the future. I'm not sure if it would have helped in this specific case but I can definitely think of other situations at work where taking your advice would have helped me.
- sdenton4 5y ago
  Pushing back on changing requirements is also a good skill to pick up. Part of it is getting a really clear agreement on what you're actually doing - what's the real scope of work - and actively changing the agreed plan when requirements change. I also find it helpful to highlight that changing requirements will have a cost in time, etc. There's also a an art to getting together a good MVP efficiently. You can treat lots of added requirements as shiny feature requests, and prioritize them below getting the MVP working. Having an MVP that people can try out and see it working at all goes a long way towards building belief in your work. At the same time, you want to build flexibly enough that the MVP can expand rationally to take on those added feature requests... without writing in SO MUCH generality that nothing ever gets done. Doing this well is a skill learned on the back of many failures and tedious refactors... But efficiently getting a demo+MVP is golden, even if you build up some tech debt to get it.
  - btown 5y ago
    I'll add here that there's a ton of nuance to "pushing back on changing requirements." My rule of thumb is this: program managers should understand the expected and worst-case consequences (including baseline time, switching costs, stepping on other team members' toes, etc.) of any proposals to expand scope, and as an individual contributor it is vitally important to be vocal to ensure they understand the full dynamics. But if and once they do understand and acknowledge the consequences, and still say a scope increase is justified, it's highly highly likely that they have more business context than you. Document the decision, of course, but fundamentally trust your team.
- DrNuke 5y ago
  I’m afraid the boss’ boss was talking with the wrong part of your team, in that his criticism really seems made for your boss, not you? That said, you were not treated like a novice at all, being given a fair share of high-level feedback. Take it as a nudge to improve and do better, without thinking too much: it will be your manager’s job to assess your output fairly.
- r00fus 5y ago
  The 'bother the professor' part is key. With new teammates, I want them to reach out if they're on a project I'm leading. If things look like they're going well - then it's great to get positive feedback. If not, better to change direction early (lost work due to changing requirements). Do you have a weekly 1:1 with your manager?
i_like_waiting 5y ago
Definitely, I remember as well, that everything they hated me for in school was super beneficial in business. Copying other work? Amazing. Telling boss that I don't have time to do the new task? Trendemous. Solving issue without using latest tech that I just learnt? Incredible. Compaining that some parts of task are harder than anticipated? Brilliant. The only hard part is to bring fake absences into this mindset, so I can be praised for them.
- HomeDeLaPot 5y ago
  You called in sick yesterday and went to the beach with your buddies? I'm glad you did! We all need a mental health day once in a while. Being happy actually makes you more productive in the long term.
  - quantified 5y ago
    My first manager would call these “health days”, and they were always supported. He would declare random “sun” days, when it was an especially nice New England day.
  - hkolk 5y ago
    if your manager is ok with it, don't register it as a sick day. Makes it potentially more complicated with the company doctor. Just consider it a workday spend on ...whatever. Manager being ok with it means you deserved it though :) (EU based engineering manager speaking)
    - tunesmith 5y ago
      company doctor?
      - tomcooks 5y ago
        In EU companies have to appoint a medical expert that checks worker's health (for free) upon joining the company, and routinely (1-2 times a year, depends on country I guess). Edit: Could be something that only companies whose workers have to do physical labour ("blue collar" jerbs) If you call in sick for more than three days you usually go through your own doctor, so that you get a certification that you're taking X days off in order to cure yourself
abfan1127 5y ago
this is really good advice. To go further, sometimes the homework changes, sometimes its not really necessary and can be delayed or ignored. Sometimes other unassigned work is more important. All of these are important discussions to have with co-workers, mentors, and managers.
xanaxagoras 5y ago
I have this junior engineer DM'ing me right now and I've been ignoring it because I don't want to deal with him and I have my own work to do. I'm reading through your comment here thinking "hey, I'm pretty good at walking that line, bothering the professor when appropriate, not waiting too long and not asking him for help too soon"... and then it occurred to me this guy is probably bothering the professor where I'm the professor. Oops. Need to work on being more charitable with my time.
- quantified 5y ago
  You may well be right. +1 karma for the adjustment. Mentoring/helping the juniors is part of the un-tracked/unplanned workload of the seniors.
- OnlyMortal 5y ago
  If your a senior dev it’s part of your role to help the junior ones out. You should cultivate that behaviour as it brings up the quality of your colleagues and builds work relationships.
  - Communitivity 5y ago
    Let's say you are the cryptid 10x engineer/tech lead, supervising a team of 8 junior engineers. You can spend 4 hours, the equivalent of a 40hr week of lesser mortals (this math is almost never true in my experience), or spend a half hour of time on each of your junior engineers. The problem you help each of them solve is solved in 30m as opposed to the 3-4h they might have tried solving it themselves, and they've learned something that maybe saves them an hour a day. You do this twice during the week. You've 'lost' 80h effectively of productivity for the company (remember, mythical 10x), but you've gained 104h (32h+32h+81h/day5days) from your team, for a net 24h gain. Of course, numbers are exaggerated, but the point remains the same: if you are a tech lead helping your team succeed is your primary job, not coding/design. You are the person who connects the lines of communication, removes obstacles, mentors the team on coding and design, and gets the team moving in one direction that aligns with the customer needs. You probably will code, to fill in gaps and help out, but personally I find it's split around 5/2/2/1 - 5 parts are working with your team to guide them and help them overcome obstacles, 2 parts communicating with management and customers, 2 parts coding/design, and 1 part administrivia/training.
onphonenow 5y ago
Wow - this is the best advice on HN (top comment to while I write) in a while. For junior folks I REPEATEDLY say, if you find yourself getting stuck / slowing down touch base. Or keep me in the loop, let's check in regularly when you have a good moment to chat, I'd love to hear how its going. Here's the other thing I noticed. I work with someone who is is my peer. Ie, 15 years+ experience etc. THEY check in with me proactively 5x as much as the folks who really need to be checking in. I also like that they don't schedule a call, they just zoom me. I know this seems rude, but it actually saves time. If I'm busy I don't answer, but usually I can. This is a personal preference. For junior folks if you schedule some time for early next day that works well (my calendar auto-accepts). Also, not end of world to socialize / connect with 1-2 other devs below your managers level to share tips / get help, just be sure to pass it on to the next FNG.
- stef25 5y ago
  > For junior folks I REPEATEDLY say, if you find yourself getting stuck / slowing down touch base. Or keep me in the loop, let's check in regularly when you have a good moment to chat, I'd love to hear how its going. Sometimes work goes in such small incremental steps, full of unknown unknowns that there's so many occasions you can get bogged down. Even if you apply the rule of "touch base if you get stuck for more than an hour", you can still end up interrupting the senior guy 5x / day. And when they're obviously annoyed and provide too short an explanation it becomes very uncomfortable to interrupt them again. Often it's not even their fault, they have a high workload and supporting the new guy isn't foreseen. Or, they're good devs but just incapable of explaining things. I had this experience at a fintech company that didn't have a single page of internal documentation and you'd have 8 point Jira tickets that consisted of one bullet point - figure out the rest (everyone remote).
  - onphonenow 5y ago
    One issue is turnover, it's annoying to spend time training someone who you won't be working with a long time. I've only had that really happen once. So a tip for junior's might be to look at places where folks have a bit of tenure and stick around (I know some places cycle folks between teams like crazy - that makes this hard).
vivekv 5y ago
This is a mind shift for the new hires. I typically ping them after a few days asking if they need any help understanding the problem or just a friendly chat on why we are doing that particular project and how it will make relevance to the business. The good ones quickly understand if the path they are choosing makes sense and most of the times opens them up to ask questions.
alfor 5y ago
Definitely agree, I would say, if you think about something we might have fallen short (likely) go ahead and say it, the abilities to see your own shortcoming is gold for a manager. They should be expecting rough edges with a junior dev, but if you are willing to talk about your weakness real or imagined you will grow fast.
- alsetmusic 5y ago
  > if you are willing to talk about your weakness real or imagined you will grow fast. Similarly, owning up to mistakes (rather than making excuses) is gold. It wins respect and trust when you really weren't at fault.
  - Claude_Shannon 5y ago
    I just don't understand that part. Where I live, admitting to making a mistake would be equal to admitting to your incompentence, and I'd be shown the door on my way out.
resonious 5y ago
I agree 100% that learning from the people around you is paramount. But I disagree with the idea that you can't/shouldn't do that in an academic setting. During my undergrad, a lot of the more driven students were always bothering the professors for help. Those students often brought back gold nuggets of information while working on a team with them. It made me regret not doing so more myself. Though to be fair, the assignment doesn't really change in academia - that's true. Those students aren't asking the professor if the requirements changed; they're bouncing ideas, and asking for further explanation.
trynewideas 5y ago
I'd go one step further and log my work and blockers in a place that's visible to everyone internally, like a company wiki if there's one. Still check in frequently but have that already written up and ready to share with anyone else who might be able to help. The biggest problem I've had being new at a company is knowing everyone else's skillset, and many people have a history at the company that gives them a unique voice or perspective that's especially valuable to someone new. (A big example: people who transferred between departments over time and can contrast how things are similar and different between them, what the connections between them are like, and the history and changes over time in them.) Having something easily sharable and already public can make it trivial for your manager or boss to track your progress — managers LOVE focusing their meetings on actions with context already in hand — and also make it easy for your boss to point you in the direction of someone else who can help with specific issues or blockers.
acbart 5y ago
> without bothering the professor What the hell kind of academic culture is this? Maybe in graduate research, if I expected a research assistant to know how to do a task... but certainly not true in an undergraduate course! If they can't do the assignment, that is the perfect time for them to come to me and learn from me how to do the assignment. That's like, the whole point of my job as a teacher is to help people learn. Yes, I make assignments too, and people underestimate how difficult that part of the job is, but helping people figure things out is like my #1 job. It's sad to hear that your experiences (and apparently many other commenters) are something very different?
- barry-cotter 5y ago
  > That's like, the whole point of my job as a teacher is to help people learn. Many professors see teaching as a distraction from their real job, research, not an adjunct to it.
  - ponow 5y ago
    Could it be because you lose your professor job is in peril if you don't get research funding? Survival explains so much.
  - bluehatbrit 5y ago
    This resonates with me, I had a real mixed bag when I was doing my undegrad degree. There were some incredible professors who wanted to teach, were very approachable, and would always make time and reply to emails with good detail. Then there were other professors who clearly only had their open office hours because they had to, would rarely reply to emails, and the moment you stepped into their office it was clear their top priority was getting you to leave.
    - dagw 5y ago
      This is getting off topic, but I'd love to see a fundamental rethink in how 'teachers' for undergrad courses are hired. Certainly for year 1 and 2 courses the 'teachers' should be selected and hired ~100% based on their pedagogical skills and passion and ~0% based on the impact of their publications. Universities also need to start recognizing, valuing and rewarding teaching ability. The best first year math lecturer I had at university (and the person that is the reason I ended up majoring in math) didn't get tenure and ended up taking a job a smaller 'unprestigious' local college. The by far the worst lecturer I had is now at MIT.
laserlight 5y ago
> In business, it's much better to 'bother the professor' regularly and check in affirmatively on whether the assignment has changed This is definitely management's responsibility. If they assign a task and let it continue after it has become obsolete, what kind of management is that? > As a junior employee, you're not going to know the full business context of what makes sense Agreed. I would add that explaining enough business context is also management's responsibility.
- dagw 5y ago
  This is definitely management's responsibility. Ideally yes. But the truth is that you will often find yourself in situations where management is less than ideal, and no matter how unfair you will end up looking bad if you fail to navigate that.
  - laserlight 5y ago
    Definitely. I argued the same in a top-level comment.
forty 5y ago
Yes! I'm trying to convince junior devs to bother me more. Some do (did) a lot, and are very efficient as a result, they learn fast and become more autonomous quickly. Then I feel it's also part of my job to evaluate when the bothering was not needed and to let them find on their own for a while. After a while, they adjust and ask only good questions.

bumby 5y ago

Also, related to the OPs comment: >"he says I probably just misinterpreted an offhand comment of hers as a hard requirement." It's sometimes helpful to explicitly reiterate your understanding of tacit/implied direction, especially when in a junior position. For example, a short email of "my understanding is that you want me to do X". A lot of this stuff boils down to communication. In academia, it's not as much of an issue because professors assign well-formulated problems with a definite solution. In business, a lot of the work is fleshing out those details and building a consensus about the right approach. Plus, it creates a trail to CYA (although that shouldn't be your primary goal)

taternuts 5y ago

I often find myself falling into this trap of not reaching out for help quick enough and I've been a dev for a decade. It really is a super bad habit and I've made some strides recently to get better at it.

dazeandconfuse 5y ago

Thanks. I definitely will take that into consideration in the future. I'm not sure if it would have helped in this specific case but I can definitely think of other situations at work where taking your advice would have helped me.

sdenton4 5y ago
Pushing back on changing requirements is also a good skill to pick up. Part of it is getting a really clear agreement on what you're actually doing - what's the real scope of work - and actively changing the agreed plan when requirements change. I also find it helpful to highlight that changing requirements will have a cost in time, etc. There's also a an art to getting together a good MVP efficiently. You can treat lots of added requirements as shiny feature requests, and prioritize them below getting the MVP working. Having an MVP that people can try out and see it working at all goes a long way towards building belief in your work. At the same time, you want to build flexibly enough that the MVP can expand rationally to take on those added feature requests... without writing in SO MUCH generality that nothing ever gets done. Doing this well is a skill learned on the back of many failures and tedious refactors... But efficiently getting a demo+MVP is golden, even if you build up some tech debt to get it.
- btown 5y ago
  I'll add here that there's a ton of nuance to "pushing back on changing requirements." My rule of thumb is this: program managers should understand the expected and worst-case consequences (including baseline time, switching costs, stepping on other team members' toes, etc.) of any proposals to expand scope, and as an individual contributor it is vitally important to be vocal to ensure they understand the full dynamics. But if and once they do understand and acknowledge the consequences, and still say a scope increase is justified, it's highly highly likely that they have more business context than you. Document the decision, of course, but fundamentally trust your team.
DrNuke 5y ago
I’m afraid the boss’ boss was talking with the wrong part of your team, in that his criticism really seems made for your boss, not you? That said, you were not treated like a novice at all, being given a fair share of high-level feedback. Take it as a nudge to improve and do better, without thinking too much: it will be your manager’s job to assess your output fairly.
r00fus 5y ago
The 'bother the professor' part is key. With new teammates, I want them to reach out if they're on a project I'm leading. If things look like they're going well - then it's great to get positive feedback. If not, better to change direction early (lost work due to changing requirements). Do you have a weekly 1:1 with your manager?

i_like_waiting 5y ago

Definitely, I remember as well, that everything they hated me for in school was super beneficial in business. Copying other work? Amazing. Telling boss that I don't have time to do the new task? Trendemous. Solving issue without using latest tech that I just learnt? Incredible. Compaining that some parts of task are harder than anticipated? Brilliant. The only hard part is to bring fake absences into this mindset, so I can be praised for them.

HomeDeLaPot 5y ago
You called in sick yesterday and went to the beach with your buddies? I'm glad you did! We all need a mental health day once in a while. Being happy actually makes you more productive in the long term.
- quantified 5y ago
  My first manager would call these “health days”, and they were always supported. He would declare random “sun” days, when it was an especially nice New England day.
- hkolk 5y ago
  if your manager is ok with it, don't register it as a sick day. Makes it potentially more complicated with the company doctor. Just consider it a workday spend on ...whatever. Manager being ok with it means you deserved it though :) (EU based engineering manager speaking)
  - tunesmith 5y ago
    company doctor?
    - tomcooks 5y ago
      In EU companies have to appoint a medical expert that checks worker's health (for free) upon joining the company, and routinely (1-2 times a year, depends on country I guess). Edit: Could be something that only companies whose workers have to do physical labour ("blue collar" jerbs) If you call in sick for more than three days you usually go through your own doctor, so that you get a certification that you're taking X days off in order to cure yourself

abfan1127 5y ago

this is really good advice. To go further, sometimes the homework changes, sometimes its not really necessary and can be delayed or ignored. Sometimes other unassigned work is more important. All of these are important discussions to have with co-workers, mentors, and managers.

xanaxagoras 5y ago

I have this junior engineer DM'ing me right now and I've been ignoring it because I don't want to deal with him and I have my own work to do. I'm reading through your comment here thinking "hey, I'm pretty good at walking that line, bothering the professor when appropriate, not waiting too long and not asking him for help too soon"... and then it occurred to me this guy is probably bothering the professor where I'm the professor. Oops. Need to work on being more charitable with my time.

quantified 5y ago
You may well be right. +1 karma for the adjustment. Mentoring/helping the juniors is part of the un-tracked/unplanned workload of the seniors.
OnlyMortal 5y ago
If your a senior dev it’s part of your role to help the junior ones out. You should cultivate that behaviour as it brings up the quality of your colleagues and builds work relationships.
- Communitivity 5y ago
  Let's say you are the cryptid 10x engineer/tech lead, supervising a team of 8 junior engineers. You can spend 4 hours, the equivalent of a 40hr week of lesser mortals (this math is almost never true in my experience), or spend a half hour of time on each of your junior engineers. The problem you help each of them solve is solved in 30m as opposed to the 3-4h they might have tried solving it themselves, and they've learned something that maybe saves them an hour a day. You do this twice during the week. You've 'lost' 80h effectively of productivity for the company (remember, mythical 10x), but you've gained 104h (32h+32h+81h/day5days) from your team, for a net 24h gain. Of course, numbers are exaggerated, but the point remains the same: if you are a tech lead helping your team succeed is your primary job, not coding/design. You are the person who connects the lines of communication, removes obstacles, mentors the team on coding and design, and gets the team moving in one direction that aligns with the customer needs. You probably will code, to fill in gaps and help out, but personally I find it's split around 5/2/2/1 - 5 parts are working with your team to guide them and help them overcome obstacles, 2 parts communicating with management and customers, 2 parts coding/design, and 1 part administrivia/training.

onphonenow 5y ago

Wow - this is the best advice on HN (top comment to while I write) in a while. For junior folks I REPEATEDLY say, if you find yourself getting stuck / slowing down touch base. Or keep me in the loop, let's check in regularly when you have a good moment to chat, I'd love to hear how its going. Here's the other thing I noticed. I work with someone who is is my peer. Ie, 15 years+ experience etc. THEY check in with me proactively 5x as much as the folks who really need to be checking in. I also like that they don't schedule a call, they just zoom me. I know this seems rude, but it actually saves time. If I'm busy I don't answer, but usually I can. This is a personal preference. For junior folks if you schedule some time for early next day that works well (my calendar auto-accepts). Also, not end of world to socialize / connect with 1-2 other devs below your managers level to share tips / get help, just be sure to pass it on to the next FNG.

stef25 5y ago
> For junior folks I REPEATEDLY say, if you find yourself getting stuck / slowing down touch base. Or keep me in the loop, let's check in regularly when you have a good moment to chat, I'd love to hear how its going. Sometimes work goes in such small incremental steps, full of unknown unknowns that there's so many occasions you can get bogged down. Even if you apply the rule of "touch base if you get stuck for more than an hour", you can still end up interrupting the senior guy 5x / day. And when they're obviously annoyed and provide too short an explanation it becomes very uncomfortable to interrupt them again. Often it's not even their fault, they have a high workload and supporting the new guy isn't foreseen. Or, they're good devs but just incapable of explaining things. I had this experience at a fintech company that didn't have a single page of internal documentation and you'd have 8 point Jira tickets that consisted of one bullet point - figure out the rest (everyone remote).
- onphonenow 5y ago
  One issue is turnover, it's annoying to spend time training someone who you won't be working with a long time. I've only had that really happen once. So a tip for junior's might be to look at places where folks have a bit of tenure and stick around (I know some places cycle folks between teams like crazy - that makes this hard).

vivekv 5y ago

This is a mind shift for the new hires. I typically ping them after a few days asking if they need any help understanding the problem or just a friendly chat on why we are doing that particular project and how it will make relevance to the business. The good ones quickly understand if the path they are choosing makes sense and most of the times opens them up to ask questions.

alfor 5y ago

Definitely agree, I would say, if you think about something we might have fallen short (likely) go ahead and say it, the abilities to see your own shortcoming is gold for a manager. They should be expecting rough edges with a junior dev, but if you are willing to talk about your weakness real or imagined you will grow fast.

alsetmusic 5y ago
> if you are willing to talk about your weakness real or imagined you will grow fast. Similarly, owning up to mistakes (rather than making excuses) is gold. It wins respect and trust when you really weren't at fault.
- Claude_Shannon 5y ago
  I just don't understand that part. Where I live, admitting to making a mistake would be equal to admitting to your incompentence, and I'd be shown the door on my way out.

resonious 5y ago

I agree 100% that learning from the people around you is paramount. But I disagree with the idea that you can't/shouldn't do that in an academic setting. During my undergrad, a lot of the more driven students were always bothering the professors for help. Those students often brought back gold nuggets of information while working on a team with them. It made me regret not doing so more myself. Though to be fair, the assignment doesn't really change in academia - that's true. Those students aren't asking the professor if the requirements changed; they're bouncing ideas, and asking for further explanation.

trynewideas 5y ago

I'd go one step further and log my work and blockers in a place that's visible to everyone internally, like a company wiki if there's one. Still check in frequently but have that already written up and ready to share with anyone else who might be able to help. The biggest problem I've had being new at a company is knowing everyone else's skillset, and many people have a history at the company that gives them a unique voice or perspective that's especially valuable to someone new. (A big example: people who transferred between departments over time and can contrast how things are similar and different between them, what the connections between them are like, and the history and changes over time in them.) Having something easily sharable and already public can make it trivial for your manager or boss to track your progress — managers LOVE focusing their meetings on actions with context already in hand — and also make it easy for your boss to point you in the direction of someone else who can help with specific issues or blockers.

acbart 5y ago

> without bothering the professor What the hell kind of academic culture is this? Maybe in graduate research, if I expected a research assistant to know how to do a task... but certainly not true in an undergraduate course! If they can't do the assignment, that is the perfect time for them to come to me and learn from me how to do the assignment. That's like, the whole point of my job as a teacher is to help people learn. Yes, I make assignments too, and people underestimate how difficult that part of the job is, but helping people figure things out is like my #1 job. It's sad to hear that your experiences (and apparently many other commenters) are something very different?

barry-cotter 5y ago
> That's like, the whole point of my job as a teacher is to help people learn. Many professors see teaching as a distraction from their real job, research, not an adjunct to it.
- ponow 5y ago
  Could it be because you lose your professor job is in peril if you don't get research funding? Survival explains so much.
- bluehatbrit 5y ago
  This resonates with me, I had a real mixed bag when I was doing my undegrad degree. There were some incredible professors who wanted to teach, were very approachable, and would always make time and reply to emails with good detail. Then there were other professors who clearly only had their open office hours because they had to, would rarely reply to emails, and the moment you stepped into their office it was clear their top priority was getting you to leave.
  - dagw 5y ago
    This is getting off topic, but I'd love to see a fundamental rethink in how 'teachers' for undergrad courses are hired. Certainly for year 1 and 2 courses the 'teachers' should be selected and hired ~100% based on their pedagogical skills and passion and ~0% based on the impact of their publications. Universities also need to start recognizing, valuing and rewarding teaching ability. The best first year math lecturer I had at university (and the person that is the reason I ended up majoring in math) didn't get tenure and ended up taking a job a smaller 'unprestigious' local college. The by far the worst lecturer I had is now at MIT.

laserlight 5y ago

> In business, it's much better to 'bother the professor' regularly and check in affirmatively on whether the assignment has changed This is definitely management's responsibility. If they assign a task and let it continue after it has become obsolete, what kind of management is that? > As a junior employee, you're not going to know the full business context of what makes sense Agreed. I would add that explaining enough business context is also management's responsibility.

dagw 5y ago
This is definitely management's responsibility. Ideally yes. But the truth is that you will often find yourself in situations where management is less than ideal, and no matter how unfair you will end up looking bad if you fail to navigate that.
- laserlight 5y ago
  Definitely. I argued the same in a top-level comment.

forty 5y ago

Yes! I'm trying to convince junior devs to bother me more. Some do (did) a lot, and are very efficient as a result, they learn fast and become more autonomous quickly. Then I feel it's also part of my job to evaluate when the bothering was not needed and to let them find on their own for a while. After a while, they adjust and ask only good questions.