6 months as Software Developer and Advices for beginners

6 months as Software Developer and Advices for beginners

Sergii Kirianov's photo
Sergii Kirianov
·May 23, 2022·

10 min read

Subscribe to my newsletter and never miss my upcoming articles

Wow, it has been 6 months! It’s still hard to believe that my plan worked out and I’m a Frontend Developer for more than half a year already! Though since Feb 24th for me and million others it felt like time had stopped, actually it passed pretty quick, maybe even quicker than ever.

They say, that at work you learn way faster and in the first month at work you’ll learn more than you’ve learned during your studies. Well, they didn't lie. To be honest, I had no idea what the real project is, not just a simple Fullstack app with primitive REST API and UI, but something big and serious. With settings, tooling, tests, different environments, and so on. It's quite rare and not really expected that a beginner will do something similar for a pet project or will build some sophisticated APIs with complex Data Structures. Working on a pretty big project is, maybe, one of the most important experiences I could ever get from my first work as a Software Developer.

So, what has changed, and what I've learned in the last 6 months?

What I've learned

What's team and project management? 🧐

There's no order in things by importance, but I still preferred to put them in the way they are for a reason.

I've got experience working in a team - sometimes people neglect the fact how important this experience is. Also, since I work remotely I've got an amazing opportunity to know how to work in such conditions, which is quite a necessary skill in the current world. Of course, I can't ignore the fact that getting an idea and experience working with a Project Manager is awesome. It's not a secret that beginners don't really know what Agile, Waterfall, or enter_any_management_word_here and why / what / who Scrum Master is. Yeah, we all watched those videos and maybe even bought a course, but one thing - learning what it is, and another - actually being able to navigate your ship in the " Stories, Tasks, Tickets and bla-bla-bla" waters. Speaking of which, I HIGHLY recommend you to get yourself a free account on GitHub (come on, I can't imagine you don't have one), Atlassian products (BitBucket, Jira, etc.), and some more, and try to create your own project to see what is what. Trust me, even being able to navigate the app and knowing the terminology will put you one step ahead of others.

It's still about code 🧑‍💻

As I said previously when you start working your learning progress instantly goes to the moon 🚀🌕

Regular code reviews make you write cleaner and better code. Well, I don't simply follow the Senior's comments, if I don't think they are right. If the comment is not that obvious, or I think that what I've done is better I will discuss it with the reviewer and we will reach a consensus. In my case, they have never kicked my ass for that (benefits of working remotely 😂).

Oh....TypeScript....

Well.....what can I say...I...love it?! Yeah, it's still a bit rough with me, especially when I get some weird errors that I can't understand, especially when Google is not much of a help, even tho I'm pretty great at Googling 🥲Honetsly, I'm using TypeScript from the very first day at work and it's getting hard to imagine that I'm using pure JavaScript, tho must admit that at times I write vanilla JS first and add types later 🌝

Since most of us, recent beginners, have started with Functional-based React, I had to pick up Class-based components pretty fast, cause the project used both of them. That was great, learned new approaches and patterns. Had seen both great techniques and really bad techniques - luckily we got rid of them pretty fast 😏

Another killer was D3.js - what a great library! I've spent a hell lot of time working with it and I am kind of the "go-to-person" for any D3.js things in the company, cause I have the most experience with it and I was solely working on that part of the app, so I have the most knowledge of the codebase. Honestly, what a piece of art this library is 🥰

Personally, I have a huge interest in all-dev things, so I started slowly learning about both Backend and DevOps. It's slow but steady. Tsss...our backend is in PHP and I don't really want to touch it 🤫 So I'm going with Node right now and want to add some Python to my stack too.

Anyway, let's talk a bit about some advice I would like to give you. It's not that I'm something special, super experienced, or extraordinary coder, but I've got a job being self-taught, progressed pretty fast, and haven't paid a cent to learn to program. I know how people who just start to learn/looking for their first job/just recently got a job as Junior Developer may feel, so hope those will help.

Please understand, that advice that I give below has worked out well for me, in my company and environment. These are not some "ultimate" advice that always works, but I believe that they work in 90% of cases.

Career advice for Junior Developers

One day, a follower DMed me on Twitter that he is going to start his journey to find his first job and asked me for advice, so I will share them here and also add additional advice that have been planned for this article.

Being Junior Developer doesn’t mean that you’re a kid.

I’m not saying that you should be wearing all black and grey, don't joke or fool around a bit - no. The point is, you’re a grown-up human being that got a job in a real company in the real world. Yes, there is an onboarding period. Yes, they know that you’re junior and they need to keep an eye on you. But heck, it’s not a kindergarten, right? You are a fully responsible individual who has to take the job seriously and show that you’re capable of doing it. Capable to be responsible for the code you write and for the piece of the app you’re working on. The faster they see that - the faster you’ll be treated as an important part of the team, and not "intern+" employee.

You’re an integral part of the team, let them know about it.

Take part in the discussions, and take part in the product/design/engineering meetings. Even if you don’t understand some of it. Take a note of what you didn’t understand and Google it later. Listen and soak as much knowledge as you can. If you’re not invited by default, ask if you can join. Show your interest and willingness to be part of the project.

Don’t be afraid to open your mouth and spit fax.

Let’s be real, everyone (at least adequate people) wants to make a great product that users will enjoy using. If during discussion of a new feature you hear that some collective madness is happening, and some weird things are being proposed - don’t be afraid to SPEAK. Really! Everyone is getting tired, and busy with their own work and they may just be on their mind and miss some things from the conversation. And if you spotted, that idea is bad, implementation will be hard, UX will suffer, and it may lead to the inability to scale - SPEAK! They will appreciate it - truest me. Do it in a smart way. Kindly ask to interrupt them and explain why you think that the idea is not worth it. Give examples of why you think it's bad.

Don’t be afraid to suggest.

That last point on top? Yeah, this one is kind of a continuation of it. You’ve got a good idea, let the team know about it. If you think that it would be cool to implement some features - let them know. If you think the design could be better and you have an idea of how to improve it - let them know. Basically, the whole point is. You’re a team, so work as a team. The stronger the team - the better the product.

Do code reviews.

It may be different from organization to organization, but if you have an opportunity to review Senior’s code - do it. See how experienced people are writing code, see how they comment, and see how they style code. You can learn A LOT from just reading someone’s code. And don't be afraid to give them comments that something is wrong, or code is bulls....bad. As I said, in the end, this is the user and developers who will suffer from the bad code. If you can prevent it - do it.

Balance when to ask for help.

This one is quite individual. Everyone has their own estimation of what’s too early and what’s too late, though in this case, it’s never too late because you eventually will stuck and ask for help. Let’s define what is too early and what’s too late in my opinion.

If you ask too early you may end up looking like you didn’t even bother to try and solve the issue. Even worse, look like someone who thinks that their time is more important than other’s 😕

Few points meaning it’s still too early:

  • You haven’t Googled the issue at all;
  • You Googled it, but it was only copy-paste error message search and you didn’t get any results;
  • You haven’t looked at similar code/component in other places;
  • You checked only StackOverflow but you haven’t checked GitHub issues and scrolled through the whole thread;
  • You haven’t Googled with at least 4 to 5 different descriptions of the issue.

In general, if I’m stuck with something for more than 1 hour I start thinking of asking for help, my red line is 2 hours. If in 2 hours I can’t find the issue, I ask for help and we try together. Most of the time tho I could solve it myself, or find the solution during a pair programming session.

Asking for helo too late is not particularly bad for a Junior Developer, it’s even expected, same as asking “too early” tho. But bear in mind, that later you ask, means more money you’ve spent for the company. As I said, I’m trying to keep it under 2 hours, somehow this is the limit I’ve set for myself and till now nobody has complained and even appreciated it.

Only one point:

  • If it’s past 2 hours and you have no idea why, where, how, and so on - ask for help, you may get into “too late” land.

Don’t be a d*ck and accept your mistakes

Well, this is not only a programming thing, but it also has its place in this field. If something is broken after you changed code, you haven’t tested it and you pushed it. Don’t be a d*ck and accept that you have messed it up. Instead of hiding in the bushes, trying to find anyone (that famous “previous developer”) to blame, better take care and apply a hotfix, since you were the last who worked on it and you know what you have it fresh.

GOD PLEASE, DON’T DO BE A DUCK!

  • This is your job, not your life

A good developer is a well-rested developer. Sometimes I may stay a bit longer just to finish that last thing because I know it will take me some time in the morning to remember what’s the code about. Sometimes I may get an idea of how to fix something at 1 AM and I can sit and code for 15-20 mins. This is perfectly fine, I guess. But other than that.

5 PM. FINITO. TIK-TOK AMA CLOCK..…shut the laptop and relax.

Of course, you can,"need" and will code after hours, but that coding is hobby, not a job! You’ve done your job - you call it a day. Of course, at times, an emergency may happen and that is okay, you will take a rest once things are rectified, but other than that - see you later, Alligator.

Let’s call it a day

Pheeewwww, this was a big one. I guess I can continue with the advice, so let’s make it a Twitter Space one day cause I can talk and talk and talk about it. Don't forget to follow me on socials if you're interested in it @SergiiKirianov and Instagram js_messiah

The First 6 months were great all along. I didn’t have any single day I regret that I have changed careers and that I’m not at sea. There are some underwater rocks, but nothing really bad. What to say, I love what I do 🥰

Thanks for reading and hope you enjoyed it and hope even more that it will be useful for you. Wish you good luck with your career as a Dev. You must know one thing, you can do it! It’s not easy, it may take some time, but you can do it! I know!

Did you find this article valuable?

Support Sergii Kirianov by becoming a sponsor. Any amount is appreciated!

See recent sponsors Learn more about Hashnode Sponsors
 
Share this