Ask HN: How to improve as a struggling junior software engineer?
I got my first swe job this past August and it honestly has not gone well. I've enjoyed it, but it is clear that I am not seen as reliable and definitely not known for completing things fast.
I know this sounds like a normal junior dev, but I mean more than a normal beginner. Example: I have now been on this team for 8 months, 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.
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).
The struggles came way before this though. When I first joined I struggled to even know how to start things. 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 gets down to the issue. I don't think my team is necessarily the most ideal to learn on (my manager has been gone since December). The senior engineers also seem to assume I know more than I do (like the credentials above, it seems obvious there would be an account for QA and one for Prod, but I didn't know to assume that). But, the thing is though, 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.
I have identified some issues. 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 also tend to spend too long tackling an issue or trying to fix something I think I messed up rather than raise it to the team that I am having an issue. 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.
Honestly, I am a little deflated. I know imposter syndrome is a thing, but that doesn't count when 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. It just sucks because I did well in my CS classes and worked hard, and I feel kinda like a disappointment. Its hard to imagine anyone who is good at engineering delaying a teams release and causing problems. I don't know anything about performance (again cause manager is gone) but if I get put on PIP because of this, I feel like I can't help but see it as a statement on my potential and ability.
I know I should just focus on improvement, but I am not sure how. Should I be writing reminders to myself to always double check everything? Should I write down the steps to every process? Its hard for me to know whats a junior engineer error and whats an error I shouldn't be making at all.
[+] [-] GeneralMayhem|4 years ago|reply
---
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.
[+] [-] jmfldn|4 years ago|reply
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.
[+] [-] Ntrails|4 years ago|reply
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
[+] [-] hiepph|4 years ago|reply
[+] [-] aj91fl48znv3mpk|4 years ago|reply
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.
[+] [-] jimnotgym|4 years ago|reply
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
[+] [-] nscalf|4 years ago|reply
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.
[+] [-] Aeolun|4 years ago|reply
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.
[+] [-] brunooliv|4 years ago|reply
[+] [-] suncherta|4 years ago|reply
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).
[+] [-] lambo4bkfast|4 years ago|reply
[+] [-] shinryuu|4 years ago|reply
[+] [-] ratww|4 years ago|reply
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.
[+] [-] jwmcglynn|4 years ago|reply
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.
[+] [-] bb88|4 years ago|reply
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.
[+] [-] Twisol|4 years ago|reply
> 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.
[+] [-] daenz|4 years ago|reply
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.
[+] [-] baby|4 years ago|reply
[+] [-] spacemanmatt|4 years ago|reply
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.
[+] [-] GiorgioG|4 years ago|reply
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.
[+] [-] ratww|4 years ago|reply
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.
[+] [-] stormbrew|4 years ago|reply
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.
[+] [-] jyap|4 years ago|reply
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.
[+] [-] tempestn|4 years ago|reply
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.
[+] [-] BlackFly|4 years ago|reply
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.
[+] [-] rocketbop|4 years ago|reply
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.
[+] [-] Too|4 years ago|reply
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.
[+] [-] MrDresden|4 years ago|reply
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.
[+] [-] onion2k|4 years ago|reply
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.
[+] [-] mikebelanger|4 years ago|reply
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.
[+] [-] victor9000|4 years ago|reply
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.
[+] [-] dgb23|4 years ago|reply
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.
[+] [-] jupp0r|4 years ago|reply
[+] [-] alkonaut|4 years ago|reply
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.
[+] [-] maerF0x0|4 years ago|reply
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.
[+] [-] jmchuster|4 years ago|reply
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.
[+] [-] hjorthjort|4 years ago|reply
> 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.
[+] [-] hamasho|4 years ago|reply
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.
[+] [-] feydaykyn|4 years ago|reply
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 !
[+] [-] protastus|4 years ago|reply
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.
[+] [-] sage76|4 years ago|reply
It was an incredibly shit work environment. 0 onboarding, sink or swim. My buddy just ignored me most of the time.
[+] [-] hooby|4 years ago|reply
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.