Monday 18 November 2019

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.

Wednesday 13 November 2019

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.

Monday 11 November 2019

What's an ideal working environment?

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.

Friday 8 November 2019

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.

Thursday 7 November 2019

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
who made us who we were, I’m very sad and sorry that
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:

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