DEV Community

Claudio Bernasconi
Claudio Bernasconi

Posted on • Originally published at claudiobernasconi.ch

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.

Top comments (2)

Collapse
 
vier31 profile image
Jan Schröder • Edited

It is okay to say: I don't know this. Can you help me out?

But, when asking someone for help or advice, respect their time.

Start by explaining your intended outcome and possible solutions you already thought of. This can be in a high level concept. And things you tried, that didn't work.

This shows the other, that you made an effort and are aware of what you don't know.

I am a junior frontend developer and a lot of times, when I was stuck on a problem and asked a team mate for their help, the solution turned out to be some modifications to the backend that I would have never thought of, hadn't I asked.
I would only have wasted my time and the company's money by trying to solve something I was not able to solve.

By asking I learned a lot and am now aware, when I run into similar situations.

Collapse
 
kostassar profile image
Kostas Sar

Another tip I might add:

Document Everything: From the office network to software. You do not know if you are going to be the next person to implement a change, so the least you can do is leave a document for the next person to help them out.

Of course we can apply the same advice in sowftware! Leaving comments beside a block of code that was written in a hurry will help your future self during refactoring or, again, the next person that will maintain this code.