The 7 Habits of Highly Effective Self-Taught Developers

How to think like a programmer

There has been a lot of talk about how everyone defines good developers. Through all the years I’ve been working with other engineers and developers, I’ve noticed that there are experienced developers who are still constantly teaching themselves about programming. They strive to get better and better despite all their achievements and experiences. I've also seen developers who are already satisfied, which means they are proficient in C#, C++, and.Net but are uninterested in learning new technologies. They know a couple of languages, and that’s it. They’ve mastered them and become senior developers.

So which one are you?

In this article, we'll talk about some important habits that every developer should have, based on what I've learned from several senior developers. If you are like me—someone who didn’t learn programming at university but pursues web development simply through self-study, reading, and watching tutorials online—then I highly encourage you to read this article and take notes. Don’t just read about these habits; apply them.

This kind of teaching is not something you can just find online. Most of them were taught to me by my fellow engineers and by working with my senior developers.

1. Good Project Documentation

As a developer, it's very important to have reliable documentation that you need to include as you build your application.

Reliable documentation is a must. It will have instructions or notes that will help the next person who works on the project or you in the future. Especially when you are working on several applications or projects, it is even more crucial. It will help you track all aspects of each application. It could be for development, maintenance, and knowledge transfer for others. This will serve as your guide back to where you left off.

What is documentation in the world of web development?

Ideally, documentation is important because it will serve as a guideline that will then be used for reference by everyone on the team. The team I'm referring to is typically made up of both non-technical and technical individuals. Even though not everyone can read code, everyone must be on the same page.

When building your website, you need to practice this good habit of taking notes that will then help you in the future. It’s like taking a class and needing to write some notes for future reference because eventually, whether we like it or not, we tend to forget things along the way. And the presence of documentation helps us keep track of everything about the application. It could be mobile, on a website, or in software. It is also very helpful as we improve the quality of the application. As we implement several changes and upgrades in the future, it is important that we still keep the process, the packages, and the other resources we used intact.

It’s like taking notes, but in a proper and formal form so that everyone on the team—including the marketing department, the sales department, etc.—can understand.

Here’s another example: If you have been using different technologies, like languages, packages, and other third-party tools, you can see that experienced developers usually refer to the documentation. Whenever they are using packages, learning, or using something new, they make use of the documentation as their reference and recommend to fellow developers that they practice reading documentation as part of their good practices and habits. You can better understand its syntax, its uses, and its dependencies. So imagine developers who wanted to use a new package tool, but didn’t have documentation to read. How do you think they will be able to apply it or use it in their application? That’s why this is important.

Documentation is composed of different components. It could be documentation for setting up an environment, documentation for business rules, for the server environment, for database/files, troubleshooting, for application installation, codes, deployment, maintenance, upgrades or new features, etc.

Note: We will be further discussing how to build good documentation and when to build it in a separate article in the next few days. Stay tuned.

2. Sharpen the Saw

This means preserving and enhancing the greatest asset you have, and that’s you. Sharpening the saw doesn’t just mean mastering your craft or gaining all the knowledge you can find. Sharpening the saw also means taking good care of yourself. It means achieving balance physically, mentally, socially, and spiritually.

We all have our different ways when it comes to learning something. Some prefer reading, some prefer watching videos, and some like learning by example. Meanwhile, others want to learn the fundamentals and logic and then apply them on their own.

So whatever works for you, keep doing it. What matters is that you understand what you are learning. It may take some time for you to figure out what works and what doesn’t. You may fail a few times, but what’s important is that you will find it if you just keep going and doing what needs to be done. Don’t ever give up because we may have a different path or different experiences in our web development journey. I can assure you of one thing, though: self-taught developers exist. I am one. You can make it happen too. When I decided to pursue this, when I began my journey nearly four years ago, I had only one thought: I have to make this happen no matter what. At that time, there were still no resources you could find online. There wasn’t much in the way of mentors or tutorials available, no articles like this one.

When I started, I hadn’t seen any self-taught developers I could talk to or get advice from. But I knew it felt right, and I knew it was possible. I simply needed to create my own path. I was so hungry to learn at that time, so I guess it was perfect timing. Even after I got my first job after a year of constant hustle, I didn’t consider myself a developer right away. At that time, all I wanted was to learn as much as I could from other engineers. If you have been reading my articles, during my first developer job, I was the only one who didn’t have a Computer Science degree on a team of eight, so I was the weakest link. Without realizing it then, it was the best situation I could have asked for.

Another thing: The best way to stay sane and not go crazy is to do extra activities, like going to the gym, practicing yoga, doing sports, traveling, meditating, etc. In my opinion, being a good developer is not just about how you code. It’s also about how you keep your balance so you can stay consistent and sustain your energy. It’s about the inspiration, the fire after all the years of working. A good developer is a happy developer. How can you love coding if you are not happy?

3. Language- and Technology-Agnostic

Don’t get stuck with one language. You can’t marry a language. There is a lot of noise that you can hear online about which programming language is best.

Some people say Python is the king, C++ is still the best, JavaScript is the future, React is better than Angular, PHP will live forever, etc. Don’t get stuck in that bubble. Instead, you need to think differently.

Whenever you are planning to work on a project, think of what the project needs: what language it fits in or what language could give it the power, what technology it should have to satisfy its function, and what packages and tools it should include maximizing its potential capacity. Don’t try to fit the project into your preferred language. That’s crazy.

Go out of your comfort zone. It’s time to make a change in your thinking.

4. Have Coding Standards

How you structure things, your syntax, your naming conventions. This is very important and will benefit you along the way.

The more conventions you set, the easier it will be for you to lay out your project quickly. And this works across several projects once you set certain standards. Even before you start the development, you need to set up certain standards, certain conventions, and certain rules that everyone on the team must adopt.

It will also validate and set up a proper workflow for all the developers. This is very important, especially when working on a large team. Here are some examples:

• If you need to use a repository, everyone needs to set up and follow a universal process.
• When deciding to use the MVC, some rules need to follow the file structure of the project, the naming convention, how would you approach the logic, the controller, etc.

Everyone on the team needs to understand and follow certain rules and standards. Will you be using material design or flat design? It can’t be both.

5. Simple Over Complex

This could mean several things, whether it relates to the main structure of your app or dividing the modules into those that are easier to understand. I’d rather have an extra few lines if it means readable and understandable code than a couple of lines that the other developers can’t read. It could bring chaos to other developers who will be working on the code you built.

I don’t prefer 2-3 lines of code that are complex. Using short, complex code doesn’t make any developer better, either. The best developers make complicated code seem simple. The simple things are the hardest, and it’s the same with coding or programming. The simpler your code, the clearer it is that you understand what you are doing. Why complicate things?

6. Apply the DRY Method

DRY (Don’t Repeat Yourself) is a software development principle whose main aim is to reduce the repetition of code. Write Every Time (WET) is a cheeky abbreviation to mean the opposite, which means code that doesn’t apply to said principle.

We do have different opinions, as some prefer the WET method, but the majority of developers use the DRY method.

Here are examples of the WET and DRY methods:

This is entirely readable code. There’s almost no question about what’s going on here. However, if you read the title of habit #5, you can see that there’s a bit of a contradiction. In the example above, it may not seem obvious, but if you are going to write complex code, you will see its contradiction. Some clever programmers use DRY to the point where other developers will have a hard time understanding and following their code.

To use the method effectively, keep in mind that it’s not just about writing the code for yourself. Soon enough, when you leave your job, there will be other developers who will be handling it. Always think about others and work for the benefit of everyone. Help your next colleague.

There are several advantages to using the DRY method:

• Less code means less noise. It’s clean, readable, and straight to the point.
• Flexibility whenever you assign a generic id with a specific style on it. You can use it on several other properties by just using its id, which is easier to maintain.
• Extensibility. Whenever you need to change the background of your pages, there’s no need to browse all the classes you created. Instead, you can just go directly into one block and change it there. Less work.

Overall, this principle makes the developer's job easier, makes the code easier to maintain, and helps your team work together better and better. It’s a good practice that you must adopt.

In becoming highly effective developers, we must learn to apply certain conventions and principles that senior developers created so that even if we are using different languages, we can still understand each other. It’s like having a universal language.

7. Take a Break

Take a break so you won’t break. This is a universal rule. No questions were asked. In whatever venture you choose, don’t ever forget to take good care of yourself. Find what works for you, but take a break from time to time.

Thank you for reading!

Here’s the second part of this article, The 5 Daily Habits of Highly Productive Self-Taught Developer about building the right mindset, the right habit to becoming the best version of ourselves, the best developer that we can be, and becoming the best senior developer we wish we had, I highly recommend for you to read it as well.