My early days of coding were definitely heavily influenced by what code can do for graphics.

This is because I’ve always been heavily visual in the way that I do things, but also because I started out with an ZX Spectrum and Amiga 600.

With the Spectrum I had to learn the correlation between binary and the screen render.

But I did most of my learning was with the Amiga, with the likes of Assembler, AMOS, DPaint, BlitzBasic, and building mini games and numerous graphical demos.

Here I specifically learned the correlations between memory and different parts of the computer, even being able to fabricate a high resolution version of the screen with more available colours than typically offered by the Amiga. This was done by combining binary frames of two screens together.

I also learned the basics of sprites and how to achieve pixel environments, and animated graphics. At this time I also taught myself languages beyond BASIC and ASM like Pascal.

The Amiga and AMOS still holds a special place in my heart in terms of my computing history. Mostly because it had the best set-up (even compared to modern equivalents) for combining coding with graphics in a quick and easy to run environment. And… still also allowed to break out into low-level ASM routines.

After working on many of my own projects at home, without much programming help from school (they did have an obsession with teaching Word Processing however), I moved up to college. Where they did have a programming course that had stated it would be teaching C++ (something I had been very interested in).

So I chose that as one of my options. Unfortunately, when the course started they didn’t teach C++, instead they decided to teach Pascal instead. I did at least learn something of databases in this course (bad ones), but mostly spent time learning about Graphics dlls in class (as they were easy to access using Pascal). I continued to teach myself C and C++ at home instead.

I had one of the weirdest experiences as a result of an exam at this college. I was marked down for finding more issues in the example code than was recorded in the marking notes, and was told my written answers to some of the questions had been too technical. “Too technical” on a computing course. When I questioned this, I was told the exams were often marked by people without technical knowledge.

My coding style definitely changed when I switched over to PC and started experimenting with the “Interweb”. Things became less low-level and more about files and scripting.

CSS didn’t exist, JScript and VBScript were doing battle, and even creating a page layout was a learning curve. Everything became DHTML, and fullscreen page transitions were never a good idea.

I still remember well the brilliant access that HTML gave for learning, an example of this was first discovering the <ul><li> elements. All I had to do was inspect examples of bullet points I found around the web to learn how to use them.

It was a great time for discovering —especially as I was gaining knowledge as things were invented/released. Which made it more manageable than the sprawling complexity presented to those starting out now (especially CSS). However, you did have to build nearly everything yourself. Which meant a lot of boilerplate/setup if you wanted to achieve anything.

As ECMAScript started to become the language of the web, my focus on it grew, across various variants. The different flavours that existed between browsers, the versions that existed as sideline languages (in Flash, Photoshop, etc.). It was a revelation, because previously I had only ever been able to run my code locally. And now I could publish it to the web, or use it to interface between systems.

I did tinker with VBScript, but it just didn’t hold up to what JS could do. I know there are lots of detractors out there who have a dislike of JS (some have good arguments, others don’t). But most of them being coders who like stricter, more locked-down languages. But for me, it was exactly EMCAScript’s expressiveness that pulled me in. It was closer to sketching and being artistic.

Clearly, JS —if used improperly— can get very messy. It’s power can undo itself. But… as long as you understand what the language is capable of. E.g. you know the difference between deep and shallow cloning, you know how references work, you understand closures, you get how functions can act as first-class objects, how garbage collection works. If you understand that, you can build a great many things, very quickly and safely.

When Flash released AS3 I fully switched some of my projects away from the HTML world over to Flash —because it allowed me to seriously mix my coding ability with graphical handling (just like I had had before with Amos). You have to understand, at the time, browsers could hardly move layers, let alone handle effects.

Whilst I did learn a lot from that. It was definitely a hard lesson learned, when Flash essentially died as a technology. I did look at Silverlight, but thankfully bounced right off that one.

The disappearance of Flash set me back quite a bit in terms of my personal projects, and to this day, I will always choose native tech over proprietary or third-party if I can. Precisely because the browser environment has been stable enough to be progressively enhanced for years (and other things, well… haven’t been).

One project that particularly got hit was ALWTM, I had a full engine built in AS3, that could handle parallax scrolling, weather effects, and keyframe animation. It is an engine I can’t even run myself these days —let alone put into an online setting.

I spent a long time working mainly with PHP in my professional output, and I learned a lot in dealing with this kind of server-side code. The kind that evaluates and doesn’t retain anything in memory. Those learnings are less relevant to me today, but it was still an interesting journey.

The main thing I recall from the world of PHP was this split love/hate thing. I loved the fact that php.net was a great resource for information, but it had to be, because PHP’s choice over method naming and parameter order was a mess.

Because of PHP’s nature, I also learned a lot about securing API calls at this point. This was the period in my life where nearly everything I built was an online form.

There were A LOT of forms…

As most of my projects continued to be JavaScript focused. My learnings mostly evolved around that, although I did also have secondary streams of learning Python and Bash.

I have specifically been aware each time my coding ability has jumped up. And it has always been down to either a realisation learned from a personal project, or, learning from someone else’s project. There are some key points that I’m sure I share with other coders, mostly thanks to the power of the Internet.

Ever since triggering my first events, simple event listeners in the DOM, I’ve been keen on the simplicity of how events can disconnect systems in a good way to separate concerns. But there has also been a lot of learning of where events work (usually one way communication) and where events cause issues (often, two way communication situations, or things where timing is order crucial). It is still my favourite choice to start with, even if I might perhaps elaborate into something else beyond events later. Mainly because they are so easy to understand.

“The main thing I’ve learned to watch out for with events is that many developers never think about teardown. They are happy to set up events, but use an app for an extended period of time, and you’ll see that the first place to check for memory leaks is event listeners.”

My first foray with the power of selection was clearly jQuery. The fact that the idea of using CSS selection to target elements had escaped me (and many other devs) was something that intrinsically changed my thinking. From that point on I have always been looking for where there are crossovers between technology, essentially where you can get something for free (from something that already exists).

The day I wrote my first integration with Sizzle (not jQuery) was the day I laughed at myself for the countless times I had written the getElementById method in the past.

A second collision with the power of selection, this time with pairing data to a selection was clearly D3. This leveled up my thinking in terms of how you could build things directly from state.

This led to a period in my life where I tried to tie d3 to everything. But I quickly found that, whilst powerful, it did lead to obtuse code unless very carefully dealt with. The idea of pairing data with selection however is still a powerful one, and I use it wherever I can.

I came to streams later than most of the other tech features I know, and I still find them obtuse in places, but they can be perfect for many use-cases. I can’t pinpoint where exactly I started learning about them. But I think it was mostly with my investigation into Node. Lists however have always been with me, from some of my very early projects lists, linked lists, arrays have always been powerful tools that can be used for so much more than just holding values in order.

I once built a game called d-tron, which was a tron clone (with depth), but rather than drawing free lines on a canvas-like world. It involved storing used positions in a massive multidimensional array. Not really the best use of an array, but… it worked.

This was more of a lesson learned in how complexity should be avoided, especially when working in teams of developers. I was given the chance to help build out a company’s marketplace site, replacing their old Ember-powered site, with a React version.

This was in the early days of me taking on the title of “product engineer”, and if I’m perfectly honest, there were a number of requested tasks that went against my usual zeitgeist. There were some implementations that I still disagree with to this day, but… on the other hand, working there definitely changed my thinking —and many approaches —I would never have taken by myself— are those that were recommended to me by that team.

One choice I disagreed with then, and still tend to disagree with, is using a framework to build a website frontend. I only tend to go this route if the client specifies, and in this situation they specified that they wanted a React site.

I understand the draw for a company to use an off-the-shelf system, it helps with hiring and developer’s cognitive adoption, but —as many are finding out these days, it adds a lot of weight to what should otherwise be a lightweight system.

Because I had just been searching around for jobs prior to landing this one, I had been specifically increasing my knowledge in areas of React, Angular, RiotJS, Vue, etc. Because that was what was expected at that point-in-time.

React always seemed over-the-top to me, but I was swayed by two key ideas, having a singular state tree that the entire site reacted to, and the ability to time travel, allowing us to replay a user’s journey through the site. Two very powerful ideas.

Unfortunately, for anyone who knows what it is like to manage a complex React site, I learned a lot of lessons very quickly in this site’s implementation. I followed the then recommended practices, despite my own reticence towards some of the recommendations, which led us to a site that had a number of good bits, but also a number of pitfalls.

One area I very much definitely wish I had done differently, was using Sagas. Whilst Sagas are very powerful as a concept, it is that power (and major difference to how most other JS runs) that caused issues not only for me, but also the rest of the team. Making small changes to that area became tricky, and people needed to switch out their thinking completely (compared to the rest of the site) to understand.

I came away with a number of good ideas after that site however, and how developer cognisance in teams is more important than the power of the system you are building.

I was quite a late comer to realising how powerful automated tests can be. Mostly because I was introduced to the world of unit tests before integration or e2e tests. Unit tests, unless covering a unique or tricky area of functionality, are mostly pointless and a waste of time. Integration tests, and even better —end to end tests— can be complete life-savers. And if you are clever enough to also get these tests covering your production in a live context, they can also keep you aware of live issues.

Once I had been working with a number of production systems in a live context, I began to rely more and more on automated tests to give me confidence —especially when working with a “startup mentality” which typically means needing to release things quickly. But… it became important learning the best way to build these kinds of tests, and that’s an area I’ve vastly improved on over the last decade.

You do have to choose your tests well when writing integration/e2e, because they are more costly to put together. But I also learned that if you can build in a recording system into your tests, one that is able to capture live or staging data when required, that can help a great deal in keeping things up-to-date.

Now, if I were to build any production-based system from scratch, I would definitely start out designing my data stores and code implementation so that it benefits e2e testing. I know there are a number of people who state you shouldn’t code your production logic towards tests (i.e. your production logic should be completely unaware of tests). And whilst I know what they mean, and I would of course avoid having conditional checks in my production logic that reference test information (e.g. if(env === 'test'){...}. What I mean is to design your system so that test data and production data can live side-by-side in the same system, without fear of it leaking to the public. That way, once you’ve spent your time working on these expensive tests, you can then put them to work at almost any environment level (dev, staging, test and production).

“Being pragmatic” is a term that seems to be overused in the startup world. And it was something it took me a long while to understand. I spent a long time believing that I was slow —at least in terms of getting code live (despite being very quick in interpreting and understanding code)— and that I needed to find ways to speed up. But, I then realised that this was wrong, I wasn’t slow, it was an incorrect interpretation of events.

There are those that do “being pragmatic” well, and it is difficult to be consistently pragmatic. To do it well means you have to have a good idea of the bigger picture and the small detail at the same time. Because you need all that information to make the right choices.

But this is where many do not get it right, they only ever see pragmatism as finding the quickest shortcut they can make. This is not correct, being truly pragmatic means that you can sometimes choose the fastest route, and other times you should choose the slower one.

Being pragmatic doesn’t mean ‘move fast and break things’

My learning is that if you only focus on whether or not the code got out the door in X amount of time, then yes, the rushed version of pragmatism seems great.

But… what I learned, and I believe those that worked closely with me also noticed, was that the code I got out the door —albeit slower than some of my counterparts— vary rarely came back to bite me, or anyone else for that matter. My version of being pragmatic, was to make sure things were stable, and nothing to do with speed to release.

And this had an interesting effect, whilst there were teams that spent quite a bit of time fighting fires from previous work, whilst also trying to get new work out the door. Myself, and the team I worked with, rarely did. We were usually free to pick up new work and properly focus on it. And so, after time, I began to realise that my being slower was actually a benefit.

That’s not so say there have never been times when I could have moved a bit faster, perhaps not run certain tests that weren’t likely to fail —but my takeaway is that this kind of speed up shouldn’t be called pragmatism… for me, it was more about increasing confidence that the release wasn’t going to break things. Which I found I could definitely increase when there was more time for building automated tests.

This is possibly one of those things that has only come about due to me getting older, my eyesight getting worse, my brain starting to move through the world with fleeting moments of forgetting on why it was moving somewhere in the first place. I say this, because I used to secretly roll my eyes at people would would complain about my three letter variables, because I knew what those variable names meant.

However, one thing that has been steadily true —and seems true for most developers— is that when they look back at their own old code, they are shocked at how bad it is. You can take this one of two ways:

1. The way humans handle coding is intrinsically bad.
2. Developers are improving all the time.

And… one of the things I really do not like about my very old code is the terrible variable names. Since working at Trouva I have taken on quite verbose, and I’m proud to say, accurate variable and function naming.

Mainly because I found the better I got at this, the easier it was to get people to review PRs (and the easier it was to pick work back up after a while). And as such, there was a very visible and clear feedback that I was getting better at it. Another good test has been, that when I look back at my more-recent-but-still-older code now, I find the variables and function names cause me no problem at all.

This might seem an odd one, and it isn’t something I’ve learned myself as such —I’ve always seen how coding can speed things up. But one thing I have very definitely learned is that you shouldn’t underestimate the power of making a few quick fixes. Those fixes or changes can mean the difference between someone with a repeat task taking days to complete it, or getting it done in minutes after you’ve improved the system.

These kinds of ‘quick changes’ tend to get lost in amongst the sea of upcoming features, bug fixes and technical debt. But sometimes they can be more important than all the above, especially if administration UIs have been left to age and stagnate.

I have made small changes to UI panels that have greatly improved the moral of an entire team of admins, or added a bulk ability quickly to something that had been a mind-numbingly manual process, speeding up the work tenfold.

I think, because development always seems technical to those who do not have the technical know-how, that any change always might be big —or at least it can appear that way. But often people get things round the wrong way. Something they think might take ages, actually doesn’t —and vice versa.

This learning however needs to be tempered. I believe that it is the responsibility of those with the power to do so, to be careful that you don’t end up completely replacing someone’s job. Just because you might be able to fully automate a task, doesn’t mean you should.

For example, the current rush of the-less-than-sensible, to look at replacing numbers of workers with AI —in the name of productivity— is blind and not future-proof. Automations should be there to help people, not replace them. A human in a role will always be better than an AI, especially currently, but even if that AI becomes all-powerful.

This is true for a number of reasons, but the major one is of companies taking responsibility for their effect on society. Which unfortunately, with the likes of Trump and Musk running all-things-American (to take a few examples), is getting fewer and farther between. The more companies act like “darwinistic entities”, the more normal people will lose out. You can still achieve that highly coveted productivity, but with humans properly at the helm and in control.

Thankfully, anyone who thinks they can replace entire teams with AI agents, at the moment, is in for a surprise. They can’t. The illusion might be there for anyone that doesn’t look at the details. But, as any developer knows —the errors, bugs, and lawsuits are in the details.

This is something that there are entire industries around, and for a while, progress seemed to being made towards a better way of hiring. But lately, due to (perhaps pandemics and…) massive conglomerates doing their thing of buying companies up and destroying their uniqueness; things seem to have gone backwards.

I have personally gone through a number of different interview processes, having worked both PAYE and as a contractor, I’ve been headhunted, I’ve been recommended via word-of-mouth, I’ve gone through many interview processes: good and bad.

For my very first interview, I was on the hiring side, rather than being hired —which was interesting. I’ve also done the “whole interview day” process for a good company, and a bad company. I’ve done the usual —and often quite terrible— recruiter processes, and I’ve also gone through very well-designed processes, like the kind Hired.com used to offer (sadly, no more).

My main learning from this is that only you have the power to make people understand what you can bring in a hiring context, you can’t rely on anyone else. Hiring companies that realise this, and give those looking for a job the chance to show off, in their own way, are brilliant!

Unfortunately, because of human momentum, and the race for companies to get ever bigger and take over the world —whatever brilliance or uniqueness they might have started with gets lost in a swirl of bland, careless, number-crunching. And… you are left with having to rely on random recruiters, of which it is pot luck as to whether they even understand you or your business (if you’ve read this far, then, “no, not you”). And let’s not forget the “please submit your cv” style monstrous websites, that typically don’t even have the category “web developer”, and instead lump you into the category of “You use computers, right?”.

You might think it is only that last part that is bad, what does a category matter? but no, “upload your cv???” in this day and age. A single sheet of paper is not going to do anyone any justice whatsoever, and it is ridiculous to think that it ever did. If dating sites can take in a swathe of information, and apply clever calculations and even psychology to find a partner, why on earth do hiring companies do such a bad job?

This is the reason why, every time I come into a hiring situation, I build a website specifically for it. And this is that website. This allows me to rely on LinkedIn more heavily, as people can discover me and work out that I am a fit for their business or client. Hopefully the effort I’ve put in will be understood and I’ll be able to find a good position, within a friendly and intelligent team again.

One last thing to say on hiring (if you aren’t bored already). I have never yet come across a company that did hiring better than the original Trouva. I obviously went through the process on the interviewee side, and became the interviewer whilst there. So much effort was put into two key things: making sure the potential hire was a good culture fit, but also making sure that person wasn’t setting themselves up for failure. We hired people who clearly knew their stuff already, but also people that needed to learn.

My experience was in the product department, and every single person was always a force (or became a force) in whatever they were brought on to be —and the key to that was everyone, everyone (without exception) had respect for everyone else. I worked with a great mix of people, and everyone was keen to do a good job and make sure to help anyone else that needed it. Sadly, those days came to an end, again due to bigger businesses buying things up.

So my other repeat learning from this has been —if I ever get back into owning my own company— is to never grow too big. Find the right middle spot, give people a balanced job and a stable future, and then build brilliant things together. Hopefully this constant drive to be the next fool with too much money will be seen as the fad that it really should be.

Co-location is the practice of putting related lines of code so that they are near to each other. Whilst that might sound obvious, it is actually more difficult to do well than it sounds. if you co-locate everything together, you get no modularity or separations of concerns. But if you separate everything too much, you lose readability and fathomability.

So my learning in this area has been to find out where co-location works, and where it perhaps doesn’t. One of my favourite findings in this regard is to co-locate setup and teardown.

You may already do this to a certain degree. I mean it would take a truly wild-eyed programmer to put their setUp methods somewhere miles away from their tearDowns. Usually, you’ll find those kind of methods right next to each other. However, in certain situations, it isn’t as easy as just placing two class-level methods near each other. Take using setTimeout for example.

In the past I might have written something like:

doSomething() {
    this.tid = setTimeout(() => {
        // trigger something else
        // after a delay
    }, 100);
}

// ... potentially lots of other code

somethingThatNeedsToInterrupt() {
    if (this.tid) {
        clearTimeout(this.tid);
        // trigger the inverse of
        // the setup code
    }
}

This is all fine, but methods like somethingThatNeedsToInterrupt can be spread all over the place, meaning that your code isn’t co-located.

You can get around this by creating specifically named handlers/methods for the timeout callbacks, e.g. onTimeout and onTimeoutClear. And sometimes that can be preferable (as long as they are near each other in the source).

But… if you’d prefer to keep your callbacks anonymous and temporary, you can do something like this:

doSomething() {
    this.doSomethingTearDown?.();

    const tid = setTimeout(() => {
        // trigger something else
        // after a delay
    }, 100);

    this.doSomethingTearDown = () => {
        this.doSomethingTearDown = null;
        clearTimeout(tid);
        // trigger the inverse of
        // the setup code
    };
}

A variant of this might just return the tearDown, rather than attach it to this, it depends on your style and what you are doing.

But… either way, when you need the interrupt handling, you can just call this.doSomethingTearDown?.(). The benefit of doing this is that both bits of code are co-located.

When someone adds something new to the set-up, it becomes much easier/clearer that something needs to be added to the teardown. It also means you can avoid capturing temporary variables like tid in a more permanent manner (just to deal with the clearing).

It is a simple learning, but has seriously improved being able to find this kind of related code, and keep it up-to-date. Another place this works well is when setting up events:

doSomething() {
    this.doSomethingTearDown?.();

    const onClick = () => {
        // do something on click
    };

    this.addEventListener('click', onClick);

    this.doSomethingTearDown = () => {
        this.doSomethingTearDown = null;
        this.removeEventLisener('click', onClick);
    };
}

This is great for places where you might create a number of event listeners (perhaps on multiple descendants). It keeps the listener references caught in closure, rather than exposed and attached to the main context. And… it keeps the setup and teardown right next to each other, without any risk that someone might put a method or other code between.

The whole while I was growing up (I did, trust me), I was constantly told, by many sources, not to leave things late. Doing things early and you get ahead of the curve. And that is very true, but only in specific contexts. It is, for example, definitely better to file your tax return before Christmas —and if we’re being specific, definitely better to have filed it before Christmas of 2021.

In tech however, I’ve found that holding off on certain things is definitely the best strategy. Oh, and before you start telling me this is obvious —A, B, and C all state that delaying X, Y or Z makes fiscal, temporal, perceptual or even geospatial sense (not standing back up too early under an open cupboard door for example). You have to keep in mind I probably haven’t read A, or followed B, or gone to university with C. It wouldn’t even matter if I had, because my brain is very definitely predisposed towards being an empiricist. It has to experience X, Y or Z first-hand, mainly so that it knows what makes them tick, and… so that it knows what to do if they ever decide to break and stop being functional letters of the alphabet.

My head worries about such things, you see.

Leveraging infrastructure is definitely one of those cases.

Do not bring shiny extra or new infrastructure into play before it is absolutely necessary. Try everything you can first, to avoid such things.

But… there is a caveat, don’t box yourself in, so you can’t bring those nice shiny new things later, perhaps after everything else has failed.

The reason for this, put simply, is that the more of the rest of everything else you have built —if you have done it well— makes it easier and easier to slot in the infra at the end. If you build in a future-guessing manner, you very likely won’t do it very well.

This hasn’t been a learning from my professional work really. Because in professional terms, I’ve always been avoiding adding complexity in infra as much as possible —because infra, when someone else is paying, makes me nervous. Especially cloud-base infra, because it seems that money does grow on clouds.

It makes me nervous when I’m paying too, but usually for different reasons.

I’ve learned what I’ve learned from my personal projects because if you introduce too much complexity (a.k.a. things that slow you down) early on, the project collapses. It wouldn’t, if you had all your time to spend on it. But for personal work, you never do.

So these days I’m extremely careful with whatever I decide to add to a project, and usually that starts at the point I think I need a database.

I will do just about everything I can to keep things memory resident, for as long as possible. This allows you to build out structures, change them quickly, reset the server, clear out information, all at the speed you can code. As soon as you start to formalise schema and other things, is when you start to cause yourself headaches. Which surprisingly (or not, if you know me) is my main argument against TypeScript. It is best to be as flexible as possible when you start, like working with hot metal, and then —later on, when things start to solidify— you can start adding your formal schemas or types, etc.

Some people may disagree with me.

But I’ve seen the evidence in my own projects. The ones where I could stay fluid are the ones that finally made it.