Ask HN: How to improve as a struggling junior software engineer?

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

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.

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.

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 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.

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.

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.

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.

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.

* 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

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!

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.

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

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.

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...

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.

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.

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.

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.

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.

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)

> 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.