431–440 of 506 posts
Failures are part of life and its success.
Your version of what happened shows several signs that are red flags:
Shifting requirements, without realistic expectations.
Unclear expectations.
Lack of proper oversight for Jr developers.
But, more importantly, you are in a position that you have a lot of baggage to overcome with your leadership and that's a really hard place to be, especially if you are looking for advancement. It's much easier to find another job and start fresh, from the position of someone that a company is excited to have onboard.
I have no idea whether or not you deserves the criticism, but the mental anguish you're feeling isn't going to go away without you continuing to feel pain, for a long time.
It's not worth it. Best of luck!
Modern education has failed you (and you were probably coddled a bit too much). Hard work is small part of a much larger equation which includes context, bigger picture, results etc.
Everything you mentioned is completely normal except for you whining about it on HN, as a junior dev mistakes are inevitable. You accept responsibility and push back on the "unfair" criticisms.
Maybe your pushbacks were discarded, maybe they didn't "understand" your side. Welcome to the real world, you work on what you can control and if thats not good enough maybe this is not the right place for you.
This idea that you are entitled to an "understanding" is silly. This is not college, you're not paying them. In fact as a junior dev, they are investing in you. This mistakes you will be making and the resources (senior devs) it will take to bring you up to speed is a net cost for them for the next few months.
Earlier quoted context omitted.
Slight tangent, I've been seeing a lot of companies from the US advertising remote roles in the UK and advertising "20 days paid vaccation + public holidays" as one of their "amazing benefits". I often wonder if they realise it's a legal entitlement over here and not seen as all that amazing.
its also.. actually quite bad, I can't remember the last 'professional' job listing I saw that wasn't at least 25+holidays
Advertising 20 days + public holidays in the UK is basically advertising that you give people the minimum the law will let you.
Earlier quoted context omitted.
This was my reaction as well. The skip-level should not be the first person to let them know they're perceived as under-performing. OP: Schedule a 1 on 1 with your direct manager and have a conversation about all of this. 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 co…
sorry, not aware of that acronym, is that a new acronym for FAANG? I could see facebook turning into meta, google to alphabet... can't see netflix in there? is the other M microsoft? Or is it something else?
I immediately hate it.
1. Project time - were expectations communicated up front? What estimation methods are you using? Agile scrum for cadences/daily reporting? Your post reads that you did heads down work for awhile. That is a recipe for disaster for a junior dev. Daily checkins (or at least 3x a week) is the norm for my organization.
2. Requirements - see frequent check ins above - as well as what mushufasa comments as well. A HUGE part of great modern development in enterprise is constantly iterating requirements and getting feedback. This is something I specifically sit down with new college hires. This is not college anymore with a well bounded problem - you have unlimited problem space and you need to define boundaries constantly. One of my favorite quotes is: "the difference between a good developer and a great developer is that a great developer knows when NOT to code"
3. Design decisions - does your group have a design review / peer review process? A junior dev should always have a senior dev review code prior to check in. Your check in's should be frequent (daily is common but there is debate on exact frequency). It should not be weeks particularly for a junior dev.
4. Perhaps your most egregious error is your comment that you should have checked other projects. I assume youre working for a large-ish company. It is imperative you do not re-invent the wheel for every assignment. Particularly for the "glue" or standard pattern parts (which usually amounts to 80% of the work). This is something your manager ideally makes explicit early on (perhaps this was the meeting). I have had lots of frustrating convos where the developer took weeks to solve something that was a known pattern or solution if they just went to the firm's stack overflow or checked another similar projects github.
5. Managers are people too they have off days and can be frustrated with a million other pressures going around. I have definitely had days like that and likely took it out unfairly on a junior dev. More-so if this is your managers boss who likely doesnt deal with junior dev's day-to-day. His/Her expectations are different.
If you still keep getting unwarranted. wrongly timed criticism, I'd say quit. The problem isn't you, and I'd imagine it would be too difficult to establish a good, long term relationship.
I'm not saying this is necessarily always the right approach. It could have back-fired if my manager had judged it wrongly. But what I'm trying to say, is that manager would have never left me alone in a meeting with the PM exposing me to the scenario you describe. Eventually, as I grew more senior it was useful to be exposed to that, but at that point in my career, I really appreciated being shielded from the politics while I just focused on improving my craft.
> 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 assign…
>"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)
Earlier quoted context omitted.
As someone who's done both (dev and dev management), it's more that it's very hard to manage dev teams unless you've been a dev. We have all experienced the clueless non-technical manager who doesn't understand why any of this has to be this way and keeps pushing for "common sense" things like accurate estimates for project development. There's also nothing stopping a good dev from being a great manager, or vice vers…
> We have all experienced the clueless non-technical manager who doesn't understand why any of this has to be this way and keeps pushing for "common sense" things like accurate estimates for project development. 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 e…
"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"