5. Ask for help (and code reviews), software engineers like to help others
The first job as a Software Engineer is one of the most exciting and stressful moments of your career. The work environment is nothing like university. It’s when you improve the most and most rapidly because you have the most experience and knowledge to gain. There are a lot of things I’d like to have known when I started working, and here are 10 of them (plus a little bonus at the end).
You get a new task. You think you understand it right away. You get to write code.
Sounds familiar? If yes, then you need to take your time to analyze the task. When you think you understand the problem, think it through again. Sometimes it’s tempting to get to code right away (it’s the fun part after all, isn’t it?) and deliver your solution in record time, but more often than not it’s going to translate into more work in the long run when all the little unexpected things appear.
So, take your time to go through the implicated sections of code and that includes every function. Afterward you can craft an educated solution covering all corners.
So, what is an edge case? According to Wikipedia:
In programming, an edge case typically involves input values that require special handling in an algorithm behind a computer program.
That means to think of any possible input so you can handle all of them. When edge cases are not taken into consideration, bugs are born. What takes me to my next point:
I know, unit testing can be pretty boring. But believe me, it can also be your best friend. There was 0 unit testing at my first job so I only got to learn about it when I moved to another position (my fault, I should have been interested in it earlier). I can assure you, that bugs were raised much less in the one that demanded 80% code coverage.
In computer science, test coverage is a measure (in percent) of the degree to which the source code of a program is executed when a particular test suite is run.
Through unit testing, you not only validate that your code works and delivers the expected solution and every edge case you can think about it, but it also validates that you are not messing up something else without noticing in the future.
It can be argued that you learn to code the most through reading rather than through writing. When working on a task (if times allow you to), make sure to understand every little line of code, don’t just think “this function right here does this thing and that’s what it’s important”. Go into the function, read every line, and that way you learn how problems are solved. Trust me, when I first started learning to program, I only paid attention to what things do instead of how things do what they do, and when I started taking my time to go through everything, my knowledge grew exponentially. Even without notice, your brain starts to detect common problems and solutions.
It may be just my empirical experience, but software engineers love to share knowledge and help others. As proof, think about all the questions and answers Stack Overflow has. Don’t be afraid to ask questions, even if they sound silly. We’ve all been there and your peers won’t judge you for it. The only stupid question is the one that you don’t ask.
The same goes for code reviews. Getting other software engineers to read your code and give you feedback is a wonderful way of learning because you’ll gain insight into different ways of achieving the same result, let alone errors that you may have overlooked.
As software engineers what we enjoy most about our career is coding. Solving complex problems with some lines of colorfully highlighted code over a black canvas. Therefore it’s easy to overlook theory. And I’m not talking about hardcore computation theory, but more like design patterns, design principles, common algorithms, you get the picture. Learn about design patterns and anti-patterns (how common problems should be easily solved and how they should not), design and development principles like TDD, KISS, SOLID, DRY, YAGNI; Big O notation, and the complexity of common algorithm, and just keep going. The theory will make your life as a software engineer easier, more agile, well-rounded, and professional.
Getting your code reviewed is important, but reviewing other people’s code is too. As with getting your code reviewed, you’ll learn different ways of solving different problems and get an insight into the problem the code solves and libraries you didn’t know. It can be challenging sometimes and maybe kind of a slow process until you get the bigger picture, get what the code does and what the software engineer you are reviewing is trying to achieve, but still very worth it.
You start learning to program and begin to think you are creating a strong foundation, then you decide to start solving Code Wars problems (maybe to learn, practice, or just for fun). You work through your first exercise, you get to a pretty good solution that you are proud of and you submit it to only find out that 37 people replaced your 14 lines of code with a one-liner. Naturally, you start to question how strong your foundation was and think of all the things you still have to learn. Yes, you have a lot to learn, but maybe one-liners aren’t one of them.
One line of code looks awesome at first. You think it outlines an incomparable language proficiency that you are never going to have. But in the professional world, and if you don’t believe me ask your nearest Senior Engineer, one-liner code makes awful code. It’s slow to read, slow to understand, and unnecessarily complex. If you can achieve the same result with some extra lines of code but make it a lot more readable for the next person, it’s probably better code. Unless you work alone, and you rarely will be, chances are the next time your code is read, it won’t be by you.
This one goes along with the DRY design principle I suggested learning about in section 6. DRY stands for Don’t Repeat Yourself, and it means that if your need to write the same code twice, it’s better to make it a function so it remains reusable in the future and it keeps your code clean.
Yes, I’m talking about the main tool for a software engineer: an IDE/Text editor. Whether you use a full-fledged JetBrain’s IDE or you prefer to go hardcore and customize Vim to your taste, take time to learn your tools in depth. Error highlighting, refactoring, renaming, replacing, search… And the list keeps going. You can’t even imagine how much more productive can knowing your IDE/Text editor can make you.
Seriously, don’t underestimate the productivity of learning Vim shortcuts. It’s ok if you don’t like coding in a terminal, because most IDEs/Text editors have Vim plugins. In short, it has three modes, normal mode (also known as command mode), insert mode, and visual mode. In insert mode, you guessed, you insert text; in the visual mode you highlight text, and when in normal mode, you move around the code with letters (h, j, k, l) and different keys to perform different actions.
For example, you remove a line with dd, a word with dw, move a word forward with w, move back a word with b, undo a change with u, you get the picture. You can move around the code with a few keystrokes, replace all code inside a given character, replace a word or a number of words, lines, paragraphs, you name it. And that’s just the tip of the iceberg.
I won’t lie to you, it’s hard at first and it takes a while to get used to it, but imagine the speed you can achieve if your actions are one or two keystrokes away. And it’s not limited to moving around code, you can also switch files without ever exiting the keyboard. It allows you to code pretty much mouse-free (let’s be honest, the programmer’s dream). It’s so good that when you internalized them, you missed them when you don’t have them (e.g. writing a document) and it’s the reason why I now use Vim as my main text editor for everything outside coding too.
Hope these tips are helpful to you and I wish you all a very good and happy career!