10 Things I Wish I Knew When I Started Programming

1. The source code is read many times more than written. Just because it might seem to be the quickest, funkiest way of expressing a statement does not make this code the best you’ve ever written.

   Optimize your code for the reader, and you win in the long run. I’ve been working with code that is older than 20 years which means you are happy if the code is somehow easy to read and understand.

2. Don’t be afraid to write bad code. You don’t have to write the perfect code at the first try. Instead, focus on solving the problem first. If you have a working solution, level up the game and improve your code.

   Make it more readable, more maintainable and more expressive. It not only helps your co-workers; it also helps your future self.

3. Working as a software developer not only means typing code into an editor. There are meetings, you need to think about different ways to solve a problem, and there are people involved in projects.

   You also need to take a break from time to time, and you need to dislocate for the different meetings. Sitting in front of the computer and writing code is one of the many tasks and certainly not the only one.

4. You need to know more than one programming language. When starting you believe that you need to be the best JavaScript or C# developer. It’s just not true.

   Programming languages are a tool in the toolbelt and depending on the scenario you need to choose either the hammer or the screwdriver.

   Throughout your career, you’ll come across many tools. Some of them will always stay in your toolbelt, and some of them might be replaced.

5. Googling or searching for answers on StackOverflow are not embarrassing things to do. As a software developer you not only want the best possible solution to a given problem, but you also want to create unique solutions. You want to do it yourself.

   It’s an honorable behavior, but we also need to be efficient. We want to keep the development cost low, and therefore it’s not only okay but encouraged to look for solved problems on the internet.

   Splitting an array, concatenating files, opening streams, sorting data, etc. are all tasks that should not be reinvented. Although the university wants to make every student believe that you have to develop your algorithms yourself – they’re wrong. What’s important is to select the best algorithm to solve your problem.

6. Working as a team doesn’t slow you down. Writing code as a one-man-show is very productive. You don’t have to explain your code to anybody, and you don’t need to argue about which solution fits best.

   It is kind of short-term thinking that hurts people applying this strategy in the long-run. It’s important to talk about your solution and tweak your code here and there to make it more maintainable, extensible and understandable in the future.

   Nothing is more expensive than unmaintainable code nobody understands. I’ve been there, and it’s no fun.

7. Juniors don’t write worse code than seniors. As a junior, you sometimes write the better code because you are solving the same problems all day long. Seniors are often called in to solve hard problems in different areas of a software product.

   Juniors often face the luxury of being able to work on the same program or same part of a program for a more extended period which allows them to gain a deep understanding of that particular area.

   If you’re a junior, trust in yourself and your co-workers will happily help you out if you’re wrong once or twice during the week.

8. Task switching destroys focus. Although you learn to deal with interruptions, it still hurts your productivity. One of the things to decrease the number of interruptions is to schedule meetings at the beginning or the end of your workday.

   If you’re working on a particular algorithm head-down, you should not stop until you solved that problem. It’s best to use headphones when working in an open space office.

   Wearing headphones is a signal for people surrounding you that you’re working on a difficult task and that they should only interrupt you in case of fire.

   Always remember – git commit, git push, run!

9. Switching programming languages is not the end. You might be a ninja, rockstar super guru programmer in a specific language, but you’re a total beginner in another programming language.

   If a project requires you to change the tool you use, you’re not starting all over again. If you understand the mechanisms behind a programming language, you should be able to learn a new programming language quickly.

   It’s especially true for programming languages that share the same principles and paradigms, e.g. object-oriented programming languages.

   As they say: If you know someone from the family, you know all the family.

10. Work smart, not hard. Sometimes the most straightforward solution does not involve a hundred lines of code. Sometimes you need to take a step back, look at the program twice or a third time to unlock its best and most simplistic solution.

    Often the second or third idea is better than the first one. Start small and improve. Don’t always stay with the first attempt.

BONUS: You know more than you think you do. Sometimes I cannot think about what I’ve learned the last week or the previous month but let me tell you we are learning every day.

A million small steps add up to a giant step towards becoming a more experienced developer. Never stop learning and always be open to new solutions. Even after solving a problem many times there might be a chance to improve your code this time slightly.

Do you have any tips for beginners? Please share them in the comments section below.

This article was originally published on claudiobernasconi.ch on April 17th, 2019.