Shivan Moodley

Caring

I don’t care about code anymore.

At least, not all the time. Not in the way I used to care about it. It might be better to say, I don’t care about the specifics of implementation all the time.

I’ve reached a point with programming where, when I’m presented with a problem - there isn’t often a case where I couldn’t solve it given some time. This is in part because I work on things that are technically simple (for now), and in part because I have a bunch of context about the things I’m working on (for now).

Timing

So - given a problem, what do I care about these days?

Mostly, I care about whether it is the right time to pay attention to things.

Is it the right time to make this set of components generic?
Is it the right time to extract this functionality out into it’s own little application?
Do we need to solve search in a different way right now?

Right now, I care deeply and intently about timing.

Untitled

Mistakes

The reality is, if you build software that needs to make money, you will write code that is bad. You will write code that will cause problems in the future. The more of this code you write, the more you will start to care about picking your future problems actively, instead of letting them arrive unannounced.

Over time, you start to pay more attention to the trade-offs you’re making, and yet, you will still make some unknowingly. Obviously, you can’t know everything.

Enough

It is possible to care a little bit, all the time and reduce risk slowly, but this isn’t a very satisfying plan.

It doesn’t give you the same dopamine rush as big architecture overhauls, or refactoring legacy code into sensible chunks.

Caring about timing is good input for continuous care. It gives you space to have the dopamine inducing ideas, whilst grounding them in reality.

The core, generalised question I’ve been asking myself regarding timing and code has been:

What is the first step toward this thing? Can I do the first step, and not do any other steps for a while? What changes in the next while that makes my goal different?

Identifying the first step toward something can change its timing. Because of course, it has a different lifecycle. Maybe now is the right time to do it.

This harkens back to one of the principles you’d find in an agile handbook. I’ve also seen it called “Lean Architecture”:

“Just enough, just in time”

The problem still remains, what’s the timing of the thing that’s going to work? This is something that I think you have to become okay not knowing precisely. You have to trust your gut, and be wrong a few times.

Advice

I think reading a bunch definitely helps. It’s useful to learn about how others have failed. Don’t limit your reading to books and blogs about software. Read about all types of organisations and systems.

Take a look at hospitals, emergency services and brick-and-mortar business.

How do they make decisions for the future, and for the now? How did that impact their financial success?

What bad decisions did they make?

I’ve been doing this a lot, and if nothing else - it’s just interesting and fun to learn about other things outside of software.

Expectations

I expect to be wrong about a lot of things over the next few years I spend building software.

It seems natural and emergent. I’ve done a lot of things, in a short amount of time - and it’s timely for that to unspool, and play out.

I expect to be wrong about decisions I’ve made in the past, and I expect to be wrong about decisions I might make tomorrow. I am hoping to be less wrong about tomorrow’s decisions though.

You can read and learn a ton and still be wrong about decisions that you made. That’s fine.

Maybe being wrong helps me understand timing better. Perhaps I should’ve done the one thing sooner, or maybe a bit later?

In fact, the only thing I expect to right about - is being wrong.