> 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.
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)
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
> 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).
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).
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.
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.
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.
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.
> 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?
> 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.
Could it be because you lose your professor job is in peril if you don't get research funding? Survival explains so much.
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.
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.
> 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.
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.