BAD Developers are not BORN. They are CREATED
My first day as a developer, 18 years back began with a question.
“Tell me, Ravi, what is the difference between a vandal and a developer?” my boss asked
I was confused. This was not something which I expected to answer on the 1st day of my career.
“Well Bob, a developer writes code. I am not sure how is he related to a vandal” I answered hesitatingly, not knowing what to say.
He smiled.
“They are very much related Ravi.”
“If people destroy something replaceable made by mankind, they are called vandals; if they destroy something “deemed” irreplaceable made by mankind, they are called developers.”
“So in a nutshell, you need to be a “Creative” Vandal to be a GREAT developer. You need to question and change the status quo every single day.”
And here are some simple ways, that will help you to reach the pinnacle of GREATNESS.
Brand your code
Larry Wall nailed it when he said.
“Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.”
A lazy developer just keeps on writing lines of code as part of his daily routine. Once the day ends, he gets “lost” among the “pool” of developers who are supposed to be working on “something” every day and getting billed for the same.
On the other hand, an “active” developer makes his code unique; he brands his code with his unique signature. This “uniqueness” can be as simple as adding a “bit of code” that makes the user’s life a little easier to as complex as outstanding code optimization which boosts up the performance to significant levels.
Good Programming is a few brief moments of sublime elegance embedded in months of niggling, exacting, precise trivialities. Make that sublime elegance stand out.
The point to be noted here is that you must do something that gives you an edge over other developers which makes people remember you. This very “edge” later gives a boost to your career where only Darwin’s principle of “survival of the fittest” reigns supreme.
Good Programs Are Fast, Reliable and Cheap. All THREE are REQUIRED
Mich Revera once said.
I can ALWAYS write faster code if it doesn’t have to work.”
Avoid the rat race. You are not competing for the Olympics here. Your useless coding written at a very fast pace is not going to give fruitful results in terms of you in person or your organization. As such code will require a lot of efforts in terms of code leakage, bug finding and fixing.
Instead, you should set a goal of writing useful, quality rich and feature-rich code in stipulated time.
Your job is to make it work, make it right and make it fast in that order.
Deadlines, Timelines, and pressure will always be there and that does not give you an excuse to deliver crappy code at a fast pace. Your credibility goes for a toss once you start doing it.
Keep it Simple Always
Steve McConnell aptly said once.
“It’s okay to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it.”
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. The rule of thumb is “Do the simplest thing that could possibly work’, not the most stupid”.
If your style of writing code is such that only you can understand it later, it needs your attention to analyze your style of writing complex code and find out a way to start writing high quality of code in a simple and structured manner. This will help you and your organization in a big way.
Always remember the ultimate elegance is simplicity. Controlling and eliminating complexity is the essence of GREAT programming. Bad, unwieldy programming is like unsafe sex; one mistake and you would end up supporting it throughout your life.
Never underestimate Testing. Your reputation depends on it.
Steve McConnell has rightly said.
“It’s hard enough to find an error in your code when you’re looking for it; it’s even harder when you’ve assumed your code is error-free.”
If your code is constantly requiring too much of attention of your testing team to find out a large number of bugs every time and spend a lot of time with you to make you understand the flaws in your code, it definitely is a severe crime you are committing towards your career and also towards organizational growth.
The best option is to devote some time to exhaustive “self-testing” before handing over the code to testers. This way, you are not only giving a quality product to the testing team but also building a stellar reputation for yourself. Bug-filled code, however exciting is a sure shot recipe for disaster.
Tom Cargill gets it right when he says “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.”. Avoid and eliminate rework efforts. It does not help anybody including you.
Be a REAL ROCKSTAR Developer
The rock star developer is not a myth. But unfortunately, there are FAKE ones and there are REAL ones. You need to aspire to be a REAL ROCKSTAR developer.
People love to say that a rock star can do the work of 10 regular engineers. That’s just nonsense. 9 women can’t have one baby in a month, and 10 “rock star” developers can’t replace 100 regular ones.
So Are rock stars all about lines of code?
No, measuring programming progress by lines of code is like measuring aircraft building progress by weight. Good developers solve problems. More specifically, they make problems go away.
They fix problems rather than complaining about them. Every great developer you know got there by solving problems they were unqualified to solve until they actually did it.
Just because someone has written a blog, or a book, or speaks well doesn’t mean they are a good developer. You certainly don’t want a diva. Diva Developers do more harm than good.
So be the REAL stuff. As John Johnson has rightly said:
“First, solve the problem. Then, write the code.”
The One Lesson I learned here
In the end, the most important factor in becoming a good, or even great, developer lies within yourself. Perhaps it takes talent and a true innate passion to become a phenomenal top 1% programmer, but anyone with an interest in programming and solving problems can be a “good” programmer.
If you don’t want to become a good programmer, then no one, not even a great mentor, can help you. You are your greatest enemy, and you should always aim to be a better programmer than you are now.
As Kent Beck has rightly said.
“I’m not a great programmer; I’m just a good programmer with great habits.”
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.