DEV Community

Cover image for The Secrets behind highly effective programmers
Abdullah Alhariri
Abdullah Alhariri

Posted on

The Secrets behind highly effective programmers

Being a programmer requires much more than the simple act of sitting at a computer looking for solutions through Stack Overflow. To be a programmer, you need a set of skills that allows you to reach these solutions in an abstract way and use the specific knowledge of programming languages to make them come true. We are problem solvers. But is this really all it takes to be a good programmer? Not necessarily.

Take care of your own system

Everything you see every day is part of a system, from the leaf of a tree to the ant that eats it. All these individual systems inhabit and interact with each other directly or indirectly. Your body is a system that works towards the goal of keeping you alive, but if your system starts to fail, everything else does too.

As a programmer, I know that we spend most of our work time sitting in front of a desk with at least one screen pointed at us. Additionally, I also know that when we are working we focus so much on our task or on meeting a set goal that we forget to give our mind and body a break. Why do I mention this? Because our average screen time is 7 hours a day and this is not the problem. The problem is what this entails: it is 7 hours of sitting in the same position, 7 hours of concentrating, 7 hours that represent approximately 30% of the entire day.

In order to solve this problem, you can follow the next suggestions:
1. For every hour of work:
Take 5 minutes of rest, and if you can’t take those 5 minutes, save them for the next work hour and take the accumulated time (in this case, 10 minutes). Never accumulate more than 10 minutes of rest; you will be procrastinating by the end of the day and you will not see the advantages of taking a break if you save 7 hours of work to rest for 35 minutes at the end of the day.
2. When you take your 5 or 10 minutes of rest:
If it is easy for you, make sure to go out and get some sun. If that’s not possible, stay where you are and find a calm place.
Breathe. This sounds obvious but it is very important. Take a 1-minute deep breathing session. It’s not hard.
Clear your mind. Do another thing unrelated to what you are currently working on. Watch a video, listen to a song, play a short video game match, whatever. But don’t think of work during your rest time.
Do some exercise or stretching. You can find a lot of those on the internet and make a daily routine.
Make sure to drink water or any other liquid to stay healthy and hydrated.
The point here is that you have to take care of your well-being. If you have a healthy body and mind, you will be able to carry out your tasks without feeling tired or overwhelmed by day-to-day problems and be a more effective programmer.

Be more receptive and less defensive

As programmers, we tend to be a bit jealous of our code and how we develop it. So it can be harsh when some of our colleagues tell us that our code is wrong or that it can be optimized in a different way than what we have. As a result, we begin to adopt a defensive attitude rather than a receptive one.

In my previous job, I was a kind of technical leader in the area I was driving, so everything I knew, in theory, was fine and there was no one to tell me otherwise. I was always proud of my code because I was pretty sure it was perfect or near perfect. All this changed when I joined FullStackLabs. The first thing they gave me was a document that said that team members review code before being merged. At first, I was intimidated by this fact, but I considered myself a good coder so I did not give it much importance. What a mistake.

When I began submitting my code for review, several times it would come back with simple errors: a comma here, an arrow function there. At first, I just took care of implementing the changes without asking anything and I felt attacked until one day I decided to ask what was the difference between my code and what they asked me to correct. The result was a small talk on optimization and standardization that allowed me to understand what I was doing wrong. I felt ashamed but at the same time very happy because I had learned something new. I was starting to play in a new league.

So my second tip to be a more effective programmer is, take a receptive attitude instead of a defensive one. If you give yourself the task of seeing the world in the eyes of different people, you can grow with the help of their knowledge, never take for granted that you know everything, defend your ideas and solutions but also listen to the solutions of others. In programming, for the same problem, there are infinite solutions.

Know when to ask for help

When we are working on a specific problem that does not allow us to move forward, we tend to think about it a lot while we find a solution without realizing it makes us less effective programmers.

Instead of being focused on a small problem for a long time (more than 1 hour), it is best to ask your coworkers for help. This will increase your knowledge in a more effective way and additionally increase your communication skills. Now, our co-workers won’t always be available to us, or perhaps we are the only ones working on a certain technology. In cases like these, it is best to stop working on the problem and divert your attention to another feature that has the same priority and resume the task later. Our brain will continue to work in the background and we can return to the problem from a different perspective.

Don't show off

Throughout my career, I have come across different types of code, some very impressive and difficult to understand due to their complexity, some simple and very easy to understand. But also many that are simple to begin with and for some reason became complex with no need other than to satisfy a programmer's ego.

I think this is one of the elements that make a programmer very ineffective and additionally harms others around him. For some reason, every time I come across this type of excessively complex code, it is related to an individual who feels he has something to prove by his status or seniority when all he is doing is writing code that could be very simple and for some reason is turned into spaghetti that only he understands and can explain.

advice

My advice here is: keep the code simple and consistent. If the character described above leaves the company and a new developer enters to add/maintain the code, it will be much more difficult than if the code had been kept simple from the beginning. As my algorithms and discrete mathematics teacher once said, "Elegance is in simplicity because everyone can understand what you want to communicate".

Top comments (23)

Collapse
 
mtrantalainen profile image
Mikko Rantalainen

Good article, but let's be honest, 7 hours per day for screen time is not nearly enough for most software developers.

I've been doing some bodyweight training and it has saved me from shoulder and neck pain that I used to have. Sometimes I find myself being "in the zone" for 5 hours straight but then I feel like doing some pull ups and archer push ups or pistol squats for a few minutes to get my body to work, too. The good part with body weight exercises is that you don't need equipment (I do have a pull up bar a couple of meters from my workstation, though, and it helps to avoid procrastinating pull ups because I can do 5-10 on my way when I go to bathroom or get something to eat).

Collapse
 
thomasvanholder profile image
thomasvanholder

Exactly! Staying in the zone with a break every hour seems contradictory for me. Once you are in it, it’s so easy to keep going.

What helps me is to do stay physically health is to do some non-coding activities after work, like go for a run or long-walk.

Collapse
 
dpereira profile image
Diego Pereira • Edited

If you can't break down the work you are doing in 1h-2h chunks, you probably haven't thought out an overall plan and shouldn't be coding away like crazy anyway.

Being "in the zone" for more than 1h, at most 2h, means you are just lost without an actual plan on where you are going and how to get there.

Thread Thread
 
mtrantalainen profile image
Mikko Rantalainen

I would say that it depends. There are tasks that are straightforward but simply need more code than you can type in 1-2 h. Recent example for me was porting existing code to a new backend architecture. I had automated tests with 100% coverage so it was easy to see any problems and I was constantly aware of the failing parts of the code.

Thread Thread
 
dpereira profile image
Diego Pereira • Edited

I wouldn't use "straightforward" then. And if it is not, it probably could be broken down in smaller chunks.

Collapse
 
piyush181 profile image
Piyush Raj

Very well said, I completely agree

Collapse
 
abdullahalhariri profile image
Abdullah Alhariri

thank you

Collapse
 
awohletz profile image
Ayron Wohletz

I will add that getting good sleep is crucial for any kind of mental work. If I don't sleep well then it's hard to concentrate the whole next day.

Collapse
 
imasterzed profile image
ImasterZed

Hey man, Your article was awesome!
I translated it to my language and shared it with your name and added a link to this page, and again, Thank you very much

virgool.io/@MasterZed/%D8%B1%D8%A7...

Collapse
 
abdullahalhariri profile image
Abdullah Alhariri

The article looks awesome, thank you 🌹

Collapse
 
shadid12 profile image
Shadid Haque

Could not agree more. Hats off

Collapse
 
abdullahalhariri profile image
Abdullah Alhariri

thank you

Collapse
 
ashleyjsheridan profile image
Ashley Sheridan

I think the "showing off" part can depend on your and their level. Code that is hard to read isn't immediately someone showing off, it might be that it's following a standard for that framework/language that might not be very obvious to someone new to it. I feel that way when I'm learning a new language, and come across something that's very particular to that language that looks unusual.

The exception is regular expressions. I think most people who use them are showing off :P

Collapse
 
virtualmachine profile image
ByteCodeProcessor

Nice article. Especially the one on spaghetti code. I would have to work on the "asking others for help" part. 11/10 article

Collapse
 
abdullahalhariri profile image
Abdullah Alhariri

thank you

Collapse
 
gtobar profile image
Guillermo Tobar

I agree with you, thanks for writing the post.

Collapse
 
33nano profile image
Manyong'oments

Nice article and definitely highlights some great points, especially the point of taking care of ones own system.

Collapse
 
abdullahalhariri profile image
Abdullah Alhariri

thank you

Collapse
 
joycelee11 profile image
Joyce Lee • Edited

Know when to ask for help

This! Couldn't agree more. Know when and how to ask for help sounds easy, but I've found it really takes practice to get good at.

Collapse
 
yashiroquy profile image
UMR

me working as a developer for 1 year and get varicose vein.

Collapse
 
worldtok4u profile image
Emmanuel David

I doff cap for u on the case of asking others for help. I find it difficult as most of my colleagues are not always around for that.

Collapse
 
chautien profile image
Chau Tien

thank you for article

Collapse
 
viral7chauhan profile image
Viral Chauhan

Great article, Programmers should focus on physical/mental health for more productivity.