7 Mistakes to Avoid as a Beginner Software Engineer
Today I wanted to talk about a few common mistakes I see beginner software engineers making all the time. These are things I've seen repeatedly pop up while mentoring and managing junior engineers. I think these are things that come out as a side-effect of how most educational institutions approach teaching computer science, which works very well to teach the basics but how things are done in the real world are different from how you do things in school. And I feel like a lot of fresh graduates struggle making that transition. Hopefully this post will give you some idea about what to look out for as a beginner software engineer.
If you prefer the video format, I’ve got a video on this exact topic on YouTube… feel free to watch that instead. Otherwise, continue reading.
ONE: Building the next big thing
So you have just graduated college, and armed with your newly learned programming skills, you want to build the next big thing. However, in most cases, that drive comes from passion rather than experience, which is not a bad thing, passion makes great things happen, but more often than not, you will need experience to pull it off. I know, there have been amazing engineers like Bill Gates or Mark Zuckerburg, who dropped out of school and went on to build some of the largest companies in the world. But beyond all the success, what we fail to see is that they probably started coding very early on and by the time they were in college, they had likely mastered a lot of things that most college students are just starting to learn. So, while these are great people to hold as inspirations, trying to follow their exact model can be detrimental for most beginners.
In school, we build simple projects and call them things like "Inventory management system" or "library catalog system". But all we really do is build a basic 3-tier system. Real world projects are much more complicated than a simple 3-tier system, esp. when you need to build a scalable, distributed and fault-tolerant system. So, a better approach as a beginner is to build small "components" and gradually build up your experience to be able to create something end-to-end. Instead of trying to build Facebook, build something simple like Tic-tac-toe, which is small enough that you can implement it properly in a short period of time. It can be a simple console app. But it will let you get comfortable with data structures and even some game algorithms like Min-max. Once you have done that, maybe try chess. It's much more complicated, but it builds on the same concept of a board, players, etc. Start by building a simple 2 player game where you just manage the game state, then try to add some supervised learning where a player can play against AI. If you finish that, then maybe make it a web-based game and add some UI elements. Then add user management where users can save their game state online and resume later on any device. Then build on to make it an online multiplayer platform where you can match players based on their skills.
You see, as a beginner, it's much easier to start with a basic idea and build on top of it instead of trying to build a large and complicated project. As you repeat this process over and over again with different projects, not only do you get better at your fundamentals, but you also get better at thinking through your projects and how you can combine multiple components to build an end product, which will make you a better designer where you think through the problem before jumping in to code right away!
TWO: Jumping in to code too quick
Which takes me to the 2nd point, jumping in to code too quickly. As a beginner engineer, you have so much excitement to code, and it's common to view your responsibility and to some extent, even quantify your skills with the amount of code you write. Let me tell you right off the bat that this is a very flawed concept. If you are the kind that jumps to code the first idea or solution that comes to your mind, you will end up wasting a lot of your time. Resist the temptation to code and think about alternate ways to challenge your own assumptions first. Yes, some of this comes with experience, but it's good to build the habit early on. Too many times I see beginner software engineers jump to code something, work on it for a few days and then realize that they didn't even understand the problem in the first place.
THIRD: Trying to code everything from scratch
This kind of builds on the previous point, where new software engineers are so eager to code that they want to write everything from scratch. Building something on your own is a good way to learn an area you are interested in. However, in practical terms, you should look to get the most out of your time. And one great way to do that is writing less repeated code and re-use as much as possible. And libraries are a great way to achieve this. Any time you come across a problem, try to find an existing, mature library that someone else has already written. Are you parsing commonly used structures like trees? There is probably a library for it. Are you serializing and deserializing objects a lot? There is a library for it. Are you mapping properties between various similar objects? There is a library for that. And there are libraries for almost all common things like HTTP requests, API clients, retry logic, so on and so forth.
Of course, you need to be careful when pulling in libraries in your project. You will need to think about things like privacy, maintainability and package size. But that comes with experience. The main idea is to start thinking about reusing instead of writing from scratch so that you can focus your time on solving the problem and not reinventing the wheel.
FOURTH: Being a means to an end coder
What I mean by this is that you search for something because you are stuck and need some help. But the moment you find a post that gives you the solution, say in a place like stackoverflow.com, you copy-paste it and move on without understanding how they solved it and why you could not. You solved your immediate problem, but you didn't fix the root cause. This leads you to become the kind of engineer that solves problems in a very hacky and patched up manner without understanding the actual inner workings of your own solution. This is very dangerous and can cause a lot of issues in your projects down the line and can lead to significant technical debt for whoever will eventually end up addressing your patched up code.
So don't be the "stackoverflow dev". It's okay to look for solutions online, but when you find one, make sure to fully understand how it works and to fill gaps in your own knowledge that led you to being stuck in the first place!
FIFTH: Not writing tests!
There is not enough emphasis placed on testing in colleges. But in your job, you will most likely not even be able to check in your code without accompanying test cases. Beginner engineers write test cases as an afterthought. They write their code, and then write test cases later to "test" their logic. This is better than not writing tests at all, but it still isn't the best approach. Build a habit of writing test cases for your code, even before you have written your code. Because test cases don't just test your code, they expose bad design as well. To be truly testable, any class you create should be self-contained, mockable and should have a single responsibility. When your classes follow these rules, your tests can simply mock the expected behavior without needing to pull in the entire dependency chain.
So when writing code, a great habit is to just create a skeleton of your code (just classes and stubs), then write test cases for the expected behavior. At that point all your test cases will fail. Then you fill in your skeleton with logic to make all the tests pass. This way, you not only write fully tested code, but also build a maintainable, and extensible codebase with no hidden dependencies.
If some of this sounds a bit complex to you, don't worry. The key take away for you is to follow a test-driven-development process. The rest you will learn as you go.
SIXTH: Not reading enough code!
This is so common, it's not even funny. I've seen great devs who can code up quick, effective solutions on their own, but completely crumble when they have to contribute to any project that is not their own. The reason: they are just not used to reading other people's code. Reading other people's code, understanding it quickly and being able to debug through it is a skill on it's own! So start building this early - because you will be doing a lot of this in your job, and reading others' code can sometimes be more challenging than writing your own. The end goal as you progress through your career is to not only be able to read a codebase that multiple devs have worked on, but understand the big picture quickly and identify areas where you can improve.
A great way to build this skill early on is to go to open source projects, read the code there and try to understand what is going on. Even better if you can identify some improvements and put in a pull request to do so!
SEVENTH: Trying to learn too many things at once
I think there is a severe case of FOMO in young developers these days where they want to be up-to-date to the latest trend in Software Engineering. I've said this in multiple videos, Q&As and direct DMs already, but I will say it again — quality over quantity! You may impress your recruiter with a list of fancy new tech on your resume, but if you are straight out of college and list out a dozen things, I will immediately be suspicious. So, focus on a few things and learn them well. Don't worry too much about being up-to-date with the trend, you will have enough time to do that in your job.
Another thing this FOMO leads people to do is follow tutorial after tutorial on different technologies. You've all heard of the "tutorial hell", where you follow tutorials and get the false competence of being able to build something but in reality you've learned nothing. Don't waste your time on those things. I also see a lot of engineering channels popping up with 2-3 hour videos on building a Twitter clone or Instagram clone and things like that. Look, if you could build Twitter in 3 hours, you'd probably be the smartest and fastest engineer in the world. Building a UX that looks like twitter with a simple API with a backing store like Firebase is NOT a Twitter clone. You will be hard pressed to hand-draw just the data flow diagram involved in Twitter in 3 hours, let alone design a complete clone. So please do yourself a favor and get out of the habit of following these tutorials, and instead, invest your time on learning how things like twitter actually function behind the scenes.
Also, hopping from one tech to another never gives you enough time to learn something in depth. So spend time really nailing your fundamentals in one stack. It will not only make you a better engineer, but also build a platform for you which will allow you to learn other languages and frameworks much faster!
