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 content, meaning they are good with using C#, C++, and .Net, but they don’t care about the new stuff. 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 will be discussing several points that I have gathered from several senior developers about important habits that every developer must practice. 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 but apply them.

This kind of teaching is nothing that you can just find online. I have experienced and learned most of them through fellow engineers and working with my senior developers.

1. Good Project Documentation

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

Reliable documentation is a must. It will be composed of instructions or notes that will be useful for the next developer or your reference 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 from 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 am referring to is usually composed of non-tech and tech 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 writing 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, website, and 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 on 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 to practice reading documentation as part of the developer’s 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 they don’t have documentation to read. How do you think they will be able to apply it or use it on 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, for troubleshooting, for application installation, for codes, for deployment, for maintenance, for 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, 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. The moment I decided to pursue this, the moment I started my journey almost four years ago, there was only one thing on my mind: 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, 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 hustling, I didn’t consider myself a developer right away. At that time, all I wanted was to learn as much as I could with 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, 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, right?

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 or what language could give it the power, what technology it should have to satisfy its function, what packages and tools it should include to maximize 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 your certain standards. Even before you start the development, you need to set up certain standards, certain conventions, 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 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 the complicated code become the simplest. 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 wholly 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 when 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 life easier, will lead to maintainable code, and improve as well as develop the coordination of your team. It’s a good practice that you must adopt.

In becoming a highly effective developer, 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 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 into 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.