When I go to events and I meet others juniors developers like me, everyone starts to talk about one thing (in fact, that’s why we get together in the first place): “it’s been so hard, but I am loving it!” So I decided to talk a little about this today and maybe help others who are in the same situation.
Your first weeks
You are so happy someone finally hired you and are excited to work with a team and develop the software. Suddenly you start to feel a lot like this:
- You are terrified because you think you’re gonna be the intern who dropped the company’s database.
- You hold your breath for a few seconds before typing git push origin because you are afraid you will push it to master by accident.
- You have an idea of how to solve a problem, but you are terrified of breaking something important.
- You move other’s cards in Trello by accident.
- You are afraid to ask for help again to the team, they all look so busy solving complicated tasks!
- “How am I going to ask for help if I don’t even know what is happening after spending almost 3 days trying to understand what I am supposed to do?! “
- “How can she/he find the problem just by looking at it for like 3 seconds??”
- “I hope I can be a great professional like this person one day!”
Some tips that may help you during this phase
After you freak out a little — or a lot — you start to think:
- Oh no, that’s why nobody hires people without experience. They will fire me, I know NOTHING!!
- You feel like you are a burden to the team
- hello Darkness, my old friend
Unfortunately, this is a very common experience for junior developers. Do not let this put you down, please. This is a sign that you are persevering and you’ll be fine. Here are some tips that I’ve learned that may be helpful when working on a team:
- Understand and study a lot about Git. Seriously.
- If you find a command line that you don’t understand, always ask if that’s okay to use it. It’s really important to check the source of the commands and to understand how it works!
- Write clear and self-explanatory commits and Pull Requests.
- Read the documentation, even if you don’t understand it first time.
- Write down commands that your team uses frequently so you don’t have to ask every time.
- Take 1 hour per week to learn something new will help you improve your learning journey.
How to motivate yourself
For those moments when you feel like you should quit:
- Remember that you get to every day with people who have a lot of experience and have a lot to teach you (and I am not only talking about code) and they were in the same position years ago.
- Celebrate every small victory that you accomplish every day.
- If you are stuck for days, ask for help.
- Know when and how to ask for help.
- Talk to others so you can share your feelings with other juniors and seniors too and ask for advice.
- When you feel like you still got tons of things to learn, remember how much you’ve learned until today.
- Work on your motivation and enjoy the process. Try your best every day, try to improve your mental health. It can become a stressful process that may make you lose all the fun about programming.
How are you doing being a junior developer? Have something to share here?Do you remember how your first internship was like? What terrified you the most? How did you overcome your fears? What do you have to say for junior programmers like me? See you next time!
This post is also here at Magnetis backstage!
Top comments (72)
I completely agree about taking the extra time to learn more git and command line actions. They're both extremely important and can lead to so many more disasters if used recklessly. My main priorities are often those, and the basics of whatever team technologies I understand the least - a lot of work is done in Rails, and learning the basics of that has helped me immensely.
As for dealing with the thoughts of fear and insecurity, I don't think those feelings truly go away. But they're an extra motivator for asking more questions and trying to take on progressively tougher tasks. My best response to it has been a few tips you had: reminding myself of my small wins, reminding myself of how much I've learned so far, and learn at least a little each day.
Another big tip I've learned recently is, as you improve, don't be afraid to trust your gut more. In the early stages it's easy to always distrust it since you need to do lots of research and double-checking for new work. But don't get stuck in the habit of this, since eventually it'll be what tells you when something is wrong before your brain knows it.
Thanks for sharing your experience here. The tip about trusting your gut is something that I am starting to do, having Code Review in our daily practice also gives me some confidence to do that. The best!
I look forward to one day experiencing this. 😁
Hope this day comes very soon! :D
I DID accidentally push to master, and had to ask for help backing it out 🙇🏻♀️.
So now I always push with
git push origin <branch-name>, even if there are shorter ways.
I've been using git for what seems like a hundred years, and I still do that. Not only does it mean you're absolutely sure what you're doing, but if you scroll back up or look in your history to see what you did yesterday, it's explicit.
LOL, this is more common than we imagine, I've heard some people saying that too and they're not junior's anymore, so I think we are fine :D
but this also teaches a lot about git, right? I learned how to organize my commits and used
this month, it was exciting :D
Wow, those first weeks statements are so on point :D
They really are, right?! :P
Great post Steff, here's some perspective from someone on the other end of the experience spectrum.
Dropping the db. It's great that you are cautious around the production DB, but the company should really have better processes in place. A new team member really shouldn't have that kind of access until they are more comfortable. At my last startup, I had a rule that NOBODY was allowed to run any sort of write query against the production database without someone double checking their work. That included me, the CTO. I made sure to call someone over to sanity check my queries before running them.
Same thing with accidentally pushing to the wrong branch. It's a structural issue. Production branches should be protected from careless pushes.
If you know how to solve a problem, speak up. If your team is good they will listen to you no matter your experience level, and ideas stand on their own merit. If they don't, find a better place to work.
"You move other’s cards in Trello by accident." - Again, seems like a UI or setup problem with Trello if it's so easy to do the wrong thing.
Don't be afraid to ask for help. Unfortunately, you will undoubtedly encounter prima donnas among senior developers, but the best senior developers (or senior anything, really) do embrace their roles as mentors. The only thing I ask is they you've made an earnest effort to solve the problem yourself first, and don't just go asking for help the instant you get stuck.
It's normal to feel like you don't know what you're doing when you're thrown into a new codebase, no matter your experience level. Every codebase that has been worked on for a while has its quirks and nuances that you only really learn over time. Good programmers understand and respect this and start by being very cautious with their changes. Bad ones think "I have 10 years of experience, I can start mucking around right away", and probably break things because of all the things they didn't know.
"How can she/he find the problem just by looking at it for like 3 seconds??" It's true that more experience will help you spot things quicker. Sometimes a problem that other people are stumped on will trigger something at the back of my head that I've seen a long time ago that leads to the solution. On the other hand, sometimes all it takes is a fresh pair of eyes. I was once stuck on something that seemed silly and called over the developer who sat next to me to take a look (she'd was about 2 months out of a bootcamp), and she immediately spotted something that I had become blind to from starting at it too long.
“I hope I can be a great professional like this person one day!” You seem to be smart and have a great attitude, I think you're well on your way!
"Unfortunately, you will undoubtedly encounter prima donnas among senior developers, but the best senior developers (or senior anything, really) do embrace their roles as mentors." THIS, this is exactly what I think! I wish there were more people who think like that, but that's not only software related, right?
Thank you so much, these are awesome tips that you are sharing. Thank you so much for this final comment, sending you the best :3
but the best senior developers (or senior anything, really) do embrace their roles as mentors." THIS, this is exactly what I think!
Based on my recent interviews at several different companies, they seem to prefer to hire prima donna (aka know-it-alls) senior developers instead of people who would embrace a role as a mentor and guide.
Take on risky tasks like updating a change on production however nervous they make you. It breaks the anxiety of dealing with scary projects.
Yes, thanks, Allan, excellent point!
I would change a few things
GG, perseverance will win.
Hi, Adrian, thanks for sharing here your great advices!
What if after 8 months you still feel much of this? And it’s more like “It’s been so hard, and I’m not really enjoying it"? After 6 months you had a panic attack so bad you where almost committed to an emergency room at a mental hospital, and the depression and anxiety still lingers after 2 months .. is this field of work not for you?
So sorry to hear about this. I think that when that happens, it's better to talk with other people who can really help you. I have anxiety and I know how that feels, but I am getting better since I started therapy last year. Please, take care. Let me know if I can help with anything else. Trust me, I know that feeling but you don't have to go through that all by yourself.
Thanks, yeah .. starting therapy soon, and I'm lucky that everybody at work have been great about the whole thing.
Just so scared that I won't be up for it. Especially since it has taken me almost 10 years to get back up from some other bad stuff, quitting my first passion education because of chronic tinnitus, aborting the first CS degree attempt because of cancer etc... you know, just to crash again.
But yeah, let's hope the therapy helps, good to hear it has helped you :)
that's great that people at your work are supportive! I am sure you'll figure it out, you've been through a lot, you're strong. If you need to talk more feel free to reach me. I know how talking helps. Take care :)
Hey! I'm sorry to hear this too. I went through something similar. I was working two dev jobs for a year, about 4 days as a swift paid internship, and 3 days as a web dev. I was employed as the web dev first, and quite frankly, I didn't enjoy it. I was slow at tickets and would give me any excuse to not do them. It actually meant that I had to work late to get the tickets done. The overwork and stress was a trigger to my severe depression, if anything, one of the major factors. I did have to have therapy which is finished now but I am still on medication.
When I was in the office as a swift intern, the work was great, I really enjoyed the language and company culture. The CTO was understanding as were the rest of the team, generally great people. I've moved on from both places and now a jr fullstack dev where I'm still happy.
Please don't doubt your skills as a dev too much, especially if it's making you sick, you were hired for a reason. And don't overwork yourself! Please also reach out if you're having a tough time. Take care! I hope you feel better soon :)
Speaking of that reddit loser "who dropped the company’s database". It's not his fault! I can't even imagine someone can include ANY of the production database parameters in a readme file so this fuckup refers directly to the person who wrote that readme file, indeed!
Typically, I get those setting in about a month or two after i'm involved into the project.
Do not let juniors even a chance to break something in real world
I see this as an example of how most companies are not prepared at all to have juniors... but this is a question for another post. But I totally agree, thanks for commenting!
Nice post Stefanni.
I think one of the best pieces of advice I got for this back when I started out was to, in a sense, celebrate the small victories.
Every time you push a fix (let's face it, most juniors start out doing smallish bug fixes) and you see it working in production you build confidence. When the customers get it in their hands and they are happy that a feature is no longer broken it can be a tremendous boost to your confidence.
My first "big test" as a junior was during a trade show that my boss was attending. I was maybe a couple of months in as a junior. I got a call at around 4:00 from my boss that he was set to present something the next morning and part of an integration with another system had recently been broken. I had never worked in the integration's code and now I was looking at it for the first time under some degree of duress. I was short on time to get this fixed. It was scary as hell, I didn't know what I was going to find before I looked at the code. I knew that other parts of the code were a mess, if this part had been a mess too I would have been in for a long night. The senior devs had already left for the day so the fix was all on me. Myself and the QA team stayed a couple of hours later than usual, me fixing, them testing. By 6:30pm we had pushed the changes to the demo server and my boss had his first look. It worked and my boss was extremely grateful that I was able to get the fix in for him. It built my confidence and had the side effect of building my bosses confidence in my abilities.
After that I became the point person on a few of our integrations and was considered "the expert" on one of them. Even nearly a year after leaving that company I still get occasional emails from the senior devs about some aspects of the integrations I knew well.
When I started programming for the company I also got to know their source control solution well. I downloaded Vault to use at home. I never became a vault guru or anything like that, I just wanted to be familiar with it enough to get the job done.
If I got stuck or didn't understand something(LINQ was very good at confusing me at first) I would dig for a while and try to understand it. If I still wasn't able to understand it after some time I would ask the senior dev that sat in the cubicle next to me. He would perch on the divider between our desks, I would angle the monitor towards him and point to what I didn't understand. Then I would slowly walk though what I already understood. It was usually a sort of "this does this, and this does that...but what does this do?" kind of question. If it was something simple that I was missing he would say "you know this, just think a little more", if it was more advanced he might give me the answer or at least point me in the right direction if I was completely off track in my thinking.
So, in short, how I learned how to deal with it was this:
The moral of the story is just to keep chipping and chopping away at things you don't know. It will be hard at times. Sometimes you'll want to give up and say "I don't get it, maybe this kind of work isn't for me" but don't. Those hard fought victories are the sweetest of them all.
as one of those sr. folk, i love this article. not everyone likes to teach but some do, and don't mind answering as many questions as you've got and might even ask you questions. thanks, I'm sharing this around
Great article, totally how I felt when I started, and still do most of the time. One more difficulty for me is being a junior older than most of the senior in my company :) .
Seriously I have no problem with asking someone younger than me for help, but my coworker (and managers) often forget that I've been a developer for only one year (internship included).
And I think it's another tip : don't be afraid of being humble and remind your coworker that you are a beginner. If someone makes fun of you just tell him or her that it would be more clever and productive for him/her to explain the thing to you than being mean...
I think the main tip for asking for help and avoiding the traditional "read the fucking manual !" is to show that you read it. Show that you tried. Do not say simply "How do I do this" but "I've tried this and this, the problem seems to come from this but I just can't find a solution. Do you have an idea?". It may seems obvious but it's never bad to remind it.
Hi, Quentin, congrats on starting this adventure! I agree with everything you said, thanks for sharing :)
Wee all were afraid to do things when we started our journey, but it's important to remember that every senior dev was a junior at first.
Do not hesitate to do mistakes, even if it will coat your job, by doing so you will learn faster and sometimes it will reveal for you new things, release your fear to do something different, and paid off eventually.
One last point, Our job is not the mandatory point in our journey, but our unique donation to the world eventually.
Hi, Netanel! Yes, agree with you. Thanks for sharing here your thoughts =D
I am very excited to say I will be in this position less than a month from now, moving to a junior dev position from an IT support role. This post is gold and I will treasure all advice in it and in the comments :) wish me luck!
Congrats, good luck! :D
In the beginning I felt that my code was just too bad, not otimized enough etc. I started to work as a programmer in a startup, the entire team wasn't too experient. I've been working as a programmer since 1 year, I have improved my skills significantly since then, but there's still a lot to learn.
Legal ver uma pessoa do Brasil aqui! :D