---

Second, let's adjust your expectations a bit. You're expecting to be great after 8 months. Nobody is great after 8 months.

> I am actively slowing the team down or causing problems. I take a really long time when finishing stories unless one of the seniors is giving input.

When I hire junior engineers, I expect them to be worse than useless for about 6 months (because they're contributing nothing of value, and taking time away from more experienced people who do the onboarding), and maybe to be net neutral after a year. Some are a little quicker, some take longer. And I expect them to have a senior engineer (or several) "giving input" forever. That's what it means to be junior; you aren't expected to do anything alone. (Most senior engineers aren't really expected to be able to do anything alone, either; if the senior SWEs on your team are any good, they're checking each other's work and talking through plans/designs with each other.)

> Its hard to imagine anyone who is good at engineering delaying a teams release and causing problems.

I think I'm a pretty solid senior engineer. I've led and managed teams for a while. I was promoted from new-grad up to staff level at a FAANG company, and have consistently gotten good performance reviews and shipped solid code that solved real problems, sometimes problems that more experienced engineers had tried and failed to solve.

With that said - I've caused three production incidents in the past month. We had release procedures that were poorly documented that helped cause two of them. The third was just a silly typo bug that I didn't write a strict enough test for, and that made it through code review. The cleanup from that third one slowed down our release, and had a knock-on effect that delayed a customer-visible product launch by a week. It's a mistake I wish I hadn't made, but I'm also not going to get fired over it. It happens to everyone.

There's a famous quote from Thomas Watson, longtime CEO of IBM: "Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?"

---

Now, to get into the underlying problems - it sounds like your team/company is really, really bad at onboarding and training.

>this team isn't a bad one. I can make excuses all I want, but an experienced engineer joined the same time I did and is doing great.

Part of being more experienced is that you've seen more different things. Senior engineers are a little harder to surprise, because there's a good chance they've seen something at least comparable to their projects before. This makes them more valuable, obviously, but it also makes them qualitatively different. You're not experienced now; you should focus on becoming experienced through the work you're doing. I guarantee that that more senior new hire was useless the first couple quarters at his first job, too.

>I was sometimes assigned stories no one else on the team had done anything like before, so at times I couldn't even ask the senior devs for help.

This is idiotic on the part of your mentor/team/manager. A healthy team will have a backlog of bugs or small features that they've more or less figured out, but haven't had the time to implement - those are the kinds of things you should give to new hires to get their feet wet. If you've been there 9 months, you should probably have gotten through a starter project that's actually productive, but again, it shouldn't be anything new. If you don't feel like they can effectively mentor you, that's a problem with them.

> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.

That senior engineer should be fired, immediately. That's inexcusable. I don't care how needy a junior engineer is, or how many times you've shown them something. You show them again, teach them how to find the documentation, and do everything you can to make it so that they don't need the help. What you don't do is refuse help that they still need.

---

Finally - how to improve. Two things have to happen. First, you need to find someone who can actually mentor you specifically. This should be someone at least a couple levels above you who isn't an asshole and can show you the ropes, who is themselves reasonably well-respected on the team, and you can bounce ideas off of and who you feel comfortable asking questions. In an ideal world, this would have been done proactively by pairing you up with someone more senior to do a project together after you'd been around for a few weeks, but if that didn't happen, and you want to make this work, you'll have to be more proactive. A good manager should help, but if that feels weird, go to someone you respect (NOT the person who refused to answer your questions!), schedule a 1:1 meeting, and strike up a conversation - "hey, I saw you were able to diagnose XXX problem, and you seem to really understand YYY process - can you walk me through how you did that?" People love talking about stuff they're good at.

Second, you need to find a way to phrase the problems you're having as problems with the team rather than problems with you. You can start this with your manager (I know you said the manager has been out for... four months?... but there must be someone filling in). If you don't know how things work because there's no documentation, tell them that. If you don't feel comfortable asking questions in meetings, tell them that. I've gotten both of those comments from junior engineers before, and we took them as serious problems, and fixed them - that's important feedback, and any leader worth anything should see it as such.

Oh, and keep asking questions. It drives me nuts when anyone - junior, senior, engineer, manager, PM - doesn't ask questions. The alternative is that they'll just guess, and that doesn't do anyone any good.

Your experience is not unusual, it seems that many tech companies are terrible at onboarding not only juniors but devs in general. It seems almost like a systemic problem to be honest. Many companies are good at this but too many aren't.

I think one thing that might help is more industry focus in CS degrees. CS is great but a "year in industry" and vocational training would be welcome for many as part of their training. Data structures and so on are great but until you've worked with the plethora of tools and processes you will encounter on day one in the industry, being thrown in at the deepend will be baffling and overwhelming. CS degrees and most day to day work as a dev are very different. A practical heads up on things like cloud infra, monitoring tools and CI/CD pipelines (to name just a few things) would be good.

The point isn't to make companies better at onboarding, it's to stop juniors entering their first job feeling completely at sea.

I will be honest if on month 9 someone asks me how to stick some code onto the integration test platform for the 10th time I am going to make a snarky comment.

Similarly, if on month 6 someone asked me how to log time or make a jira ticket I would probably be of the opinion that we are pretty far along for that kind of basic workflow not to be known.

There are limits to how long a new employee gets to be useless at everything - so without knowing which process we are talking about I would probably hold off on that firing button

My response would be to answer the question when they ask it, then wait for a calmer time and ask the process questions if you need to (or better yet, ask the junior employee's manager first):

* "Hey, it feels like we've been through X a few times now. I'd rather you ask if it's not clear, but is there something that isn't clicking for you in my explanation?"

* "I was a little surprised when you asked me about X, because that's something that we usually cover in first-week or first-month onboarding. Was it not covered then? Is there something unclear in the documentation from then?"

I feel ya. I've been there. But now what I do instead is sit down with them and have them work up a document with screenshots (if necessary). We then go back through the process using the document as a guide to fix any mistakes.

Bonus: Everyone can use the document.

I would rather spend time 9 times, or 10 times, and make sure the person understands it. However, if the solution is screenshot from 1st attempt itself, I am sorry by the time we get to the 9th version, I am at my limit both with the junior and the manager.

Imagine thinking a company is going to fire potentially high value senior engineers for getting frustrated with junior engineers. Do the seniors need to chill? Sure. Fired? Come'on.

Pretending that underperformance is OK doesn’t help people - it’s the kind of thing that leads to them being put on PIP “out of the blue”.

Junior engineers aren't expected to do this alone, your senior engineers should be there to help you as you learn to do this yourself.

For me, it's still a bit intimidating asking questions to people 2+ levels above me, but the biggest thing I've learned is that those people want to help me. For more senior engineers, it's their job to help you: You're not wasting their time.

My first dev job came after mid-way through a PHP course in college. Prior to this, I had also completed courses in Java and C++. At $10/hr (boy was I desperate), I was hired on to replace the outgoing fullstack web dev (basically at an email advertisement spamming company).

I was supposed to "get up to speed" with my replacement within a couple weeks of being hired. It was unwritten and unspoken, but basically I was to become the ad agency's sole fullstack web developer. At the time, I knew zero front-end and the PHP that I did know was murky (5.x) at best.

I had no chance in learning enough to replace the then sole fullstack dev and quit because, I just wasn't ready at the time to absorb front-end web technologies in that short amount of time. Boss warned me that when I give a deadline for a project, it may as well be prophetic - however, I was scared sh1tless giving any kind of projection on any kind of project with me as the sole developer doing things I've never done before; it seemed to me to be absurd.

Fast forward a few years, I just couldn't land any programming/web job because my experience didn't line up with what was requested - even when I thought I was around 70%+ qualified. After a while, I got fed up with the esoteric requirements, even for junior positions. It's exhausting reading through countless job listings trying to find something that may fit. So, to this day, I just code for fun - like a locally hosted movie server that I prefer over Plex. Sorry for the ramble. I'm estranged by the industry in regards to hiring for junior positions.

I'm long past my junior days and this still bugs me. In case it helps anyone else, now I give my estimations with two [low, mid, high] qualifiers next to them:

1. Uncertainty: this is where I signal whether I think the task is well defined and we have the expertise to deal with it or not. The estimation gets a multiplier (however stupid I think the task is) when this is not low, and I make it clear that uncertainty can be reduced by either better defining the task or breaking it into an "exploratory" phase (where we try to come up with a tech-demo to get a better "feel" of that new thing) and then an execution phase that will turn it into a reality (which will be estimated _after_ the exploratory one is done).

2. Environmental risk: this signals how external factors can impact the task (e.g.: the client is complicated to work with, this necessitates collaboration from a third company that may or may not be fluid, we require key people from the team that is busy doing something else, etc.)

I've found that this both reduces my anxiety and tunes the client's expectations much better (it becomes much easier to explain after-the-fact why two tasks that had a similar estimation ended up taking wildly different efforts).

To add an even more backing to this, here are some tasks I gave to a new hire.

+ change four placeholder images for the correct ones, and learn the process to check it in

+ find out why one text element has the wrong font

+ change the favicon

This demonstrated to me that he was familiar with git and he said smart things about react so I gave him more. Your manager sucks not you, stay in there it will click in time....unless you find a better role for you

As far as actionable advice goes, it sounds like you should be documenting most of the process things you're unaware of. This acts as a reference doc for you while you do things (checklists help avoid dumb mistakes, if you find that being common), an onboarding tool for future hires, and a consensus mechanism for your team.

Hmm, by the 60th time I’ve taught them how to make a commit in git I’d probably be pretty done.

I agree with the general sentiment though.

The only thing I would take issue with is the first paragraph where you try to calm down the OP:

> Okay, first things first - take a breath. This is not that big a deal. If you're at a company that's big enough to have a PIP process, then there are two possibilities: (1) it's well-established enough to know that junior engineers aren't productive for about a year after hiring, or (2) it's completely incompetent. If it's (1), even if you actually are way below average, you still have some runway left. If it's (2), they almost certainly have enough of a reputation that you can "fail" at your current job without it really harming your long-term career path.

This way things are at least in US, is next to impossible to harm your long-term career path by failing at one job. One needs to be at least prosecuted to harm their long-term career.

OP, if tomorrow you'll get fired on the spot, in a year time frame your most-likely will find yourself better of than you are now (and, frankly, likely to be better off if you stay at your present company).

Also, unless the sprint duration is four weeks and there's no dailies, I really can't see a junior being able to delay anything by 1 month in ANY sane company. Unless you're preventing people from working, actively sabotaging things (and skipping code review processes!), I really struggle to see how a Junior Developer would be able to slow a team down like that. If this is happening, that's a huge red flag, and you're not in a good team/company. I really don't think you're the problem.

> When I first joined I struggled to even know how to start things.

That's how it is with new companies. I'm at this for 20 years and at some places it took me six months or more to unravel the massive amount of stupid code and processes before I was productive enough.

> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point

I'm a team lead and I ask basic questions all the time. Sometimes to juniors or interns.

What kind of things we're talking about? Opening a PR? Simple programming questions? Opening up tickets in JIRA? This is basic. But deciphering convoluted code or navigating convoluted processes? Using an arcane shitty ticketing system? That's not really basic level anymore. But even if it were, that senior engineer was out of line...

PS: If you think we're being "nice" to you on the replies out of sympathy, it isn't. This is for real. HN is the kind of community that would call anyone on their bullshit.

If you had to ask someone how to open tickets? Create a short doc or wiki with those instructions.

That's a good way for even a junior engineer to start producing value, for established teams they often have tribal knowledge without realizing it.

Also you'd be surprised how often basic questions actually are not basic at all, when instead people are all assuming everyone knows the answer and are too far in to ask the question.

I had to ask at our last planning "wait, what, where do add the red flag to JIRA tickets". Considering I'm the one who's been conducting meetings and co-managing JIRA, and the one who red flags most stuff, that was 100% a brain fart. Someone telling me "you shouldn't be asking basic questions" not as a joke wouldn't go well.

Unless you're asking the same question every single week, that's not a problem. I doubt that's the case since OP already said his problem is he asks too little.

Ideally yes. But realistically no.

Ideally there would be management available and coaching on any junior SWE, or at least you'd hope so. Realistically he may be looking at the business end of a PIP.

Ideally there would be blameless post mortems. Realistically there's no such thing, if you fuck up bad enough you're going to be shown the door.

Ideally if you're a great software engineer you would be with a company for the life of the company. Realistically, the politics and toxicity of workplaces limit the career of any employee.

A junior being able to delay a process for a month means gross incompetence from everyone else involved.

We as developers have the duty to push back against stupidity in the workplace. The labour market is in our favour, those companies should die.

It's kind of like poker. The moral is: if you can't see the sucker they're going to fire next, it's probably you. Basically, don't be the sucker at any work environment.

That, or the junior taking WAY more responsibility than a normal junior and deserves a fantastic raise.

> I was sometimes assigned stories no one else on the team had done anything like before, so at times I couldn't even ask the senior devs for help.

> my manager has been gone since December

> I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.

To summarize: you have no prior work experience, you're assigned tickets beyond your abilities, management is MIA, your team doesn't support you, and people make you feel bad for trying to improve.

It's not you, friend.

As a junior engineer, a lot of responsibility falls on your environment to help you grow and gain more independence in your day-to-day problem solving. Your environment is demonstrably not living up to that obligation, and they should not have signed themselves up for it if they weren't prepared for it.

I've been on teams that have been similarly inhospitable to juniors. Several of us went out of our way to provide that support, because it's necessary. But nobody higher up had planned for that need, so our schedule was impacted anyway.

It's not you. Try to look for other teams (possibly within your current company!) that are willing and able to nurture your growth. Juniors aren't independent; that's almost definitionally the difference between a junior and a senior. Cut yourself some slack, and try to expect more of your working environment.

As to your other points, it sounds like it may not be a good team for you to learn on because everyone is expected to behave senior.

For what it's worth though, I think you have a good attitude. You're willing to put in the work and learn, and you're practicing self-awareness about what you don't know and need to know. You'll be fine. Just try to interact with as many senior people as you can and ask questions. Don't be a jerk when you start getting some knowledge. Keep learning even from those people who are less experienced.

He was hired behind my back, and began a React project using some "admin template" that we didn't need, and now it's a dirty mess. He had a wedding+honeymoon planned before he started with us I guess, which took him out 2 weeks shortly after starting. But he also missed half days of work whenever a contractor showed up at his house. Meeting calls were attended with of his wife making outbound sales calls in the same room and frequently with his dogs barking like crazy the whole time. He often traveled on the weekend and emailed that he "got stuck" and wouldn't be in until Tuesday or Wednesday. On days he showed up for a full day it was typically 10:30am to 5:00pm. I had to change pretty much every code commit to use it.

If you're showing up and producing anything of value there is probably someone around who can help you stop hitting the process bumpers. My guy wasted my time by not showing up often enough to get support.

Having him hired behind your back is obviously not his fault. Wedding/honeymoon should be a non-issue as well as long as management was made aware. Being expected to show up to work regularly and in an environment free of distractions should be a no-brainer, but for lots of people (especially juniors), working from home is something they aren't used to.

As far as the work itself, as a junior, why was he starting any projects at all without supervision/guidance? All of his code should have required PRs (maybe they did - again not enough details?) Juniors generally don't know how to write production quality code, it should be expected that code will be reviewed and issues addressed before being merged into the codebase. They're juniors because they don't know what they're doing and as seniors/staff engineers it's our job (whether it's fair or not is irrelevant) to help them get up to a baseline of proficiency.

Seems like the company and the junior were both contributors to his failure.

For a Jr remote SWE position, I would expect heavy pair programming the 3 first months.

There's a basic expectation that people should be actually showing up to work. How can you possibly vet during an interview that someone will be flaky like this? Sometimes people just don't have a good enough work ethic that meets the basic expectations and no amount of ramp up plan or initial feedback is going to produce changes quickly enough to make continuing the relationship worthwhile. People like this are just constant ongoing headaches. Thankfully, they're in the extreme minority in my experience.

Although I would cut some more slack for the background noise during calls. Not everyone has separate rooms they can work from. Instead, the company should have sent him a good headset to use which would mute background noise. Sometimes my coworkers will apologize for their dogs barking and I'll say I can't hear anything when they are using a good headset.

No question about that. We ended up pair-programming well more than that and things just weren't clicking.

First off a Jr shouldn't be working on a project all by themselves, obviously. That's on management to fix, an employee shouldn't be expected to perform at a higher level than they were hired at.

>Meeting calls were attended with of his wife making outbound sales calls in the same room and frequently with his dogs barking like crazy the whole time.

The idea this would happen "frequently" is crazy.

As a meeting leader myself if someone showed up to a (virtual) meeting with such noise/distractions in the background I would absolutely stop the meeting immediately and let the employee know they need to find an appropriate place. Once they did I'd resume the meeting. If claimed they didn't have access to a quiet/appropriate place at that moment I'd have them leave that meeting (or at least mute themselves) and speak to them offline about appropriate behavior during meetings.

The stuff about him missing work (presumably without using PTO or LWOP) should be met with an immediate formal reprimand. Any other instances after that should be termination.

Not the employee's fault...

> But he also missed half days of work whenever a contractor showed up at his house. Meeting calls were attended with of his wife making outbound sales calls in the same room and frequently with his dogs barking like crazy the whole time. He often traveled on the weekend and emailed that he "got stuck" and wouldn't be in until Tuesday or Wednesday. On days he showed up for a full day it was typically 10:30am to 5:00pm. I had to change pretty much every code commit to use it.

Those are issues where firing would be appropriate if they happened more than a couple times. Especially if they happened early in the job (aka probation period in most countries).

"You're not working the previously agreed amount, quantitatively!" is probably the least controversial reason for firing someone.

Agreed. I happen to work for an imperfect company, if you can believe that.

I did my post-mortem homework, and certainly concluded I could have done more and sooner about the situation. I was too busy trying to code for both of us to put my management hat on when I should have. Lesson learned!

Good eye.

I'm gonna come right out and say the thing most people here are too polite to say:

If your description here is at all accurate, you're on a bad team, a sinking ship, and your team is scapegoating you (and maybe other junior devs) for their downward spiral. You should be looking at moving to a team or company where you can grow.

Like, your manager has been gone since December?? Who's in charge? Who's assigning these stories to you? Who's making sure these mistakes don't happen again?

And I'm also going to say this: YOU have not caused any production delays. Whoever put you in a position to do things you weren't prepared to do is. But really, most likely: it was going to be delayed anyways and if it wasn't those incidents it was gonna be something else.

As for the senior dev who you think is doing great: either they know this is a fucking gong show and they're already looking to leave, but are keeping it professional, or they're coasting along for other reasons. Sadly, the "This is Fine" dog mask is one thing you definitely learn as you get more experienced in tech.

This sounds like it’s your first job so people should be forgiving and helpful. If you are at big corp (since you mention PIP) then why isn’t there a better onboarding?

Anyway yes you should probably be writing more stuff down. A lot of what you’re learning isn’t taught in class which is the processes and dynamics of the actual team and company.

So a lot it would be new and an adjustment period, not only to the job but work life in general. Adjustment to my first job was hard. Being in the same work space for a full work day was difficult when friends were just studying. Interacting with people twice my age. Being the youngest person in the office.

With this new environment comes new difficulties so what comes as common knowledge or second nature to experienced employees can be confusing or hard to grasp for first timers. Having said that, not grasping this or acting forgetful or needing something to be explained multiple times can come across as incompetent or often rude. When that’s happened to me in the past it’s given me the impression of “this person clearly does not give a shit or is stupid because this is the 5th time I’m explaining it”.

So yes I recommend taking good notes.

Other strange flags is your Manager being away for so long. This whole post reads as things you should bring up with your manager. Not having a manager around since December may even be something you want to bring up to HR so you transfer teams.

So yes, definitely write down every process and take notes on everything you learn. Also review and summarize your notes so they're actually useful. That way you hopefully won't often have to ask the same question twice. But any time you feel like you're spinning your wheels or are unsure what to do, I'd encourage going ahead and asking. Over time you can also probably identify who's best at answering what kinds of questions, ideally allowing you to ask the right people, while not pestering any one person too much. But keep in mind sometimes you can actually be saving the senior devs' time by asking a quick question early rather than having a bunch of wasted work or delays later on.

This requires motivation, capability, and opportunity from the team members. Maybe no one cared, maybe no one was capable to, maybe no one had time.

You should have received more active immersion from your team from the beginning. Since they let you down, you still need it. If they seem unwilling to admit that maybe they are partially responsible for you still needing help, you might be better looking for a new team that sees collaboration as a two way street. I think you should be seeking mentorship.

This is a bizarre comment to make by that engineer. There never comes a point when I would say to someone you shouldn't be asking this.

Stop worrying and focus on finding a better team to grow in.

The only thing worse than a junior asking too many questions is a junior not asking questions. Seen many times people taking pride over quality and spend weeks in their own hole coming out in the other end delivering completely the wrong thing.

What is being asked? If it’s about processes and system design perhaps there is some architectural documentation, checklists or automation that is missing.

You may also have to realize that learning new tools, on your own, is part of being a swe. You are not in school anymore and will not always be given detailed instructions on a silver plate. Often you have to read tutorials and stack overflow yourself. The seniors should guide you into picking the right tools, best practices and the higher level design. Simpler questions like “how do I iterate a list in react” are things you need to figure out yourself.

If you still have trouble discussing feedback on your work and higher level goals or system design with seniors, it might be time to go look for another opening.

Publicly document the things that you 'discover'. Things you figure out or need others to tell you are in all likelihood going to be something any new junior developer coming in will need to 'discover' as well.

Do this publicly, in the companies wiki for instance, as a way to show that you are learning. This will also be a way for you to bring actual value to the company and team.

Finally, as has been mentioned we developers who are not new to this can still break things on production.

I once broke NFC payments for all of the Android users that were using my employers banking application. While not an ideal situation, as long as you learn from these events then no one is going to throw you into the guillotine for them.

You can always ask for help, from anyone on your team, and they should do their best to help you. That includes saying "I don't know, but I'll help you find someone in the company who does know." If you're breaking new ground and doing someone no one in the company has done before then a senior should be working out how to solve the problem with you - how is anyone going to review the code or accept the solution if a senior hasn't help work out a good approach?

This is a massive red flag that there's a chronic problem with the engineering culture where you work. Teams need to pull together to build a great product; if a junior is being left to build things on their own without advice or assistance then that isn't happening. The product will suffer. You should bail ASAP.

Also, for fun, pop a link to this thread in the team chat on your last day. The seniors and management need to understand that they're getting things very wrong.

Yup, or, just have the expectation that this problem may take longer than whoever is making projections thinks. What else can someone do if it's completely new territory, and apparently no senior dev wants to touch it?

On that note, I'm wondering why a senior dev isn't doing these stories. I suspect it's because the seniors don't know themselves, and they're just throwing someone else at the problem to avoid dealing with it themselves.

For the love of God, yes. Do you just intend to memorize everything? Are you assuming that you'll never get interrupted or pulled away from a task? Are you going to memorize the task backwards in case you need to revert?

Ok, I think you get my point by now, please create a playbook (checklist) for every critical process that you're responsible for. This will make life so much simpler for you.

Basically you should create a system or process that turns your most consequential tasks into the most boring part of your day.

However this is the most important one. Yes one should be able to lean on others as a junior, ask questions and so on. But in order to have _any_ progress and confidence at all one has to do _this_.

Writing things down, even drawing, helps to think clearly and to remember important details. Even just questions, assumptions and so on. It helps to focus and to organize.

Checklists/steps are great too, because one can see very quickly how they initially lack very important steps. Our brains are very selective when it comes to details that are not grounded in experience, or have not been used multiple times already.

The third benefit is hard problems (that may or may not have simple causes). The back of our brain will pattern match and process the notes during sleep or other activities - and suddenly solutions appear.

Never be afraid to ask. Most importantly be transparent in what you are doing and what you intend to do. If you feel left stranded without enough guidance then make sure you let the relevant people know. If you are stuck on something, say so immediately.

If a mistake can be made or is made, then make sure you don’t see it as a personal failure but as a process failure. Suggest that the process should be changed to safeguard against the same mistake. It’s something you as a newcomer can provide a unique perspective on.

If you are given unspecified suggestions you should “improve” or “do better” or “make fewer mistakes” then leave, quickly. As a jr dev you need a good environment. If the company can’t provide that, you should find an employer that can.

That's what a good company expects from Junior SWE's, what is your manager's expectations? (it should be clear and explicit)

> and I made 2 costly mistake back-to-back that is pushing back the release of a production feature by a while month at this point.

That's what qualified seniors expect from Junior SWE's, where was your team?

> I was sometimes assigned stories no one else on the team had done anything like before, so at times I couldn't even ask the senior devs for help.

Seniors aren't good because they have done specific tasks before. They're good because they're able to adapt their wide past experiences to new unknown ones. Perhaps you don't have a good team?

I generally advise my Juniors that their main job is to 1) Invest deeply in learning, RTFM for everything they touch, do laborious but educational things (eg: read the diffs before vendoring a new version and look at what code will be affected in our current impl). The compounding interest of learning lots early on is worth so much more than learning something late in career.

This is wrong thinking on your part. You 100% should be asking senior devs for help with these things. The skill of a senior isn't that they've done something before, but that they know how to approach new problems. So you're asking them for help in, how should I be thinking about this new problem, or how would you try to approach this problem?

If your senior devs can only go do things they have done before, then you actually don't have any senior devs at your company, you just have a lot of junior devs who've been working for many years. So, at that point, I'd recommend looking for a company that does have senior devs, that you can learn from.

> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.

This is both mean and unhelpful. And possibly a sign that they don't realize how bad they are at training a junior.

The senior dev is toxic. Any member should feel easy to ask any questions, no matter how experienced they are. It's almost always better to ask questions immediately.

I've also made mistakes by not asking questions.

I joined a team as a senior dev and worked there for more than ten months. Sometimes, I felt like I didn't understand very basic contexts in the meetings. I couldn't ask what they were talking about because I was afraid of being seen as an incompetent dev.

It turned out that they forgot to invite me to one of the most important Slack channels, where the product owner, the marketing team, the executives, and devs had discussions on important business decisions and the direction of the entire dev team. I was the only member who didn't follow the channel, so know nothing about the important decisions.

We found out that after ten months, and they apologized for the mistake. And they even prized me for being productive despite not knowing the decisions made in the channel. But I was really ashamed of myself. I felt like I lacked some basic context a dozen times but never asked "sorry, what are you talking" even a single time. Instead, I pretended to understand what they said.

Once I followed the discussions there, I became more productive due to much fewer communication errors on the business decisions and direction of the dev team. Since then, I've tried to ask any questions as soon as possible.

Maybe you should quit and find a team more able to help you learning? That kind of environment requires safety, both moral and technical. For instance, you should ask those kind of questions to your manager, and get effective help.

In the meantime, it sounds like you could work on two areas.

First, create a documentation on your work infrastructure and processes. If it exists, read it in order to complete / update it. If you don't know it, you will learn it. If it doesn't exist / is incomplete, that will give you more grounds to get the answers you need from everyone else. Also ask why the process /infra was made that way, what do they wanted to accomplish, did they succeed in their opinion, what could be improved on ?

Second, you could improve on your work quality by putting more checks in place:

- write down the "definition of done ": how will the world be when your task is complete? That will allow you to check whether your work is correct. For instance, the definition of done for an account request is access at the qa level. Does my request do that? No, since I asked for a prod level, but maybe it's the same thing? Let's ask for the qa level as requested and go ask the documentation / someone about the difference. - for production changes, if possible try to filter out as much as possible the resources you don't need. If the ui is not enough, write scripts

The main idea there is to have the Swiss model of errors in mind : https://whatsthepont.files.wordpress.com/2013/09/20130926-22... For an error to happen, it must go through all slices controls. Add more slices !

What does this mean? Surely you report to someone, and this person is accountable for your work. If your manager is on leave, they should have assigned someone to act on their behalf.

At this point in your career you should have weekly meetings with your manager, and the feedback you're looking for should be communicated in these meetings. This person is responsible for creating the environment to let you learn, grow and succeed. Something is not right here.

It was an incredibly shit work environment. 0 onboarding, sink or swim. My buddy just ignored me most of the time.

What does NOT feel normal to me, is that you are just assigned stories and that there seems to be no one who's there for your questions, double-checks your work, and shows you the ropes. Places I've worked before, new employees would always be given a buddy - a more experienced programmed to act as help and mentor. Someone who could take a junior under their wings. That wasn't done out of kindness either - but purely for business reasons: new employees get up to speed faster, become more efficient, and there's less costly mistakes, when someone is looking out for them.

The biggest problem I see with the no-help approach though, is that the fear of making mistakes creates a company culture that stifles innovation.

If you are the only junior SWE, then the problem might be that they were actually wanting to hire a more experienced person. Perhaps the manager who has since left was trying to save money by hiring a junior instead of an experienced person who would have cost far more.

To your point, this is causing you distress, and in a sense that's a good thing! harness that feeling to improve yourself. The times in my career when I grew the most is when I made big mistakes or received tough feedback: I used the pain to force myself to avoid it from repeating.

There is a lot to unpack there so I'll focus on a few points.

Only you can judge if your team is the right place for you at this time or not. It should never be too late to ask basic questions. Heck, I've been in my team 2 years and this week I asked a colleague to explain to me some basics about how our system works. If they judge your or shun you for asking then you know is time to move on. But if you don't do you'll never learn.

Not to sound too harsh but if you made the exact same mistake twice (or more!) it's on you. When I see colleagues making the same mistakes over a over it certainly raises some questions about their performance. It's ok to screw up and I've done plenty, but make sure to learn and correct for the next time. How this looks like is context dependent, but it might be changes in you (e.g. being more careful), changes in the process (e.g. more automation), etc.

Lastly you say it's hard to know what's a junior error and what isn't. It doesn't matter. What matters is that you made a mistake and should learn from it. Not making those mistakes is part of your career growth.

I understand that all of this is easy for me to say but hard to do. You seem to be in a low point and facing mistakes a criticism is emotionally draining. You should start by practicing the cycle of building confidence [1] so that you can use that surplus to tackle these problems. Find something you are an expert at and give your team a talk about it. If there isn't anything, find a part of your system and become an expert in that. Find something you enjoy and brings value to the team (e.g. writing documentation) and become an exemplary practitioner. Even small wins go a long way.

[1] https://www.google.com/search?q=building+confidence+cycle&sx...

I wouldn't necessarily leap to this. If the mistake is like the op said (doing something in the wrong environment without realizing) I'd lean more towards a system problem. Why was it possible to do this without realizing? Why is prod the default? Why wasn't there confirmation? Why is there something that relies on peoples memories or undocumented knowledge?

When I come across these types of things I fix the system/docs/process. I can only do that because I have the experience to recognize that's the problem, the confidence to call it out, the clout for others to agree (instead of blaming me), and the technical ability to execute.

It takes time to build that up, and it's one of the differences between jr and "senior" positions.

Sometimes I recognize these situations before but often it's by making a "dumb" mistake, which I still do despite having nearly 20 years experience. I generally don't make the same mistake twice but that's only because I make it so I literally can't.

This. The first mistake in a class of mistakes is a freebie, and even if the outcome was pretty bad, if it was also a process failure, it's not on you. After that you should know better. Too many different mistakes is also bad because it shows you're not being careful.

Think about how actions might be risky. If the process is error-prone, triple check your work. If you're not sure if something is right, ask. There will be situations without guardrails, and you need to learn how to work without them.

Stop that. You have nothing to be ashamed about. You have tried really hard despite many times being knocked down. Making mistakes is normal, and not doing well when not being guided is also normal. These are not things that reflect badly on you as an engineer, let alone as a person. So stop beating yourself up. Then ask for help. If no help is forthcoming either escalate to your manager's boss, or quit and find a less shitty place.

I know with todays inflation in "senior" titles, it comes earlier, but personally, I have low trust in anyone who hasn't done the job for 10+ years.

As more concrete advice: Own the fact that you are green & new. Ask the "dumb" questions. If you are unsure on how to start something, ask "what would be a sensible, concrete first outcome on the way?". Ask, ask, ask.

Also, as a junior, it is immensely valuable to pair on problems and code with more senior members. So if it's not a thing, maybe suggest if you could try pair programming from time to time in the team. It reduces bugs and errors even for very senior people.

Finally, mistakes happen. Sure, try to avoid them, but don't freak out when they happen, just find a solution to correct it. Every mistake you make is a mistake you are less likely to make again (but some of them, you will make again, and that's fine). If you are able to do expensive mistakes on production systems, I'd suggest it's more of a process problem than a people one.

Main thing about pairing is communication: one person "drives", while both people talk through what they are doing/thinking. The non-typing partner can be a "map reader" of sorts, thinking ahead. It really will be different from person to person.

The benefit of remote setups with two people working the same code in their own editor is one person can run ahead and write the tests, while the other writes the implementation code (and both communicate what they're doing).

What either setup has had in my experience is constant communication between the parties.

This is a decent article as well: https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effec...

The technical struggles you've described sound like they're about par for a junior dev. You made some costly mistakes and you think you could achieve some tasks faster? Honestly, I would find it suspicious if a junior dev isn't experiencing those kinds of issues.

However, if you get put on a PIP, it's because someone in your management chain has the perception that you're underperforming. You'll have a lot more context about the political environment -- it's hard to gauge why senior devs might be brushing you off. If they have the perception that you're not achieving up to your expectations, that's going to show up in their own private conversations with your manager (or whomever handles your evaluation). If your manager has a negative perception of you, the healthiest thing to do is to find a different team.

Perception is Reality for your manager if they put you on a PIP or give you a bad performance rating, even if you are performing well within expectations. Perception is Reality for your coworkers when they either do or don't support you as a team mate. Unfortunately, when it comes to imposter syndrome, Perception is Reality once again.

An exercise you can do that will likely help is to look at how others are performing. Actually check to see how much code others are landing, or how many bugs others are fixing, or how many stories others are completing. You might have the perception that you're not performing up to the same level, but you can look at some statistics and get a better idea of what the Truth really is.

To prevent bad changes going to production, put more checks (more people, code review, test gates, etc.) in place. Everyone who plays a part is (equally) responsible for the change in production. No one should have to code and push to prod alone!

2. These are generally not people problems (except socialization issues). They're process problems. Want to fix it? See #1.

You are currently being mis-managed or -mentored, based on the problem statement. Doubly true given you're manager-less and not getting oversight from more senior staff.

But don't worry about blame.

Focus on how the process allowed a problem and then fix it. You probably don't need strictly written rules so much as a buddy system. That helps the whole (current and future!) team (and doesn't piss anyone off with rules).

Also, please understand that working in industry is almost always nothing like school was. Except that everyone still likes pizza. And sometimes they mention Big O. ;-) Anyway, everyone goes through this. There's usually a mentor around to talk people off of ledges, though. Try to be the mentor for future yous so that they don't feel so alone as to post something like this on HN!

Yes, anyone can learn to code. No, not everyone can become good at it. Without more nuance it's hard to say - but it sounds like you might need some training in critical thinking. You may be in an industry segment that you're not suited to. You may be using a language that you don't think naturally with, or which isn't suited to how you think or organize thoughts. You may need to improve your organizational skills, or perhaps you're just not good at that. You may not work well in the kind of company structure you're in. While supportive comments are good, take a critical but objective look at your shortcomings and evaluate if you can improve upon them. Seek mentors outside of your current company.

Software development isn't for everyone, just as any trade isn't for everyone. I'm trained in and went through apprenticeship to be an electrician (seriously, I gave 4 years to that), and I know damn well I'm not a very good electrician.

For your situation, it might be a an excuse to ask “n00b” questions again: Say you’re assembling resources for yourself and future hires to avoid mistakes in the future

Anki for both general knowledge (useful git flags, short code templates) and sometimes project-specific things (tagged with temp so I can pull from rotation in a few years)

Don't conflate being a good programmer/engineer with being a good employee.

In my experience, most software companies are hopelessly broken. They have complex processes that no new joiner can understand. In fact, almost no one at the company understands.

The experienced engineers who do fine probably don't understnad the whole process either. They just know to avoid screwing things up, for example, by being super extra careful before doing anything with the production servers and double/triple checking with other more senior engineers before doing that.

In general, I strongly believe that you will not learn how to be a better engineer from your company. Improving your engineering ability is something you can only do at your own time.

The only thing you can learn from being an employee is how to be a better employee. In sense, you can only be a good employee if you are well adjusted to all the broken processes. As you might guess form my language, it's not something I recommend that anyone should aspire to do.

Very true. I've been working in IT since 1994, initially as a programmer, later as a sysadmin, and nowadays as a cloud-guy.

In all my jobs I've done good. Except one. I just didn't fit in. Tasks that even I could recognize as being simple were a real struggle, and I was frankly doing a terrible job at them.

I've always fit in, I've always had both people and technical skills, but in that one particular company I was doing a terrible job and it was obvious to everybody, and myself.

The topic of a "performance improvement process" came up, but I admit I'd spent so many weeks struggling to get better, to do better, that I just quit the day it was raised. It seemed obvious that for some random reason I just couldn't do the damn job, and it was better to admit defeat gracefully than stretch it out over additional weeks and months.

I've done a lot of reflection, but even now I don't know what was going wrong, or why I was so bad. All my other employers have been happy with me, and I've always felt proud of my work.

I guess culture/skills fits are real, in a way I'd not appreciated until then. Happily the very next job I accepted things worked out wonderfully from day one ..

So then what process will have prepared you? None, and it will have to happen on the job. It's part of being a junior and it's part of hiring a junior for the company.

The company should have had processed in place to shield you from being able to affect it like you say you did. Seems like you are working in an environment not suited for a junior.

Remember, everyone has blind spots. Seniors especially can have blatant and surprising ones.

Where I'm at we know our documentation is bad and our systems complex, so diligently treating every question, whether from a junior or senior, with respect and answering in a manner that teaches and inspires confidence is seen as a duty. A "simple" question will often prompt workshop-like answers with whiteboarding, etc.

When you walk away from that conversation you should feel good about having dared to ask what you might have thought was a "stupid" question. The next time you ponder whether to ask for help or not you should hopefully feel less hesitant.

Anyone brushing off or not taking a junior's questions seriously should keep in mind that they too have blind spots.

I believe very much that there are no basic questions that are too basic to ask if you don’t know the answer. As an experienced engineer, I go out of my way to ask basic questions constantly so everyone else knows it’s OK, and you wouldn’t believe the number of times doing so has shown that the basic thing isn’t basic at all.

> one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.

Just be honest and own that: “I realize that, but when I was learning this the first time I didn’t realize… so now I’m trying to…”

If you’re worried about asking too many questions, one thing I do, which is a variant of rubber duck programming, is just opening a text document and start writing the question with as many details as I know or can find in my iwn already included. This process will certainly involve doing research, but since you’re writing a question and not “coding” other parts of your brain are active and you end up with that new perspective that answers the question for you. If not, you’ll still have a useful question thats well crafted.

I don’t know about anyone else, but I’ll take a junior dev who is curious over one that is cautious any day, but they also need to know when to say they need a second pair of eyes if exploration in some area is or could be dangerous.

One last thing I’ll say, which may not apply to you at all (but it certainly did for me): the more I hid my actual status from people when I was junior the more stress I made for myself and the more stress I made for my manager. Managers want their ram happy and to hit deadlines, and they can’t bring in extra help if they don’t know there’s a problem. Being late with something is, every now and then, just a part of the job, and the sooner that is communicated the better for everyone.

You're literally getting no support from your team. No manager and no assistance from the senior members of your team is absurd. How are you supposed to get better?

Feel your feelings (like "I feel kinda like a disappointment") but don't project what you think other people are feeling or thinking unless/until they give you direct evidence otherwise like " I am not seen as reliable and definitely not known". Is anyone saying anything directly like that to you or strongly suggesting it?

As far as the QA/Prod issue, HOW where you supposed to know? How is the next dev supposed to know? If your team (i.e. the senior devs) aren't providing documentation or operating procedures, then they're failing you; not you failing them.

> I was sometimes assigned stories no one else on the team had done anything like before, so at times I couldn't even ask the senior devs for help.

Again, if you're tackling issues that the senior devs haven't seen, then how are you working "slower" than them? They have no frame of reference of how long it should take.

So how do you improve? You need to find a mentor (or even a therapist?). Someone, anyone who you can talk to and get an objective perspective on things. You're new (and that's okay!) but that also means that you don't have a reference for what's okay and what's not. It's not that you have imposter syndrome, it's that you think that causing sprint-slowdowns or prod issues is something unique and awful. They're completely par for the course.

As far as the whole PIP thing, if you have no manager, who's going to put you on a PIP? If anything, you need to be raising a stink of how you're a junior without a manager and working without senior dev support.

The reason why that senior dev is being an ass, or why your manager is MIA, or why your team had open headcount for you in the first place, may very well have nothing to do with you at all. Especially if you don't have a manager, it can be helpful to understand how your org actually works. First, it'll make you feel better (which is important), but crucially it informs you on how you should spend your time and what to focus on.

- breathe

- ask for help! you've done nothing wrong. one of the core responsibilities of experienced engineers is to help out less experienced engineers - if they don't know how to do things then hopefully y'all can figure it out together. "Hey _____, I was assigned ______ and I'm having a hard time figuring out the best approach to take. Would you be willing to sit down with me to talk through approaches?"

I can't stress enough how many of my "failures" in my career were due to me being too stubborn / proud / egotistical / etc to ask for help because I thought it would look bad.

If your senior engineers and leadership aren't setting you up for success that's a problem, but other than that…breathe.

From reading your post, my intuition tells me you’re learning & adapting at an above-average rate within a pretty average dev team.

Focus on the meta things:

- Eat well. Snack on celery & carrots.

- Sleep well. Minimum 7 hours a night and a consistent schedule.

- Divide your time clearly (have fixed work time, fixed chore time, fixed recreation time, and a flexible buffer that can be applied to whichever of those three calls for it).

- Practice async communications. Ignore all emails & messages (do not disturb mode) while focused. Set an hourly reminder for checking emails (see Alarmed on iOS). When enough accumulate, deal with them in batch. Advertise to others a means which you can be reached immediately for urgent matters (I let phone calls through DND mode).

- Hold your tongue when your assumptions are unfounded. Respond later.

- Collect articles (both work docs & internet articles) into a reading list. Sort it briefly each time you sit down to do some reading (which should be regular, but not too long).

- If you cringe when thinking about a mistake you made, don’t block out the memory. Let it flow over & through you. It takes practice, but eventually you’ll be able to exploit your mistakes for learning rather than experience suffering whenever you’re reminded of them. Some people never make this development, and continue to suffer into their twilight years. It’s part of emotional maturity — to be able to reflect and grow, rather than simply shy away from difficult areas (“I’m not good at math, my brain just gets all muddled and I always mess up. It’s too stressful.”).

- Don’t forget to breathe. It regulates so much.

Beware of more specific and/or opinionated advice from any source. It may be easy to misinterpret due to over-summarisation, or may be subject to survivorship bias (people who are succeeding will more readily share advice, but it’s often the words of those who are failing or have previously failed that would benefit you the most to hear). This applies to my advice too :)

I would read some books too. Actual, "costs money to buy" books. Digital or on paper, as you like.

Look for those that cover your chosen tech stack at "more than beginner" level, and more importantly look for books on Software Engineering. Ask around for classics that are recommended in your field.

If you where in a position to derail a release twice, someone (not you) is not doing their job.

You mentioned working on new features by yourself. That's fucked up. Junior devs can work on new things, sure but they need to have a senior guide. And the resposibility of the feature should be on the *senior* dev.

In my opinion the best way to use a junior dev if resources to hold their hand are missing is to have them work on fixing bugs and support tickets for a while. This will give them a solid understanding of the code base and most external dependencies. Working on new features after that is way easier.

It's best to leave a bad job within 3mo, or at least 6mo, as that signals it a mismatch vs you having a fundamental flaw (vs getting fired at the annual review / quitting after your bonus: horrible look). You letting it drag out so long is a real problem, so maybe an internal transfer would be less of a CV hit.

I've worked at companies where juniors have been hired to fill senior roles so they've been given access to prod, expected to know the quirks of the language (not the system obviously) and to be able to get on without too much hand holding.

If the Devs think you're a senior then they might just think you're incompetent when you're not you're just new at all this!

I've never worked anywhere someone hired as a junior could break prod code just makes me think perhaps the hiring process is screwed up.

Someone else already said it. Ideally this is a company problem. In practice this often becomes a personal problem.

Stories like this frustrate the heck out of me. As someone who progressed from junior to senior in a little over 2 years at a pretty major company (pretty much any American would know the name), the quality of mentors early in your career is PARAMOUNT to efficient progression. A seniors top priority should be the progression and happiness of their junior engineers (one of my best tech leads used to say "The less code I have to write, the better a job i'm doing"). Sure, they could bash out a production ready service once a month - or, they could nurture the people they're meant to be guiding, and at the end produce several senior engineers of equal quality.

My advice? Have some frank conversations with your team, and if it comes to it escalate higher. Ask concretely what the expectations of a junior are there and why that is the case. Also ask what they see the role of a senior to be as well. Express that you're coming from a place of wanting to better yourself not only for your own sanity, but the benefit of the company at large. If things don't change, move on swiftly.

I also tend to forget things so I have setup OneNote and write everything down that is important - maybe doing the same will work for you? (Other tools like private Confluence space or even simple text files work too!)

Also I want to touch on your last sentence: I have seen principal engineers doing absolutely stupid mistakes because... they are people and people screw up from time to time. Don't let it bother you too much. You are self reflecting and want to improve, this is the most important first step. Keep working hard and smart, don't try to rush things, write things down, ask for help and the rest will come totally naturally over time :)

What's "enough questions"? What's "too long" when tackling an issue? It's good that you're actively trying to consider these things, but a senior dev should be able to answer these questions, and preferably when you first start a story.

When you first get assigned a story, try asking your superior for some guidance about what you should be able to figure out on your own, what you might need help with, and how long something should take.

I'm assuming you've been given a timeframe for how long a story should take to complete, so consider asking your superior more specific questions like "how long should I look on my own before asking for help on sub-task X"? Obviously there's some uncertainty in how long anything should take, but senior devs should be able to give some parameters.

If they can't give any parameters/guidelines, and you're still being told you either took too long, or ask questions you should know by now - then something is out of wack with management.

Practice

- have a 3 hour weekly practice session (minimum) outside of work. Won't do much for you in the beginning but it'll add up a lot over the years

- focus on the fundamentals related to the type of work you're doing

Reflection

- Identify what went wrong

- Identify the root cause

- Come up with a solution

- Implement the solution

- Identify what went right

- Come up with how you can further improve it or at least keep doing the right things

Feedback

- You can ask for feedback and advice about the areas of improvement you identified in your reflections

Concentrate

- When you work, make sure you're concentrated. Don't check IMs/email/socials

I must say, that I don‘t fully get that example with the prod account. Sounds like it is a larger place where the ‚ticket‘ went to some other team to e.g. change some configuration of the prod stage. If we‘re talking about changes to the code, there should be code reviews from which you get feedback and can learn from it.

Overall, there seems to be a lack of well-defined processes and basic documentation and little awareness for onboarding tasks.

Even if no one had done some of the things you were tasked to do before - could you have asked the other devs how they would approach the task? Are there some dailies in which you can describe what you‘re doing and get feedback from the team?

Going forward, maybe try and identify one of the more experienced devs to build a more trusted relationship and try to get answers to your open ‚basic‘ questions from them. If you‘re afraid of annoying that person, rather batch a few questions and ask them in one session than asking small questions all the time, I‘d say. Depending on how well that goes, you might go further and tell them about your situation as you did here.

Since there doesn‘t seem to be documentation of e.g. the release process, you could write some and get a review for it, saying that you‘d like to prevent similar mistakes in the future.

Finally, if you don‘t find a way within the current team and you start every day in agony, find a new place and prioritize one which feels like it has a more welcoming culture.

Onboarding is very tough because there is no substitute for it but time. And new people are hired because the existing team didn’t have enough time.

Here’s the thing: the way I see the prod blunders were as gaps in our process. If our process or environment is such that a new person can bring down the whole system (just an example, this didn’t actually happen), or cause some data loss, that’s on me for creating that environment, not them.

That doesn’t mean that we say it’s totally cool to make mistakes. We review what went wrong, what they can do differently to avoid it, and what we can do differently too as a team.

Also like someone else said, I’ve written code for 20 years and still make blunders. But I can figure it out and recover faster. But it still happens. So it’s important to lead by example as a senior person in how you respond to crisis.

Take these experiences and failures as part of your learning. Keep plodding forward and do better next time. If you get a pip so be it. Do the best you can and play the long game. If you have survived 8 months and you feel the passion for what you do you can survive 8 years. The devil is always in the details. Throughout my career I have learned more from my failures than my successes. I suggest you should also. Don’t doubt yourself. If you don’t have a learning disability you can learn anything. Just be a bit more careful about the deployments and that really should fall to a devops group. Jr means many things the least of them being your technical awareness. Business acumen, social and many others you are just learning.

Change what you can and don’t try to change what you’ll can’t.

Others have said (and I agree) sounds like your company needs some more robust production processes and documentation practices.

In addition assigning you a mentor would also be good practice ideally someone at the lead level or higher.

Additionally you mentioned your manager is no longer in the picture and that’s critical. Managers are also important in helping to guide you to your technical mentor.

Don’t beat yourself up too much.

Keep marching on.

You're making a lot of assumptions about your performance, since your manager is out who's filling in for them? Express your concerns to them and get a frank evaluation on your performance from their point of view. Don't spring this on them, but tell them what you wrote here and ask for feedback.

A couple of thoughts:

1. Nothing you've said sounds PIPable. Everyone makes mistakes, as roles grow the effect of those mistakes grows. Accidentally pushing to prod....really should have safe guards...I flipped a switch a few weeks ago, on a Friday, before leaving the office, and well now we lot of lessons learned. We all make mistakes.

2. Once you leave school you will get involved in projects/work that no one has done before. These take longer, and probably need more support. I think it's hard for those who have been working for a long time to remember what it was like to be a new grad.

3. New grads aren't hired for your ability to produce vast quantities of code/fix problems. Those are L5s....three levels above a new grad, and probably 10+ years later.

1. Test your code. I'm a senior engineer and the only way I know how to make sure my code works is by testing it. I use unit tests for this. If you don't like unit tests, find some way that works for you.

2. Try to get someone to review your work. When I'm working on something thats completely new, I ask someone I know and respect to review it and indicate which parts I'm unsure about.

3. First few months you may have to work harder. When I join a new team, despite being a senior engineer I spend time outside of work going through references to refresh/learn things so that questions I may end up asking will not be totally off the wall. After the first few months this becomes less of a problem until perhaps the next new thing comes up.

As for the mistakes you made, specially that QA/prod stuff don't worry too much about that. It's not only your fault. It's seniors job to create a working environment that's safe. On the teams I join, specially after I become a senior there, I push for safety measures whenever someone screws up unless it's deliberate or gross negligence. The fact that you feel bad about it shows that you did your best. I have seen once one of the most talented devops engineers brought a prod server down instead of staging because he is too quick on the terminal with many terminals open in his terminal multiplxer. Once a very talented db admin dropped an important table by mistake fortunately in dev and had backups. Things happen, and leaders/seniors should try their best to secure the environment.

Your job right now is to broaden/deepen your knowledge, ask intelligent questions, test your work before submission and keep calm and carry on.

* take notes and reference them, particularly when asking questions to teammates. This way I won’t ask the same questions repeatedly. Usually people won’t get irritated by questions unless you give the impression not to be learning.

* ask questions frequently!! Everyone is shy about asking questions but the more people ask the better for everyone. Sometimes simple questions surface important issues. (Also, this https://danluu.com/look-stupid/)

* sometimes a team isn’t a good learning environment. That’s okay. Learn what you can and switch to a better environment when you can.

* sometimes senior folks don’t know how to assign tasks appropriately for someone to ramp up.

* ask for feedback directly!! This can be intimidating but it’s the only way to really know how the team perceives you. And if they see you looking to improve hopefully they’ll help with that.

* try to find an explicit mentor who can meet with you on some regular cadence and help you distinguish what is an issue just because your Junior vs what’s a team issue vs whatever else

Second: at one place we used to do code reviews side by side on a single screen, and I have seen junior engineers make tremendous progress. Nowadays with remote work it can be hard to meet people. But the thing remains: mammals learn by copying, and learn best in a 1:1 setup. You got that remark you should not ask basic questions anymore, but this is actually a statement that your enrollment in the team did not go as planned. Based on that shared understanding you should feel entitled to ask basic questions. Now is the time to catch up. Go and see people with your laptop or ask them politely to come over to your desk. With instant messaging, ask them when they have time for you and share your screen! Do not let them share their screen for the reason below.

Third: of course you should take notes. Copy paste every command line you got from a senior in a notebook, every tip. I switched jobs quite often and can tell you this is vital, no less. It is disheartening to give a great tip to a junior and not seeing him/her take note of it :)

It happens. That's just part of it. We all make mistakes and bork things, and it has effects like that sometimes. Just learn from it and try to do well enough in the times you don't make mistakes that overall it's a net positive.

As to the rest - not knowing the process, and apparently your team also not knowing the process - indicates that the process isn't clear. You don't have checklists in place, or the relevant review steps or whatever. That's not your fault.

You might do well to advocate for a little more formalization there. But try not to go overboard. As a new person, it's a difficult situation. But raising the concern might open some people's eyes and shine a light on problems they'd been conveniently pushing off.

Your work (everyone's work) should go through a testing and review process involving multiple people. As in, you test yourself, someone else reviews your work, then someone else tests it, and finally someone else (often a non-developer subject matter expert) confirms that the work and testing done meet the intended objectives. The end result should be a documented checklist. Multiple people, from different viewpoints, have said this is good to go.

Then mistakes aren't all yours (or your coworker's), they're a case where the entire team and process failed, and the solution is to fix the process so that doesn't happen again. You (and everyone else) will still make mistakes, of course, we all do, but it doesn't have as much of an impact if the process catches it.

If your boss won't allocate time to automate and improve those little tasks, there's not much you can do. People are more prone to making mistakes than well-tested pipelines.

> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.

The bulk of a junior SWE's time should be spent on getting better at translating business requirements into code. Exposing you to some processes will set you to fail.

> I got my first swe job this past August

My advice is that you start interviewing for other positions once you approach 1 YOE, which is pretty close. Your post describes some typical issues small companies have when they try to scale. Hint: it often doesn't end well.

You also mentioned how some of the tickets were for things that even the senior team members had never done before. I’m sensing a lot of red flags here, the first one being they seem to be dumping shit work on the junior member of a team because no one else wants to do it.

In my first job I had several of the same problems. A manager that expected me to know everything and would become visibly angry and frustrated when I asked questions. I can remember some of these questions now several years later and in hindsight they were actually reasonable questions but it still angered the manager - which made me stop asking questions and I struggled even more, and his vague explanations were bad enough.

This led to me feeling like I was a fairly shit developer that was a pain to everyone and constantly feeling inadequate. But in reality it was the fact that there was no mentorship and little guidance - which also led to a bad production incident once too.

Again it is your first job, any perceptions your coworkers and managers have of you exist only to them. Once you change jobs (and honestly I’d maybe consider it sooner rather than later and find a place that properly mentors juniors) you’ll no longer have to feel the way you do now.

In the absolute worst case scenario if you do get put on a PIP due to their failings then consider it simply advanced notice of them firing you - it’s a few extra weeks for you to update your CV, interview elsewhere, and bounce. Never stay anywhere that puts you on a PIP or extends your probation period.

I'd say talk to them and tell them you need a bit more oversight because everyone will be better off that way - you're entitled to it as a junior dev after all. If they don't cooperate, just get out of there and find a better team because KNOWINGLY overloading juniors with difficult unsupervised work just sounds like exploitation

I was migrating an existing internal web app from a manual process with some shell scripts for deployment, over to Terraform. I wrote down every major step, every file that needed to be added, every environment that it needed to be tested in.

Don't try chasing things like org-mode or some software solution first. Build a process that works for you with something like a big hardback dotted/squared paper notebook. Here's something I wrote a couple of years ago, I hope it helps you: https://gist.github.com/anthonyclarka2/0485b49abd29fbac77bed...

And the image example from that post: https://imgur.com/gallery/Ft7JNLg

1) In my experience, I've learned and improved the most when things have been the hardest. It's tough for you now but stick with it; even just from your opening comments, you've clearly learned a lot already, and that should be the main focus of your first job.

2) A degree doesn't generally prepare you for the world of work, and computer science and software engineering are two different things - success in one won't automatically translate to success in the other. More important I think is that you have the will to work hard - remember the old quote about genius being 1% inspiration and 99% perspiration.

3) At my first job, I was working on a client's system because their tape backup drive had developed a fault. As an interim "solution", I configured the backup system to write to a file on the hard drive (so they would at least have a second copy of their data in the event of a problem)... then forgot to mention it to the support engineers and left it like that. Fast forward three months and their hard drive developed bad sectors - my "backups" were corrupted and their tapes were three months out of date. Oops. At the same job, while working on a project to write data to disk using assembly language, I made a mistake and trashed the file system on my development machine, which also contained the only copy of the code I'd spent a couple of weeks working on. It took me another two days to manually piece together enough of the FAT to recover a recent copy of my work (I was making backup copies!) and get back on track. These are the two most memorable f-ups from that job but certainly not the only ones.

Now I'm a senior software engineer and I haven't made any mistakes like that in a while :-) But I wouldn't be here without all the failures.

Good luck!

Yes, but... this should be in the form of code if feasible or shared documentation (README or wiki content) if not. Organizations cannot (and healthy ones do not) rely on perfect execution from every human at every step.

To support this if you have solely been relying on GUIs (IDEs, web UIs, etc.) I strongly encourage you to learn the command line interfaces (or even APIs) of every tool you interact with (source control, build, ticketing, deployment, ...). There is almost no common dev task in modern environments that can't be automated with a simple shell script once you know these. Check those scripts in so they're available to everyone to use and review, correct, or enhance. A working shell script is the best documentation possible for many processes.

My initial recommendation would be to reach out and ask to pair program on either your tickets or your teammates.

Another things that’s helped me personally is writing down steps for processes for non trivial things and referring to it when the task comes up. You could also keep a high level log of the things you’ve done and how you did them so if it comes up again you’ll have some context to refer to.

As far as the production issue it seems like your team doesn’t have a good process in place or documentation so I wouldn’t put the blame on you. It’s the whole teams fault when something like this happens. And it’s a shared responsibility to prevent others from going through the same thing in the future.

You have the right attitude and intentions, Hang in there and you got this! Whether it’s with this team or another.

EDIT: Oh and I just want to second the top comment in that any "senior engineer" suggesting you "shouldn't be asking that question any more" should be fired immediately. Willingness to admit uncertainty is a critical quality in a good engineer, and fuck anyone who makes you feel inferior for asking an honest question.

EDIT2: By the way, I lost thousands of dollars by misprogramming a fraud rule once. This shit is hard, don't be hard on yourself.

Right off-the-bat: It sounds like a team and manager issue.

Where’s the knowledge transfer and team on-boarding? Where’s the process to catch mistakes?

Where is the process to treat research as its own time-bound spikes, before you do the work?

Why isn’t the team pushing for a well-defined acceptance criteria, before you do the development (not prototyping) work?

I ask because I think you should get started on the leetcode, trying to make it to one year, and start looking for something else. Assuming you're reading things right ("one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point"), it's hard to change perceptions, and you're better off cutting your losses. Think about the team, the company, what would have helped you be more effective, and look for that. Do what you can to set yourself up for success by finding something that uses your existing skills.

If you really want to stay, focus on delivering value and not delivering un-value.

I made a Trello board with a default card that was a "Todo list" that I copied for every ticket. The checklist was an overly detailed how-to for our company workflow. Like "1. Pull main, 2. Branch off of main." And later when the dev work is complete, things like "run tests, write merge request, deploy to qa server". The process wasnt hard but it was long, and keeping it on a Trello board with a checklist for every ticket I did helped me offload the mental load and keep me consistent so I made fewer beginner mistakes in that regard. Just having a progress bar was invaluable, being able to log in on Monday and answer the question, "where was I with this ticket?"

The other thing I did that was really helpful (and unfortunately probably only applicable if you are working remote) was that I screen recorded all of my meetings. Most meetings were massive information dumps that I had no context for, it was like trying to collect rain water with my bare hands. So if I got help on how to work on a ticket I would have a video I could refer back to of a senior dev screen sharing with me, explaining how things work, which files I should be looking in, and answers to whatever questions I was asking along the way. I still had to bother people for clarification later, but I didn't have to ask them to repeat themselves.

The final thing I would recommend is to start taking notes as if you were going to give them to the next new hire. It helps you distill your own knowledge and it helps future-you when you have to come back to a thing you haven't done in a few months and you nearly forgot everything. I was dumping notes in the slack channel to myself at first, I recently downloaded Obsidian and I just started playing with that. Find what works for you.

I've been at this job for 14 ish months now and I only recently felt like I got over the beginner's hump, and I still have bad days. It's okay, you'll get there.

Take a deep breath. Treat each project as a clean slate. Ask questions sooner rather then later. Find the parts of the technology stack you enjoy working on. Take notes and write documentation for the next person when someone helps you. Be nice and courteous to people who take the time to share knowledge with you.

And if this doesn’t work out, there’s lot of other places that might be a better fit culturally. You’ll be fine

I’m seriously not making a joke when I say this, senior engineers are only experienced by attrition. They got to where they are by making the mistakes before

There is no such thing a error you shouldn’t be making. Why does the tool make it so easy for you to ship a big in prod? Why are there no tests to verify the code you made? Why does your company not have a review process for dangerous or brittle areas of code

Systems fail, not people

I recommend investing effort in your note taking processes.

I have 20 years of experience at this point, but I only got really serious about making detailed notes a few years ago - and now I wish I'd developed that habit at the start of my career!

My goal these days is this: "Never figure out the same thing twice". If I figure something out, I write it down - sometimes as private notes (I use a private GitHub issues repository for this) but often in public GitHub issues or published to my TIL website: https://til.simonwillison.net/

You only get to encounter a new codebase once. While everyone else justs accepts things as they are, very few will ask why. Some of the senior devs won't even know why certain things are the way they are. By documenting everything, for yourself initially, you will over time gain both experience and get one over on the complacent senior devs.

If a junior dev makes a mistake, it's more on the senior devs and managers to catch it, you're not expected to be supernaturally correct all the time coming into a situation with zero knowledge.

Find different team.

Also, my survivor of the same advice: write down things everytime someone tells you something. Every time you go across term, process of piece of tech, Google basic tutorial and read it. Don't go deep, but read basics.

Sleep enough, eat well, exercise and don't be tempted to stay overnight to make up for mistakes. That leads to being tired and making more mistakes.

Listen more than you speak.

Replicate more than you innovate.

And write it all down as you go.

If your team is half decent, they already know where your skills truly are, and they're comfortable with it. And before you know it, you'll be the senior engineer.

Your team sounds awful though.

I think it's because I've also had a rough start and no help from the toxic senior on the team (until that guy left) and now me a junior with ~6 months experience was leading the project but I was overworked and underpaid for some time.

The most important thing that I want from anyone is transparency, I would totally make that one of the pillars of any big organization.

If not, is there are knowledge gap that you can fill to better understand how to deliver value to your customer. Your customers may be in accounting, marketing, service delivery. Learning the basics of the way they operate can be immensely helpful to deliver the things that will bring them success.

Your team should be helping you, they aren't. Just try to rack up time so your resume looks ok and move on, or move on with low time because it doesnt really matter right now, or omit that job from your resume completely and try again

There's so much to learn, both within coding and company domains, that you really need a reliable go-to person to guide you.

And as others have noted, you shouldnt be expected to be producing prod-ready code and making releases so soon.

Try asking another one lol

Some people don't like to help each other as much as others

if that's a big company, consider looking for other teams/projects to work on

if you're fully remote, try going to the office (and spend some time with your team if they're going too)

Mistakes happen in general to everyone in SW development - seniors will make less of them but that doesn't mean they won't happen and that they won't be costly. Generally I'd say if there were serious setbacks to the entire project I'd say something is wrong either with the development process or with communication. Lack of leadership can be a pain but although not ideal I've worked and thrived in such an environment as well.

Ideally your team should catch and prevent bad things from happening before production. This begs the question what kind of testing you do both yourself and as a team (Do you have QA? Do you do automated acc. testing? Do you do integration testing? Do you do code reviews? What about unit testing?). Lack of testing will generally lead to a variety of bugs. Having a ton of untestable legacy code on board also makes development hard in general.

Second thing I'd ask is whether you verify the approach you take to solving the task at hand with your teammates? It's easy to take a few wrong decisions especially if hard legacy is involved. It's in general better to address the approach to solving the problem early and involve seniors even if they don't have experience with the codebase.

Also regarding dealing with production it sounds to me like they simply unleashed you into prod. environment. Giving a junior prod. credentials to me is like throwing him under the bus. I mean what could possibly go wrong there? :) It's relatively easy to break prod. without experience. I suggest getting somebody to assist with production deploys if you don't feel confident. Setup a videocall with somebody from operations/senior dev., share screen and make the relevant changes. Also if somehow you managed to easily mixup QA/prod. that would also imply separation between environments is not that great.

Also if you want to improve the process consider going back and writing some post-mortems. Understanding what and how went wrong and addressing the issues means it's less likely they will happen again to you or another unlucky junior.

when you make a mistake, learn deeply _why_ you made the mistake (ask why at least 3 times deep), and dont do it again

junior does not mean 'somebody will guide me on a rose paved path until they pay me 300k'

if you are not meeting the expectations of the people in your team, you better raise up and start meeting them.

keep in mind, once the trust in you from the team broken, it will be very hard to repair, and as a result your confidence will decrease and it will become even harder as you will start second guessing yourself.

to learn is to remake yourself, which requires patience, dedication and confidence that you can do it.

most of the answers in this thread are advising that 'its the team's fault', which it might very well be, but i advise you to do all you can to not lose confidence in yourself and keep pushing, every day, little by little you will get better.

quit if you feel like quitting, stay if you feel like staying

as a "senior" consultant, I once dropped a customer's production database, because production of course has a D suffix, whilst Development has a T.

As they say, there's only two hard problems in CS, naming, cache invalidation, and off-by-one

The response sounds like it’s coming from someone who’s never thought deeply about problem solving and it’s relationship with mathematical complexity.

When one is given a task that they have no idea on how to proceed, to them, the number of solutions could be infinite. At that moment, even knowing what to Google could be overwhelming.

Imagine the junior developer being given a traveling salesman problem as their first task but neither the manager nor the junior developer recognize that the problem is a TSP problem. The Junior Developer can spend years and years rediscovering all the heuristics and algorithms related to TSP without knowing they’re actually doing that. You can’t google for it very well because the task doesn’t explicitly say TSP.

What you need is a Senior Developer to step in, hopefully they recognize it’s a TSP problem based on their experience, and then give context and an explanation on how to recognize such problems in the future and finally tell Junior Developer “Just Google traveling salesman problem”.

No working beyond 5pm needed. Junior dev is happy they solved the problem that was pushed to production, Senior dev is happy they don’t have deal with a pile of technical debt and Manager is happy that the task got delivered on time.

With respect to the rest of what you wrote, I’d just say that the possibilities are always infinite and my point is that being able to discern and limit the possibilities to something reasonable is a skill that has nothing to do with seniority and everything to do with general (read: fixed) aptitude.

I disagree with that.

You don't need to be a genius to be a good developer, you can be learn to be one or you can be mentored to be one. Some aptitude is required, but nothing extraordinary. Hard work obviously is a good thing, but not a pre-requisite.

P.S. Our success criterias might differ though. I'm not part of silicon valley or FAANG so my standards might be lower than yours.

Learn how to make small incremental changes and get these little changes reviewed and merged. The biggest mistake a junior Dev can make is biting off a huge diff, going down the wrong route and then trying to back-pedal.

Feature flags and the other ideas at trunkbaseddevelopment.com can help.

If i would you, look for new opportunities elsewhere.

- never stop asking questions

- don't get discouraged if you don't get the mentorship you are looking for

- get feedback from senior developers who like you

- don't believe for one second that there's one correct way to do things

- learn to write testable code

- when you're done learning on this job, leave & get a different one

Most of us have gone through some version of this at some point in our lives, so take a breath and cut yourself some slack.

Lots of great advice on this thread already, so I will live it there.

There is a lot of good advice given to you. I have read about a dozen top posts (at the moment), and haven’t seen something major I would like to correct. I am not going to give you full answer, repeating most of what already being said. Instead, bellow are few actionable items I would like to emphasize.

1. Prepare to leave the ship. Start looking at codding/algo problems, preparing answers to behavioral questions, probing your network, etc. Also, if possible, look inside your company, are there teams that you will be better fit for you? Do not wait for PIP, as in a lot of companies you can’t transfer while you are in PIP.

It’s not you, but life is too short to be on the team that doesn’t nurture you. More so, as starting junior getting right exposure to good engineering culture at the beginning is critical to your professional growth. I can’t tell you how many times I got to interact with basically smart folks that could have been a good engineers but who were damaged by early exposure to toxic software development environment.

On top of this, as of now, you are going to be interviewed as junior or even out of college, with lower expectations. A year or 2 down the road you will find that expectations from people who interview you will start to raise significantly. If you don’t grow now to meet them, you are putting yourself in a bad spot latter.

You might not need to leave your team, but being ready to do this will give you comfort, and looks like you need it.

2. Find good mentor. And another one, and another. Look both in inside company and outside. Be prepared to iterate through a few, and learn to be a good mentee. I saw at least one offer here, try to take it. Also, ask proactively here. If you leave me your throughway email in comment, I may be able to help you too (mostly depending on our timezones).

3. Start asking a lot of questions. It’s bullshit that you have been at the team too long to do this. It doesn’t work like this.

At the very least, you can think that if your standing with your team is damaged starting asking basic questions will not damage it significantly more (you might find that it actually improves it, but no guaranty).

Also, think about it as a skill you are developing: the skill to ask questions easily and early. You will need it throughout your career.

Few tips on asking questions productevly:

1. If you don’t know or understand something it is a legit question. If context is in person conversation or meeting it is OK to ask it right away.

2. If you need to find somebody to ask the question or ask for the help. You will end up with having 1 or 2 persons you are most comfortable asking questions, and as result asking them a lot of them. This is anti-pattern. Do not overload just one favorite coworker, go out of your comfort zone and reach out to other people.

Make for yourself a small SOP (Standard Operational Procedure) to ask questions, and timebox, say, 10-15 minutes to try to answer question yourself before reaching out for help: 3 Google searches using different queries, looks through product documentation, search through internal system(s), maybe post on the question board (different questions land themselves to different research steps). Also amount of preliminary naturally research depends on the urgency.

Communicating to your coworker that you did your legwork before asking for their time is a good thing and will save you few embracing incidents when the answer was right in front of you (happens to me far too often and is not that big deal).

After getting help from coworker (and naturally thanking him), ask how you could have found it by yourself. This will teach you to be better at searching information in the future, and in lot of cases it will turn out that there was no reasonable way to do so.

Also ask your coworkers what their preferable communication channel is to be asked for the help in the future and do your best to use it.

If person you asked doesn’t know the answer, make note to ping them when you learn it and ask them if they are interested in it.

Document your finds at least for yourself (it will take time to develop reasonable note taking system, aim it to be adequate, not perfect). As a stretch goal see if you can also document it for others, like updating internal wiki, etc.

Question, why do you think it is? If you're truly objective an honest with yourself, might there be a reason you can think of for this? If so what is it?

I would say as a more senior engineer and someone who hires juniors, some of the most frustrating but easy to fix things are as follows:

1. Not asking questions and doing the wrong thing instead. You mentioned it's too late to ask, bullsh!t, it's not too late, start asking now, explain why you're asking, come clean, tell them why you're starting to ask...because you want to improve and help them. If they do spend time answering though, you better either remember or take notes so you don't forget. If this reason isn't good enough, maybe start looking for new team mates, they should be very happy you want to improve.

2. Not communicating, just in general, "I didn't update you because my dog was sick, so I took the dog to the vet, it's ok now, but them my girlfriend was sad so I took her for ice cream", ok cool... but just tell me before disappearing for the day, then it's much less of an issue and I don't have to chase you.

3. Being too slow and not accomplishing things. There's many, maybe infinite reasons why this happens, but just don't be that person, if something is assigned to you, take a deep breath, step back, and plan your path to success. If there is a reason why something isn't achievable, that's cool, go back to point 2. Make sure you communicate it, ask for help.

4. Understand the big picture as best you can, be less fixated on code, problems and solutions. Be more focused on solving issues the team is facing. If you're just focused on tasks, you're likely to produce solutions which might not be ideal and properly contribute to the overall success of the team.

5. Not being reliable, honestly, you might just have to sacrifice sometimes, I think it's part of learning and being a junior, but it will be part of being a senior too. If you committed to doing something, just make sure you do it. If you've accepted a meeting invite, make sure you're there. It's basic stuff, just do it. Be disciplined.

Should I be writing reminders to myself to always double check everything? Should I write down the steps to every process?

Yes, you should be doing that, surgeons and pilots use checklists, you should be too and you should be documenting things, the whole team should have visibility into this documentation. The next time a junior comes along, you can become a mid-level, because you've made yourself somewhat redundant by documenting the things they will need to know.

Last thing I want to say is, no one is perfect, we're all learning. I'm not perfect, you're colleagues aren't perfect, you will never be perfect, we're all students, we all have things to learn, and we're always going to make mistakes...at least from what I've been told :)

Hope it helps.

Its not me, its them.

> Long story short, screwed up a step I had done before in the fall without realizing. Then when it was fixed I submitted a ticket for a prod systems account rather than a QA one not realizing there would be a difference. (Just so many mistakes all in a row).

This is a failure of procedure by your team. if their systems are that badly documented, monitored and controlled, you are doing a great job of QA'ing their shitness. Be sure to document what you've learnt clearly, so that others can avoid your mistakes.

> I was sometimes assigned stories no one else on the team had done anything like before

Thats another failure of the team/company.

> this team isn't a bad one. I can make excuses all I want, but an experienced engineer joined the same time I did and is doing great.

They sure as shit sound like one. You know the difference between you and the experienced engineer? _experience_ sure they are doing better than you, but thats because they've made all your mistakes before.

> one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.

That engineer is a shit. if its not documented, then they are being top grade pricks.

> when I am actively slowing the team down or causing problems.

if that was the case, why are they letting you slow the team down? like if a member of my team was "blocking" something because they were slow, we'd all be free to help. Thus we would help you to get up to speed. If they are letting you stew on stories that are unrelated to what the rest of the team are working on, then I suspect you holding them us is bullshit.

> I certainly didn't ask enough questions when I started and I definitely will wait around for people to get back to me sometimes rather then be proactive.

I assume you are working with, or are remote? knowing when to ping or VC is one of the things that isn't taught, or even agreed upon. so I have every sympathy with your predicament. However you can afford to ping people more, and ask to setup a 1:1 to make sure you understand (write bullet point summaries and get them to send links)

> PIP because of this, I feel like I can't help but see it as a statement on my potential and ability.

Ironically a PIP might be actually good. It _should_ give you clear, actionable information along with measurable goals and managerial support to reach them. All of which appear to have been lacking so far. Even if it is a reflection of your potential and ability (its not) it only reflects that team and company.

Everyone else: If you see your self in any of the actors in OP's post, you need to fucking change. You're the problem, you shits.

Definitely good that you recognize this. That's the hardest part. Your next step is to fix it.

------------------------------------

> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.

It's never too late to ask dumb questions. Especially if these certain processes are your first time really working with them. Sometimes that happens, you get used to working around a knowledge gap. You're new, it happens. Not all senior engineers will quite get it. Is there someone else on the team you have a better rapport with? Show that you're taking initiative and making improvements and you'll get results.

That being said, some companies have a poor engineering culture, where you won't get the right feedback. IMO the worst part about being new is not knowing how to recognize a good team from a 'bad' team as easily. You said that the team wasn't bad, but you don't really know for sure. I don't know if this is really what you should be thinking about in this situation at all, even if you have your mind made up on whether the team is good or not. If it does become a distraction, the book "Extreme Ownership" can help a lot with having an internally focused mindset, which helps a lot in this profession.

------------------------------------

> Its hard to imagine anyone who is good at engineering delaying a teams release and causing problems.

This can and does happen even from good, experienced engineers.

------------------------------------

> I know I should just focus on improvement, but I am not sure how.

When I was new to software development, I had to spend a LOT of my free personal time improving my skills, working on side projects of my own (even though they never got finished, it helped). I have no doubt that if I didn't do that, I would have not been successful. Those side projects can really accelerate your improvement. Just make sure it uses the same technologies you use at your job since your goal is to improve at the job itself.

------------------------------------

> Should I be writing reminders to myself to always double check everything? Should I write down the steps to every process?

IMHO if you use a note taking app/methodology that is frictionless, you won't need to really think of "should I write down x" as a decision, you'll just do it when needed. Try using some of your personal time to research note taking apps till you find one that works best for you. I personally like Obsidian, it was a game changer for me and it only was recently made available. An app like that can also help you take notes on advice given in this thread ;)

------------------------------------

> Its hard for me to know whats a junior engineer error and whats an error I shouldn't be making at all.

IMO, don't stress over that. Just do what you can. When you know you've made a mistake, learn from it, maybe even write about it if you want to really cement that knowledge. Are there parts of your system that are easier to work with than others? Can you find a way to add value to your product through focusing on those parts? Some systems are just built in a way that is not easy to work with as a junior.

------------------------------------

How good is your sleep quality? Are you out of shape physically or have a poor diet? Do you have uncontrolled ADHD or depression? Things like that can make or break your problem solving ability in subtle (or not so subtle) ways. Don't overthink it, but don't ignore it.

I am also curious what languages/tech you are working with?

Since you have made a mistakes that moved the release dates, it takes a long time to change the impressions.

If you ask me, just switch company and start from scratch. This might be unpopular opinion but this will save time in years w.r.t to career growth.

One thing that I've learned to boost my speed a little bit up is:

1. Ask tones of questions before implementation, even if they're stupid ask. Asking and knowing the right thing will help you prevent wasting time building something that wasn't needed

2. Ship the simplest piece of code that solves the problem. Don't be afraid if it's not fancy, or not optimised. You'll think of that later on.

3. Then before you go down to code, please spend almost an hour brain storming the entire problem through, think through all entire edge cases required for the problem.

4. I also sucked at stand up meetings , terrified I hadn't finished my stories. Keep them short 2 max, at least explain how far you've gone with the problem. If you don't have anything to show, at least mention something related to your progress.

Lastly , budget your time and always be optimistic , I've realised most things I presumed were hard but as long you're optimistic and tackle them , some how you find yourself shipping things

These are all the things that stick out as red flags to me, in terms of your company - all based purely on what information you've provided, with speculation: - No onboarding process - No documentation to help someone getting started on the project - Giving a junior dev a task nobody has tried to do before is generally a bad idea. Giving a task that is unknown to the junior, but something that a senior can cover for or at the very least assist in is sane. - Shit code review; you fucking up twice so bad that a release gets delayed by a month means there's a systemic failure in how your code is reviewed, and QA tested, before being released. That's not just on you (because we all make mistakes), that's on your company for not making their integration and delivery more protected from mistakes like that, or being able to quickly roll them back or fix them. - YOUR manager has been gone since December. You're a junior. Just lol, if you aren't laughing - you should be crying. The most critical person in your start at this job is missing, and very obviously not being replaced by anyone competent enough to manage you (otherwise they'd be or soon will be a manager). - Senior telling you that they shouldn't be helping you with certain things at this point: Yeah look, I can understand what the guy is saying, you've been there for 8 months...but you weren't on-boarded properly by the sounds of it, your manager is fucking GONE, and you were giving shit tasks to learn with seemingly with no support...according to how you tell the story. 8 months is well past most probation periods. You may be sorry that you're still asking these questions, but if there was a way for you to learn it and not have to ask, that would be a lot more helpful - go with that.

Here are your unhelpful behaviours, especially as a junior: - Not asking questions often enough and soon enough - Not following up on questions already asked, to get answers (probably to avoid being a bother)

Really that's it - that's kinda all you gotta make sure as a junior that you absolutely do not fuck up, is ask questions like your life depends on it. I bet a lot of your slowdowns are due to you trying to bust trough the wall with your head with certain issues, rather than asking, because now you've stigmatised yourself about asking questions given ""how long"" you've been there for, and what that one guy said.

Please make sure you are asking questions AFTER you tried to figure it out yourself - maybe it's about how you've been asking questions, you know? There's nothing more annoying than someone asking you a question and just expecting a full answer handed to them on a silver platter, especially if its about something that's involved and would take time working out yourself, or something that is known to be able to be easily looked up. That being said - look up your own answers, and try your own solutions. Time box them to 5, 10, 15, 30 minutes...depending on how big the thing you're working on is, and then ask the question...telling the person what you've tried, where you've looked, and what you think the answer might be. Show that you put some effort into it...but don't do what you HAVE been doing, waiting too long to ask!

>I know I should just focus on improvement, but I am not sure how

The answer to that questions has been missing, apparently since December. Seriously - this is what the fuck your manager is supposed to help you figure out. If you do get performance managed, that may be a blessing in disguise because it would mean knowing where you are lacking and forming a plan to bridge that gap and then review it after a certain amount of time. Don't view the PIP as some dreaded thing -- it is meant to make you productive and effective. Yeah it sucks in essence that "it got that bad", but given the circumstances BESIDE you, it IS that bad.

>Should I be writing reminders to myself to always double check everything?

Writing down your own version of whatever process you need to do when you're submitting a change, or doing whatever at your company would be super helpful...ESPECIALLY if they don't have any such documentation that everyone can read already (which should be a fucking crime).

>Should I write down the steps to every process?

Every process sure, but in varying detail. Some things you may want to write down step by step. Some things you may just want to write down the most important thing to remember/check. It all depends. Either way...write down whatever you KNOW you will not retain in memory AND that cannot be easily accessed online or through your company's documents and documentation.

>Its hard for me to know whats a junior engineer error and whats an error I shouldn't be making at all.

You're a junior. You're meant to be making all of the errors - but you aren't meant to be allowed for those errors to proceed to consequences. Thats literally what the work processes and all the fucking DevOps and systems infrastructure is meant to be there for...to stop errors, both machine and human, from making it into production. Writing shit code is on you...but letting shit code into production is on whoever created (or didnt safeguard from) a system that lets that actually be deployed...so...the team, the rest of the company.

Writing shit code and having your team review it and the company's pipelines alerting you to errors is how you learn that it was indeed shit code, and then, through the grace of professionalism, are shown the right way, or at least given the opportunity to figure out how to fix it.

I don't know just how "bad" you may actually be (if I was to just believe you - pretty terrible; that's how you feel about you). I am only reading your "take" on it...no idea what your team actually thinks. Maybe you're overreacting, or maybe they are just incompetent assholes...hell, maybe its both.

It doesn't matter. What you gotta do, is start asking questions (more often, sooner), start writing down what you know (so you don't forget, and avoid fucking it up), and talk to someone about these very worries you're having. Is someone replacing your manager currently? Talk to that person. If nobody is, find out who your managers manager is and raise these concerns with them.

Caring about the juniors you hire is on the company. You aren't being hired to be cannon fodder. You're an investment: they get someone who is fresh and can be moulded (on the cheap, relatively), knowing they wont be productive for a good while, but will be able to pick up a lot of the processes specific to that company without "old ways" getting in the way.

A responsible team would not let juniors have that much impact. They would monitor you closely, review your work and make sure the mistakes you make don't afftect the team much. Having said that, a lot of the teams are growing and learning and maybe they end up learning things from their experience with you. Have they done something about preventing such problems from future junior hires? Have you suggested anything on how to prevent it in the future?

> When I first joined I struggled to even know how to start things.

Why do you think you were supposed to know that? They should have explained or one of the seniors should have work closely together with you and helped you along the way. It seems that the big part of the probelm is the teams lack of experience with juniors. You didn't mention how big the team is but if they are too small they may not have the resources to hire juniors and give them the environment to grow. I have written on the topic before: https://news.ycombinator.com/item?id=30464521

> no one else on the team had done anything like before, so at times I couldn't even ask the senior devs for help

Not true. You should have asked them to help you figure things out anyway. Of course you shouldn't get them to do all of your work but what you should do is do your research on a few different ways on how you think you should start based on your understanding of the problem and try to explain your thinking process to a senior in a short session. If they think that is OK, you can go ahead and do some work and explain it again in a couple of days how it went and again explain how you intend to proceed. They should have thought about this before they decided they will hire a junior... but it's never too late.

> senior engineers also seem to assume I know more than I do

Do they assume that or do you let them assume that by pretending that you know everything and don't have to ask anything about anything?

> an experienced engineer joined the same time I did and is doing great

Juniors have to be treated differently. If the team doesn't have a different processes for a junior, it's their fault. You can make it clear to them by communicating more.

> The problem is at this point I have been on the team too long to ask any basic questions

You ask what you don't understand at any point. If you don't, you just keep adding to the problem. Imagine you have been in the team for 3 years and still don't know what you need to know because you didn't ask now. That would be much worse, don't you think?

> one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point

Avoid that one and ask someone else.

> I know imposter syndrome is a thing,

I don't think it is. I have written about it here: https://news.ycombinator.com/item?id=30924557

> I am actively slowing the team down or causing problem

As I have indicated before, a good team would not let juniors have that much control. Of course, hiring a junior comes with extra costs (mostly that of senior developers' time with them) but it is supposed to pay off by giving the team some useful value... and some of the pay off will come later as you gain experience (and hopefully stay in the company).

> I take a really long time when finishing stories unless one of the seniors is giving input.

Exactly! They should never give a junior a task unless there is a senior available to assist them. In fact, they should give the senior the full responsibility of the task and give him you as a resource that they can make use of so that they can spend more time on their primary task which may be more important.

> Its hard to imagine anyone who is good at engineering delaying a teams release and causing problems

Everyone makes mistakes like that. Maybe different kinds or classes of mistakes as they gain more experience but there will always be mistakes and problems.

> my manager has been gone since December

So you have nobody to report to since then? Why don't they give someone else this responsibility?

> Should I be writing reminders to myself to always double check everything?

You can't check if you don't know what to check. A senior should be reviewing all your work.

> Should I write down the steps to every process?

For whom? Who is going to read this?

What you should do is talk to whoever you are supposed to report to... and tell them how you have not been as productive as you have wanted to... and that you think that it would be better for you and the team if there was a senior available for you to assist you with every task until you feel more comfortable to be more autonomous. It seems the team isn't proactively helping you so it is up to you to proactively seek help if you are going to make progress. You should aslo ask for a monthly one-on-one meeting with your manager (or who is supposed to take that responsibility when he's gone) where you can discuss these issues.