4 ms·
A few takeaways from an old-timer here: > First, he basically tells me this project should have been finished a long time ago and he can't believe it's taken t
by tacostakohashi 5y ago
A few takeaways from an old-timer here:
> 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.
- davidw 5y ago> Do not put work into things that may or may not be needed. 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.
- tacostakohashi 5y agoTrust, but verify. The advice was about how not to be a junior dev.
- wbsss4412 5y agoAs a junior, you really shouldn’t be constantly maneuvering around your immediate supervisor up the chain of command. 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.
- iovrthoughtthis 5y agoi find it useful to develop my own internal model of the goals and direction of a project and lay peoples (including the higherups) "opinions" against that. if they match, it's probably on point if not, its probably not worth it
- chana_masala 5y ago> You need to communicate, build relationships, and get feedback from many people in the organization. One of those people is your manager's manager. 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.
- xupybd 5y agoIt's hard to do but an effective tool to build political standing and gain insight to be able to assess the quality of feedback.
- shard 5y agoBuilding relationships with a skip level manager doesn't have to be about direct updates. It's not about going around your manager, either. It's building another channel of communication where you can ask for help on blockers, get updates on issues specific to what you're working on, build visibility for the work you are doing, and create good working relationships. Unless your manager never goes on vacation, you're going to have to work directly and report to your skip level manager at some point in time anyway. In my company, my manager has regular sync-up meetings with his skip level manager, and encourages me to do the same.
- ryukoposting 5y ago> Do not put work into things that may or may not be needed. 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.
- aidenn0 5y agoI guess I also qualify as an old-timer and I just have to say that your comment meant I didn't have to write one. You hit all the points I wanted to make.
- rendall 5y agoAs another old-timer, I honestly think this is not very good advice. 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.
- pertymcpert 5y agoI think this advice is out of touch. It’s been written without considering the person the advice is for. There is a time and place for these points and a junior developer in a new job is not one of them. OP listen to others, not this one.