Tips for Developers

Update: Rewrote several sections

“Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.” - Alan Perlis

This article contains some things I have learned that has made me into a better developer than I was before I learned them. There are nine tips. These are not necessarily the only, or the best things I have learned, but I like the number nine.

Becoming a better developer is a complex path. What I have found to be the most important attitude is to be versatile. Digging yourself down in one kind of activity, one “phase” of a project, one technology is a sure way to stagnate. I try to balance technical knowledge with “softer” skills. Developing software is about communicating, thinking, and programming. In order to be effective, you have to master all of these areas.

1. Accept Failure (but only settle for perfection)

“Knowing the path is not the same as walking the path” - Tao te Ching

Sometimes, you know you could do better. But time, skill or luck may have it otherwise. The most important thing to learn to be good at anything is that you will fail. But failure is okay. Life goes on. By accepting failure, you should also realize that you can always improve. Be sure that you understand why you fail and how to improve. It is better to fail fast than to kinda success very slowly - failing allows for feedback - feedback allows for improvement.

A tip to help improve: Ask a friend “what would it take to get a 10/10?”

2. Be brief

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

“No code is better than no code.” - Unattributed

When you communicate, whether through code, documents, or emails, the more the information, the harder it is for the recipient to find what he need to know. Remove everything that is not needed: Comments that explain what the code does, sentence that don’t add to your email, code that is no longer needed, default values in code.

Besides, if you write the code, somebody will have to maintain the code as well.

A tip to help improve: “What sentence can I remove?”

3. Develop in-depth knowledge of your field

Understand which parts of your code are needed and which parts are not. What is the difference in behaviour between catching an exception in the main block, like this:

public class Foo {
    public static void main(String[] args) {
        try {
            doSomething();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

… and letting the main method throw the exception, like this?

public class Foo {
    public static void main(String[] args) throws Exception {
        doSomething();
    }
}

Exceptions are interesting creatures in Java-code. Understanding what causes exceptions and what you can do about it is very important. For those in a hurry, I give you Johannes’ first rule of exceptions:

“There’s usually nothing you can do about it” - Johannes Brodwall

Lastly, there are some basic skills that every developer should master: How to use source control, how to write unit tests and how to use continuous integration. If you don’t know how to do the first two of these, you’re not doing your job!

All tools also have default values for configuration. Recently, people have started talking about “convention over configuration” as a design principle. This basically means: Use smart defaults. Remember that configuration is also code, and that no code is better than no code.

A tip to help you improve: When you make something configurable in your program, consider adding a smart default value.

4. Don’t overspecialize

"Specialization is for insects - Robert Heinlein

There are many ways of overspecializing. Learning only one programming language is one of them.

Languages are the tools we use to think. Different languages will make you think differently. If you’re bilingual, you will probably notice that when you speak a different language, you have a different personality. I, for example, master both English and Norwegian well. (I am speaking in English now, right?) And I am much wittier when I speak Norwegian.

The same thing holds for computer languages. The language you use shapes the way you think. You will benefit enormously from learning a language that is radically different from what you use daily.

Choose a language that uses dynamic typing and that contain lambda expressions, or code blocks.

This code implements a very complex concept. See if you can understand what it does.

function getById(parentId) {
  var rs = ....;
  var parent = transformFromRs(rs);
  parent.kids = lazyLoad(
    function() {
      return kidsByParent(parentId);
    });
  return parent;
}

“A programmer should be able to find a bug, market an application, refactor a spike, lead a team, architect an application, hack a kernel, schedule a project, build a database, route a network, give a reference, implement UserStories, analyze UserStories, work in a team, work alone, use patterns, innovate, write documentation, have a RealLife, create a cool website, email efficiently, resign gracefully, AdmitIgnorance, and keep on learning. Specialization is for recruiters” – with large apology to RAH and his estate, Peter Merel

5. See the bigger box

“The easiest way to build something simpler is to not build things you don’t need. 64% of our software is barely used” - Alan Shalloway

Your problem always exists in a context. If you understand the context, you might realise that there is another, much simpler solution to your problem.

A hypothetical example: Your task is to implement a mechanism for prioritizing jobs. This is to make sure that our real important jobs complete within a minute. (The “why”) Maybe you find out that by optimizing an algorithm, everything runs fast enough, and you don’t have to prioritize. Or maybe you just buy a faster machine and you end up not even having to optimize.

Even when you cannot thing of a way to simplify, understanding why can help you create a better system, or understand your role in the organization. Why are we implementing the payment function? To make our users pay for the online ticket system. Why do we create an online ticket system? Because our relationships with xxx gives us a unique chance to offer a better service.

Look up from your computer, look around. Why is the world around you doing what it is?

6. There is only one rule of design

Get the right coupling between the parts. Two things are coupled if change to one requires change to the other. If this change seems inappropriate or clumsy, that means that the parts are too closely coupled. Overly close coupling is cause by: Duplication, faulty abstractions, inappropriate intimacy, poorly design system boundaries.

When you remove coupling, be sure you remove it, not that you just hide it. Using string (for example XML) as a communication format instead of rich objects can often hide the coupling without removing it.

Design is about coupling. The rest are details.

A tip to help you improve: “When I change this decision, what else in my system will need to change? Why? How can I avoid that?”

7. Understand the difference between haste and productivity

“Don’t just do something, stand there!” - Unattributed

The most common problem I see when something goes wrong is that people panic. Take a deep breath. Don’t panic. This is especially true for those who feel responsible, but have nothing they can do to help, like project managers.

Productivity is a matter of managing and completing tasks. Productivity guru Dave Allen outlines a method in “Getting things done” a method that I find helpful:

1. First, make sure that all that you have to do to complete your goal is written down and organized, so you can see what you have to do. For work email, I use the “flag” functionality in Outlook. For private emails, I use the gmail inbox. You goal is to get everything done. To empty your inbox. Use lists, failing tests cases, reminders, sticky notes as well, but be sure that you know the totality of your work. Whatever you do: Don’t waste brainpower remembering what you need to do.
2. When you get an item, decide whether to Do it now (if it takes less than 2 minutes, do it right away), Delegate it (but remember to follow up!), Defer it to a specific date, Do it later or Drop it

Two tips to help you improve: Make sure everything is written down and nothing falls between the cracks, and master the art of the two-minute email to keep your backlog short.

8. Implement for today

The most common root cause of problems that I see is insufficient myopia. People see too far ahead and think too far ahead. This leads to code that: Tries to optimize things that turn out not to be important, tries to generalize things that will never vary, tries to expose interfaces that will never be reused (with web services! whee!) or try to handle situations error situations in clever ways.

The problem is that code that tries to solve a more complicated problem is usually more verbose, which means that it is less robust. And functionality that has never been tested properly (for example: error handling routines) never work.

At the same time, don’t be restricted by what is there today. Delete code that is no longer needed, comments that make no sense. Learn how to discover whether code is dead or not.

9. Leave proud

You cannot always solve the problem you’re working on in a perfect way, but you should leave your code, your document or whatever you’re working on in such a state that you could be satisfied never touching it again.

Don’t leave needless boilerplate comments, name your classes, methods and variables well. Indent your code properly. Fix typos.

You could be hit by a truck tonight. What will those who come after you think of your legacy?

Finally: A word in parting:

“It is better to be clearly wrong than obscurely right” - Ken Orr [1]

• Software Development