Beyond that, have clear goals, and communicate them clearly. Most people want to do the right thing. The better they understand the goals, the better able they will be to make decisions on their own that don't need adjustment later.

You need to encourage your juniors to ask questions as soon as they need to get clarification or unblocked. To do that, you need to embrace the interruptions, that is your job now. Both the interruptions from your juniors so that they get unblocked, and the interruptions from pesky people that will distract your crew must be short-circuited by you before they get to your team.

I find it very odd that most ICs take the path of management. This seems like an unnatural transition, like going from being a minister to playing in a death metal band.

There's also nothing stopping a good dev from being a great manager, or vice versa. A good dev learns to listen well, which is also a key skill as a manager. A dev creates working systems out of conceptual components, a manager creates working teams out of actual people. The biggest difference is that there's no Stack Overflow for management - every situation has to be treated as unique and you can't just copy-paste the solution.

This is in my opinion actually quite easy to explain to managers: asking for time estimates in software development is like asking for time estimates in proving a deep conjecture in mathematics.

Since every economics major has to take some courses in mathematics (which at least in Germany are often there to weed out bad students), this should not be difficult to understand for managers.

The problem rather is that these clueless non-technical managers insist that this perspective is simply wrong and theirs is right.

"Why can't you hit a hole in one with every golf shot? You know exactly where the hole is, you know how much the ball weighs, you know the length of the club, you know how hard you need to hit it and in what direction. So why isn't every golf shot a hole in one? Because, obviously, you may have miscalculated how hard and at what angle you should hit the ball, you may not have the skill to hit the ball exactly right, and any amount of random factors can affect the ball between you hitting it and it arriving at the green. Same for software development"

This is exactly my point: at least in Germany, the compulsory "mathematics for economists" courses are there to weed out student and are thus feared among the respective students.

In companies when expensive tech only people are allowed you see less techies among managers.

Then, when you graduate and can start making real money (probably), if you work at a hospital that does resident education, you're almost immediately expected to let the residents do as much as they can safely do, so they can learn. You go from working 80 hours a week performing surgery after surgery at a senior resident to working 30 hours a week watching the senior resident perform surgery.

Similarly (and admittedly it isn't a perfect analogy) as a junior and mid-level you're spending all this time learning how to write real software. Most of it's bad and especially at the junior level you're going to spend a couple years being more trouble than you're worth in terms of productivity. But by the time you're a senior, when you theoretically know what you're doing, you're going to have to spend most or a large portion of your time helping out the juniors in your org.

If you don't want to do that, you shouldn't be accepting senior positions. Or at least, go work somewhere where they don't hire juniors.

At a certain point, you probably know considerably more about the work than the people working around you. You might say you develop "seniority". At that point, the balance of value between your individual contributions and the knowledge you can share with others reaches a tipping point.

If you're limiting the value you're bringing to the company to only individual contributions, you're capping the value you can bring the company and by correlation the compensation you're due.

With that said, I don't see anything wrong with stagnating at your peak IC efficiency if that's what makes you happy.

I agree with sibling which says that mentoring is not leadership. Helping out others is not the same as giving them instructions or evaluating performances for example. However I can understand that someone would like none of that.

Honestly, it's a weird remark. Pretty much all jobs on this planet have aspects you wish you don't have to do. You work for your employer and your employer needs you to train the juniors. If you don't want to do that, change for an employer who only recruit senior engineers, if you can.

Beyond that, you could go into contracting. Do the work, point to your contract whenever someone asks something else of you, move on after 3-6 months, rinse and repeat.

When pairing with juniors, I avoid directly solving problems for them as much as possible–lessons tend to stick better when you ask leading questions and let them discover solutions for themselves. Perhaps this technique would also work to filter out "lazy" questions.

Working with a mix of super competent developers at all levels has really driven home for me that everyone is better at something, and worse at something, than you are. I've learned lots of new things from developers with less experience than me. I've also worked with many devs with senior titles who were worse off than most juniors.

Ultimately it's okay to find mentoring unenjoyable, but if this describes you, please stick to teams with most/all seniors and don't agree to mentor even if pressured. Attitudes like this can really exacerbate imposter syndrome for juniors, and I've seen it damage several careers.

When I was a junior, I would have been greatly satisfied by more time and attention from seniors, as I would be today grateful for more time and attention from people in differing specialities, where I am quite junior. We do however live in the real world, where these people's time is extremely valuable, and I wouldn't dare disrespect it by asking them trivial questions. I would value 10mins of their time and the context switch they pay to help me on the order of days of my own. And if I do resort to bothering them, I do so with an attitude of utmost humility, akin to digital dogeza.

I get frustrated when folks fail to do any of this. I regard is a breach of professional etiquette that unfortunately seems all too common. I've found myself responding "Try harder" or "LMGTFY" to these sorts of inquiries, which is about as polite as I can muster.

> everyone is better at something

It seems that this would be trivially easy to prove false, and very difficult to prove true. I've certainly met developers with nothing uniquely useful to contribute, in spite of best attempts at coaching them.

> imposter syndrome

I'd like to note that I'm actually extremely forgiving of mistakes, even very expensive ones, so long as they're honest. We all make them, and it's really on me to ensure that processes are in place and enforced to prevent the most critical sorts of them. But you don't know what you don't know. It's more the "I'm a baby, please hold my hand" attitude that I'm frankly somewhat disgusted by. If that describes (hypothetical) you, then perhaps some imposter syndrome is in good order.

I wouldn’t want to work on a team with someone who has such an attitude. I’m very grateful to work in an environment where we all want to help one another. This really reminds me how good I’ve got it.

Training your replacement is how the cogs in the machine reproduce.

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.

10x engineers can be a good match for startups where shipping now is essential and for big businesses who need something done quickly (for a change, the bigger the company, the slower everything else).

The only cons of 10x engineers is that they will burn out and that they're incredibly rare. Advising 10x engineers to help out other and collaborate is also nice to give them a bit of down time so they don't burn out and leave for the next startup with a 50% raise.

That said, it's not like HR managers are able to distinguish between senior low productivity engineers and 10x engineers, so it doesn't matter. No company will have a strategy around employees productivity.

I disagree the 10x engineer is a myth, as an hiring manager, I can easily tell you who is a 10x engineer after working with them for a year or so.

The only hard part is to bring fake absences into this mindset, so I can be praised for them.

Not quite. It's great when employees take care of themselves and make a point to enjoy their time outside of the office.

However, it's not really cool if you commit to be somewhere on a certain day, no-show, and then lie about being sick.

If you want to take a day off, that's perfectly fine. Please just communicate about it honestly. Don't lie. Reputation and trust are hard to build but easy to destroy.

Also keep your coworkers in mind in these situations. It's rare that engineering work exists in a vacuum without connections to other people's work. If your team mates have to fill in the gaps because you disappeared for a day without warning, that's not really great for the rest of the team.

People sometimes take "sick" days because the culture is such that they aren't allowed to be more honest about it. Many places I've worked operate in a never-ending cycle of extreme urgency. Taking days off usually must be approved far in advance, making it useless for those times when you wake up and simply cannot be productive. This leads to burnout pretty quickly. I have no issue with saying "I'm not feeling well" when I know I've hit a wall mentally and need to separate myself from my work. This makes me much more productive for the weeks following.

In Europe, calling in sick when you're not actually, recognizably ill is a pretty serious breach of trust. No cutesy "mental health break" exceptions. That said, you likely have at least 20 days of paid vacation, plus holidays.

In the US, where 10 days paid vacation is the norm and you're often punished in some way for actually taking it, the occasional "mental health break" of calling in sick is winked at.

You misread what I wrote, and then got angry about what you imagined I wrote. Usually I don't explain myself to strangers on the internet, since people who angrily misread also usually angrily double down, but here goes.

In the US, it is frowned upon to take a scheduled day off just to relax, outside of your annual 2 weeks of vacation. So you call in "sick". Since you're not really sick, but want to relax, you call your reason for illness a "mental health day". I characterized this practice as cutesy, because it's a cutsey repurpose of the concept of sick day for self-care. It's not a mental health crisis, it's relaxing. But as long as you characterize it that way, it gets a nod and a wink from anyone who cares.

In Europe, by contrast, if you need time off because work is stressful, you plan ahead, take the day off and be cheerfully honest that you spent the day at the beach or whatever. But if you tell people you were sick, and then spend the day at the beach, people will at best think you are odd, but probably will think you're a liar. Telling people it was a "mental health break" to call in sick in order to go to the beach will not get the same cozy reception it gets in the US.

Clear?

If I am anxious or depressed, going outside into nature or to the beach would help me tremendously. Much more so than sitting at home. How anxious and depressed do I have to be before it flips from "relaxing" to "legit"?

At my job I get x vacation days and y sick days. If I feel I unwell mentally I am going to use a sick day. Why is it anyone's business why I am sick or what I did on my sick day?

If my coworker said they were feeling terrible yesterday so they took the day off to go to the beach I would understand and encourage that. I would also admire them being brave enough to admit that rather than pretend they had a virus.

> If I am anxious or depressed, going outside into nature or to the beach would help me tremendously.

If you are feeling that semi regularly, you might be on your way to a burnout or actually experiencing one.

Advertising 20 days + public holidays in the UK is basically advertising that you give people the minimum the law will let you.

That's why it's such a breach of trust here to take a sick day in order to relax. A sick day is to recover from illness.

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

For long term absence each country has different rules and paperwork.

In theory you should get a sick note after 3 days, because the government pays SSP (statutory sick pay) if you're ill, but in practice most companies pay you at your normal salary rate (if you're permanent, not per hour) and don't bother asking for sick note as the SSP is little more than minimum wage. Of course, this is in tech, I know that there are a lot of crappier jobs where employers trust their staff less, and I suspect in those industries the sick note is very much required.

The business goal is usually to have a new product, feature, a/b test deployed to make money/validate an idea. If there's code ready for that, it's not a great idea to write it again.

Also, _latest tech_ is only meaningful for the devs, and usually not even helpful, since the shine new things might have new problems that you (and other people) still don't know and will have a rough time trying to find a solution to.

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.

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

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

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?

Many professors see teaching as a distraction from their real job, research, not an adjunct to it.

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.

And if you have questions, it is fully expected of you to just study harder and check for the question in books.

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.

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.

My advice to you: 1. Put serious effort into Slack (or whatever your company uses). It is just as much a part of the job as writing code 2. "You don't get a second chance to make a first impression." I'm not saying you should definitely change companies, but you should seriously consider it, as you are now going to have to put in a ton of effort to regain trust. There is a good chance that you'll have a better ROI just putting in that effort at a new job instead - if you kick ass in your first 6 months to a year, you will enter into a flywheel of being well regarded which makes you more effective, which makes you more well regarded.

Do you have a weekly 1:1 with your manager?

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.

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.

>"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)

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.

Similarly, owning up to mistakes (rather than making excuses) is gold. It wins respect and trust when you really weren't at fault.

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.

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.

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.