You can learn a surprising amount about a person from code they never meant you to read. Open a file someone else wrote, one they moved on from years ago, and within a few minutes you know things about them. Not their name, not their title. Their character: whether they were in a hurry, whether they thought about the next person, whether they cared about the part nobody would ever see.
I have inherited a great deal of other people's code over the years, across more teams and more countries than I expected when I started out. And I have come to believe something I would not have said out loud at twenty-two: code is one of the most honest portraits we leave of ourselves. Long after the meetings are forgotten and the deadlines stop mattering, the code remains, and it quietly records how we thought, what we valued, and how much we respected the people who would come after us. Every programmer is an artist, leaving a signature in every line. The only real question is which signature you are leaving.
The Two Engineers You Inherit
Sooner or later you inherit a system, and it tends to have been written by one of two people.
The one you quietly thank
- Clean, commented code.
- Clear intentions, readable by anyone who opens the file.
- A joy to debug, and a joy to maintain.
You meet this person only through their work, and you are grateful for them. You can change what they built without fear, because they thought about you before they had ever met you.
The one you meet at two in the morning
- Quick fixes and jittery code.
- Living life, and debugging, on the edge.
- A rollercoaster ride for whoever inherits it.
You meet this person too, usually in the middle of the night, trying to reverse-engineer a decision they made in a hurry and never bothered to explain to anyone, including their future self.
So which one are you? And, more usefully, which one do you aspire to be? Nobody is purely one or the other every single day. We all ship the occasional two a.m. hack and promise ourselves we will come back to it. What actually defines your character is the direction you lean when you are tired, under-resourced, and the deadline is tomorrow, because that is the moment your real self writes the code.
Your Code Is Also a Compass
If your code is a portrait of who you are, it is also a compass for how you decide. Your values show up as defaults long before you could put them into words. Read enough of someone's work and you can name, with some confidence, what they instinctively reach for:
- Security-first. Trust is your middle name; you assume the hostile input and the worst case.
- Scalability-first. You are building for the long haul, not only for today's load.
- Speed-first. You thrive on the adrenaline of shipping, and you ship.
- Signature style. The quirks and patterns that are unmistakably, recognisably yours.
- Kindness. Readable, maintainable, and welcoming to whoever opens the file next.
- Curiosity. You keep reaching for new tools and techniques instead of the comfortable ones.
- Integrity. You do it right even when no one is watching, which, in this craft, is most of the time.
None of these is wrong on its own, and none of them is free. A prototype you will throw away next week does not deserve the same care as a system that moves someone's salary. Character is not rigidity, and it is not gold-plating everything in sight. It is knowing which of these the moment in front of you actually calls for, and choosing it on purpose rather than by accident or habit.
The "I'll Remember This Later" Fallacy
There is one small, daily test of character that almost all of us fail at least once. You write a piece of genuinely intricate logic, the kind that cost you an afternoon and three cups of coffee to get right, and at the end you decide not to comment it. You will remember how it works. You are certain you will remember. You never remember.
The next person to open that code is very often you, six months older and stripped of every scrap of context, meeting a stranger who happens to share your name and your commit history. A comment at the hard part is not bureaucracy and it is not noise. It is a small act of respect, usually for your own future self. The engineers I have come to trust most are not the ones who never write confusing code. They are the ones who leave a light on for whoever walks in next.
When the First Draft Is Not Yours
These days, more and more of the code in front of you is not yours at all. It is generated, suggested, autocompleted, pasted in from somewhere a model learned it. That does not retire the question of character. It sharpens it. When a tool writes the first draft, your signature is no longer in the typing. It moves into what you accept, what you reject, and what you take the trouble to actually understand before you put your name to it by committing it.
The craftsman and the daredevil both still exist in that world. One reads the generated code, questions it, and shapes it into something they would be willing to sign. The other pastes it in, watches the tests go green, and moves on. The tools changed. The character test did not.
I have written elsewhere, at greater length, about what it actually means to be an excellent engineer – the slower, harder self-assessment. Consider this the short version, the one you can act on inside the next hour, in the next function you write. Because the question was never really whether you can make the computer do the thing. It is who you turn out to be while you are doing it.
Make it a masterpiece.