1. Doesn’t fear problems
Yes, correct. As a programmer, our day to day job is to solve problems. Think of a project or a simple switch case that we apply, everything comes in the form of a problem. And our job can be defined as problem solvers.
“Life is essentially an endless series of problems. The solution to one problem is merely the creation of another.”MARK MANSON
But, do we fear problems? if yes then why?
Yes we do and that is because our instincts are always guiding our actions and choices that we make.
Instincts do so because our super-intelligent brain tells it to assign more priority to those choices that take the minimum effort which leads to saving energy. In other words, we become lazy.
Most people plan so much but fail to execute.
We can easily relate to this. Just try to remember the time when you had a side project or assignment that you thought would finish over the coming weekend. But that weekend never came easily.
Most of the weekends either you binged the Netflix or were busy hanging out with your pals or preferred doing something else.
If I am wrong then you might be on the right track. But if I am right (which I hate to be in this case) then you know what I am talking about.
Even if you try, you can not become a good programmer overnight. It takes time. The mantra is to take one small step at a time.
While doing a side project or assignment or taking an online course over the weekend, don’t aim big.
Don’t aim big to finish the whole thing at once.
Instead, convince yourself to start by saying, “Okay, I will only add two text boxes to the login form and that is all for today”.
Once you start doing that, you will see that you ended up doing much more than you had originally planned.
It worked for me big time. This helped me to get into a gym. Initially, every day was tough but now I can’t think of skipping the gym. If you would like to know the story then let me know by commenting below, I will post it for your motivation.
Finally, a good programmer wins laziness with constant practice and by gaining grip over his or her field of expertise.
They don’t ignore problems they look for problems to solve.
2. A good programmer asks questions
Solving a problem requires many answers before the start. We can relate this to our projects.
When a project starts, we receive a Software Requirements Specification in some form. In simple term, we receive our problem statement or the mother book of problems.
Then we break down those problems into sprints and then stories and then to tasks (if you are following agile).
Of all the other points, asking question sounds the simplest one. Simple, because it doesn’t require any behavioural change to ask questions.
But simple is not always easy. You may ask what is so hard about asking questions?
Asking a question is not hard but, asking the right question is tricky.
And we all have this basic understanding of what is right or wrong, we think a lot around it. Maybe we think a little too much sometimes. Which is why we refrain from asking anything at all.
Let me give you a real life example.
Try to remember the number of students in any of your classes who asked questions. Five, ten, a handful? The numbers vary but never results in the majority.
Why didn’t everyone asked questions? Were they all understood the topic or was it pointless to ask questions. The answer is, clarifying your doubts are not pointless.
But we still don’t ask because we think:
- What if it portrays me as a less knowledgeable person.
- What if my question has no basis.
- And what if I end up bothering someone.
We get stuck at the infinite loop of what-ifs. And no one cares of our what-ifs unless we take those out of our head and put in front of everyone.
A good programmer never hesitates to bother someone if something is not slightly clear.
They listen carefully and ask questions. Because experience says that some of these questions lead to the hidden loopholes or undisclosed logic in the project.
And on the contrary to all the what-ifs above, this increases the credibility and shows the perseverance.
Being a programmer, logical thinking and the ability to mentally visualize a problem is very critical.
The ability to mentally visualize a programming problem is what differentiates a programmer from a non-programmer.
If you are reading this article then I assume you already have that ability and it’s good.
Listening is important.
Careful listening helps us in understanding a problem quickly and it remains in our mind for long.
Good programmers listen and think ahead of the problem. They break down the problem into small digestible parts and then thinks through each part.
Because of this, they can visualize a problem/flow ahead of any discussion.
So by the time a discussion reaches a certain stage, they have their questions stacked up in the head.
Sometimes the discussion answers many of the questions, which is why listening is necessary. This is how you avoid asking unnecessary questions.
3. Doesn’t hesitate to seek help
“Impressing people is utterly different from being truly impressive.”Ryan Holiday.
Superiority is lucrative. Better perks, respect, amenities what else could one ask for. In this era of competitiveness, “I am better than others” is a very common thought in professional environments.
And with growing experience, this though grows. It grows so much that our simplest decision and behavior reflects it. It’s a state of mind, we assume.
Assumptions are both powerful and self-blinding at the same time.
“I am the jack of all trade.”
“I can solve all by myself.”
“I help others but never seek help from others.”
“All this makes me superior, #respect.“
If one or more from the above comes in your mind then I have a tip for you.
Go die for a day, please.
And remember, you are REPLACEABLE.
. . .
We think seeking help makes us less superior.
We know but often refuse to accept that there’s a programmer ego sitting deep down inside of us. Fueling our superiority rocket to fly high above all.
Seeking help hurts our ego (Not when we are dying but when we are coding).
Setting aside our ego is a tough task again, but when we try, it works.
. . .
Think of that primal group of apes, who invented the wheel for the first time. And then someone asked for some help to transport crops from bushes to the camps. This necessity slowly transformed our already invented wheel into a full-fledged vehicle and offered a better mode of transport (It took thousands of years to cover the journey though).
The primitive men and women didn’t feel any ego. Ego was not born back then. Staying in a group and surviving every day was their priority. Now imagine, what would happen if no one asked for help. Or everyone tried to invent their own set of the wheels? Have you heard the term, “Re-inventing the wheel“? That would happen to us.
A good programmer never hesitates to seek help because:
- They know that our brain has limited capacity to remember things.
- Good programmers are rarely the jack of all trades.
- They accept the natural fact that our memory is finite and non-extendable.
- They accept the fact that we all are individuals and some of us can be more logically capable than the others.
It’s all about acceptance.
Learn to accept.
A good programmer ships.
- Prioritize self-learning above all so that they can deliver at per the standard. From the latest update in their specialized programming language to the shortcuts of a code editor, they do whatever makes them faster and keep updated.
- Always looks for improvement but at the same time understands priority.
- Communicates if there is any problem that can defer the timely delivery.
- Takes responsibility for work. Instead of focusing on blame games and excuses, collaborates equally and delivers.
- They do not ship for the sake of shipping. They are not a “Yes man” or a “Yes woman”.
Every day some random John Doe is inventing something. Every day something adds up to the programming world. It’s a vicious cycle, it never stops and will go on for the betterment of programming itself.
Most of us don’t realize the revolutionary role of a programmer in human history. Let me connect you there with some facts.
If we go back to the history of human communication or specifically to the history of calculation, our ancestors used mere signs to keep track of things. They even used knots on threads to do the math. Then came the clay blocks of letters, stone-carved letters and letters written on the papyrus.
As the number of calculations grew, indexes, ledgers, catalogs came into the picture. Slowly those became hectic to manage. Thousands of years passed when we made machines that would take care of all the calculations on behalf of us. Yes, computers were born.
We travelled from the invention of letters to the invention of computers. All happened because, at every stage, someone or some group had shipped something useful, something updated than the existing.
So from evolution to deliverable stories, it’s a continuous update of everything that exists. You see, shipping is a skill and everyone doesn’t possess it. Or better to say we don’t try to see the bigger picture at a glance. On the contrary, a good programmer thinks from the point of timely delivery.
You have read it all. It was completely my point of view. You may say “Anjan, your point of view is sh*t” and go on. That doesn’t change anything.
But if you have found anything useful then don’t worry, you will forget that by lunch.
A habit takes time to be built. So take small steps and don’t try to change everything in a day. You can try reading Atomic Habits, it’s a good book by James Clear.
Please comment and let me know what do you think. And subscribe to my blog if you want to follow my upcoming thoughts on life as a programmer and my personal stories such as how I have convinced myself to go to the gym regularly.
I will not promise anything interesting, instead of that I will try sharing something valuable.