How To Be An Awesome 50-Year-Old Developer – Hacker Noon

Real old age begins when one looks backward rather than forward.

The ax fell on me when I least expected it; at the end of yet another Friday evening.

“Jack,” my boss started speaking in an unusually subdued tone.

“As you are aware that, business has been slow for quite some time now and the organization needs to take some tough steps now to survive this phase. Therefore, we have decided to downsize our workforce and your role would no longer be required as part of this restructuring. I am sorry.”

I was 50 years old and was working as part of the same organization for the past 20 years. Life had been cool and I had firmly ensconced myself into a life of comfort, complacency and “routine” operational” work.

A wave of indignation washed over me, followed by disgust, then anger and finally ending with fear gnawing steadily within. No words came out of my mouth as I listened further.

“However,” he continued, pausing for a minute that seemed like an eternity to me.

“The organization would like to give you another chance considering your long tenure with us. We need another developer for the upcoming clarus project we just won. If you think you can again brush up your coding skills and come up to speed within the next 3 months, we can consider you for that role. Remember this is a high profile project and we cannot afford any weak links. The choice is yours.”

I had developed my last code 15 years back and since then my work had solely been operational and resource management issues. The possibility of me “coding” again was as distant as reaching Timbuktu. Odds, including my age, were heavily stacked against me.

It took me a day and a lot of thought to say “YES”.

And it has been six months since then….

In six months I have become an awesome developer.

In six months, I have become invaluable and indispensable.

And here is how I did it…..

Be the MASTER of only ONE trade at a time. That is, it!

Epictetus rightly said.

“No man is free who is not master of himself. “

“Ben is an expert in SAP BADIs.I need to be like him.”

“Tom quickly finishes business testing identifying the right areas. I need to beat that.”

“Susie creates Great ALV reports. I need to master that.”

These were some of the thoughts which crossed my mind but I banished them quickly.

I realized that I need to be a MASTER of myself. I cannot become the master by competing with “others” expertise and speed. That will only lead to more frustration and demoralization. I need to quickly find my niche area and excel in it.

In Clarus project, a lot of SAP Smarforms was been required with different degrees of customization. Forms were one area which no developer would be “keenly” interested in, given its cumbersome nature of the work and “patience” required to create the right form with the perfect alignment. I made the “mastery” over the forms my ultimate objective for the next three months.

It was a win-win situation. The team was happy and I got my Mojo back.

Learn what to UNLEARN.

Larry Niven hits the nail on the head when she says.

“Half of wisdom is learning what to unlearn.”

As technology marches relentlessly things which used to be of paramount importance fall off the path. Not only do they become useless but they also reduce our effectiveness.

For example, When I was first programming, memory overlays were a big deal.The whole program would mostly not fit into the main memory so I used to break it into chunks and swap the chunks in and out. This required a different design and coding style.

Now Memory limitation isn’t a problem at all in most of the cases.

But old habits are hard to break and even harder to notice. The first step in unlearning is to “realize” that you are using an outdated approach and the second step is to let it “go.”

Not completely though!!!

You still need to use the old logic in the right context and snip away all those dendrites off the body. For example, I had worked in SAP Script which is a much older version of form development. The logic of forms remains the same, I just replaced and mastered the new IDE and functionalities that came with Smartforms.

In simple words, I discarded the old language tools and created “new “habits and associations with the new tools. Transitioning became a lot easier this way.

Question until you understand

Indira Gandhi gets it right when she says.

“The power to question is the basis of all human progress.”

Consider how a doctor works. When you are not well, the doctor asks you various questions-your habits, what you ate, where it hurts, what medication you are taking and so on. The human body is complex and a lot of things can affect it. And unless the doctor is persistent, he will miss the symptoms completely.

Any software works in the same way. I am the doctor in this case and my code is the patient. I need to let go of my “ego” and get to the “right” way of doing things. I need to graduate from “doing” to “why I am doing this” to get to the root of the problem.

It is my responsibility to ask others to bear up with me-have patience-as I keep on asking questions which may be relevant at times and at times downright silly.

My questioning worked, and in lot, many cases gave the fresh perspective to the team to solve a problem.

As Richard Feynman rightly said.

“I would rather have questions that can’t be answered than answers that can’t be questioned.”

Code in Increments

Confucius rightly said.

“The man who moves a mountain begins by carrying away small stones.”

What do you do when you go on a long drive?

Do you just sit firmly in one position, stare straight ahead and floor the gas?

Of course not.

You have to steer. You need to check the traffic and also need to stop as required for food and fuel. Only then your long journey comes to a successful end.

Coding works in the same way, especially after a long gap.

Don’t code for hours nonstop without stopping. Instead, code in short increments. Coding in increments helps to not only to structure your code properly but also gives the chance to do comprehensive unit testing on smaller chunks of code.

You should be constantly evaluating how the code is shaping up. You will also notice that making small adjustments are far more effective than making long changes right at the end.

The key is to keep on doing something small and useful and notching up those “small” wins, rather than saving up for a long session of coding.

Get Frequent feedbacks and act on the same

Robert Allen correctly said.

“There is no failure. Only feedback.”

What is the shortest word in the English Language which contains alphabets a b c d e f?


And it is the most important weapon in every developer’s arsenal whether experienced or novice.

Very rarely we come across situations where we have a “fully frozen” functional or technical specifications cast in stone. The only thing any developer needs to do is to read the requirements and start coding.

It does not work like that in the real world.

In the real world, requirements are as fluid as ink and constantly evolving. If you try to freeze requirements you will end up freezing the wrong ones.

That is why frequent feedback is so important; from your peers, from your customers and even from your third-party vendors with whom your code is been integrated.

For example, when I started creating SAP forms, I would make sure to schedule frequent feedback sessions with my peers and my end users at regular intervals. This not only improved my confidence and my standing but cleared all my understanding gaps in a very concise way. Rarely I found myself in situations where I had to “rework” the code again.

Get feedback often and keep the frequency as weekly or bi-weekly. This keeps the application in “sight” during development and leads to collective collaboration.

Measure real progress

Dag Hammarskjold correctly said.

“Never measure the height of a mountain until you have reached the top. Then you will see how low it was.”

My 1st form development nearly took me 5 weeks to complete (including weekends also!!)

My 2nd form took 3 weeks.

My 3rd form completed in just 10 days’ end to end.

When you finally finish a task, keep track of how long it actually took to complete. Odds are, it would have taken much longer than estimated especially when you are just starting out. The key is to factor and add the actuals to the next development so that you approach as close to reality as possible.

You will zig-zag around for a while sometimes overestimating, sometimes underestimating but sooner or later you will become a pro at it and you will get a better sense of how long it actually takes to complete a given development.

One side advantage of accurate estimations is that you improve your standing among your peers and the customer starts “believing” in you. This acts as a catalyst for boosting your self-esteem and works wonders on your confidence levels.

Keep all informed

Seth Godin rightly said.

“The less people know, the more they yell.”

By accepting a task, you have agreed to deliver it on time. But we do run into problems and gaps beyond our control. Imagine a situation when you arrive at a “demo” meeting and inform all that you have not finished the code yet? What is the image you are conveying to others about you?

Missing the deadline is not only embarrassing but it also gives others the opportunity to “micromanage” your work. Everyone will start checking with you several times a day to make sure that you don’t miss the deadline again. This is detrimental for any developer whether new like me or the experienced ones.

By keeping others informed, you eliminate surprises and they are comfortable when they know your progress. They know when to help you out and you end up “earning their trust”.

The key is to “always under commit but over deliver”. This mantra always works.

Bringing it all together

Ultimately it is all in the mind. Life gave me two choices; either reinvent myself and do something new or slip into a never-ending quagmire of self-pity and uselessness. I chose the former and the rest was history.

As Satchel Paige has rightly said:

“Age is a case of mind over matter. If you don’t mind, it doesn’t matter.

About the author-:

Ravi Rajan is a global IT program manager based out of Mumbai, India. He is also an avid blogger, Haiku poetry writer, archaeology enthusiast and history maniac. Connect with Ravi on LinkedIn, Medium and Twitter.

read original article here