Habits of good developers

Good developers are rarely the ones who know the most tricks. They are the ones whose work you can read, trust and change a year later. That comes from habits more than talent, and habits can be learned.

Here are the ones we see make the biggest difference, at any level.

Write simple code

Clever code is fun to write and costly to read. The person reading it next might be you, tired, at the end of a long day. Prefer the plain version: a loop over a one-line puzzle, a short function over a long one, an obvious data structure over a smart one.

Simple code lets the reader follow the idea without holding much in their head. Sometimes that takes a few more lines, and that is fine. A good test: could a colleague who has never seen this file explain what the function does after one read?

Remove what you do not need. Dead code, unused options and "just in case" layers all have to be read and maintained. You can add them back when a real need appears.

Name things for the reader

Names carry most of the meaning in code. Compare these two functions. They do the same thing.

def calc(d, t):
    r = []
    for x in d:
        if x[2] > t and x[3]:
            r.append(x[0])
    return r

def overdue_invoice_ids(invoices, days_allowed):
    return [
        inv.id
        for inv in invoices
        if inv.days_open > days_allowed and not inv.paid
    ]

The second one needs no comment. Some rules of thumb:

• Name a function after what it returns or does: overdue_invoice_ids, send_reminder.
• Name a boolean as a yes or no question: is_paid, has_access.
• Use the words your users and clients use. If the business says "booking", do not call it "reservation" in the code.
• Short names are fine for short scopes. i in a three-line loop is clear; d as a function argument is not.

Make small commits

A commit should hold one idea: one fix, one rename, one new field. Small commits are easy to review, easy to revert and easy to understand in the history months later. Write the message for the person who will run git log while hunting a bug: the first line says what changed, the body says why.

git add -p                      # review each change before staging it
git commit -m "Reject empty e-mail on sign-up form

The form accepted a blank address and failed later in the
mailer. Validate it on submit and show the error inline."

git add -p shows each change and asks whether to stage it. It is a quick self-review and catches stray debug lines before anyone else sees them.

Read more code than you write

Most of a developer's time goes into reading code, so it pays to get good at it. Before you change a function, find who calls it and what they expect. Read the tests to see how the author meant it to be used. Use your editor's "go to definition" and "find references" instead of guessing.

Reading other people's code is also the fastest way to learn. Pick a well-run open-source project in your language and read a few merged pull requests: what was changed, how it was reviewed, what the reviewers asked for.

Test what matters

Tests let you change code without fear. Start with the parts where a bug would hurt most: money, permissions, data that users cannot recreate. Write a test that reproduces a bug before you fix it, so it can never come back unnoticed.

Keep tests fast and independent, so you run them often. A slow test suite gets skipped, and a skipped test protects nothing. Our Python tips and tools guide shows what a small pytest file looks like.

Ask for help at the right time

Struggling a little teaches you a lot. Struggling for a whole day on something a colleague could explain in five minutes teaches you very little. A workable rule: give a problem a fixed time, such as thirty to sixty minutes, then ask.

When you ask, make it easy to answer. Say what you are trying to do, what you expected, what actually happened, and what you have already tried. Include the exact error message. Often, writing the question down this clearly shows you the answer before you send it.

Developer or engineer

People argue about the difference between the two words. In practice, the useful difference is scope. A developer turns a well-defined task into working code. An engineer also asks how it fits the rest of the system, how it fails, how it is tested and monitored, and what it costs to run and maintain.

You do not need a new title to work like an engineer. Ask "what happens when this breaks?" and "who maintains this after me?" on every task, and the wider view comes with time.

Learn steadily

Technology changes, but the foundations change slowly: how the web works, databases, networking, security, clear writing. Invest most in those. For new tools, learn them when a real project needs them, and build something small with each one.

A little every week beats a lot once a year. Half an hour of reading documentation, a short side project or a code review you would not normally do adds up. If you are just starting, Which programming language should you learn first? suggests a path.

When you feel like an imposter

Most developers sometimes feel that everyone else knows more and they will be found out. The feeling is common and it does not mean you are bad at the job. Software is too big for anyone to know all of it, so everyone is a beginner in most areas.

• Keep a record of what you have done. A simple list of shipped features, fixed bugs and things you learned. Read it when the doubt is loud.
• Compare yourself with your past self, not with the most visible people online.
• Say "I do not know yet". Good teams respect it far more than a confident guess.
• Teach something. Explaining a topic to a newer colleague shows you how much you already know.

Common questions

How small is a small commit?

Small enough that its message fits in one clear sentence. If you need "and" to describe it, it is probably two commits.

Should I comment my code?

Use comments to explain why. Good names already say what the code does; a comment records a decision the code cannot show, such as a workaround for a known bug.

How long should I try before asking for help?

Set a time box that fits the task, often thirty to sixty minutes. Then ask, with what you tried and the exact error.

Is imposter syndrome a sign I should change careers?

No. It is very common among capable people. Track your progress and talk to colleagues; most of them feel it too.

Working on your own? Freelancing tips for professionals covers scoping and pricing, and Getting paid on Internetivo explains how professionals find paid tasks.