My list of things that I wish I knew before my first day as a Software Engineer.
I've been an Associate Software Engineer for a little over 3 months now and I thought it would be a good time to write a helpful article for other junior engineers who are about to start out at a new job, or maybe for those who are actively applying for their first development position. This list may not be as relevant for you, however for me these were my five big points. Honestly, I wish that my school work covered these areas more. Collaboration is such a huge part of development and I feel like most of what I learned through school was theory and how to program as an individual engineer, not as part of a team.
So without further ado...
1. I wish I had more experience setting up and troubleshooting my work environment
It's day 1, my only responsibility is getting my work environment setup and meeting my peers. Easy... right? Not so fast...
So throughout my university experience and while doing personal projects, I had not setup Visual Studio one time. While I did have experience setting up Netbeans @WGU, Eclipse @CSU and Rider and IntelliJ at home, I had no experience using Visual Studio. This isn't too surprising considering all of the IDEs I've used prior (except for Rider) were to development Java applications and now I am writing C# in .NET Core.
My first day I ran into a handful of errors while trying to compile my code. I was troubleshooting most of the day and while our documentation was really well done, there were areas that were not covered in it, like handling specific errors that I was running into. I really think that a course on setting up an IDE work environment could be a valuable class in college. Apparently, some of my co-workers take their whole first week to setup their work machine, which now I can understand as it takes time to get everything exactly how you want it to be. Finally, a few days later I was able to get everything working smoothly with the help of our principle engineer.
Tip to make it easier: Once you accept a job offer, contact your boss and ask about the IDE and any plugins that the team uses. Take your time to learn the IDE and try downloading some projects from the internet and try getting them setup.
2. Wish I was more familiar with Git and using it with a team
Git... Perhaps one of the most important areas of modern programming. Almost every company is either using git or some version of source control. For me, in school Git was simply not used, at all. There was no course on how to use Git, what it was, or why it was important. Luckily, I had used Git in some of my personal projects so I was not completely lost, but it was only to store projects on Github and not to collaborate.
The problem is that git really shines at collaboration but there are some scary problems that you can run into while trying to merge your branch's code back into the trunk. These problems are especially scary at a junior level when you're afraid to make mistakes. Once you go to merge your code, if you see the build fail, I guarantee as a first time recently employed junior developer your heart will fall right into your stomach. It will be okay. You can fix pretty much any Git problem that you run into and your senior engineers know this.
Tips to make it easier: Practice! Find projects that you are interested in and try to contribute to them, github is probably the best source for this. Take some of Gitlab's courses on Git... They're free. Finally, I have found that if I rebase my branch first before merging, I have a greater success rate because of how rebase works versus merge. Here's a great article on rebase vs merge.
3. Debugging code and using break points
During my first week as a junior developer, I was tasked with writing some Unit Tests for existing code that was confirmed to be working. By the way, writing Unit Tests for existing code is a great way to learn the code base and get familiar with the structure of the application you're working on. During this time, I was very green at using break points and debugging. You can imagine how ill-prepared I felt to write tests, but I did it and I even found my first bug.
In retrospect; I don't recall writing any Unit Tests at all during my time in college. I remember taking some software testing classes, but they were manual testing/ quality assurance classes. These were helpful for sure, but they helped very little with unit testing. While writing my first set of tests, I didn't realize that I could place a break point in the controller I was testing. Writing that now makes me feel a little silly, OF COURSE I can put break points in the controller I am testing but while I was writing the tests, I only thought to put break points in the test class.
Tips to make it easier: Write some unit tests for your personal projects. Test Driven Development is a big deal and a lot of companies use it. Where I am at now, we are not allowed to push out RESTful Web API Controllers/ end points without Unit Tests to go along with them. Also, ask your new team what they use for Unit Tests prior to starting and try to get familiar with it. At my job we use xUnit and I wish I had spent a little time with it prior to starting. It's not particularly difficult, but having that confidence boost in familiarity goes a long way.
4. Learning how to navigate my IDE better
This could technically go with "I wish I had more experience setting up and troubleshooting my work environment" and "debugging code and using break points" but I felt it was important enough to have it's own section.
Imagine this; You're in a 1-on-1 code review with your new supervisor. You bring your laptop into the room and you fumble around the shortcut keys and tabs while trying to run through your code with them. Sure, you're new and it's understandable that you may not be able to explain your code quickly, but fumbling around because you're unfamiliar with your IDE is something that you should be able to workout in a few weeks.
Tips to make it easier: Learn the shortcut keys for your IDE (Visual Studio, VS Code, Intellij, etc...), it will help a ton! On your next home project, code in the IDE your job uses, just to get a bit more familiar with using it. Also if you're company uses extensions or plugins, it's a good idea to get familiar with those as well.
5. It's okay to learn on the job
Okay, this is the most important point. Impostor syndrome is real. It is okay to learn on the job, in-fact it is generally encouraged. There's a line of course; you still need to complete your work and focus on work related tasks, but learning is a continuous part of programming. When I got a job offer at my current job, I was very nervous about learning C# when I had previously only used Java and Python. I did some self-learning at home, but most of my C# coding skills definitely come from learning on the job.
It's important to remember you are trying to land a junior level position. These positions are created with learning in mind. My company pays for a PluralSight and LinkedIn Learning subscription for it's developers so that we can learn new technologies or help junior engineers learn our current stack better. It's okay not to know everything and it's okay to ask questions. My advice is try to solve the problems on your own first, then try Google/ StackOverflow and if you are still stumped, ask one of your senior engineers if they can help you learn how to X.
Tips to make it easier: Learn to go with the flow and take advantage of the resources that are available to you. Become comfortable asking for help but become even more comfortable searching for solutions to your own problems. Again, it's a balance. You need to spend time trying to solve your own problems, that's expected... but it's also known that you are still learning and will need to ask for assistance at times. Also, please don't let impostor syndrome stop you from applying to junior level jobs. Get your resume out there, if you're passionate and know the basics, you can learn everything else!
And that's my list of things that I wish I knew prior to my first day as a software engineer. Hopefully this list helps someone relax and prepare for their first junior software engineer position. Also, your results may vary... All companies are different, but this should be a good starting point for most any company. Good luck on your position as a software engineer!
Please subscribe and follow me on my website for more posts like this: https://iamtravisw.com
Top comments (15)
I hope that git will be the norm for Computer Science degree. My country does not require git in schools. They simply throw a boilerplate code and never bothered to use FOSS. They simply put "Paid IDEs" in their machine and make use of it.
Project Management, Methodology, Design System, Proper Documentation, and productivity.
I think that is the direction it's heading. While applying for positions here almost all of them wanted experience with Git in some form.
I can't blame the school for not providing proper real world team collaboration. It's just that, technology moves so fast and the professors don't let students collaborate with each other. We(me and my friend) held a small session teaching git for the students. They got bored because it was too complicated to use. We tried several methods but in the end, some were not interested and never bothered to learn anymore(we didn't force them to come btw).
My mistake for having a session is that
final_1,final_finallyproject.Hi Dennis, It's just not right that Git isn't taught in your school when company's are now requiring Git as a job pre-requisite. If I may suggest, there are a lot of free books on Git on Kindle that you may want to checkout. This is what I personally read when I get lost using Git
I hope this helps!
As a Senior dev, I feel the need to point out that only your last point actually matters for juniors.
If you took less than a working week to setup your new machine, awesome, you've beaten EVERY single junior I've ever worked with. Hell, I'm still changing things up on my office laptop!
Git/SCM... don't beat yourself up. I know Seniors that don't understand how a "pull --rebase" works. Find someone on your team that's comfy with the SCM, and pick their brains whenever you're stuck. Also, there's no shame in Googling.
Re the IDE, some firms mandate it, some don't. Generally the better employers realise that all that matters, is that the code is readable. If your IDE & plugins is mandated, as a junior, unfortunately you have to just suck up the learning curve. But communicate with the team as you go. If a junior came to me with a "how do I do X?" - I'd not only help them, but I'd also feed back to management that you're putting your best foot forwards, and I'd help you keep the project management team off your back.
Back to your last point: chill. You're new, you're a junior. Deep breaths, and use the Seniors & Leads - they get paid to help you out.
Hey Dave!
I really appreciate the feedback and I hope that some of the people this article was written for find it! You're right, the only point that really matters is the last point, technically everything else rolls into that point.
Cheers!
I do share your point of view. Mostly point 2,3,5. The IDE is somehow subjective but the rest just stands as-is.
Have fun being a junior developer. Once you go senior, you never go back :)
Ha, thanks! The IDE portion is definitely subjective. I agree!
Thanks for sharing this!
As someone who's starting a software engineering internship in a month, this was really helpful and made me reconsider how well I really know Git and my IDEs/tools.
Absolutely! I was pretty nervous starting at my job, but so far so good! Best of luck to you at your internship!
Definitely... I know that we're seen as "anti-social" but forcing us into at least one team project would be such a good experience as students.
I agree 2~4
Thanks for providing such type of useful and motivational information.
You're very welcome! I really appreciate your comment.
All of this is very basic. I would say obvious for passioned people but not obvious to the majority of average students as universities do not necessarily focus on this. Still good to mention it.