Ask HN: My boss doesn't think I'm doing good work, how to proceed?
I'm working my first job out of college and I really enjoy it. I get to do fun computer vision stuff, write Rust, great pay, great benefits, short commute, etc. And my manager and her boss are both super smart.
However I'm a bit frustrated. I thought I was doing well - I'm working hard on the project I was assigned to, and it's coming along nicely. The deadline was pushed back once (which that seems to be very common at this company), and the new deadline is still in the future.
Two weeks ago, my manager's boss schedules a meeting with me and my manager. My manager is busy putting out a fire so it's just me and the boss, and the boss made a some of criticisms of me. I've been thinking about them and I can't shake the feeling that some of them were kind of unfair. (To be clear, I absolutely did make some mistakes on this project that contributed to it taking longer than it had to.)
First, he basically tells me this project should have been finished a long time ago and he can't believe it's taken this long etc. I had no idea that he felt this way before the meeting - I've mostly just been working to get it done before the revised deadline my manager gave me.
He looks at the code and criticizes design decisions, some of which were made largely on my manager's explicit suggestions. (When I bring this up, he says I probably just misinterpreted an offhand comment of hers as a hard requirement.)
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. I don't think the boss appreciates that and just sees that the amount of usable output is low for the amount of time I'd been working.
He did also make some criticisms that I thought were fair. For instance he said I should have looked at other projects to see how they accomplished what I'm trying to do. That definitely would have been a good idea.
After our meeting, my manager and my boss had a meeting with just the two of them to discuss the status of our project. I have no clue what happened in that meeting and I haven't heard anything about it from either of them since.
As of today the project is pretty much done (save for some procedural details). I'm happy, but I can't stop thinking about that meeting. I really did work hard, so it's demotivating that it feels like the result of me working hard is unappreciated.
I'm not thinking of quitting over this or anything, but it seriously bums me out. I don't know if I have a future at this company if the boss thinks I'm not a good dev, and I really like it here. A month or so ago they added someone else to my project and I trained him on my code, and he's super smart and capable, and I'm thinking that now they probably feel that they could fire me if they wanted and not lose much.
But the saddest part is that I really admire my manager and my boss, and I wanted to make them happy to have hired me, and now I feel like they probably aren't. I guess I can try to learn from my mistakes and get over it, but at the very least it feels like an inauspicious start.
How should I proceed?
505 comments
[ 4.5 ms ] story [ 317 ms ] threadTake some notes about what you can do better on future projects and try and improve. Rinse and repeat.
Gj on delivering.
As a new person you can't possibly know everything. If you dont have someone showing you the ropes then you have to take initiative and talk to others.
Especially in larger orgs, this is invaluable.
Also keep in mind that there is a good chance the manager might have had OPs back in all this, maybe it's just the managers boss who has unreasonable expectations (maybe due to poor communication from the manager about changing requirements etc).
Simply continue to produce good work. Learn from the more senior devs and remain respectfully accepting of comments from your manager's manager and anybody further up. Remembering that they do not have sufficiently detailed knowledge about what you do but they like to think that they do. Being diplomatic means that you never debate with them. If they make any substantial suggestions, discuss them with your immediate manager and ask them for advice on how to proceed.
Talk to your manager. If you don't have 1:1s, ask to have routine meetings. If your manager can't help you, alleviate your stress, or guide you forward, look for a new job.
It's hard to really say anecdotally if things were fair or unfair, but your manager's job is to help you (and selfishly, for you, they should help you grow in your career).
It does sound like your manager’s manager has poor people skills / favors a more confrontational management style. If you have a good direct manager that can be tolerable, up to you to decide how much it bothers you.
See how your actual manager describes what you just went through. If they're supportive, write them an email thanking them for their defense of the aspects where you felt attacked by your super-manager. Having it in writing will make sure it's _real_ and you're not being gas-lit.
If you don't get it in writing, or if your manager isn't supportive during a 1 on 1, then it's time to start looking for another job.
You would also benefit from talking to other engineers who have more experience, especially in that company. It is easier to talk casually to people you don't report to.
It is difficult to give more concrete advice w/o more context:
* a "best case" scenario is that the senior manager (your manager's manager) was having a bad day, maybe got themselves into trouble for X reason. Managers are human too.
* another scenario is that your senior manager is actually still inexperienced. E.g. did not have time to talk to your manager first and then decided to skip directly, etc.
* a worst case scenario is that there is something weird going on between your manager and his manager.
[edit] A manager's manager talking to an individual contributor (you), especially about technical details of a project is just weird. It is hard for me to think of a scenario where I would do this. Why ? Because as a Manager's manager, you lack context about why certain things happen. And the person responsible for your outcome is by definition your manager. You mention both manager being smart people, "knowing their stuff": they may lack experience on the "people manager" side of things. That's often a drawback of working in very technical environments.
From the subject line, I came in all fired up to start with "just quit; it's the greatest market for SWEs that the world has ever seen". After reading some of the details, I'm inclined to think "eh, it's some poor leadership being shown, but it doesn't sound irretrievably broken anywhere yet."
Start with your direct manager and setup an hour long 1:1. Let her know that you have some mixture of confusion and a small amount of concern, but that you're focused on understanding the feedback and, where appropriate, using it to improve. I think it's terrible form for your manager to bail on the 1:1:1 meeting and, if she had to, your skip-level manager should have rescheduled it. It's not just development for you, but it's development for her and while you should be having quarterly or so skip-level meetings with them, you should never be in a position as a fairly fresh grad to have your project work reviewed in a setup like this one. Poor leadership technique (IMO), but it's not evidence of anything toxic if they're open to "yeah, that sucked; we won't do that again".
I'm often in the role of wondering "why the hell is this project taking so long?!" and simultaneously realistic that there are generally very good reasons for it. (How many software projects in the history of world took wildly less time than originally contemplated?) Two years from now, I expect you to have developed a clear sense of how to explain those justified delays in a way that's convincing and non-defensive, but it's pretty damn unfair to expect you to be able to do that now, especially if you're a summer 2021 grad. You're spending all your time busting tail to just get the damn thing to work and someone's chirping about a second-order effect ("sure, it works, but why'd it take so long?" is just not a question that you're well-positioned to evaluate yet).
I think your overall approach and attitude here is going to serve you well in your career and dive into this one head-on and with curiosity with your direct manager. You've always got the great SWE market to fall back on, but this one seems like staying and fixing is a better plan.
Wow, actually that feedback is quite surprising to me. I’ve been working hard on the project, and all the feedback I’ve gotten until now is that it was coming along nicely. A lot of the design decisions you pointed out were direct suggestions from (manager) and I thought I was doing a good job by implementing them thoroughly. Maybe we should have this meeting again with all of us in the room?
I am trying to think of one way it was useful to tell you that, but I can’t.
Seems like you should feel justified in not being a fan of working under this person. What you do with that is hard to say. Sounds like you got to work on a cool project and got to mostly solo it. That’s pretty great for a junior.
I’m not sure any “you should have” phrase is ever beneficial UNLESS it’s in the context of giving guidance about the future. And even then, it’s better to phrase it as “next time, I would suggest…”
This has been a pet peeve of mine for a long time. “You should have” phrases are often used to berate or make the recipient feel bad while acting as a vent for the sayer. By grammatical definition, they refer to events / things in the past and suggest an alternate course that didn’t happen. A theoretical construct. Good for language construction, bad for feedback.
I’d love counterexamples if anyone thinks differently, btw.
For example: You have kids, you should have life insurance.
Man, grammar is weird. ;)
"You should have been able to finish this in 2-4 weeks, but it took you 6 months. What went wrong?"
That's actually useful feedback, I think. It highlights that the giver believes the recipient has abilities that exceed the demonstrated result.
(2) Others pick things up super quickly, but never become super productive as the first group.
And of course lots of variations of people that don't fit neatly into either group.
I am in group (2) I think, but in my experience you really want people that become strong experts after a while. They are the ones I have seen do the best over the long term.
He seems to be very careful about placing value judgements on which is "better", and he's also very careful to crop the graph near time T. His big push is to make sure that teachers understand that people that are categorized as "slow learners" actually often take just as long to get to the same level of proficiency as "fast learners".
Also a 4 weeks task for a member of a larger team is something that turns them into their own development shop and it's probably not something you want to have in a team.
I also understand some will say "a senior dev should manage such a long task on their own" - well maybe they should and some might, but in the end it's not their business and they can jump the ship 2 weeks before the deadline of a 3 months task (seen that) - that's why good project/tech/team management is a skill ))
I also think it works well, better than "next time I would", for giving someone permission to do things. "You should have called me when the client asked for XYZ" sounds more forgiving and less venting than "Next time call me when the client asks you for XYZ". Or "you should have felt free to take a mental health day". It's more empowering.
in this case, i would say something like "hey, we need ot[or should] use a cryto library here since it's battle tested, rolling your own crypto might have issues [yadda yadda yadda]".
it makes it feel like it's not a single developer decision, but a team/company wide one.
But I respectfully disagree with your second example:
"You should have called me when the client asked for XYZ" is _exactly_ the kind of phrase I find unhelpful. All that does it lay blame - it says you did something wrong and in a perfect world you would have done something right. Your counterexample is the kind of feedback I'd MUCH rather hear.
"Ok, you didn't call me when the client asked for XYZ. That is fine. If it happens again, call me." It addresses the situation that happened, emphasizes that you are indeed forgiving, and gives guidance about how to handle it in the future.
I still feel like "If you needed a mental health day yesterday you should have taken one" can be empowering more than "If you need a mental health day in the future, take one", for the same reason that the middle example is poor. It shifts agency (and blame in the second example) to the person you are talking to. But I no longer even feel as confident in that example either, and would welcome pushback or not on the point.
Thanks for pointing it out. I'll try to be more aware of that going forward.
I was in a meeting where a group of devs were presenting a technical solution to our director, who was overseeing the product as a whole. At one point the director asks, "Did you look into other companies doing this and potentially licensing their solution to the problem instead?" All the devs were confused because they were tasked with building a technical solution in-house. I was confused as well because it seemed like a question the director should've asked a PM or one of the dev leads, not the grunts who were tasked with writing the code. The devs presenting were flustered by the question and didn't know how to proceed. The director continued with the line of questioning and it was clear he didn't like what he saw in the presentation.
The experience left a bad taste in my mouth.
Anyway, a couple weeks later, my manager mentioned the incident and told me he asked the director about it. The director admitted that he had only asked the question to get the team thinking differently about how they were solving the problem and cut through some of the technical details they were providing him. My manager thought it was a clever tactic, but I thought it was manipulative. I also think he just lost his cool since the solutions weren't to his liking and wanted to take it out on the team a little bit. I didn't think it was a great way of building trust with the team, nor do I think it made them think differently about the problem.
That's quite clumsy to say it only once the project has been released. Anyway, don't take it too personally, he/she probably just wanted to keep the pressure on you so you keep improving and never stay satisfied with your current pace. That's not very good management, but that's the way it is in most companies.
It's useful if it's a warning that OP isn't meeting expectations. Getting that feedback before a formal review, when there is still time to turn it around, is beneficial.
I've seen junior engineers be blindsided during a review more than once. They go in thinking they're doing great, because they've gotten no incremental feedback and lack the experience necessary to guage on their own, and then hear they're not cutting it. Getting this feedback before review time (and preferably even earlier than OP did) is good, even if it hurts to hear.
Obviously that feedback should have gone through their manager though. OP's manager should have rescheduled this meeting if they couldn't make it, since they probably already knew the feedback was negative.
As for the project, you should consider how much mentorship you received. If there was none, then obviously a high degree of mistakes is natural, especially for someone new to "professional software development" (if such a thing exists). If there was a lot of it and you blatantly ignored it, you should take responsibility for it.
Most importantly, keep a healthy work-life balance. It's easy to forget it, especially when first entering the workforce and thinking that you need to "prove yourself". Most of us are average; if you are too, accept it and keep living as best as you can. The 10x coders can keep on 10x-ing, but the world depends on the average person.
Early days. One of the key things you get with experience is the cold blood to wait some things out and to not let minor or major incidents get under your skin. If/when this becomes a pattern assess it against the rest of your experience and decide on your best path forward.
Communication is the answer.
If you think you're going to quietly go back to your laptop and solve all of these problems by being more careful, you'll probably end up disappointed.
You should take this as a learning opportunity to improve your communication skills. Communicate early and often. Ask for feedback. Ask for clarification. Ask for code review. Ask for a performance review.
Also: There is some good advice in this comment section, but there's also some absolutely terrible advice. Please ignore all of the low-effort comments insisting that you should quit or the comments suggesting that your boss's boss is malicious "gaslighting" you. This may be your first stumbling block in the workplace, but it won't be your last. If you make a habit of shutting down, quitting, or becoming resentful in these situations then you're never going to learn how to build actual healthy relationships in the workplace. Do as much as you can to learn from this, but make sure you do move on as quickly as possible. Don't let it eat you up.
In a situation like this you need to be able to think on your feet and choose your words carefully, which can be very difficult if you have reverted to a defensive or fearful "fight or flight" mind state.
I personally have benefited a lot from biofeedback and meditation over the years, if only because it has given me the tools to recognize when I am in a fearful state and calm myself down.
The "fear is the mind-killer" mantra from Dune is not really fiction!
In this scenario, I'd work through a 5-whys for figuring out why the multiple reasons why the "you're effectively on warning for being fired, and certainly not being promoted" just happened, and the reasons behind them. Ideally with someone at least a few years ahead of you who, and not at the company to avoid politics/bias issues. Maybe you need a tech lead or a senior dev mentor. Maybe project planning is broken. Maybe product expectations are broken. Maybe they don't know you're a junior dev and that means basic stuff like teaching you how to work in a team. Once you've done that, then repeat it with your team: they want to do better too, hopefully.
From there, if possible, maybe get it fixed... but it's not your job to fix team culture as someone junior, so also look at switching teams (managers) or even companies. If you believe you're being diligent and working hard, it's a net loss for yourself and better functioning teams to keep underdelivering for reasons not under your control. Other places would be happy to have you, help you be more productive, and your career + their results will be better. Leaving at 1-3mo point is not that bad on a CV (and you can drop it later) -- leaving at 6mo-24mo is the bad one.
I think this is the most accurate and actionable advice in the thread.
I'd give it another chance though, sounds like the work is fun and maybe you can communicate your concerns to your direct manager.
I think it's a sign of bad company management, but it's by no means a dealbreaker. i.e., not something to quit over.
OP, I’d say keep this situation in the back of your mind and reevaluate in a few months. If it happens again, start the job search.
But both of them always filled each other in, and it was never about any performance issues on my part.
My skip-level at my first MAAAM job used to snipe at me when I was a new hire. He told me to my face he "would not have chosen me" and "didn't know how I got in." It made me so angry it was all I could do to hold my tongue until I got the fuck out of his office. But I went on to become very successful there, and he eventually had no choice politically but to support me. He got managed out a couple of years later.
Holy shit. Glad that this person got managed out... eventually.
A good manager would not say stuff like that unless he really felt the person would take it the right way. A bad manager will say stuff like that to stroke his own ego.
So those are absolutely different sorts of relationships. The coach is not your superior so it changes everything about what they could say to you and the consequences it could have on you.
So no, a good manager should never say stuff like that. It's the sort of words that can be the involuntary sparkle which could ignite depression or even suicide. And for what ? A better performance at writing crud programs ? No. Professional things are not important enough to say any of this.
Or is it something else?
I immediately hate it.
Not sure if it was meant to be a good job, or a "you're lucky."
Like, why are they complaining about this on hacker news? They should be venting to their manager (we can see why that fails), or some engineer with some clout they trust. If they don't have these avenues, that can turn sour quickly.
I also got the impression that the manager's boss was venting... presumably they were feeling some pressure from elsewhere to deliver the project. Not a great sign that they took it out on the junior, but this would normally be the job of the middle manager to deflect / explain / shield the junior from.
To the OP: try to not take it personal, the manager's boss was almost certainly venting their own frustrations and "taking it out" on you. Very unprofessional but it happens. It's very unlikely to be a real reflection on your performance. Try to take it as a growth experience to build a bit of "thick skin". You shouldn't have to but it helps to have it (especially if in future years you become the middle manager who has to absorb the venting). Hopefully your direct manager will give you more useful feedback on your performance and perhaps explain the boss's frustrations.
But seriously if you are writing rust code every day and it works and none of your peers is visibly complaining to you, you are probably doing right and your manager is just not doing their job at filtering high frequency nonsense from chattering at the management level.
If they really slipped a deadline because a junior developer wrote code with design issues even when it was pointed out by his manager, it's the managers problem. The way to deal with that is tell the developer "this is the new peer review process" and just stomach the delay.
Also, see if you can chat with the boss to clarify their expectations for you.
In the future, don't linger on a projects, no matter how fun you find it. The main principle should be "get it done." That's industry for you.
because of course it was :(
If a lateral transfer seems possible, tell HR you would like be transferred out of your manager's boss's org structure.
Go above manager's boss's head and file a complaint against them for incompetence and unreasonable expectations: blaming workers for delays caused by poor project management is counterproductive and unacceptable CYA behavior. (Ideally once you already have a better offer in hand)
This is terrible advice..
Scenario 2) You did a fine job but your manager is unable to appreciate that. In this case, you still have more to learn but not on the programming side (well, probably still more to learn there, but not relevant to this situation). This is a lesson on how to deal with bad managers. They are not better than you, they do not own all of your time, and you have the right to leave at any time. As a dev, you will probably be able to find employment again easily. Use this to your advantage and any time the pressure from this bad manager rises, remind them of that fact and be ready to call their bluffs. Polish your resume, and get out of there in 18 months (bad managers don't get better). Leverage your position to a better job at higher pay.
How to tell between Scenario 1 and 2? That's hard to say without more specifics, but either way I think the takeaway is to try to learn what you can from this and don't take it too hard.
But once you spend some time in the industry you've seen enough that you can recognize the mistakes of your superiors, and you feel comfortable enough to point them out. Because what are they going to do, fire you? Better to be fired by a stubborn boss who refuses to learn than to work under one, I'd say.
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.
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.
Do you have a weekly 1:1 with your manager?
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.
The only hard part is to bring fake absences into this mindset, so I can be praised for them.
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.
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.
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.
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.
Advertising 20 days + public holidays in the UK is basically advertising that you give people the minimum the law will let you.
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.
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.
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.
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.
Training your replacement is how the cogs in the machine reproduce.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
>"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)
> First, he basically tells me this project should have been finished a long time ago and he can't believe it's taken this long etc. I had no idea that he felt this way before the meeting - I've mostly just been working to get it done before the revised deadline my manager gave me.
You need to communicate, build relationships, and get feedback from many people in the organization. One of those people is your manager's manager.
> He looks at the code and criticizes design decisions, some of which were made largely on my manager's explicit suggestions.
It may be the case that your manager is wrong, his design suggestions were dumb, etc. Or, it may not. This is one reason you need to get feedback from people other than your manager.
> 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.
Use this as a learning experience. Do not put work into things that may or may not be needed. The correct way to tackle a big project with changing requirements is to get something working end-to-end, possibly with a whole lot of copy and paste, hacks, hardcoded stuff instead of configuration, whatever. Then, when it is doing what it supposed to do, go back and improve it, rinse and repeat. Do not put lots of work into one part if other parts are missing, non-existent, and the project doesn't work end-to-end.
> For instance he said I should have looked at other projects to see how they accomplished what I'm trying to do.
This is great advice. It is often the case that if you ask the right question/person, someone will say "oh, yeah, I already did that, here's the code." or "I tried that last year, and it didn't work". Or, they might not, but the only way is to ask around, talk to people. This also goes back to the first point, build relationships with people other than your manager, because your manager doesn't know everything, and is probably wrong about a bunch of stuff.
You're a junior dev, someone tells you something is needed, you work hard on it. I guess you learn to question your boss as to whether it's really needed, but that sometimes isn't optimal, either.
Either your supervisor is good, and you need to trust them, or they are bad and you are likely SOL. Ultimately an organization who is holding a junior directly responsible for high level project decisions that were made in concert with their supervisor, is a bad organization.
if they match, it's probably on point
if not, its probably not worth it
That's an unreasonable expectation. That's your manager's job, not yours. If you have a skip level manager that is expecting direct updates from you... they're doing management wrong.
Hindsight is 20/20.
> You need to communicate, build relationships, and get feedback from many people in the organization. One of those people is your manager's manager.
This is valid advice, but the manager/colleague/etc's feedback has to be useful. In that regard, OP's manager's manager failed.
I mean "communicate" is always good advice, but reading between the lines, the situation as described is a setup for failure. I doubt it's intentional, but no one there knows how to develop software, apparently, other than to blame the junior for a timeline slip. There's only so much "managing upward" this kid can do.
My practical advice is:
Do tell the immediate boss what was said in the meeting.
Keep a good, positive, helpful attitude.
Understand there is no future for you at this place, because it is poorly managed. This is a place that will blame a junior for a timeline slip.
Do not blame yourself for the failures of the people whose job it is to support you. They are asleep at the wheel. This will be hard, because at this stage you don't even know in what way they are failing you, and likely will never learn that while there.
Do your best, anyway. But don't kill yourself over this.
Communicate with your manager. Your manager not being there in that meeting definitely didn't do you any favors. Make sure the both of your are on the same page. They should have been there to deflect. Be proactive about communicating and making sure everyone is in alignment. Easier said than done especially if the company is smaller or the manager is busy. But a 20 minute time investment per week will be worth it.
Figure out why this happened. Figure out what can be fixed and move on. But be vigilant because that kind of behavior is frankly uncalled for. On the other hand getting a new job in this market should not be too hard.
Always remember that almost any negative comments might be due to the perpetrator simply having a bad day.
If you manage to find a workplace that does not sport atleast one manager that does this, consider yourself lucky.
My advice, look for truths in what he said ( I am sure he was correct on some aspect somewhere ) and work on that. Ignore the rest and move on.
Also, this sounds like something that would happen at Amazon. I'm curious if it was there.
Most likely you should leave in this situation, because if your skip manager thinks you suck, you don’t have much of a future at the company. They will likely need to approve promotions, raises, etc.
However, you don’t have much to lose by being very open with your manager and seeing if the situation can be repaired.
What manager is going to stick his neck out or put effort into a subordinate that doesn't even know if they want to be there.
It could also leave you in a compromised position under many circumstances if they wanted to get rid of you / move you etc.