If your organization has a junior putting out "fires" in production after 3 weeks, a few major things are wrong. First of all, code shouldn't be "on fire" frequently in production. Especially a domain of functionality that is simple enough for a 3 week old junior.

Honestly I can't think of as valid reason why there would be something breaking in production that a junior with 3 weeks of experience on a team could fix. Where are the dev ops people? Why is the production code so fragile? If the "fire" is easy enough for a junior with 3 weeks experience on the codebase to put out, why is it even a problem in the first place? Many questions here.

Yeah, this. It's great that the poster leveraged it as a learning opportunity and could handle things, but it speaks to the poor quality of the organization/team that this would be an issue to begin with. But of course we have limited details.

Also, when you're a green software engineer it can be hard to know when to ask questions. You definitely don't want to ask too many questions which are trivial and easily googleable. But you also don't want to spend 4 hours figuring something out that a teammate could explain in 10 minutes, unless their time really is 16x more valuable than yours.

Not to put the original poster down but I was hired into a similar role but that was with 8 years experience plus several years sysadmin experience.

I was in a similar situation. In my case, i was on the ops team for a big chunk of the company, so it had an unusual amount of fires in production. I was rushed into oncall basically only because the existing rotation was only 2 people and they were very miserable. Later the company made more structural changes to relieve the situation (e.g. dev ops).

Sounds like the team lead is very desperate for external help. I worked in a startup where I contributed to production code two weeks after. I was at intermediate level at that time. But the team was short of people and needed extra hand at any level.

You can be proud of yourself, but you should also be mad as hell! You may have come a long ways, but you'd be so much further with good mentorship and coaching. It's not that your team was moving "a million miles an hour", it's that your team suffered from bad leadership. Leadership incapable of providing the right support for the people on the team.

You deserved better, and I really hope as you moved further into your career that you found it. Finding great mentors and coaches is truly transformative.

I don't think this is the right way of thinking about this. People react to things in very different ways - and this might have worked for this person. The reason we put in place mentorship and different structures to help people is so that there are as many avenues for success as possible. It might be this guy kicked ass in the one way he was given. That doesn't mean his team is doing the right thing, but it's not fair to assume that he actually missed out. There's a difference between doing things because they need to be done to raise success rate, and doing things because they're essential.

No one deserves anything, you get what you can get.

If one wants to learn in the best environment, one usually needs to go to university and _pay_ for the education. To go into a highly competitive industry, get _paid_ (usually quite well) and complain that someone didn't teach you the way you'd like to be taught is some kind of astronomical entitlement that I can't even begin to comprehend.

A CS education has little to do with software engineering itself.

Beyond that, I disagree with your basic assertion. It's a sign of team maturity to encourage mentor/mentee relationships.

I agree on both points. Yet disagree that you can expect to be taught while being payed and complain.

I agree that you can't expect anything. The job is the job, you're there to give value, not take it.

But, if you end up at an org that has their stuff together - if you're coming from nothing maybe you show a high aptitude for programming - it is something that should be an aspect of the experience.

This expectation vs. entitlement discussion is just quibbling over semantics.

I don't expect to be mentored, but I won't give an employer the time of day if I don't see myself growing in the job, so it's the same effect. Personal/professional growth is table stakes.

You can pick however you want to frame it. It's the same end effect: if I work for you and not as a founder/C suite, mentorship on the job is a baseline requirement when we negotiate the terms.

No one 'deserves' anything, but it's worth noting that it's not impossible to create fast-moving and nurturing environments, and maybe trying to learn how to do that for your peers.

"Deserve" means to show qualities that are worthy of either reward or punishment.

This poster is someone who took the initiative to get better and therefore showed qualities worthy of reward. They absolutely deserve better than they got.

> They absolutely deserve better than they got.

How can you be so sure? You don't know what the compensation of the GP was, you don't know that they weren't / won't be written a stellar letter of recommendation (or better yet introductions) that will land them directly into coveted senior dev land, you don't know that the experience forged won't make the GP an effective startup founder, etc, etc etc.

Learning on the job is mutually beneficial. The employee learns useful skills, and the employer gets a more useful employee. Tossing people into the deep end and letting them figure it out is short-sighted. We should expect more, even if just for the employer to do what’s best for them.

They need to have the skills to ask for a mentor and identify what they'll get out of it.

Replace "deserve" with "can find somewhere else".

Maybe think of it as the article describing life-jackets and basic swimming strategies to help those that may be drowning.

In your experience you were thrown out into the rough seas and survived just fine-- I don't think it would be right to deride someone for drowning by saying that in their situation you would swim just fine.

There are many inputs to the system/society that outputs an article like this one, and this is perhaps what you are pushing back against-- and reasonable people would.

I work at one of these “everything is on fire, nobody has time, going a million miles an hour, hiring inexperienced people” places. They are not good. They may make you feel like you’re really learning loads and taking on lots of responsibility. You’re actually mostly learning hacks that work in an emergency and learning to be taken advantage of and do multiple people’s jobs. Why do you think they hire inexperienced people and put them straight on production fixes? It’s because inexperienced people are cheap and won’t say no to anything. Management there are likely very dysfunctional. Get out!

It's not a dichotomy — you learned a lot in your situation, but you might have learned as much or more from a different situation. It's normal to assume your own life experience is normal.

It's good for learning to be put into a situation where you have to perform outside your comfort zone "on your own", but in the context of a support system that will back you up if you fail. It's called "emotional safety" and it's an important factor in good teams.

> My team races at a million miles per hour, and frankly doesn't have the time to hand-hold a juniour as they learn the ropes.

Something is wrong if this is the case. Training new hires is part of the job. If they literally do not have the capacity to do that, then you are badly understaffed.

It can be a struggle to convince management that the team is understaffed for the expected work and needs to hire.

It can be an absolutely Herculean task to further convince them that, not only is the new person not going to increase velocity right off the bat, they're actually going to slow down the rest of the team to some extent.

They can always learn the cost of turnover the hard way... when the team leaves.

I think this kind of thing really comes down to the situation. You have not provided much detail here. There are cases where something like this can work very well (low scope project, low amount of proprietary information) and cases where it may end up in disaster (very large scope, misleading information, footguns). Particularly, fixing fires is one thing. Writing high quality code that follows good patterns is another, and leaving a junior to just "figure it out" doesn't actually make much sense. Often things like "accessibility" are just forgotten completely.

One can always try to pull themselves out of a bad situation, but that doesn't hide the fact that efficiency was lost, and from what I've seen, rather than creating lots of excellent engineers via such a trial by fire, you rather get a lot of missed old knowledge and reinventing the wheel combined with people getting high egos and thus getting very defensive over whatever it is they got attached to during their trial by fire.

Yes, the work gets done, but how well, and do we care? As an industry, we seem to do a poor job of gathering and reinforcing good practices. I still encounter completely opposing silos that often have no clue the other exists. And everyone seems very strangely certain in the correctness of their choices.

> My team races at a million miles per hour

I must ask, though, what is this magical company?

> My manager during performance reviews would heap praise on me for being so green and yet so low-maintenance.

And I'm very curious how much you're paid.

I'll reply to your comment because it's the most aggressive. Glad to see another grumpy-wumpy internet commenter.

I fully agree that I, by necessity of my lack of experience, have made mistakes and lost efficiency. I have engineered things suboptimally. I have cut corners to get some feature out the door. But I also recognize that the business I work for cares about earning money, not about making nice software. My managers like me because "I get shit done."

> I must ask, though, what is this magical company?

In terms of my company. I work for a company with ~250-300 devs. The total employee count is in the high 400's. It is not a unicorn. The yearly revenue is something like 50 million USD, and we operate at a break-even in terms of profitability.

I work on a team of 4 overworked sysadmins. I would say the team's "product" is managing the production application + all dependencies (way too many dependencies...), an ETL pipeline, and VDI. At least this company has an IT team to deal with stuff like printer/WiFi/laptop issues.

> And I'm very curious how much you're paid.

My salary is 82.5k CAD with ~1.5 years of experience.

---

And as a reply to most other people commenting on the parent. Yeah, mentorship is probably the best way to develop a career. I think it really is a luxury, though, and probably very few companies do it right. I wish I could have gotten some guidance, but I didn't. I'll just make do with what I've got. It's worked so far.

You should be proud of yourself, you have an ability to deal with what would be a very stressful situation for most.

I'd only caution to appreciate that the team dynamic is not healthy; if you are ever in a leadership position, please don't mimic it. A little assistance can go a long way, and while I don't like the terminology used in this article little bits of appreciation regularly given do really help team cohesion.

I would say there is a push to expand productivity of the population instead of simply stroking the ego of the most disciplined and adapt at sink or swim situations.

This does that.

Your experience should go by the way side and tap into the productive capacity of people that shouldnt be distracted by pressure.

I think I understand where you're coming from with this commment. I too, went through a series of jobs being thrown into the deep end, and while the amount of help I recieved from my co-workers varied, I can't think of a single time they actually left me hanging totally by myself. Instead they encouraged me to learn on my own as much as possible, and minimize asking questions that I should be able to find the answer for myself.

Eventually, we all find ourselves in a situation where there is no one to turn to, and you either sink or swim on your own skillset.

I've been on both sides of it. I think it's good to have a trial by fire or two to build up self-sufficiency and drive, but I think if that's all you have then it just makes scars.

I don't find this comment to be abrasive ;P

My onboarding experience at CircleCI was quite similar to yours (minus Pagerduty). One of the reasons my documentation gets shout-outs (as I mentioned in this post) is because there are sections of our codebases that didn't have any until I wrote them.

Succeeding in spite of difficult challenges is worth being proud of. Many of the moments I highlight in this piece are moments where coworkers helped me to see that I'd made it through a particular fire and had emerged alive and still-breathing on the other side.

I commend you for making it to where you are today, keep up the good work :)

Update: (More thoughts, approximately 2 seconds after posting)

And, as many commentators have blessedly noted below, coming through the fires with the support of a team is a generally much more positive, and often more constructive, experience.

I have worked at places far less supportive than CircleCI and would choose not to go through several of the same experiences again having experienced how much _better_ this is.

There's a healthy balance to be struck.

On the flip side, I hired a couple of juniors, and am hand-holding them WHILE going a million miles an hour, deploying "infrastructure as code" and "deploying to baremetal hardware", so while i would love to have a junior like you were, it's totally the onus of developer managment to figure out how to handhold juniors, if they need it.

Organizations function best when they help their employees be maximally productive. It takes a special kind of person to discover and derive Newton's laws of motion... and that too can take years. There are vastly more people who can understand it quickly once it's explained to them, and start applying it to solve real-world problems.

I mean, it's great that you thrived and didn't cause any huge issues as you got up to speed but uh...

...surely we can all agree that this is highly sub-optimal right?

> My team races at a million miles per hour, and frankly doesn't have the time to hand-hold a juniour as they learn the ropes. I was put on pagerduty and started putting out production fires within 3 weeks of being hired. With no prior experience.

I'm not saying this applies to you, but by experience has been that very well performing teams are so productive that they can be measured and calm. Overtime isn't needed, emergencies are rare, and "fires in production" don't happen, because the team is so far ahead of the curve. Whereas once a team starts to cut corners on documentation and processes, then more and more emergencies start to crop up, and all of a sudden it's crunch mode 24/7.

> My manager during performance reviews would heap praise on me for being so green and yet so low-maintenance.

Okay. I recently had a conversation with my manager about two recent hires. One asked a lot of questions, has become productive incredibly quickly, and is extremely well liked by the team. The second has been very low maintenance, has been very reluctant to ask questions, has been very slow to become productive. My conversation with my manager basically centred on how great the fist dev is, and how we can make sure future hires are more like the first dev, and less like the second dev.

Low maintenance is not really a trait I would want to optimise on.

> Coming from basically nothing. Allow me to brag a little bit. I'm proud of myself.

As you should be. But I would suggest that the average new hire, in your shoes, would certainly have come even further if they'd been given a healthy environment. You might as well.

> It is stressful, there are long hours involved, but the experience hardens one for sure.

Yeah, I'm just going to say it: That sort of stress is not good, and long hours simply aren't something we as an industry should expect or condone.

I would interpret the linked article as "good environments are better that stink ones", which is true. I would interpret your comment as "skilled and/or lucky devs can survive stink environments", which is also true. But just because you can doesn't mean it isn't better to not have to!

> I distinctly recall trying to limit my questioning to daily stand-up

If you are doing anything scrum-like, the daily standup is the worst time for a junior to ask questions, except if it's "I'm stuck with X, who can I ask after the standup about it?" (but that type of question is better done in a team chat, if you ask me).

The standup is meant to identify impediments and blocked issues, not time for technical questions. The standing up part is to make everybody uncomfortable if it's dragging on to long.

Now, I don't expect a junior developer to know this, but a scrum master (or in its absence, a team lead or more senior developer) should really have told you about it, and gave you instruction for a better time to ask such questions.

I've had a similar experience.

I changed careers to web development. Was hired on a 3 man team. My boss was overwhelmed by work and after I was hired an unbelievable series of family health issues.

I just sat down and decided I was going to work my way though the code until I figured it out.

My coworker was a good guy, CS degree, better coder than I am. More knowledgeable for sure.

Coworker guy moved on, he needed more structure, nothing wrong with that. I managed to just dig my way though and learned a lot.

Different experiences for sure, works for some, not so much for other.

I was the same way, and eventually realized my biggest skill is self teaching and managing uncertainty, but I'm not a shining star of design or algorithms, for example. So I try not to hold everyone who joins our team to my greatest strength.

I've heard from multiple engineers that have been put in a similar situation and hated it. It directly negatively impacted their self-esteem as developers and some of them quit at the soonest possible point.

As someone who went through pretty much the same thing and fought very hard to earn where he is today, I'm glad you're bragging and I'm glad you're proud of yourself.