Learn Other Skills to Transform Your Code

Open up a whole new world of coding with these unlikely skills

Chris Cooney
Jan 13 · 7 min read
Photo by Joshua Earle on Unsplash

Writing great code is more than just writing code over and over again. It isn’t the exclusive right of greybeards to look upon their solutions and marvel. Yet, a pervasive idea in our industry is that one must have worked for many companies, over decades, before our code attains that all-important crown: clean.

I have been writing code professionally for five years. I’m miles away from greybeard territory, yet I’m proud of many of the solutions I’ve built during that time. Below are the basic skills that helped me on my way to writing those solutions. Some aren’t obvious, but all of them have had a profound impact on my engineering career.


Learn Five Different Programming Languages

If you want to write great Java, you need only to learn Java. If you want to write great code, you need to learn more. There’s a difference here and it’s subtle. Different languages offer different perspectives, but they’re all trying to achieve the same outcome: to make the computer do a thing.

When you’re writing Java, the temptation is often to:

  • Represent the problem with an Object
  • Attach some state and functionality to that Object
  • Create classes that make use of that object and work together to solve the problem

These patterns are typically how one would write some good Java. But if you want to tackle the problem effectively, you need more than the Java approach in your toolbelt. For example, if you were to learn Golang, you might:

  • Create a simple struct with the data
  • Break up your functionality into a series of composable, stateless functions
  • Create an application that ties together a series of calls to these functions

Same problem, different ideas

Different languages force you to train different ideas, much like different movements or machines at the gym engage different muscle groups. If you want fitness, you need to do a wide range of activities. If you want to write elegant code, you need to exercise many different techniques.

I’ve seen people obsess over Java paradigms, and it has lead to monstrosities like this:

private void doAThing() {
AbstractFactoryBuilder afb = AbstractFactoryBuilder.instance();
Factory f = afb.buildFactory(config);
Object o = f.build();
}

When I see code like this, I wonder if there is a better way, and there often is.

So why five?

It’s a bit of a random number, I must admit. Learn three if you’re short on time, learn ten if you’re really into it. The idea is to see new horizons. If you’re a Java pro, learn a little Clojure or Haskell. If you’re a Javascript expert, try your hand at a little Ruby. Once you’ve gotten five, you’ve seen plenty of different problem-solving philosophies and your mind is furnished beautifully with sense-making skills.


Practice Writing

This one seems a little odd, but hear me out. We’ll start with a simple quote from Martin Fowler about the intended audience for your code:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

When you write code, you’re not solving the problem. You’re describing to the compiler how to go about solving the problem. When you deploy the code and it’s correctly running for its intended user, the problem is solved.

And that description is often lacking…

Some of the best writing advice I’ve received over the years is directly applicable to my code.

  • Don’t use unnecessarily complex language.
  • Don’t use complex sentence structures; keep things simple.
  • Make sure you understand what you’re trying to say before you say it.
  • Write multiple drafts and be sure to regularly review your work.

And even down to seemingly specific advice, such as “Break up your writing into paragraphs.” Heard that one before? Ever seen a function like this?

private void doAThing() {
System.out.println("Initial log");

List<String> words = Arrays.asList("hello", "world", "something", "is", "in", "here");

for(String s : words) {
System.out.println("I am doing something with this word");
System.out.println(s);

doSomething(s);
doSomethingElse(s);
thenDoSomething(s);
finallyDoThis(s)
}
for(String s : words) {
System.out.println("I am doing something with this word");
System.out.println(s);
doSomeOtherStuff(s);
andSomeMoreStuff(s);
// This is the last but not the last
okayLastThingIPromise(s);
finallyDoThis(s);
}
}

With some basic writing advice, without any knowledge of code, one could improve this code immeasurably.

  • Break it up into smaller paragraphs (methods).
  • Make sure you understand what you’re trying to say (i.e., write the solution elegantly).
  • Don’t repeat yourself (for instance, why are there two loops over the same data like this?).
  • State your ideas clearly (for example, what does “last but not last” mean!?).

Fowler’s advice rings true again and again. I’ve seen many, many engineers wrestle their software into submission, with confused and clunky code that takes hours to unpick. The true masters, the senseis, write simply and effectively. How do we grow this skill?

The remedy

Learn to write a little. Read some of the basics, like The Elements of Style: simple, clear books that are designed to improve your prose. With that, you learn how to communicate your written ideas more effectively, avoiding the obvious pitfalls of the many engineers who have come before you.

Then, start a blog! Blog about technology or literature, holidays or conflicts — whatever your heart desires. Practice makes perfect and you’ll develop a keen sense of pithy, simple descriptions that fully and accurately reflect your brilliant ideas. No one needs to read it, mind you. It’s just for you to try out some of these new skills you’ve picked up.

A staple read for any aspiring writer

Remember, coding is the act of expressing ideas, both to the compiler and to your fellow engineers. Don’t cut corners on that expression and never, ever underestimate the creative element of your profession.


Don’t Overload Words

Did you know that an Order might signify a collection of items that a customer wants to pay for, or it might represent some sorting logic for a list, or it could be the power to which a number is raised. When someone is coming to read your code, they’re bringing all of their own baggage with them and, as a good author, your job is to ensure that you use language that reflects what you mean.

private void printAThing(String a) {
System.out.println("I am printing: " + a);
sendToPrinter(a);
System.out.println("I am writing in print: " + a.toUpperCase());
}

Print, in this context, could mean write it to the screen, create a physical copy on paper, or write it all in upper case. English is an awful language for double-meaning.

Develop a glossary

This is a core component of domain-driven design (DDD). As you leap over the problems that your industry places in front of you, a new language will begin to form. This happens naturally — we can’t keep covering the same ground. However, without someone keeping track of this new language, this can become out of hand.

DDD advocates for a glossary of terms that are specific to your organisation or your domain. For example, an Order is always a collection of items that a customer wants. This document creates a commitment — that Order means one thing and nothing else.


Don’t Be a Zealot

The industry is regularly in a battle between the status quo and the disruptive, the new ideas that are being introduced. Technology is incredibly fast-moving. A rebellious concept today becomes a battle-tested best practice tomorrow.

This fluid movement of ideas means one thing. Placing your ego into these principles is a recipe for stagnation and pointless argument. Simply put, don’t do it. Instead, look at each paradigm as a tool on your belt.

Photo by Hans-Peter Gauster on Unsplash

If you have an application that needs to transform a lot of data, functional programming techniques are going to be your friend. If there is a lot of domain logic baked into various concepts, you may want to mix some object orientation into your solution. These approaches are not mutually exclusive, and a great programmer applies a measured amount of each when necessary.


Test, Test, Test

This one I’m sure you already know. Testing isn’t just a mechanism for ensuring that your code works. It is even more than a safety net upon which you can safely refactor. Tests provide another level of confidence: that your code is testable.

Photo by Science in HD on Unsplash

TDD isn’t always the answer

This is typically where people advocate for test-driven development (TDD), which is the practice of using tests to help evolve the design of your code, leading to highly testable structures. I am not going to do that. TDD is great and if you want a mechanism for creating highly testable code, go for it.

Likewise, sitting down with a pen and paper and drafting out your solution, looking for points to inject a mock, and deciding where the boundary of your system is will give you a brilliant level of clarity, too. TDD isn’t the only game in town, and don’t believe anyone who tells you otherwise. See the above: Don’t be a zealot.

Better Programming

Advice for programmers.

Chris Cooney

Written by

[‘tech’, ‘insane rambling’].map(category => new Article(category))

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade