Fresh posts about experiences developing and maintaining microservices

In March 2026 I got caught up in the 10% workforce reduction by Atlassian.

I am not taking it personally as I have seen that a lot of other very experienced and well regarded individuals have also been posting their new status on LinkedIn.

As I was the last one to join a team of more than 10 developers I can see how some metrics would have zoomed in on me as a suitable sacrificial lamb to attempt to satisfy investors that Atlassian was actively shifting to focus on profitability. Ironically, I was encouraging the team to move to smaller stories as I had recognised that flow of Jira tickets would be a metric of team productivity.

I did find it a bit offensive that the announcement implied that the individuals being dropped from the company were somehow not seen as able to adapt to the new direction, as from my personal experience none of my managers or colleagues were consulted and I was more active in applying AI than some colleagues. I can empathise more with the former colleagues who got caught up in the previous layoffs now.

Anyway, while I have some time on my hands I will be posting a few experiences from my time at Atlassian and other companies onto my main blog. Some posts will be intentionally vague, but should provide enough context to teach about the importance of attention to detail - something that will continue to be valuable with or without AI. 

New Country, new domain name, new blog

Now that I have moved back to New Zealand, it makes sense for me to switch over to having a "dot en zed" domain name - like I have the "dot london" domain for this blog.

Domain name management has changed a bit since I left, so instead of having to decide whether I'm a ".co.nz" or ".org.nz" or something similar, I can just go for a top level ".nz".  My name of choice this time around is "sounie.nz".

The new blog can be found at blog.sounie.nz and is likely to become the main platform for my updates from now forward. If you get tired of seeing fresh posts there, don't worry I will most likely ease off once I start into a new job.

(PS: technically it's old country for me, but that didn't feel snappy enough to go in the title).

How to test Spring's Transactional behaviour

Introduction

In order to properly test the behaviour of the software that we develop using frameworks such as Spring,  we need to run our code with the framework code and configuration in place.

A recent situation that I wanted to verify as working correctly involved a data access component which relied on Spring to rollback the underlying database transaction if an exception had occurred.

Level 1 - Unit testing

We could unit test the class by creating an instance of it and passing in mock collaborators to trigger exceptions, but that would silently ignore the @Transactional annotation, since the annotation is effectively just metadata for the relevant Spring logic to detect and wrap logic around.

@Test

void throwException() {

   Foo foo = new Foo("xyz", "Unit test example foo.");

   FooDAO fooDAO = new FooDAO(someMockConnection);

   try {

     fooDAO.updateFoo(foo);

     fail("Excepted exception to have been thrown");

  } catch (MyAppDataAccessException exception) {

    assertThat(exception.getMessage()).isEqualTo("Foo with id 'xyz' does not exist to be updated.");

  }

}

Level 2 - Component testing

Slice testing

- Have the test include part of the framework to create the component so that the framework will introduce the appropriate logic (extending or wrapping the object with a proxy for transaction handling).

Level 3 - Testing component within the app

To ensure that the layers all fit together in the way that we expect them to we can run the full application, using locally provisioned resources - e.g. with TestContainers providing a real database server.

There are some situations that can only be reached if another user or system happens to be interacting with the same data that we are operating on.  In my case the data was read in as part of validation prior to attempting to apply the database updates, so if the database representation didn't match at the start of processing then validation would fail and no update call would be made.

As an initial approach I have introduced a component into the test codebase which will be included as part of the running application.  It implements the validation interface with a behaviour combination of delaying processing before calling through to a delegate - in this case the real validation component.

The move back to New Zealand

The new flat

By August 2021 I was in a different flat and working from home on a fulltime basis.  There were some good and bad aspects of the new place:

Good:

 - Very limited shared living areas, so minimal risk of catching Covid if one of the new housemates got it

 - My bedroom overlooked a quiet(ish) garden area, and the flat was on a quieter side street

Bad:

 - Maintenance works that I was home for, including installation of a new boiler and clearing of existing radiators

 - Being home for deliveries - including a fridge freezer that the delivery guys weren't keen to lug up the narrow staircase

 - Long running complaints about noise from downstairs neighbours carried the potential for having to be significantly disrupted by installation of under floor soundproofing

Another lockdown

After a couple of months of being able to go out and meet with a very limited number of people "support bubble" to keep me sane, another UK lockdown followed including the cancellation of my very limited plans for Christmas.

Several months later the UK lockdown restrictions eased again.  Around this time I started to evaluate timelines and notice periods and the scarcity of places in New Zealand's Managed Isolation and Quarantine (MIQ) system.

Timing and luck

Because I needed to give 12 weeks notice for resigning from my job I would only look at the furthest future available dates in MIQ, as those timelines typically only showed the next three months or so of availability.

Sometime in May my employer's bonus announcement came through, so I set myself a timeline of resigning shortly after the bonus payment had made it into my bank account.  Around this time I was also fortunate to find that MIQ spaces for August had opened up, so I managed to reserve my MIQ stay from the last day of August and promptly booked a one way flight from London to Christchurch.

After serving out the notice period at my job I ended up with four weeks or so to finish organising my move - packing boxes and offloading things.

Avoiding Covid

I had hoped to enjoy some long walks around London on my own for the last couple of weeks - keeping isolated to reduce the risk of catching Covid, but then my knee decided that it had other ideas that involved leaving me unable to walk due to a minor injury that I had picked up almost exactly a year earlier.  I didn't want to risk picking up Covid from a visit to a doctor or MRI scanning place, so I spent a lot of time lying down and bought myself some crutches for the limited excursions out of the flat.

My first ever Covid test was the one that I had to book in for shortly prior to my flight home.  I was bricking it!  If that result came through as carrying the illness then I would have a few problems:

 - Nowhere to live, and no clarity around where in London would accept someone who is known to be carrying Covid-19

 - No source of income

 - No timeline for when I might next be able to attempt to travel to New Zealand (MIQ spaces were then an extremely sought after and scarce resource)

The flight home

The PCR test came back as negative for Covid-19, so the final requirement for being allowed onto the flight was in place.

On the first leg of the two hop journey I had a row of seats to myself, on the second flight I had almost an entire section of the aircraft to myself.  I'm curious whether the government may be subsidising the airlines to maintain the service, or if they are carrying more unaccompanied baggage than usual to make up for the lack of passengers.

Getting to MIQ

I used to live in Christchurch, so I had some ideas around the locations of hotels.  When the bus driver said it would be about a 20 minute ride to the MIQ facility I was relieved to realise that I wouldn't be stuck out in one of the hotels close to the airport.  I checked over the list of other possibilities and recalled that my old friends in the hospitality industry used to say nice things about Chateau on The Park...   I can confirm that it is a nice spot - I'm feeling comfortable, as I write this with my balcony doors open overlooking the exercise area in the Spring sunshine.

On the first night I couldn't sleep properly, so I went online to check the availability of online grocery orders.  The following afternoon I had a bunch of paper bags outside my door, filled with the goodies that I had ordered.

Less is More

This post shares a title with a little article that a university classmate authored a couple of decades ago - back before blogging was a thing, so the platform that hosted it no longer exists - so you’ll just have to take my word for that.

The article was a comparison of two commonly used unix shell commands that are commonly used for viewing the content of a text file one page or buffer at a time.  The gist was that the “less” command offered greater functionality than the “more” command.

Evidently the same phrase also has a more widely known history for architecture and design being more impactful when there is less complexity or clutter.

People use social media for different purposes, and with different expectations of how to interact. One such example that I was not directly involved in, but found to be particularly strange, was when someone who holds himself up as a community leader became abusive because somebody had commented on their completely public post on Twitter, responding that it was as if he had been interrupted by a stranger while talking with his mates in a pub.

So, I should have known better than to chime in with “Less is more” on another individual’s tweet after having listened to a podcast that had included them as a guest.

Makes me wonder whether anybody that I have blocked on Twitter has taken it personally.  I very much doubt it.

The Return to London After Spending Lockdown in New Zealand

Whenever possible I try to minimize the amount of unnecessary stress in my life.  Sometimes that involves flying to the other side of the planet during a global pandemic.

This can be considered as part two of my "What I did during the Coronavirus Pandemic" post - a series motivated by the old "What I did during the school holidays" essay theme from childhood.

In mid-July I made the decision to book my flights back to London.  By this point the infection rate in the UK looked like it was going down, and my old accommodation was less at risk, but a key motivator for moving back was to ensure that my tax situation would not become complicated due to the country of residence situation.

When I went online to book my travel I was thinking about the risk of catching the virus en route, so I aimed to minimise my travel time and transit stops.  I wanted to catch up with friends in Christchurch, so had that as my departure point.  Australia - particularly Melbourne - was experience an increase in cases of the virus, so I decided to avoid any transit stop there.  Hong Kong was still not looking great due to political unrest, so I ruled out having any stop there.  Singapore looked like a safe option, and had been okay when I had travelled from London to Christchurch a few months earlier.

A few weeks later I came to realise that I had made a slight boo-boo when booking my flights.  Although New Zealand was on the UK's list of countries that it was okay to travel from without having to go into self-isolation when arriving back, Singapore was not on the list.  By including a transit stop in Singapore airport in my return flights to get me back to London I had destined myself to 14 days of being stuck in the flat.

Part of my pre-flight entertainment in Christchurch was to try out setting up a delivery of groceries to my UK address so that I would have enough sustenance during my second round of self-isolation.  As the supply / demand balance of online grocery orders had gone into a sensible level, I was able to schedule a delivery for a few hours after my return.

Even with the benefit of hindsight I don't regret my decision to travel via Singapore.  Realistically, given the limited range of countries within the UK's "travel corridor", if I had set up a travel route only involving those countries I believe that I would have been more at risk of becoming infected.

What I did during the Coronavirus Pandemic

The move to New Zealand

On March 23rd I decided that there was too much uncertainty around how long London would be in lockdown, so I booked myself a flight to New Zealand to stay with family.

A few days later I was in Balclutha in time to hear the town's civil defence siren sound half an hour before the start of New Zealand's level four lockdown.

Due to the remote possibility of being a carrier of the virus, I had to self-isolate for two weeks from the day that I arrived.  This meant that I could not go to the supermarket (the only retail business still open).  I was still permitted to go outside and walk around, keeping my distance from anyone else who happened to be out and about at the same time.

Work

At the time that I left London my team had already started to work remotely, so I was able to continue to contribute to the software development effort from my laptop - just in a different timezone.

Online only job interviews

Participating in the job interview process is strange enough when meeting face to face in a meeting room in the office, but we had to adapt to try to achieve the same level of confidence with a candidate being met exclusively online.  The challenge that we didn't really solve was finding a suitable mechanism for having the applicant draw an architecture diagram for a hypothetical new system.

Staying connected

For my circle of friends back in London I found myself making new connections on Facebook with people who I would semi-regularly meet up with in the local pub.

My pub quiz team WhatsApp group also kept me informed of changes in my London neighbourhood, though I eventually found myself sending them pics and videos that I had received - such as how a local pub was temporarily converting itself into a delicatessen.

Post lockdown socialising

By the 21st of May New Zealand had gradually moved to a lower level of Covid-19 restrictions.  More shops could open, and cafés, restaurants and bars could operate with social distancing restrictions for customers, known as the three S's: seated, separated, and with a single server.

I didn't expect many businesses would open under the restrictions, as their overheads could be higher than before and the likely turnover could be expected to be much lower.

On one of my daily walks I came to realise that the pub closest to my side of the town was opening, so I decided to try it out for some food, beverages, and people watching - I hadn't really spoken to anyone beyond my immediate family for well over a month by that stage.

 

Revisiting exploring relatedness of videos using youtube APIs

Introduction
 
Way back in 2012 I dabbled with youtube's APIs to see how to determine whether two videos could be related via following their "related videos" out until finding a common video or running out of non-duplicate videos in the accumulated graph.

I've recently realised that the code from that particular experiment was only held on my old laptop that died a few months ago.  This is a good excuse to re-write it from scratch and produce something a little more useful - such as listing out the videos along the related path.

Blocker

Youtube's APIs have changed, so the approach that I took seven years ago won't work any more due to quota restrictions on API calls.
The only call that can bring back the related videos data is a search, and the minimum quota cost for a single search call is 100.  With a daily limit of 10,000 quota that would restrict us to 100 searches - which is simply not enough to build up a graph between videos unless they are very closely related.

Java 11 support added for AWS Lambdas

I've just deployed a little "Hello world" lambda that also logs out the system properties as verification that the setup is correct.  Seems to work.

Connection pooling in AWS Lambdas

A few months back I posted my findings from troubleshooting a resource leak in a Java application that had been lifted and shifted to become a lambda rather than a long-running app on AWS.

The resource leak turned out to be the setup of a fresh pool of connections to the back-end cache on each invocation of the lambda, without any corresponding clean up call to close those connections.

Yesterday I attended the Redis Day conference in London during which a presentation happened to include some code for a much simpler use case involving connecting to a similar back end cache - Redis - but with a different approach to initialisation.

The lambda from the presentation was extremely lightweight, so there was no bloated microservice framework involved.  Just a single method to perform a single task. The initialisation of the connection to the Redis system was performed in a static block and had no corresponding call to close it. I believe that this approach would ensure that the Redis client is reused between invocations of the lambda, and appears to be a recommended pattern for setting up connection pools for other resources such as database connections - relying on the receiving end to clean up resources if / when the lambda's container is shut down terminating the connection.

The static initialisation approach reduces the startup time for all but the first invocation of the lambda.

What's an ideal working environment?

Introduction
My most recent job interview included being asked about what I would consider an ideal working environment to be like.  This post will be me thinking aloud about how to respond if the same type of question comes up again.

Team Structure - Serenity Now
Based on my twenty or so years of working as a professional software developer, I have found the most productive teams are those that are self-sufficient for the things that they need to develop, and have the big picture awareness to anticipate in advance what they need from others.
Partway through writing this section I thought about how this matches up to the serenity prayer:

"God, grant me the serenity to accept the things I cannot change,
Courage to change the things I can,
And wisdom to know the difference."

Being able to deliver working software at a stready sustrainable pace is where I get a lot of satisfaction from my work.  Having to wait for another team to produce something can be frustrating, so having strong communication skills is a key aspect of ensuring that progress is not blocked.

Team Diversity
This section title may sound like a team name from The Apprentice, or The X Factor, but for me it is all about having a broad range of worldviews and levels of experience.

In two of my jobs I have worked alongside students completing a year in industry as part of their university course's programme.  Those projects were some of the most rewarding of my career in terms of developing my mentoring abilities and the satisfaction that can be gained from teaching a concept or the benefits of a methodology such as test driven development (TDD).

My half-joking contribution to the diversity of my latest team was that I was the only member originally from the southern hemisphere.  The only time that I considered making a suggestion based on that backround was when I heard that a team was contemplating introducing a snowy winter theme to the homepage of the product's website.  It would have been Summer in the southern hemisphere.

Thanks to the melting pot of cultures that London provides, I have also had the opportunity to learn from people of different cultures and religions about how they go about every things in life such as choosing what food stand they can visit at the local street markets, and managing their working day during periods of fasting.

Team size - no one size fits all
Depending on how you shape it, I've either been working in small teams, or large teams.

For the day to day incremental changes that my immediate neighbours and I worked on I have had a small team of three.  For the effects that our changes have introduced to the wider development group the number goes up to something closer to fifty or sixty - not counting external consumers of our APIs who should have noticed no impact from our seamless changes.

The main project that I worked on during my time at Elsevier involved something closer to a hundred people.  I had regular contact with around fifteen members of the core team, and interacted with a dozen or so others when we needed to address a publication version consistency problem.

Getting back to what I would consider to be an ideal working environment, I think a group of between five and ten people - depending on the range of skills required - is a good size:
 - There is enough cover for keeping the work progressing if someone is ill or takes a holiday
 - We can have a range of levels of experience
 - There are enough people to be reasonably certain of having at least one strong opinion when a decision needs to be made

Inter-team socialising
I find that it's much easier to have a discussion with someone if you have already had an informal conversation with them about non-work matters.  I'm not someone that runs workshops, so I'm not going to be that person who sets up icebreaker activities for people to get to know eachother at the start of a multi-day meeting.

On the other hand, I do quite enjoy trivia, so sometime back in 2015 I introduced the Friday Pub Quiz as a mini social event for self-organised teams to participate in at the office's break-out area after the Friday afternoon knowledge share session.

It started off small with just a couple of teams, then expanded out to have a couple more teams, then I introduced the rule that the winning team would have to produce a quiz for the following week.

Four years, and three office moves later, Friday Pub Quiz is still a fairly regular event.
Individuals from different development teams, product owners, senior managers, designers sometimes meet eachother for the first time to form a team, then find themselves presenting to their peers together the next week.

Office environment - open plan, but keep the noise down
I have always worked in open plan offices, so I don't see myself moving to my own walled off space anytime soon.  I like the buzz of hearing pairs programming and discussing the next test or feature to be developed.

Having said that, there have been a few ocassions when I might have preferred a different setup - mostly around the issue of noise.

Providing table tennis or foosball in the office environment is all well and good, but it really should be in its own space - not somewhere that has no doors between it and the working environment.

A pet hate of mine at a recent job was the daily crinkle of packets of crisps being eaten at some desks near mine.  I consider it a bit like water torture when you don't know when that next noise is coming.  I'm now wondering what the mouse and keyboard of those laptops would be like as that salty type of food is something I always need to wash my hands after eating.

Shaking off some job interview rustiness

Introduction - looking for a new challenge is a full time occupation
Having a long term secure job is great, but in general the longer that you are away from the process of looking for a new role, the less well prepared you will be for interviewing for the next one.  Please don't take that as an indication that you should hand in your notice for the sake of it, but read on to learn from some of my experiences.

I find the whole process of looking for a new job to be quite a strange situation.  Most people that I have worked with somehow find ways of arranging interviews and accepting an offer while they are still actively employed.

I don't like the awkwardness of sneaking around and being economical with the truth - not lying, but not giving a full explanation. So whenever I have come to the decision that it is time for me to change jobs I have resigned, served my notice period including all the appropriate knowledge transfer, and then gone to look for an appropriate company to work for next.

Fortunately in London there are many companies that have a technology team that needs someone with my skills and experience, so I have been able to afford to not ace every interview first time.  What follows is a bit of self-analysis of my most recent experiences of being back on the job hunt in 2019.

First interview - brain fade
I did my early interview preparaton no favours by taking a relaxing holiday for six weeks or so without touching a single line of code.  Don't get me wrong, it was great to unwind and take some deep breaths and be away from thinking about the ins and outs of the product that I had been working on for the last year and a half.  I just didn't appreciate that even twenty years of commercial experience isn't enough to be ready to churn out code at the drop of a hat.

You come to realise just how much you rely on the code completion features of an IDE when you try to jot down a technical solution on a piece of paper.  String.charAt has been around forever, but it just escaped my memory when I needed it most.  So I found myself going back to first principles and introducing an unnecessary array copy of the underlying characters.  🤦

Second interview - time management
For the second company that I interviewed at I made sure that I had dabbled with some code to solve some common types of low level exercises, then proceeded to make an entirely different type of mistake when it came to the interview.  I didn't think enough about the time limit when I came to introduce myself, so ended up giving a five minute speech about my background when a thirty second high level description would have been perfectly sufficient.

Sure enough my technical solution became a little rushed, so instead of reaching for the modern obvious implementation approach of applying streams and lambdas I went back to first principles and applied a simple for loop - making it seem as though I wasn't familiar enough with some of the most widely used Java 8 functionality - despite having used that for over five years.

When it came to a whiteboarding session I was fine for describing how the solution that I had fully designed and implemented worked, but didn't pick up on the different nature of the company that I was interviewing at and the types of challenges that they have had to overcome.  My main takeaway from this shortcoming was to look outside of the industry that I have been working in.  Check out the various videos available on Youtube where vendors and other businesses describe their approach and the solutions that they produce.

During the third hour of the interview process I faced another group of people, this time probing my personality, attitude, and experiences of different cultures and situations.  In the process of producing this blog post I have thought of an answer to one of their more peculiar questions - something that I have learnt from people I work alongside that came as an "aha" moment that I might not have considered before: Colleagues in the US generally get their medical cover through their employer, so it would be a major risk for them to leave their job without having another one lined up to go to.

For some of the more general, "Can you think of a time when..." situational questions I didn't have much of a response.  Sometimes I feel fortunate that I haven't felt like I have worked in particularly stressful projects, but unfortunately this line of interview questioning doesn't seem to believe that's possible.

Third interview - getting better technically, just not enough emphasis on end users
I really appreciated having a thorough interview feedback call from the company's in house recruiter recently.  The fact that most of it was positive and constructive is making me feel more confident that I am getting better at preparing for interviews and being able to present my thoughts to strangers.  Even though I found myself apologising for being flustered and repeating the same introductory wording (so self conscious about repetition...) the tech interviewers expressed that they were pleased that I had managed to come around to a suitable workable solution to the hypothetical scenario that they had raised.

This particular interview had a slightly unorthodox format of including a product focus stage where other companies have a more general behavioural / soft skills stage.  Here I didn't strike the right balance between refering to more recent projects versus projects that involved developing functionality for end users.  Having spent the better part of a year largely self-managing migrating an internal framework and its associated libraries doesn't offer much to talk about when it comes to requirements and compromises and team dynamics.

Onwards and upwards
I was tempted to consider an offer to go to work at the third company that I interviewed at, but the lower pay rate range that they were suggesting would have been too much of a step down from what I know I am worth.  I also had a couple of reservations about the approach that they have taken with their microservices, so I will leave those challenges for others to face.

In the next week or so I expect to be attending interviews at a few more companies that I have applied to.  My confidence in my technical and social abilities remains high, and my preparedness for the interview processes has grown considerably.

London potentially losing the best IT meetup organisation

I was shocked to read a tweet in my timeline a few days ago from Wendy Devolder, the main person behind Skills Matter:

"To all the people

@skillsmatter

who made us who we were, I’m very sad and sorry that

@skillsmatter

has gone in administration. A massive thanks to my beautiful team, who contributed so much beauty, passion, talent and experience, words cannot express my gratitude."

Skills Matter were the hosts of the very first IT meetup that I attended when I moved to London over eleven years ago, and also the hosts of the most recent meetup event that I attended just a few weeks ago.
Over the years they have moved from a quirky building in Clerkenwell to a more conventional setup near the Barbican, and finally into a large purpose-built central city facility near Moorgate.

Here is a link to the page on LinkedIn outlining the circumstances that led to this administriation situation:
https://www.linkedin.com/pulse/skills-matter-appointed-administrators-wendy-devolder/

I really hope that someone was able to step forward to keep Skills Matter going before the deadline.

New blog dedicated to microservices

I liked my previous post's title so much that I have decided to spin up a new blog dedicated to my experiences and observations in the development and operation of microservices.

The title is, "New adventures in microservives," and you can find it at the following URL:

https://ms-blog.elegant-solutions.london/

You'll have to excuse me if I don't go into specifics about where or when I have encountered the issues that I will post about.  There are not horror stories or embarassments that I can recall, it's just professional courtesy not to disclose irrelevant details.

New adventures in microservices - reducing inter-service calls

Not so long ago I was working on a product that internally exposed an API to allow clients to keep in sync with a user's most recently read documents.  I expect most readers of this blog will have used Amazon's Kindle or a similar online reading application so I won't have to explain any of the fundamentals of this functionality.

On the surface this "recently read" service was quite simple - just read the user's most recent records out of a specifically designed database table and present it to the client application.

A complicating factor in this particular system was that some documents belong to a group rather than an individual user, and as a result the rights to access documents could change over time.

I consider this to be a case study of when catering for an edge case can lead to unnecessary pressure on core systems.  Approximately 75% of calls to the documents service were permission checks from the recently read service.

All of the clients of the recently read service would silently ignore any reference to a document that the client did not have, so the permission checks were completely unnecessary.

After consulting with the various teams involved I removed the permission checking calls and as a result the response time of the recently read service improved, and the load on the documents service reduced significantly.  As a result the documents service was able to run with fewer instances.

This was one of the rare cases when the best way to improve the performance of a service call was to remove it altogether.

Recent Holiday Reading

Travelling to the other side of the world offers plenty of idle time in the airport shops.  Turning up to the airport three hours before the flight is a given, when considering the hassle and cost involved if the first flight is missed.

Even if I have a book or two in my carry on bag I still peruse the paperbacks shelves at WH Smith or the local equivalent airport retailer.

So, here's a list of books that I have been reading during my latest holiday...

Technology books (on Kindle - since typical bookshops don't have these titles)

Site Reliability Engineering - How Google Runs Production Systems

Kubernetes Patterns - Reusable Elements For Designing Cloud Native Applications

Accelerate - Building and Scaling High Performing Technology Organizations

Not so technology books

Eric Idle - Always Look On The Bright Side Of Life

Permanent Record (Edward Snowden)

Interview preparation

I had a mental blank while attempting to jot down some code for solving a problem on paper during a recent job interview.  Less than a minute after leaving the interview I remembered the name of a method that I should have been using instead of my clunky array manipulation.  I put the experience down to a combination of being so reliant on IDE code completion, and not having written much code for a couple of months while I have been unwinding on holiday.

Alas, even my depth of knowledge on changes to HashMap’s implementation (List gets replaced by tree when 8 elements fall under the same bucket since Java 8) did not balance out for that particular glitch.

Oh well, it was always going to be unlikely to ace the first interview after a four year break.

Preparing for interviews versus skating to where the puck is going to be

"I skate to where the puck is going to be, not to where it has been." - Wayne Gretsky

I'm in the process of seeking out a new challenge in my career (no need to whisper - I've left my previous job on good terms and taken a nice long holiday - so I'm not sneaking around to speak to recruiters during work time).

While updating my CV I have been quite aware that once again I find myself without professional experience of the latest popular technology in my sector - Kubernetes ... and maybe Kafka.

It's very tempting to go away and complete a full-on course to fill in the gaps, but I've been in the industry for long enough to appreciate that there's still a reasonable chance that my next role might not include those technologies anyway.

So, for now I'll just have to find the right balance of revising what I already know, and reading about and watching videos about enough to be able to carry my end of a conversation.

How NOT to use LinkedIn

I've recently taken the decision to look for a new job.  Much like most of my other career moves I have chosen to leave a comfortable position, treating looking for the next one as a full time endeavour - rather than being sneaky and booking a "dentist appointment" or taking time off to attend interviews.

In this modern era I thought that I would not need to update my CV, as LinkedIn is the go to place for publicising that I am available, and I have kept my profile there relatively up to date and complete.

My main discovery of the last few days has been that the "Projects" section in a LinkedIn profile is not very prominent.  For example, if I choose to export my profile as a PDF document then none of the project information will be included.

The significance of this issue was reinforced when I attempted to export my LinkedIn profile across to a third party system as part of applying for a job.  Sure enough none of the project information was carried across.

With this in mind, I will be restructuring my profile so that the key aspects of my project experiences will also be mentioned in the high level description section for each job that I have held.  This should prevent the unpleasant experience of having to fill in a lot of gaps in face to face interviews where interviewers have only seen the top level of my LinkedIn profile as that has been provided to them by their recruiter.

I've also seen this situation as a reason to finally get around to buying and installing Word on my Mac, rather than cranking up my 11 year old Windows laptop for updating a CV to circulate.

Contributions to open source - it's not just about hardcore coding

Just a listing of some contributions that I have made to open source software, from creating my own code to making a third party's documentation a little bit more readable.

Created plugin for GoCD continuous integration server to enable polling of status of application in Cloud Foundry.
https://github.com/Sounie/springer-gocd-cloudfoundry-plugin

- Identified code change in Apache Camel that resulted in messages being deleted from an AWS SQS queue even when the application logic encountered an error path.

At the time we had a situation where a regular trickle of events would normally fail to process, resulting in retries and ultimately being automatically moved onto a dead letter queue.

When the DLQ stopped receiving messages it took a while to trace back what had changed.  As an aside, this type of situation can be considered as a good motivation for making small distinct changes - this is where a continuous deployment pipeline is a real enabler.
CAMEL-9405 - Amazon SQS message deletion behaviour change on exception

- vavr (formerly known as javaslang).
Some wording tweaks

- Jenkins CI
Bugfix in translation perl script

- AdoptOpenJDK Docker image scripts
Correction to comment

- IntelliJ IDEA Findbugs plugin
Typo in label shown in IDE