Lately, online competitive programming platforms such as HackerRank/Leetcode have been gaining popularity among developers and recruiters alike. These are awesome platforms that provide an easy way to practice common algorithmic and data structure problems in preparation for an interview (or anything else). But assessment (and most importantly, preparation) of software development skills based on these results is inaccurate and not representative, as I will explain now.
Bubble sort, insertion sort, merge sort, heap sort, quick sort. Depth-first search, breadth-first search, Dijkstra’s algorithm, Floyd’s algorithm. You have been putting a lot of hours into algorithms and data structures, and know it all. You feel confident and ace the interview, solving all of their assessments. Then first day of work comes, you open your list of tasks and realize you have to fix 2 CSS errors, refactor a unit test and add an error handler to an API call. There were not covered in any of your preparations, you feel overwhelmed with studying a huge new codebase and slowly burn out.
This short story is supposed to show you that there is so much more to programming than algorithms and data structures, but no one pays attention to them. I will now cover 5 points that you should pay attention to in addition to algorithms and data structures.
1. Reading other’s code
This is the most underrated skill there is. Reading existing (and maybe legacy code) is vital to any software development occupation. You have to fully understand the codebase before making changes to it. You should be able to do code reviews of your peers and be open to receiving them.
Code review is essential to maintaining a consistent codebase and making sure everyone is on the same page. If you feel confident reading code, you will not refer to the documentation and your peers as often with redundant questions, thus raising productivity.
Additionally, by reading more and more code your code will become better and better. You will find solutions to common problems before you even have them. You will spot code smells instantly. Luckily, this skill is easy to learn.
To learn to understand unfamiliar code, head out to Github and look up some open-source library you are actively using. Read its code, try to understand it, and, ultimately, try to fix some existing issues in it. By doing this simple exercise, you will instantly get better at producing quality code and your seniors at a workplace will recognize it. You will also be giving back to the open-source community, which has its perks.
While closely related to the previous section, this is such an important problem that it deserves a separate one. The readability problem manifests itself as your codebase grows and you fail to keep it consistent and easy to understand. You will need to use principles like encapsulation, reusability, KISS (Keep It Simple, Stupid), and DRY (Don’t Repeat Yourself).
There is no one-size-fits-all solution to produce readable code. You can get better at it by (1) reading unfamiliar code, (2) refactoring your code over and over until everyone can understand it. Also remember that comments are no remedy for bad code: if your code needs comments for readability purposes, there is something wrong with it.
If you want to produce consistently readable and high quality code, I highly recommend reading Clean Code by Robert Cecil Martin. It will walk you through common problems, introduce solutions to them, and make you do some independent reading and refactoring to practice. If it was up to me, this book would be studied in every Software Engineering program.
Solving interesting computing problems on your own is fun, but not very efficient in workplaces. It requires a different type of thinking that cannot be taught, only learnt. In addition, you need to be confident with tools like Git, Jira, Slack, or their alternatives.
To become a more efficient teammate, you will need to work in groups, and this is something that platforms like HackerRank/Leetcode cannot yet provide (due to no fault of their own). Thankfully, most people get this experience by working in group projects in college/bootcamps, but if you are a self-taught developer (like me), you will need to upgrade your collaboration and communication skills.
4. Big picture thinking
While you are working your way through small, atomic problems, you will quickly get overconfident once you get your head around it. But you will still be missing a crucial skill: big picture thinking.
While problems on learning platforms are (most often) limited to one file, your actual project will not. Moreover, they will contain thousands of files with hundreds of classes and millions lines of code. While making changes to one part of the codebase, you have to be constantly aware of the changes this will bring to other parts. Of course, clean code and rigorous testing can help with that, but not eradicate completely.
As a developer, you constantly make decisions, even at an entry/junior level. It ranges from how to call this variable and which HTML element to use to which cloud provider is best for our needs and which application framework would work best. Regardless of its nature, developers need to be conscious of the consequences of their actions. This type of thinking can be developed by working on a single project for a while, so it can grow just enough that you see all the consequences of your initial actions.
Information security is a broad and complex subject, and no one expects you to even know of it when you start working. What I mean by security is code-level, applied practices that everyone should follow.
These are really simple: encapsulation (hiding the implementation of internal features), single responsibility principle (one entity should do one thing, and no other entities should interfere), and single point of truth principle (your data comes from a single source, and is never repeated). These principles will protect your code from the most obvious of attacks and are really simple to get your head around of. You do not really need them while working on isolated exercises, but they are important nevertheless.
Thank you for reading, I hope now you understand that there is more to programming than just grinding exercises. Still, I would like to reiterate that algorithms and data structures are equally important and you are expected to know at least the most common ones.