This post is just a brain dump of different bits and pieces that I have worked on over the course of my career. I will risk showing myself as being some sort of dinosaur by starting out with some of my hobby coding at university way back in the 90s.
The Internet was a novelty in the mid-nineties
The Internet was just starting to become a thing that the public could get access to when I was part way through my university studies in the mid nineties.
Mosaic was the first browser that included the capability of displaying images, so I suppose we could compare this with when films transitioned to include audio.
When Windows 95 first came out it didn’t include a web browser.
I just rememberd something that gives a solid indication of how much things have changed, back in the mid-nineties there was a firm distinction between international and domestic Internet traffic. If you tried to access a site that was outside of New Zealand from the uni network, you would be prompted to enter your credentials and be charged per megabyte.
Here we are thirty years later and people complain if their mobile phone switches to a slower data rate because they’ve been streaming too many sporting events with video feed so far this month.
I got interested in HTML
I was curious about how the world wide web worked, so I taught myself about HTML. Those were the days before cascading style sheets (CSS) were properly supported so achieving layouts involved clumsy arrangements of nested tables.
An old school friend who had moved to the UK a few years earlier made contact via email, which resulted in becoming aware of GeoCities, so I had my own page there – complete with the “Under Construction” road sign graphic that the kids of today have probably never seen.
CGI scripts
Static content is a bit dull, so I did some digging around and realised that I could create scripts under my home directory in the computer science department and have them execute and generate some dynamic content as a web page. It didn’t get particularly sophisticated, maybe selecting an image in a directory at random for display on the page.
Looking back now, I can see a potential explanation for my less-than-amazing grades for my undergraduate uni courses back then. While none of this muddling around contributed to course work, it probably gave me a bit of a head start in the workforce.
The early 2000s – Client Side JavaScript
After uni I didn’t think that my grades would be good enough to get a decent job, so I decided that I would take another year to study for a Postgraduate Diploma. That plan didn’t quite work out – in a good way – as I ended up getting a full time job when I thought that I was interviewing for a part time job.
The projects that I worked on for my job gave me practical experience of the pain involved in producing web pages that would look consistent across different web browsers. This was before mobile devices were even a thing, so we weren’t even getting into responsive design back then – just “Why doesn’t this work in IE?”.
One of our main long term clients was a snow sports website that enabled ski field operators to log in and update the status of their facilities. The Snow Report Wizard was my first involvement with slightly complex client side Javascript. Netscape and Internet Explorer were the main web browsers and they had some subtly different ways of interpreting some commonly used JavaScript expressions. At one point some urgent modifications made parts of the system require “Only works on this browser” (I can’t remember which one).
Desktop Java – Swing and AWT
Further into the 2000s I got more involved in desktop applications, so I was dealing more with Java Swing GUI components than HTML.
At risk of traumatising people by triggering old memories, a few aspects of Java UI work back in Java 1.2 got interesting:
- GridBagLayout
- Swing worker threads
- Memory management (or mismanagement)
Selenium for testing
In our Java code we were applying test driven development and keeping unit tests and integration tests in place to prevent regression. It made sense to have something in place to automate testing of our web pages as well.
We started small, then expanded gradually, then ultimately included a grid to run in the continuous integration build server.
At the time it felt a bit painful when a regression got caught, but it was always better that way than hearing about it from a client after a production release.
Versioning of static resources
One good thing about setting up websites with a lot of daily active users is that you can rely on browsers to cache the static resources, including CSS and JavaScript files.
One bad thing about setting up websites with a lot of daily active users is that you can rely on browsers to cache the static resources, including CSS and JavaScript files…
Since we cannot control when and how browsers will re-request the CSS and JavaScript files, I learnt to apply a simple approach to change the name of the underlying resources so that the browsers will treat them as new and not be left with stale formatting or scripts. This works best when a templating system is in place for specifying the resource name, so we don’t have to find and replace in multiple files to achieve the change.
CanIUse
Once in a while I come across a website that becomes my main reference for dealing with particular types of problem. CanIUse is one such site, saving hours if not days of struggling to produce something that will work for all browsers that we have committed to our clients to be compatible for.
I think I was living in the UK when I first heard about this, so I was in more of an overseer role as the tech lead of a team that included specialist for the front end.
Hello jQuery
Around 2011 I was working on a project where the customer facing UI was being developed as and iPad app by a third party company. I was getting frustrated that there had been one or two occasions where our back end team had missed a subtle requirement in our API design, so I paired up with a teammate to try out dogfooding our REST API with some minimal HTML and JavaScript. This was my first direct exposure to jQuery, that abstracted away the browser incompatibility issues, making it possible to focus on the core intended functionality.
I was a bit nervous about showing the dogfooding code to the rest of the team, as this was a slight tangent from feature development work, but they really liked it. Over the next few weeks the dogfooding code extended further and further, catching one or two sneaky gaps in the API design along the way.
(Shout out to Felix, if you’re reading this – that was a great little pairing session when we both learned useful tidbits).
Node.js
I think that I first heard about server side JavaScript at an eXtreme Tuesday Club meetup in central London. I was a bit Java focussed back then, so I didn’t pay much attention at the time.
Fast forward to about 2015, I was working for one of the biggest publishers of scientific journals in the world – basically every university you have ever heard of will have some contract with them to have access. Node was already proven as a great technology for the server side of content delivery, so the main development teams all attended a few days of training about the fundamentals of Node.
I think one of the main advantages of Node over Java for web apps was that Java had been tied to the servlet model, which had historically involved a thread per request – which doesnt scale well.
I didn’t have much need to get into developing in Node as my team’s services were focussed on asynchronous processing of event data, or parsing XML for generating documents.
As an aside, one thing that stood out as odd to me from the training was the expectation that dependencies should default to picking up the latest available version. Looking back from now (May 2026) that seems like a risk from a security perspective, so I wouldn’t see my self jumping to apply that approach today.
A couple of years later I spent a day or two setting up a redirection feature in the topic pages front end microservice, but let’s not count HTTP routing as being front-endy.
GraphQL
One of the core services for presenting information about accounts in Atlassian’s AdminHub involves a GraphQL interface that is served via Node.js (maybe Apollo?)
When my team needed to extend the API to support an additional permission state, I updated some existing code and added fresh tests to keep everything up to date.
Blogs
This year (2026) I have established this blog on a hosted WordPress system as an alternative to Blogger, because the mobile-first approach that Google’s indexing system applies made my old Blogger hosted blogs invisible to Google.
I have analytics and / or logging in place for measuring how much attention the posts get (it ain’t much), plus a bit of setup for seeing how Google and Bing are getting on with sitemaps and indexing.
I’m a bit frustrated by all of the “Upgrade now” prompts and the number of clicks that I have to go through every time that I want to add a post on this site, so I may yet resort to setting my own virtual server for hosting my blog posts in the future.
So, What’s Next?
I’m on the lookout for my next job or contract at the moment. Back end Java work seems to mainly be associated with companies that I perceive as being likely to have a re-org involvign redundancies due to AI, so I expect that I will need to make a pivot to applying my skills and experience in other areas – one direction might involve front end or “full stack”.
I used to describe myself as a “Web Developer” so let’s see what the future holds.
Leave a Reply