Skip to main content

Hi! My name is John Slipper.

I do product management & frontend development in Auckland, New Zealand.

A Reflection on 3 Years of Product Development

Wall of dense JavaScript code on a screen that blurs out at the edges

Photo by Markus Spiske

After 5 years creating static and content managed sites for a creative agency I started a new job developing a JavaScript application within a startup. That was 3 years ago.

I used the term “product development” in the title as although I was hired as a JavaScript developer, in a small but quickly growing startup it pays to be flexible.

A lot has changed over the last 3 years so I thought it time that I wrote a few things down mostly for my own record and see if I’ll agree with myself in another 3 years.

Learning on your feet: A great asset

I had some experience in JavaScript frameworks but it quickly became clear that there was a lot more I needed to learn to do it at the level required. Having the confidence to get stuck in with the knowledge that making mistakes is a healthy learning experience and you will improve as you go helped me get going.

Initial choices: Matter more than you realise

When time is pressured it can be to jump at the first solutions you find. The consequences of hasty choices may not however reveal themselves until much later on.

A good idea is to factor in some time initially to think on a problem from a wider perspective to try and see potential problems down the road.

Easy to say now with hindsight of course, but it’s a lot easier to change before things grow, especially when it comes to technical debt.

Tech choices and people: Choose based on your strengths

When it comes to technology, especially with JavaScript frameworks you can easily search “X” vs “Y” and find opinions for why both of them are both great and terrible. While this kind of discovery can reveal some useful insights, it’s likely that many options can be used to achieve a solution. Spending some time actually using a technology is a great indicator.

When you have a few possibilities the most important question then is which one works best with the team you have, or are aiming to have. There’s no point in using something new and shiny if you can’t be productive quickly with it or find anyone with existing experience in it.

Adaptation and iteration: Things will change quickly

Where you start may not end up being the same place you find yourself a year later. It’s important to adapt to new situations and be prepared to rewrite as well as iterating. All work is potentially disposable so getting things 100% perfect should not be a priority in the early days as long as it fundamental achieves its goal.

Managing technical debt: The first step is admitting you have a problem

With great change comes great …problems. Along with the new there is always the burden of the old to some extent and attempting to ignore it only makes it more angry. Trying to incrementally improve the biggest irritations will likely pay off more than you realise and better than building yourself into a corner.

Scaling into chaos: Everything is easy until it’s not

Roles and responsibilities are less important in small teams, but quickly become important as you grow. Scaling, even if linear in resources is not in the resulting complexity, and as such require more robust processes and system to ensure productivity.

The more you make the more to maintain: Planning can only ever be more important

A product brimming with features is a product with lots of moving parts. Making changes can now impact in many more places and as such, good planning is essential.

Part of this planning is to ensure that additional features not only work with the existing ones, but also worth creating in the first place. Remember those people paying the bills that you built it for in the first place? Might be worth seeing how they’re doing.