Harry Winser.com

To do more, do less

I’m not quite sure where this adage came from, but it’s become something I now live work by.

Let me explain.

5 years ago I joined Edozo, which is a start up focused on Commercial Property technology. I’d never worked for a start up before, but coming from Rightmove it was a fairly big shock. Suddenly gone were all of the guard rails. Code quality, deployments, infrastructure etc. were all things I needed to really focus on and align. But the biggest thing; Work Management. Gone were the well ordered Planning Sessions. The multiple teams breaking down a large task and sharing it. Gone was the deployment platform and multiple Tech Leads to bounce concepts off of.

On top of this, I was thrown into a world where the work I was doing would have a direct impact on sales conversations, and ultimately revenue. Feedback was fast. That’s not to say the work I did at Rightmove didn’t effect real users, but it was certainly more removed than what I see at Edozo.

Those working for a small start up like this will know exactly what I mean.

What’s very easy in these situations is to get your “wheels” jammed. Though, some might say “wheels spinning”. There are so many needs; from potential/new/old customers, to maintaining infra, to smaller bits like keeping Java/Node up-to-date. It’s a lot. And when all of that falls onto a single 5 person team, Work Management becomes incredibly important. Get this wrong, and you and your team can be crushed.

So relatively early on, I started to say this in meetings:

“To do more, we need to do less”.

But what does this mean? Ultimately, it means you need to look at what your team can achieve and prioritise. Once you’ve picked what you’re doing, methodically work through it. One item at a time. Avoid doing it all at the same time. Get the dopamine hit of actually finishing something. That feeling will get you through the next thing that needs doing. And the next.

I’m not saying as a team you can have only one thing in flight. It’s more about being aware of the teams capacity, and those the team relies on. If you find yourself in more meetings than actually doing work, maybe “do less”.

You may of heard the term “Stop starting, start finishing” - this links perfectly with the above.

With this in mind, I should probably share the set up of the team; we have five full time developers. We build/maintain four products, multiple backend services to power them, and a load of data + ingestion. For a team of five, with some DevOps and a product manager / owner, that’s quite a lot. If you don’t believe me, here’s our release blog showing that our “wheels” aren’t jammed.

One day I’ll share my full journey at Edozo, and how we introduced Continuous Delivery, Open Telemetry, Docker, and more.

But first, I want to finish and post this. Because to do more, do less.

Over the last few months, I’ve moved more into the JavaScript / TypeScript realm at Edozo. This has been exciting for me, as it’s the first time I’ve written production, user facing, JavaScript code in “anger”. Sure, I’ve written code for loads of developers when I was at Rightmove, from Groovy, to Bash, to even a little bit of Kotlin. But for the most part, my core has been Java and writing code serverside.

With that in mind, I thought I’d start a new semi-regular column called “This week in JavaScript”, where I share some of the interesting things I’ve found.

So, without further ado…

Date() in JavaScript is not friendly

Dates are not nice to work with in JavaScript. The core library was written based on the very early implementation of Java. Which since then Java has rewritten its Date implementation twice. So essentially JS developers are working with something designed 30 years ago… Ouch. With that in mind, I thought I’d share three interesting things that you might not know about Dates in JS.

1. Months start at 0

This is actually quite common across older languages. I found both C and C++ does this, as well as the original Java date Implementation. When using date.getMonth() you’ll get 0 for January, 1 for February, and so on. Which can be a little confusing. It also leads to code like:

const givenMonthFromUserInput = 12; // where they've inputted December

new Date().setMonth(givenMonthFromUserInput - 1)

Which can seem a little wonky.

More modern languages like Rust, C#, GO, and now Java, all start at 1. Which is a fair bit more human readable

2. date.setMonth() is “dangerous”

Ok, so dangerous might be a little strong, but oh boy did this surprise me this week. I think I’ll need an example.

You’ve been given a date for November, broken down into an array; [23,11,2024] So, you might do:

const given = [21, 11, 2024];
const date = new Date();
date.setDate(given[0]);
date.setMonth(given[1] - 1);
date.setFullYear(given[2]);

// expected
// 2024-11-21T17:15:57.213Z (with the current time attached)

Which is exactly how I thought I would work. And it mostly does, except on specific days.

Lets say today is the 31st of January. In the documentation for .setMonth() is an extra parameter. Here’s it from MDN :

monthValue
	An integer representing the month: 0 for January, 1 for February, and so on.
 dateValue (Optional)
	 An integer from 1 to 31 representing the day of the month.

That Optional dateValue is the problem here. It has a weird little side effect where if you don’t provide it, it’ll use todays date. Lets take a look at the above example again:

// Remember, "today" is the 31st of January
const given = [21, 11, 2024];
const date = new Date();
date.setDate(given[0]);
date.setMonth(given[1] - 1);
date.setFullYear(given[2]);

// actual
// 2024-12-21T17:15:57.213Z - The month now states DECEMBER!

2024-12-21 - December? huh?!

Why is this? Well, if you don’t provide a dateValue, it will use todays date (which in this scenario, is the 31st). But there isn’t 31 days in November, so JS decides to roll over to the next Month. And Tada! You’ve now got December.

This is actually true for all date stuff in JS. Setting a month to 15 for example will actually roll the year over.

Something to watch out for, if you’re ever building dates.

3. Date Libraries & The Future

Of course, there are hundreds of blogposts complaining about JavaScripts Date. It’s well known source of pain. So of course there are libraries out there that will help you handle these quirks. A quick Google Duck Duck Go usually pops up with Moment.js, however this seems to be in maintenance mode and is also little “chunky”. So while it’s well talked about, it might no longer be an appropriate library for your needs. If you’re more familiar with Java LocalDateTime, it might be worth looking at js-joda. It’s API’s are very similar to what was introduced in Java 8. Though if you’re a pure JS dev, this might not be much of a bonus.

Then there’s the new Temporal implementation coming. This is baked into the language, and is slowly being shipped with browsers. While it’s probably going to be a few years before it becomes ubiquitous, its exciting that after 30 years JS is catching up with the times. Oh, and months start at 1 in Temporal 👍.

Last September I purchased a Macbook Air M3, to replace my incredibly old 2013 Intel i5 MacBook Pro. It had been a trusted companion, but it was time to put it out to pasture. On top of that, I’d started to feel the desire to code and make fun silly projects (ED. which eventually lead to building thoughtstream.me & geo.harrywinser.com ). So, after some prompting from my partner, I decided to pull the lever and buy a second hand one.

I should also disclose that I work on a MacBook Pro 2019 (it sucks), and have worked with MacOS for years. MacOS is something I’ve very familiar with. If you’re looking for “Should i jump from Windows”, you won’t get that opinion in this piece.

What did i buy?

So, I bought my laptop from CEX (which is a second hand online platform here in the UK). It’s the 2024 M3 Air, with 16GB of RAM and 500Gb disk. All of this is a big step up from my old i3 Macbook which had 8GB, i3, and 120Gb disk.

What I like

Lets dive into what I liked; the hardware. Pretty well known with Apple; they make good stuff. This is no exception. The keyboard is lovely with the right amount of travel. The form factor and weight is just prefect; feels sturdy without feeling heavy. If i could design the perfect form factor for a laptop, I think this would be it (or damn well close enough to).

It’s more squared design compared to the old wedge shape of old, which does make it feel bigger. It’s probably closer to the MacBook Pro 2019 in size. But it’s much lighter, and I’ve carried it around all day in a bag on my shoulder without noticing.

This new Air doesn’t have any fans. This sounds like a cool brag, but I have my worries. I made my purchase in September, which traditionally isn’t the hottest month, so I’ve yet to test how well the lack of fans will pan out. I can say however that my work provided 2019 MacBook Pro does become horridly hot during the summer (or a warm office), and the keyboard becomes near unusable. I previously had no knowledge of “sweaty wrists”, of which I’m now very familiar. So until I’ve used the Air during the heat of summer, I can’t give the fanless aspect a free pass. Nor do I know how it’ll hold up in 3 years time when standard software is more demanding.

One final item; they’ve gotten rid of the touch bar. What a piece of junk that was, and I’m glad it’s gone.

There’s nothing like a good blaster esc key by your side.

What I don’t like

From a hardware perspective, the black feet that sit on the underside just look a bit naff. They’re sturdy, and I don’t expect them to fall off anytime soon. But compared to how pretty everything else is, they don’t really fit in.

As for the notch at the top of the screen; eh. I would prefer it without, but i does “disappear” from your sight pretty soon.

MacOS

MacOS, sits within the “Don’t Like” category. I’ve used MacOS for years. In fact, it supplanted Windows for me in around 2018. However, it’s got some weird design decisions. Here’s a short list of what I dislike:

• Window management is confusing and broken - it still doesn’t really work
• The “Settings” are a confusing mess. For example:
  • Setting your account image, needing to both set your local and iCloud account separately
  • There’s now a long bar of options down the side, that is far too overwhelming. Why is Desktop separate from Wallpaper?
• Some UI/UX aspects feel around 15 years old
  • looking at the info for a file looks archaic These are just a few gripes I have, and it forever fustrates me as to how little they add to MacOS, and instead just add random junk.

Round up

Lets get to the point; if you’re on the fence - it’s a hard yes from me. This is an excellent machine, and one I’ve gotten constant joy out of from the last few months.

As for if you should get the 13’ or the 15’ - that I can’t answer. I can say that the 13’ to me is the right form factor to power ratio that just works for me. I can huck it into a bag, and know that I’ve got all the processing power, screen space, and battery I need.

To sum up; I’m incredibly glad of my purchase so far. I’ll probably write another post in a few years outline how well it’s aged, but I’m hoping it’ll be good.

I currently own and ride a Moto Guzzi V7 Stone - the 2021 model in burnt orange. And it brings me so much joy. I love the way it looks, feels, and corners. It’s a great all round bike; solid for highways, sneaking through traffic, carving switch backs, and having a burst of power on tap. It’s a fantastic first Big Bike, and one I plan to keep for a very long time.

A bit about my history as a rider; I got into motorcycling towards the end of the first UK lockdown - so late 2020. I took my CBT*, and got myself a Lexmoto Tempest GT which looked and sounded the part but was utterly terrible. Honestly I’m surprised I didn’t hurt myself on that; the tires alone were essentially slick and useless in the rain.

It was around this time I saw that Moto Guzzi were releasing their next iteration of the v7 Stone, with a 850cc engine (they call it a V7 for historical reasons), and came in burnt orange. Instantly, I knew it was the one. It was like that scene from Waynes World - “Oh yes, it will be mine”..

So, I started saving and I learning.

Late 2021, I put my money down. I hadn’t passed my test yet, but I knew I didn’t want to wait. I booked my test, in the blind hope I’d pass first time. As fate would have it, I did. And within a few days I was riding the V7.

And I’ve not looked back. I’ve traveled to London a few times, around Devon and Cornwall, as well as to France. This year (2025), I plan to ride to Lake Como, to where it was originally built (more on this in a future post I reckon).

Thanks for indulging me in this little post about my V7. It brings me much joy, and I look forward to the many adventures to be had with it over the coming years.

*for those unfamiliar it’s a days riding course which allows you to ride up to 125cc, roughly 10HP

I love programming.

I still do, 10 years in.

Those who follow me on Mastodon know I love to complain about code and tech, but they should also know that I only complain because of my love for it.

I love throwing myself at a problem over and over. I love the feel of typing on a keyboard. I love finding the random post on StackOverflow that is the exact issue I have, and discovering I’m not alone. I love attending meet-ups and finding so many people as passionate as I am.

There are so many aspects to love about programming.

With that in mind, this post as a sort of love letter to Java. Java was and still is the language I’ve made a career out of. Java has enabled me to travel, talk at conferences and meetups, rent flats, eat out, buy gifts, buy a house, and generally enjoy living.

This blog is also for those who wonder why people still love Java in 2025. Why it’s still one of the most used languages, and why it’s probably not going to go anywhere for a fair while.

1. Consistency & Stability

Java is a stunningly consistent language and ecosystem. The developers of it care deeply about not making breaking changes, and ensuring that folks can easily upgrade between versions. It’s “slow” to make big changes.

Let look at the build systems, which have been around for a long while now. The two main build systems are old. Maven is almost 21 years old and Gradle is 16 years old. With age comes consistency and stability. Oh and libraries are pretty most always hosted on Maven Central, and have been for years.

With this level of stability and consistency tutorials can remain relevant for years. You can read a tutorial from 2015, and it’ll probably still work today.

Libraries and Frameworks have also been around for a while too, which means there are loads of documentation. And because they’ve all been widely used, it’s likely others will have run into issues before you get to them and will have been fixed.

That’s not to say Java doesn’t change. A lesser known fact is that a new version of Java is released every six months. Every March and September. Any feature that’s ready to be shipped gets shipped. Gone are the days of massive releases like Java 8, which added a load of very useful stuff but a fair bit of stress when updating from Java 7.

When writing a complex system that needs to be maintained for years to come, you can’t go wrong with Java. Stability and consistency matter, and shouldn’t be overlooked because of a “new hotness”.

2. Speed & Compatibility

Java got a lot of flack in the late 90’s and 00’s for being slow. And it certainly deserved it. But since then, it has done a lot to be fast.

Like, really fast.

The JVM, which it runs on (as do other languages), powers a fair number of search engines. Elasticsearch is written in Java. So is Hadoop, which can deal with petabytes worth of data. Then there’s also the companies like Uber, Netflix, and Amazon, that run Java for their major systems. Amazon even releases their own JDK, which it tweaks for internal use.

Java can also be customised for its environment, specifying how much memory it uses and CPU. Standard stuff, but you can decide on what sort of Garbage Collection you’d like to use, as well as how the memory is partitioned between different heaps. This means you can tailor (or really screw up) how it runs depending on your needs.

It also runs everywhere. Set top boxes, personal computers, phones, serverless, Raspberry PI’s, ARM computers. Wherever it’s needed, Java is there. So many JVM and Java ports exist, it’s awesome. Do all of these work well? No. But if you want to run Java, you pretty much can.

Quick side note; you totally can run AWS Java Lambdas. But should you? That’s up to you, as it is slower to boot, and it is a more verbose language to write very small functions. That’ll be down to your needs and is out of scope of this post.

3. Libraires & Specifications

I know I’ve touched on Libraries in point 1. however I feel it’s worth it’s own section. There are a tonne of libraries for Java, and a lot of them battle tested.

Spring & Spring Boot deserve a mention, for powering a lot of web servers the world over. And these are free! And because they’re so widely used, there are lots of people improving them, teaching them, and writing about them. There are also loads of libraries built on top of these frameworks, enabling access to AWS services or introducing new paradigms like async/await (Reactive Programming).

Java also comes with a load of specifications, which library builders can use to interface with other tech. Accessing databases for example is specified via the JDBC API. Meanwhile, working with web applications can be done via the Serverlet specification. Just for clarity, I don’t recommend working directly with either of these specifications. They’re for low level interactions, and instead I recommend using libraries built on top, like Tomcat. Which loops back to an earlier point - tried and true libraries exist for the all the standard stuff, enabling you to build.

With Java, these specifications enable libraries to talk to each other, and build on each other. A shared understanding of whats available. This is awesome, in a world where a lot of folks don’t like talking or working together. Though it’s not always perfect (I’ve spent a fair few hours debugging when they don’t line up), it’s great when it does work and means you can focus on your Job instead of writing code to access a database (unless that is your job).

In summary, I love Java. It’s gotten me through some difficult problems, and has been a stalwart companion. I do think Kotlin is a solid alternative if you want something a little less verbose and is null safe. When picking Java for a new project you can rest easy knowing that the community is strong, the libraries are numerous and well cared for, and it’ll still be there for you tomorrow.