5 Things That Eliminate Most of a Programmer’s Biggest Problems

Brutal but honest suggestions.

Programmers face many challenges in their daily work.

For 90% of programmers, these challenges make their job interesting. For them, if you remove challenges from their job, they will become demotivated and may quit their job.

But there are some problems that even the most creative and amazing programmers don’t enjoy. These problems make their job less exciting.

Here I’ve talked about five things that will remove most of those less exciting elements.

1. Try to reinvent the wheel often

“Don’t reinvent the wheel.”

Every programmer hears the above advice almost once a day.

Experienced programmers keep telling young ones that it’s bad to reinvent the wheel. They ask them to use something that already exists.

Why do experienced developers keep giving this advice?

It’s because they don’t want you to rewrite a piece of code that already exists and is readily available.

Existing code has been well tested, and because it’s used by other developers, you’ll have less trouble finding a supportive community.

Any senior developer will give you another ten reasons why you shouldn’t reinvent the wheel. After talking to them, you’ll be convinced that reinventing the wheel means wasting a developer’s time.

But there’s a powerful reason why you should keep reinventing the wheel often.

Do you remember the first time you created a simple website and hosted it online? You have to learn a whole list of things just to launch your website.

You learned HTML first, and then you made a bunch of changes to the website. Then you learned CSS and made some changes in the background. A couple of times you made the changes and they were not reflected on the website.

After that, you debugged and improved many things to fix all the errors in the code. Finally, to launch the website, you learned unknown tools that helped you manage and host the website.

To make a website, you pushed your limits. Now think about when you keep reinventing the wheel and how much you could learn about different things.

If you don’t know how to write a graphical user interface and you wrote code your own GUI. You will get to know how the GUI actually works and how things work behind the scenes.

Most programmers have never created a GUI. They have only used the popular ones. That’s why they won’t have a deep understanding of how a GUI works.

Just like the GUI, you can create and read about many other things.

Create your own web browser, which is a mini version of Chrome.

Once you start getting to the deepest level, you will be able to solve the mystery of all the black boxes. The mistakes you will make when building black boxes will teach you more than any programming course.

2. Avoid mental mapping

All names that a programmer uses in their code must be meaningful and clear.

Using bad names can create difficulties for other developers in your organization or yourself in the future.

You may read your code after three months and misinterpret the purpose behind writing a particular name.

An example

let c;

If you use the above variable name for something that holds the name of a location. It will be bad since there is nothing related between location and ‘c’.

You can simply use ‘location’ as the name of the variable. As a programmer, you don’t have to mentally map variable ‘location’ to anything.

The code will be self-explanatory.

Abbreviated name problem

A programmer using abbreviated names must make sure it’s obvious to mentally map it to a real word.

Otherwise, mentally mapping an abbreviated to something can sometimes be difficult.

If you use ‘dB’ as a variable name, it could have many meanings at once. It could represent the database, dialback, and decibel.

With these many meanings, mental mapping of ‘dB’ to an actual word becomes a problem.

Each abbreviated word must be able to easily explain the context.

3. Treat testers like your friends

Programmers hate testers.

Programmers think that the job of testers is to make programmer life difficult. They believe that testers don’t want to see developers happy.

You will often find programmers saying “They want everything to be perfect”. Programmers don’t want to see emails or messages from testers.

It is only because of the testers that most programmers get frustrated.

But the testers are not so bad.

They help programmers in many ways.

Suppose you wrote code and created an advanced web browser for a client. The web browser uses advanced algorithmic bots that crawl different websites and collect data.

Now, while writing the code, you made some typos. Instead of writing the word ‘search’, you wrote it as ‘srch’. You have misaligned some of the buttons on the screen.

You give the web browser to the client. The client will wonder if they can’t even spell the word search correctly. How could they build advanced algorithmic bots?

Even if your company had the best team to build the algorithmic bots. The client will stop taking you and your company seriously.

It is a tester who saves the entire organization from such a situation. They point out every bug and make all software bug free.

Instead of treating testers like enemies of the developer, if the developer starts treating them like a friend, they will be less frustrated and appreciate their work.

4. Pair-programming whenever possible

Pair-programming can help the entire organization accelerate learning.

When an experienced engineer is paired with someone who is less experienced, he may feel a bit intimidated.

But it is the duty of the experienced engineer not to focus on the weaknesses of others. Instead of focusing on each other’s weaknesses, if you focus on what you can learn from each other, it will add value to both of you.

If there is a team member that the current project totally depends on, it makes sense to pair him with other engineers.

Other engineers will learn from him, and if that essential member quits for any reason, other team members are available to replace him.

Discussing difficult problems with other engineers. You get to know how they approach the problem and their approach can help you in the future when dealing with such problems.

If you’re new to a project, teaming up with other developers who were involved in the project from the beginning can make things easier for you.

You don’t have to go through everything on your own and the whole process of learning the codebase becomes a bit of fun.

So pair-programming can solve many problems for engineers. It’s just that you and your organization must be ready to accept it with an open heart.

5. Ruthlessly removing every extra piece of code

Code that does not provide any value at the present time must not be present within the codebase.

A question that may come to your mind, but what about the code that is needed in the future?

If code is needed in the future and your codebase doesn’t need it right now, just remove it. You should avoid any extra code.

Comments for entertainment purposes should not be allowed. Any code is written to satisfy a business’s needs and there is no point in writing something just to entertain the reader.

In the future, every additional line of code will have to be managed by some engineer. Their time and effort will be wasted.

Why do you want to waste any amount of engineering time?

Just delete it.

Summary

1. Keep reinventing the wheel whenever possible.
2. Avoid any kind of mind mapping if possible.
3. Treat testers like friends for less frustration.
4. Pair-program with other engineers.
5. Delete every extra piece of code.