20 years of coding

We all grow older. It is simply inevitable. As the saying goes, The only way to not grow old is to die young. Recently, I've completed my 20th year in the development industry. Through academia, consulting, and a stint in product development, I've learned some lessons once and many repeatedly. I'll try and put the most important of them to digital paper here, and I hope you'll be informed (or at least entertained) by them.

Nothing beats getting your hands dirty.

First and foremost, software development straddles the divide between art, science, and craft. Everyone will emphasize different parts of this chord, but all three tones will ring when you code. Personally, I think each of the three aspects is of almost equal value.

Each of these three pillars shares one commonality, though: It requires engagement and practice to become good at each of them. You can read a math textbook and know all the theorems - but unless you work out a few proofs yourself, you'll lack the mindset and thinking patterns to apply the lesson. You can watch a hundred tutorials on woodworking, and they will not help you much as your hand clumsily reaches for a knife and digs the blade into the wrong kind of wood for your project.

Coding is no different. That is why I don't particularly like low-code or visual code tools: They remove the hard part too early. That sounds like a grognard's lament at today's youth, but even in my youth, there were attempts at WYSIWYG editors and fancy UML executors. They did not help me.

Implementing a connection pool by hand (knowing full well it wouldn't ever be as good as the thing a global community had built) helped me. Reading the specs on Java byte code and crafting a class file from first principles on a hex editor helped me. Understanding how AWS elastic beanstalk provisions more primitive AWS resources for its PAAS solution helped me.

Once you have the skill, by all means, use the tools available to your heart's content. But always remember that the most essential tool is your own knowledge. And, quite honestly, hitting enough rocks on the side of the paved road makes you appreciate the convenience of the road more - especially since now you know why it is the way it is. Frequently, the context of a technology is as important, if not more so, as its features.

Learn by teaching

While in university, I made what might have been one of the best choices of my life: I became a tutor for younger students. I thought it would be an easy enough job: Recount material that was still fresh in my mind and get paid for it.

I did not account for the sheer wickedness of the student's problems. They challenged my understanding in ways I hadn't thought possible, let alone expected to encounter. Things that seemed self-evident were put under a microscope and examined in detail.

It's the same principle that makes rubber duck debugging work as well as it does: When you force yourself to abandon the things you take for granted, to go every step of the way instead of skipping the "obvious stuff," you sharpen your focus.

Occasionally, the student beats the master. Something you teach is entirely wrong. I remember reviewing a junior developer's code that seemed horribly sloppy with resources - opening files repeatedly instead of carefully managing their lifetimes. I could have just rejected their pull request and required them to implement my envisioned sharing scheme. I walked over to their desk (this was the Halcyon pre-COVID days) and opened a conversation.

They were unconvinced and asked for proof that it was as impactful as I claimed. So I set up a small test to benchmark things, proceeded to run it - and found literally no benefit to the lifecycle scheme. If anything, it performed worse. So I dug in my heels and tried to find out what was happening. As it turned out, the kernel was smarter than me, kept the memory map alive, and turned the re-open into an NOP.

Everyone is doing their best(!)

Believe it or not, everyone is doing their best. Or at least, that is the working assumption I've come to take on any given day until proven otherwise. That obstructive penny-pincher in your client's purchasing department who doesn't sign off on the tool you desperately need? They are doing their best because the budget for this year has already run out, and it's not even September yet. That product owner who insists things are done in a farcically complex way that makes no sense at all? They are also doing their best since that is what legal wrote down as "non-negotiables."

Technical skill is essential, but it's only part of the job. The other part is knowing and dealing with people. This is the part I sometimes struggle with the most, to be honest. But it is still essential. Knowing whom to talk to and whom to leave alone. Where to spend your limited social capital and how to enable everyone to do their best is not just a management skill - it is a person skill.

So, while venting is occasionally cathartic and makes you feel heard, remember that anyone you meet is fighting their own battle. They're doing their best, just like you.

Hardware is (almost) never the problem

Your mobile phone has thousands of times the processing power that took the Apollo missions to the moon—just a fact. Of course, we blow it on animated emojis and to serve deceptive ads, but it is there.

Similarly, three decades ago, even the smallest VM we run our backends on would have been close to a mainframe. So when we hit performance bottlenecks, the answer can certainly be "scale up" or "scale wider" if that is cheap. Money trumps efficiency. But when money becomes an issue, since we can't just make the customer buy new phones, it's time to break out the pliers and dig in.

Algorithms beat silicon, and processes beat algorithms. If something is hard, try to find a different way. Don't bash your head against an NP-complete rucksack problem if you can ask the customer to rank their delivery priorities. Don't do diffractive ray-tracing math to display an overlay on your mobile app.

The Apollo rockets didn't land on the moon on autopilot - the compute wasn't there. Think of processing power as a budget constraint, and you're on your way.

Trust but verify

A test suite is an extremely revealing thing. Few things illustrate the development team's unconscious fears as much as what they chose to spend time verifying. Take the business-critical, multi-million euro application I recently was tasked with maintaining. Highly complex code, much business logic. It was virtually untested. But what struck me as the worst part was not how little code the team wrote tests for - but the tests they wrote.

There was a class called ListTest. It primarily served to verify the correct operation of java.util.ArrayList. Similar tests were present for a lot of the libraries the team used. The team seemed to think their code was trustworthy, and the library code needed intense scrutiny.

Trust, but verify. Trust that libraries do their jobs correctly (at least until you find actual bugs). Regardless, give their source code a glance or two as you begin using them. Immerse yourself and figure out the "vibe" of their team; understand how they speak the language. Chances are, they expect you to speak a similar dialect.

Trust your teammates to do a good job - but not unthinkingly. Insist on code reviews and knowledge sharing. I don't want to invoke the metaphorical bus here. It'll help both of you out, and you might learn something in the act. That goes double for more experienced developers than you - not only are you given a chance to look at someone's work who had more practice than you. When you find weaknesses and questionable tradeoffs, talk to your coworker. More often than you think, they'll be open to a dialogue. Heck, give them a chance to learn by teaching. Don't short-change either of you on these chances.

It's okay to be greedy

Generally, greed is not good, no matter what Gordon Gekko wants you to believe. Greed is destructive, often short-sighted and alienating. But in some very niche, very peculiar circumstances, it is not only valid. It is, in fact, vital. The key is to be greedy for the right things: For cultivation of yourself instead of instant gratification.

Be greedy for understanding

Say you face a technical issue in one of your projects. The precise nature does not matter as much as it has you stumped. The deadline is approaching, and you know ChatGPT is just... over there. A click away. Your company policy may or may not allow you to use it, but you know if you copied and pasted your code, it'd spit out something resembling a solution.

You could be quick here and do your job without really doing it. You might even go home a few minutes early. That would be greedy in one way. But you could also be greedy in a smarter way. Greed is selfish. Being greedy, you may also put the project lower on your list of priorities. Instead, invest in yourself by digging your heels in and going all the way to understand and solve the issue.

And the funny part is that this kind of greed does bring dividends. You will not only be less likely to trip over this problem again and waste an afternoon debugging the same problem you had before. You will also learn and solidify your grasp of the technology of your choice. Learn what works in which way, what warts lurk behind unintuitive designs, and maybe most importantly, you'll build confidence in your ability. After all, you did it yourself, not a sum aggregate of the average ability displayed on GitHub.

Be greedy to reach the mountain

Envision where you want to be early. Do you want to be the chief architect for your company? Do you want to have a "lead developer" credit for a major open-source project? Or do you want the comfort of earning a six-figure salary and indulging occasionally without giving the price much thought? Do you want to retire by 55 on your savings? Is this only your day job, and is poetry your true passion? All these goals are equally okay, provided you actively choose them. But all of them are similarly unlikely to fall into your lap. You'll have to chase them.

And all too often, we have these goals as vexing, distant things that we don't seriously work towards. There's always another year and something more important "right now." A mountain on the horizon that is, at the same time, tempting and seemingly unreachable.

A few years ago, I hiked along the Great Glen Trail. From one end of the Scottish highlands to the other. And I saw Loch Ness as a distant glimmer on the horizon - then stood on the southern shore. And eventually, I passed Inverness' city limits on the northern shores. How did I do that? One step at a time.

Take one step at a time, and be mindful of how all your small choices add up. Be bold and greedy; take one step after another, and you will go farther than you expect. Will you reach your mountain? Not necessarily. But unless you start on the road, you most certainly won't.

Conclusions

So, where is the silver bullet that'll make you a better dev? Not here, I'm afraid. It won't be anywhere - because, like any craft, you learn something new every day. It's been 20 years, and I learned a lot. Imagine what I'll have learned when I'm 64.