Doing it right

April 15, 2014 Nigel Pepper

A famous American man called Theodore Roosevelt once wrote:

“Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty… I have never in my life envied a human being who led an easy life. I have envied a great many people who led difficult lives and led them well.”

I am somehow drawn to this, while at the same time, believe that with most things worth doing, there is a hard, and an easy way to approach them. Becoming a great developer is one of those things and I’d like to draw down on some of the things which I think help, and have certainly helped me to improve my craft over time.

Speak many languages

Knowledge of multiple languages breeds not only an improved skill set from which to draw upon, but also a conceptual advantage. This gives you two advantages. Choosing the most appropriate tool for the task at hand becomes less of a fear hurdle and leads you away from the temptation to create ‘monsters’ in a given language just because it’s your only tool.

Try a new language every year. This year I’m looking at Go.

Apply your skill

Becoming a great developer is much more than technical prowess. The ability to communicate, empathise, present your ideas, consider those of others are all fundamental to your success. Most, if not all of the best engineers I’ve had the pleasure of working with are excellent communicators; able to consider business goals and motivations to help drive out the features to focus on, and help plan how the product should best address the customer’s needs.

Stay agile, keep shipping

Always be testing. It helps drive out good design. It keeps you free to change.

Test drive your code. It helps drive out good design. It keeps you free to change.

Release often. It allows you to continually add business value. Business value? Yes, the value which your customer can measure success or failure by. It also helps keeps you free to change. When releasing your software is de-jour, it ceases to become a scary thing. Aim for low ceremony, zero-touch releases. Techniques such as Continuous Delivery should be a goal.

Say No.

Learn to sympathetically challenge ideas. Everyone benefits from constructive empathetic criticism. If there’s too much text on the page, say so. You won’t be the first, nor last to notice. Do usability testing. Get input from others on your application. Focus on the things which come up more than once. Use analytics tools such as MixPanel or Google Analytics to test your assumptions using a scientific method.

Hone your skill

Practice new things. Try your hand at new stuff that interests you. It’ll keep development from ever getting boring or tedious.


Pair programming is awesome. You get to learn from someone. For free. You get to share your skills. You improve your ability to communicate. You passively de-risk your project. You avoid creating, and singly dealing with weird ‘Towers of Babel’ that someone built and now you have to comprehend.

Clarity over complexity

No-one gives a damn if you can invert your multi-dimensional nested array in 20 meaningless characters. Conversely, people will love you for breaking down the problem simply, such that the next person can pick it up and carry on where you left off.

Your code will be written once and read many many more times. Make the latter the focus; readability.

Do what’s right

Your skills have the power to do a lot of good. Do something worthwhile with them. You have choices; don’t be a wage slave.

These are just my opinions. I’d love to hear from you if you have any thoughts on anything in here.

Happy engineering!

About the Author


PaaS Judo: With Cloud Foundry Ippon Deploys in 2 Minutes Versus 2 Weeks
PaaS Judo: With Cloud Foundry Ippon Deploys in 2 Minutes Versus 2 Weeks

Ippon Hosting CTO, Ghislain Seguy, recently shared a profound point about Cloud Foundry, “What used to take...

The Myth of the Sole Product Manager
The Myth of the Sole Product Manager

There is a myth that the Product Manager is the sole person for the success and failure of a product. It’s ...