Self learning guide to be a good programmer

Do you want to start learning programming? Do you want to improve your programming skills but don’t know what to do or in which order? When I started my career I learned how to program through my work but I was not an avid programmer spending my private time improving my skills. Some years later, I started thinking about how to write clean code, how to reduce bugs, and how a clean code looks like. However, I didn’t know which books I should read and how I can learn clean code.

I think many developers have code reviews and other colleagues may give good advice but some don’t have such a chance, especially for beginners who do self-learning. I wrote this article for you to tell what kind of techniques you need and in which order you should learn them.

Before showing the learning path, it is better for reliability to know my career, isn’t it? I started my career in 2012, so I’m 9 years experienced programmer now. I worked on an inventory management system for 3 years and created some web pages working with Oracle Database and SQL Server. Since then, I have been working on IoT-related projects.

Engineer type

Welcome to the programming world. It is a really really big world. No one can cover everything. A programmer needs to keep learning because new technologies appear one after another and existing technologies disappear or get unpopular. Non-programmer probably doesn’t know what kind of field there is. Let’s reveal it.

There are various types of engineers and a programmer is one of them. What I come up with for engineers is the following.

Software engineer
- front-end
- back-end
- embedded system
- application
Infrastructure engineer
- Network
- Database
- Server
- Security
- Cloud
Other
- Test
- Project/Product manager or leader

There are many experts in each field and it’s also important to know many of them. For example, a back-end engineer needs to know the network, database, server, security, and cloud because he needs to implement logic to connect user inputs to those pieces of stuff safely. Without that knowledge, what a user buys is not recorded in a database, private information is leaked or a user may not be able to connect to the website in the first place. Each field has a deep world. In this article, I focus on programming itself.

The order to learn

Firstly I tell you the order to learn. Following orders is my recommendation.

Language itself
Source code management system
How to write readable code
Concept of OOP (Object Oriented Programming)
How to write unit test
How to refactor
Design Pattern

Small to big. I think the order that I did was the following.

Language itself
Concept of OOP (Object Oriented Programming)
Source code management system
How to write readable code in a small chunk
Design Pattern
How to write unit test
How to refactor

I learned the first two at university and others during my career. But I think recommended order is better for the last three because I think there should be unit test when refactoring and design patterns can be learned easily if we are familiar with unit test since those designs help writing unit test.

Choose a language that you want to learn

First of all, you need to choose one of the programming languages. Every programmer has their own preference for various reasons. Some languages can do almost everything but it’s complicated and hard to learn. Some can do the same thing with less code but can’t control deep points. There is no way around picking up one of the languages to know which language fits you. However, you may not be able to decide easily which to choose, so I give you 3 points to choose a programming language.

The first point is whether you can easily find a solution or not when you are stuck. I have 9 years’ experience but I still search for something to find a solution or a better way every day. We use open source modules/components developed by someone else to develop our own software but not all modules are popular and well documented. In this case, we have to have a look at the code. It’s not an easy task to find desired code and understand it. It’s a disaster if this case applies to the language that you choose because the language becomes basic for software. Choose one of the popular languages. You can easily find websites that show popular languages top 10 by googling. Then, input the language name to the search box. It shows a number of results, so you can use its result to know if it’s easy to search for something with the language.

The second point is whether the language matches your desire. Let’s assume that you want to develop an application for android. In this case, the proper languages to choose are Java or Kotlin. It may be possible to develop an app in other languages but it’s harder because fewer people develop android apps by them. It means that the number of possible languages that you choose depends on what you want to develop. It’s most important to decide what you develop in order to keep your motivation. Your motivation probably decreases and you stop learning if you just learn something without a goal or clear purpose.

The third point is how many jobs there are and what the average salary is. I guess some of you want to learn programming just for your hobby but many of you want to have a job in the end, don’t you? It’s easier to get a job if there are more job offers. It may not be necessary to mention this point since its number relates to how popular the language is but it can be a good reference to choose a language. This is one of key points if you think you want to earn as a programmer.

Create a small application

Let’s create a small application first once you choose a language. The software requires lots of knowledge. Search a website where you can learn how to develop or buy a book. You will definitely face a lot of problems but it helps to settle new things quickly through practice. It’s boring to learn only grammar for speaking a language, isn’t it?
You get more motivated if you can see your application somehow works at some point even if it is not completed. After you get the work done you may want to try to change or add some functions. Through these experiences, you will definitely want to do the following.

Manage the source code
Make the source code more readable
Have automatic tests
Know design pattern

I will explain these things in the following.

Learn how to use source code management system

No matter where you work, the source code management system is important because it’s hard to do the change back without mistakes once you change your source code. In addition, there are many cases where we want to check the previous implementation to know the behavior or who modified it and why. Source code management systems can solve these problems. It shows us the change history and we can easily undo the changes with simple steps. It’s also important to review the source code before updating the original source code in the source management system if several people work on the same project. The process is called PR, which stands for a pull request.
Git is one of the popular systems for it. For private use, it’s enough to use GitHub because it’s free and we don’t have to build an environment on our local machine. I also use it for this blog.
You can also link your task to your code change if you choose such a product or plugin. GitHub seems to support this feature but I’ve never tried it yet. You can improve your work by creating a task because its task gets clearer what to do and a task can be smaller. Of course, it’s easier to complete a small task than a big one.

Learn how to write readable code

Regardless to say, it’s important to be able to write readable code. No one wants to see unreadable code because it takes a long time to understand and it’s stressful. It doesn’t matter if you work alone for your private purpose but it really matters if you work with other developers. We, developers, spend most of our time reading code. It takes a while to understand the code when you read it after three months even if the code is written by yourself. This step leads to the next step, writing unit test, because we need to read the original code to write unit test.

We all should learn how to write readable code. Actually, it covers a wide range but I want to mention only a small chunk here because I mention other things later. I think a beginner doesn’t give a proper name to a variable and function. I actually didn’t give a good name to a variable when I started learning programming at university. Other people did the same thing at first. The name is like a, b, number or something like that. It may be because the problem that I solved was simple. However, I heard before that those unknown variable names could sometimes be seen in legacy code. That software might work on a poor memory device. Shortening variable name is to reduce memory usage. We shouldn’t give such a name without a clear reason.

There are lots of things that we should care about. Each of them is a small thing but many small improvements make our code much better. If you want to learn how to write readable code from a book I recommend the following book. You can touch many good thoughts if you haven’t read this kind of book yet.

Learn the concept of OOP (Object Oriented Programming)

There are some types of programming languages. OOP, which stands for Object-Oriented Programming, is one of them. Most popular languages support this feature today. In OOP language, we can design our program according to the real world. For example, when we want to make a shopping site we need a shop, staff, cart, products, etc… Those objects are called “classes” in OOP language and we add features to those classes. It helps separate concerns and code itself. It means that it’s easier to maintain the code because each of them has one concern and gets smaller. It’s a similar concept to a chapter in documentation. A chapter should have one theme and different themes shouldn’t be mixed in a chapter, shouldn’t they? If concerns are properly split multi developers can work on the same software. It’s easy to avoid conflicts when different developers change the same code.

You can learn this concept by learning unit tests and design patterns. However, I show my recommendations for those who want to buy a dedicated book.

Learn how to write unit test

Source code that doesn’t have unit test is often called “legacy code”. In a decent company, the software is tested before release in order to confirm that required features work as we expect. The bigger the software is, the more time we need to spend on testing. It takes more time to find a bug and fix it. To improve this situation we want automatic tests where it’s possible.

Unit test is literally to test that each “unit” works as expected. Software consists of tons of small units and those small units should be good enough quality. No good products can be built from poor materials. Unit test covers only “unit”. Another test called the integration test can test a bigger concern but both of them can hardly test all features. Therefore, we still need manual tests but we can reduce the number of tests by them.

Unit test helps reduce test time but more importantly, it detects a coding error during our development. I think this is the most important. We don’t have enough confidence to add/change the code when we first look at it. Its function may be called by another class that we have not looked at yet. However, unit test can detect the coding error when we wrongly change the code. As a result, we can confidently modify the code. That’s why this chapter precedes refactoring. We must make sure that the code still works as expected during the refactoring.

The Art of Unit Testing, Second Edition is a good start to learn. I could improve my code quality after reading this book. It is written in C# and not the latest. If you want the latest version, check The Art of Unit Testing, Third Edition. It is written in JavaScript.

If you don’t want to buy one of the books, the following posts might be helpful.

Learn how to refactor

Refactoring means that we change the existing code to make it more readable and maintainable. Refactoring on daily basis is a nice habit. Code can easily get big and dirty especially when a copy-paste evil is in the same project. When we need to make a feature as soon as possible to keep the deadline many developers can be copy-paste evils (including me). In this case, we should refactor the code as soon as possible because added code easily gets dirty when existing code is dirty. It’s normal to think that we don’t have to write clean code in dirty software, isn’t it? Let’s stop this.

Writing readable code written above is a similar concept but it’s different because refactoring is only done after code is written. The target code is already there, so we have to make sure that the code still works after refactoring. To confirm it, we should execute unit test many times after we change something. Refactoring should be a pile of small steps. It’s better to execute after each change and save it in a source code management system explained above. It’s harder to find a root cause for an error if we make a big change but we can find it much easier if the modified number of lines is only 5.

I highly recommend the following book to learn refactoring. It explains how to do safe refactoring and how small a step should be. This book takes you a lot forward.

If you want to learn through practice you can check my past articles as well.

Following posts also help if you want to know concrete refactoring techniques.

Learn design pattern

To make products beautiful, we should know design patterns. There are patterns for most things, house, sofa, desk, chair, light, etc… There are many patterns for programming too. You should learn those patterns if you want to be a better programmer quickly. We face new problems every day that we need to solve but it’s NOT a new problem. Almost all problems to design programs have been solved by someone else. If we know a variety of patterns we can apply one of the proper techniques.

It’s very helpful to know design patterns so that we can make our code testable. It leads to writing clean code because concern gets smaller than before.

I recommend learning design patterns from a book because you can cover a lot of patterns. You can easily look for a better idea if you have it on your desk during your development. I have read a book written in Japanese and I haven’t read the following book but my colleague told me that this book was very good and he couldn’t lend it to me because he always wanted to have it with him.

The more patterns we know, the easier we can build our own system. The book above is for common things. There are many other fields. For example, if you want to learn the design patterns for API, API Design Patterns is a great choice. For the web APIs, I’ve also bought Testing Web APIs.

Important mind that we should always have

If you want to improve your work you should keep an eye open for everything.
For example,

Why is this module used even though another seems to be better?
Why is this technique using here?
How can I improve this function?
Is there better name?
Can this class be split for the improvement?
Why is for-loop used but not forEach?
etc…

The more questions you have during your development, the more opportunities you have for improvement. Ask if you have a chance to work on a task together with your colleague even if it is a small thing. This way is called “pair programming”. In this way, you can see how another developer thinks and implements. Its development process is normally under the hood but pair programming is a very good change to know it. Possible questions are

Where does he start implementation and why?
How small is his one change?
How many times does he save the change to a source management system?
How many times does he run test?
How small/big is a function/class?
How far does he consider?
Class relationship
Feature change
Performance
Maintainability

Let’s ask these questions to look for a better idea. It’s also good to ask for recommended or favorite technical books. Good programmers definitely have their own favorite books. Give the question in person because not many people input their recommended books into a list.

End

It’s not our final goal to learn those things written above. Keep an eye open and try to find improvements.