Author: Kenneth

Array’s – Reducing all duplicates

Array’s – Reducing all duplicates

Years ago when I blogged regularly about Actionscript/Flex some of the most simple and yet popular posts were on array’s.
Today I find myself doing something similar in Javascript – and there is no out of the box solution that I’m aware off.

Take a large array (where duplicates probably exist) and condense it into a collection of unique items.

Let’s say your hitting some API and it returns 1000’s of results, and in that result you want to find out how many unique types of XXXX there are. How would you do that?
One simple way is to use an object and store the items using the key part of an object.

const duplicatedArray = [
  { name: "Bob", hairColour: "Black" },
  { name: "Jane", hairColour: "Grey" },
  { name: "Mark", hairColour: "Red" },
  { name: "Marsalli", hairColour: "Black" },
  { name: "Rachel", hairColour: "Brown" },
  { name: "Craig", hairColour: "Red" },

const getUniqueCollection = (keyFilter) => {
  const reduced = {};
  duplicatedArray.forEach((person) => {
    reduced[person[keyFilter]] = person[keyFilter];
  return reduced;

What’s going on is that it will pass only once through the array with duplication’s, and each time it will write that to the reduced object. If, as there is in this example it comes across two Black hair types then the 2nd one will overwrite the first, therefor removing any duplication.

End result, you now have an Object (some may well call this a dictionary) that on inspection contains unique list of hair colours. This for example could be used to populate a dropdown box or similar. Or you could use the below to iterate over the new object.

for (var key in uniqueCollection) {
    var value = uniqueCollection[key];
    // do something...

Lets say you’ve a more complex object!

const complexDuplicatedArray = [
  { brand: "Ford", colour: "Black", ignoredProperty: "XXX" },
  { brand: "Tesla", colour: "Grey", ignoredProperty: "AAA" },
  { brand: "VW", colour: "Red", ignoredProperty: "222" },
  { brand: "Ford", colour: "Black", ignoredProperty: "111" },
  { brand: "Tesla", colour: "Brown", ignoredProperty: "ZZZ" },
  { brand: "VW", colour: "Red", ignoredProperty: "YYY" },

// pass in ["brand", "colour"] as the parameter keyFilter
const getComplexUniqueCollection = (keyFilter) => {
  const reduced = {};
  complexDuplicatedArray.forEach((car) => {
    const keyValue = JSON.stringify(car, keyFilter);
    reduced[keyValue] = keyValue;
  return reduced;

So here we are filtering on 2 keys, the brand and the colour. Convert the object to a string and drop the properties that we do not care about.


The stringify part in the above is key. What’s it’s doing is taking an array of strings to include in the stringify process.
So using
myObj = { brand: "Ford", colour: "Black", ignoredProperty: "XXX" }
JSON.stringify( myObj, [‘brand’, ‘colour’]); will output
This is ideal for using as the key to store, so if there is another Ford car that is Black with a different property that you wish to ignore, then it’s not included.

Overriding template literal strings

Overriding template literal strings

Have you been using template literals for a while? Most likely, but did you know that you can override how it constructs the overall string? I didn’t until recently.

If you haven’t seen it, then I think you’ll be sure to think that this code is really cool and so much potential use in other areas.

It’s called tagged templates. It means that rather than calling your literal with the standard joining method, you pass your arguments to your own method.
See the below – as ever code is the best way to explain.

const person1 = "Mike";
const person2 = "Bob";

const taggedTemplateStringLiteral = myMethod`you can say hello to ${person1} and ${person2} :)`;

function myMethod(baseMessages, ...params) {
  // The reduce() method executes a reducer function (that you provide) on each element of the array, resulting in single output value.
  // array.reduce(callback( accumulator, currentValue[, index[, array]] )[, initialValue])
  return baseMessages.reduce((acc, cur, i) => {
    acc += `${params[i - 1]?.toUpperCase() ?? ""} ${cur}`;
    return acc;

  /*   Adding in the below as this is perhaps a more common approach,
       but as show in previous post you can improve undefined checks
       with nullish coalescing as shown in the above snippet.

    return baseMessages.reduce((acc, cur, i) => {
      acc += `${params[i - 1] ? params[i - 1].toUpperCase() : ""} ${cur}`;
      return acc;

What’s going on?

Firstly you have you grave character `. This make it into a template literal. When a string is enclosed with those then each portion (split up by using ${ } for code/var segments) is then included into an array.
Next each parameter, whatever is evaluated for each ${ } block is passed as a separate parameter. You could call them individually or in my case I used the rest (…) operator to grab them all.

myMethod`you can say hello to ${person1} and ${person2} :)`

The means to invoke the method is what caught my eye, in that you do not call it like an actual method! The above ends up being the same as –

myMethod(["you can say hello to ", " and ", " :)"], "Mike", "Bob" );

Which is rather smart and a great little snippet to remember.

?? Nullish coalescing & Optional chaining ?.

?? Nullish coalescing & Optional chaining ?.

Javascript Sucks! It really really does at times. Take a look at the difference between the books ‘The Definitive Guide’ and the ‘the best bits’ 😁 I joke, of course, but some portions of it are just annoying.

It’s loose and simple way, is it’s strength and it’s weakness, but with each new feature from the latest ES++ range comes new means to clean up your code and hopefully stop shooting your feet!
The below new operators come from ES2020, the 11th edition.

Operators with ? in them can be a bit confusing if you’ve never seen them and also they are hard to search for. How do you search for ? if you don’t know the operator name? So this is here for my own bookmarking as well as a reference for others. First up we have the ??

?? is the Nullish Coalescing operator

What’s its purpose, to make getting expected true/false values back where it would seem normal to do so! What do I mean, well normally if you want something to be false you’d make it false. Or you’d expect null/undefined to be false.

But under normal circumstances, JS isn’t like that. I’m not going to go into the falsy/truthiness of JS, but to suffice to say that the ?? allows for default values such as 0 or an empty string to be valid values, rather than being false.

const textSetToAnEmptyString = "";
const DEAFAULT_TEXT = "This is the default";

const myText = textSetToAnEmptyString ?? DEAFAULT_TEXT;
console.log(myText); // ""

const myTextOldWay = textSetToAnEmptyString || DEAFAULT_TEXT;
console.log(myTextOldWay); // "This is the default" - probably not what you wanted

As can be seen if the text is set to an empty string which is a valid value, with the ?? operator it remains as an empty string, which is exactly what you’d wish.

But if you wished to use the || operator then the empty string will be changed as “” is considered false in JS land.

?. is the Optional chaining operator

Looking into this new feature, it is REALLY great.
Checking if a value exists in some nested object for JS is yet another of those painful items. Not that’s it hard to do, but it’s such bloated code.
So this is simplest to show via code

// set up an empty object
const obj = {};
const foo = obj.child;  // foo will be undefined - No error
const fooError = obj.child.secondChild;  // Error - can't access secondChild from an undefined value
const fooTwo = obj.child?.secondChild; // fooTwo will be undefined - no error
const fooThree = obj.child?.secondChild.thirdChild; // fooThree will be undefined - no error
const fooFour = obj.child?.secondChild.thirdChild.fourthChild; // undefined - no error

What’s going on with fooThree and fooFour???

Well the ?. operator is short circuiting when it goes to assign a value to to fooThree and fooFour.

  • Looks at obj – which is a valid object
  • looks for child, and JS being the way it is doesn’t complain, and returns undefined (as it does not exist)
  • ?. check now means that it will go no further as child was undefined
  • secondChild, thirdChild and fourthChild do not get looked at/processed due to the short circuiting of process

Also works on methods πŸ‘

const myFunc = () => { return "WOOO" };

const foo = {
  methodX : myFunc

const message = foo.methodX(); // "WOOO"
const message2 = foo.methodY(); // Error - methodY does not exist
const message3 = foo.methodY?.(); // undefined and carries on

// The ?. syntax will also work in the same way with arrays
// such as myArray?.[12] πŸ‘

Multiple ?.

In the above child isn’t defined, but what would happen if it was defined?

const obj = {};
obj.child = {}; // Set child to an empty object
const foo = obj.child?.secondChild; // undefined - no error
const fooTwo = obj.child?.secondChild.thirdChild; // Error - can't access thirdChild from an undefined value
const fooThree = obj.child?.secondChild?.thirdChild; // undefined - no error

Here we needed to insert a second ?., this will check that secondChild is set before moving on. So for fooTwo there is an error as thirdChild can’t be accessed from undefined, but fooThree is ok as it doesn’t get to thirdChild due to the short circuiting.


Both the above are powerful tools and even better is that they can be combined!
Let’s say you

let myMap = new Map();
myMap.set("foo", {name: "baz", description: "" });
myMap.set("bar", {name: "baz" });

let descriptionFoo = myMap.get("foo")?.description ?? "description not set"; // output is ""
let descriptionFooOld = myMap.get("foo")?.description || "description not set"; // Output is "description not set" - not what you'd wish for as it has been set
let descriptionBar = myMap.get("bar")?.description ?? "description not set"; // output is "description not set" as it wasn't set

Hopefully the above will give you some ideas of where to use these new operators. I’m sure as I go through some old code I’ll see better examples on where to use them.

Moving from IntelliJ to VS Code

Moving from IntelliJ to VS Code

Change is hard, and it’s always harder if you’ve been using ‘X’ for years.

I’ve been using IntelliJ for a number of years now, and it is great! It really is, and there is no reason other than cost not to use it. If cost is not a concern then use IntelliJ.

Keyboard shortcuts

You’ve spent years in one IDE, your fingers just know where to go, what to do. That instinctive physical memory would be very hard to get over. Any change will immediately make you less productive. You’re just not going to do it!

Thankfully the benefit of the community around VS code comes to hand.

Install this and your fingers need not learn anything new!

Unit tests

Next up is testing. I really like right clicking on a test to run/debug it. The below is a partial solution (right click to debug fails)
This requires two extensions to get it to work.

1 – Test Explorer UI

This gives you the side panel where you can see your tests – but you will see ZERO tests in here to start of with. You need to install one more extension.

2 – Jest Test Explorer

Install the below and you will now see your tests in a panel inside VS Code

You can see the list of test now inside the Test explorer.

As yet, I’m unable to get ‘debug’ to work. I can debug the entire suite of tests via a config command, but not a single test via the context menu.
This is really annoying… I’ll come back to this if/when I figure it out.


Next up is coverage mappings. You’ve run your tests, added the coverage flag and you want to see where in the code you are missing coverage.


I found that after I had installed the above, ran my coverage that nothing was being highlighted. After messing around with configuration for ages, restarting IDE etc and getting nowhere I disabled (not uninstalled) the previous extensions ( Jest Test Explorer and Test Explorer UI). After another restart of VS code, hey presto it worked!!!
Re-enabled the Test extensions and now all the extensions where working.

Not as pretty as IntelliJ, but it’s better than nothing. The colours can be customised, so this could be made less jarring on the eyes.

Code formatting – Prettier

Looking for auto format to a standard format that is widely accepted? Prettier is the way forward for many reasons. Install the above followed by a couple of config changes and your code will be beautiful.

Go to your settings, filter by ‘save’ then update to settings shown here.
“Format on Save” – True
“Auto Save” – onFocusChange


Lastly, this is a bundle of other extensions that enable things like autocomplete of filenames, autocomplete of imports. This type of hints and flow should be automatic and is there from the outset in IntelliJ. So getting the same here is a must.

Close enough…

So now that I’ve installed all of these extensions I’m really happy with VS Code. Sure it’s not as good as IntelliJ – but VS Code is FREE.
So if you want to mess around at home for some personal projects, this is brilliant.

Notes to my younger self – Dark Clouds!

Notes to my younger self – Dark Clouds!

Welcome to part four in my series of what I’d like to tell myself if I had the chance to pop back a few years. In part 3 I’d essentially been forced into looking for another role as I could see the dark clouds surrounding the job I was currently in, funding was obviously an issue. It was not rocket science to know it wasn’t going to be far off that if I didn’t jump I’d be pushed.

Things were looking very gloomy!

Moving forward

What the heck was going on!

  • Left university
  • Non programming job
  • Dev Job – in name only
  • Non programming job
  • Fun programming job, but as stable as a tower made of jelly

Having now been in the world of development for almost 20 years, so it’s easy for me to say there will be something else to come along. At the time it wasn’t so. What can you do? What could I have done better?

You’ll read elsewhere in feel good blogs or twitter snippets that no one needs to extra hours, that a role should never require lots of extra effort and if it does then you should leave. But in reality, this is not true. It would be awesome if it was, but it isn’t. Certainly not in the lower ends of the development market.

In this instance I was fortunate to find another role close by. I had time to look, which took a while but when that opportunity came up I made sure to study for the interview. It was a Java role, I really disliked Java, I didn’t know Java (J2ME is not the same), but somehow I passed the interview and various tests they gave 😎. Then after getting the role, I actually found the role wasn’t really Java! RESULT. It was a new language, and what’s more I actually liked it.

Try different languages, they are not all the same! You may find your niche in an area that you hadn’t seen before.

Few years later, in very similar circumstances, had I learned from the previous lessons? No, actually I hadn’t… πŸ€¦β€β™‚οΈDid I see the company in trouble, nope. Should I have? Yes. Was I prepared for what was to come? Actually I was!

What is KEY?

Experience! But what if you do not have any, you need to get yourself some!

Shortly before my 3rd enforced job move I had started up my own blog. I started this up before I knew my job was in trouble. Why did I do this. Was it to get followers, fame, status or fortune? Nope.

I wanted to put up some examples, so that when I got stuck I could look at my own code and help myself and if I discovered something that I had issues finding online then I’d put up the solution for that as well to aid others. I spent a fair amount of time doing this. Actually when I was working, but I didn’t have any work, I’d be experimenting with code. Creating small chunks, cool visualisations. Testing the latest, greatest libraries and blogging about them.

This was KEY to what was about to become my best years as a developer!

After being made redundant, I had to get into the contract market. My blog was such a selling point to anyone wanting to hire me (it’s changed a lot since then, don’t even think most of it will work anymore – written in Flex/Actionscript).

Contracting was a completely different ballgame. But it was great. So always be positive πŸ˜ƒ Even in the adversity of what was happening, I had some of the most wonderful experiences, all because I was made redundant (again) and the only places I could work were many miles away.

Take away

This is what I’d like myself and others to take away. Enjoy your work. Highlight your work. Take time to get your foot on that ladder, and make sure it stays there. In the early years you will need to invest in yourself. If not directly with your employer, you will need to spend those extra hours doing research and finding new items, probably in your own time. This WILL set you up in a good way for when trouble hits – and it does!

So go, have a rummage in your head. What problems do you see around you, what are your hobbies, do your friends, or yourself grumble about structures etc. Look for small areas you could improve something. Maybe someone has already solved it. Does that mean you shouldn’t? No.
Just give it a go, but keep it small and simple or you will never finish.

Give it time, and the sun will come out πŸ™‚


Mentioned last time I’d share my experiences of team cohesiveness and being part of a team as it’s fairly crucial in ways I did not understand in my early years. But this post took a different turn. Watch this space for the next post, and I’ll see if I can cover it then…

Notes to my younger self – Gaming comes to an end

Notes to my younger self – Gaming comes to an end

Welcome to part 3 of my guide and ramblings that I’d like to tell myself if I had a time machine. This theme was to be the basis of a talk I was going to give at the React Finland JS 2020 conference – until Covid 19 came along and tore up everyone’s plans for 2020.

Thanks (sign as you leave conference hall in Helsinki)

In my previous posts (part 1, and part 2) I mentioned that I started of my developer career in the games sector. This first role was short lived for the given reasons. So after a while of looking for a second role in the area I wanted to work, a position came along at a small start up. They were creating mobile phone games. Yeah!

For most who think about mobile phone games now you’ll probably be thinking of the literately 1000’s of simple games with the really annoying adverts that appear every 30 seconds. Well this isn’t that! This was back when the most popular game would have been Snake

New Nokia 3310 to feature colour display, 'Snake' and ...

Applications/games where being written in J2ME (Java 2 Micro Edition) and I of course had zero experience with J2ME. At the time my knowledge was C/C++ (any recruiters reading this, please stop sending requests for C++ jobs! I’ve not touched it in over 15 years!).


Be honest! I wasn’t hired because I faked my CV, or because I said I could write J2ME. I was hired, believe it or not because of my ‘experience’ in the games industry.

If you are a fit for the company then they will hire you. Good programming skills are transferable between languages – it’s just different syntax. Team cohesiveness is as key to work as how you think and code.

What happened?

So this company was small and if you’ve ever worked in a start up, then they can be a tad unconventional. Two developers, an artist, a ‘business guy’ and now myself in a small office. It was OK, not great, but OK.

My eyes were a bit more open going into this job. I enjoyed my coding, which is a key component for any developer. You must be able to enjoy it, not always, but at least some of the time. If you can’t enjoy writing code, then as a developer I’d say you are in the wrong job.

It’s a skill, almost an art form. Bringing logic, processes, instructions together to create something beautiful and useful. Code is there to aid others. The fun is what makes you get into ‘the zone’, spend longer than you should at your computer, even solve your coding issues while you sleep, but that’s the way it goes. You can’t call yourself a developer unless you’ve solved something in a dream – surely!!! 😎

One of the other coders at this start up was also a chef, and this comes to mind –

Code can become heated. If you don’t enjoy coding then you may be best looking elsewhere.

Week in, week out I’d be writing code for devices that had extreme limitations. Our games were ‘full colour’, and although it was written with Java (write once, run everywhere…) getting it to run on everything was far from simple. No rule will cover 100%, even for Java. Different phones would even use the same enum for different purposes! At the same time as trying to get a game out the door, the ‘business guy’ had grand ideas of a game with lots of mini games inside it.

We were struggling to get a single game out. Let alone a game with mini-games.


Stop reaching for the stars! Get something out there, get it out fast. As a developer it will never be perfect, NEVER!

If you have to hard code something because creating the flow to not have it hard coded would take a week or more, then yes go for it. Once your product is out, then you can tweak it.

We didn’t need a level editor, if the game sold 10,000’s and we ended up making dozen’s of clones then yes. But it didn’t.

The company went bust, you MUST get Minimal Viable Products (MVP) out the door. That’s the bread and butter. That’s why we do agile. Every two weeks you should be able to deliver something.

Bigger companies can absorb the costs of delays to releases, while it can kill a smaller one. Also getting something for end users to play with will change your road map – for the better.

What is the minimum required for this to be of use?

This question should be the first thing you ask for each user story/journey.

As I write this, I can’t stress this enough. It is most certainly one of the top items I’d tell my younger self. Just stop tweaking it, stop wanting to add that one extra feature to make the users journey so much easier! How do you know it will, do you have any users? Do you have any metrics on the applications use?
Even as I create items now for users, we had an unpolished feature in an app. Functional yes, but it had a couple of minor flaws that we knew about. Did we release it – YES.

The next week an issue arose and we needed that tool. Without it we’d have been in trouble. Did the minor flaws make a difference – No.

Get it out into the wild!

End Game of Games

This was not a big company, we did in the end get a game out. But by the time we did, the writing was already on the wall. The game was actually a great wee game. MotoX in colour, on prehistoric mobile phones, it ran really well. The game was cloned and re-skinned quickly to help create another game (Jet Ski). Exact same, but the different look and feel was very good. Ultimately this was too late. Had I have known more, had more influence I could have helped saved this company – although I think that would have been hard due to other issues within the small team. But it could have been with knowledge.

In the end I was already applying for other positions and not in the games sector. Too many games programmers I knew were losing there jobs locally, too many were having to work crazy hours to keep there positions. People were sleeping at work and so on. As much as I enjoyed coding, this was not the way forward. I needed more stability.


  • Don’t be afraid to try something new
  • Be honest – always
  • Think of the user and get something for them to try ASAP
  • Be part of ‘the team’ (going to cover this in detail in another post as it’s super important). I failed at this until at least my first contracting role. Few years after the above role ended.
  • Just because someone is more senior, does not mean they are correct. Challenge, but challenge with knowledge.
  • Working silly hours, working long hours, working for nothing (yes some at this company did at times). These are all alarm bells. If you can’t change these culture items – get out.


I’ve mentioned team cohesiveness and being part of a team a few times now in this series, but not really covered it. This is crucial in ways I did not understand in my early years. Watch this space for the next post.

What would I teach myself. My first job

What would I teach myself. My first job

Following on from my previous post. This week I should be giving a talk in Helsinki, but I can’t due to lockdown ☹. So I’m going to put some of my thoughts, memories, learning’s down into my blog. Hopefully at some point in the future I’ll be able to do this in person.

Vantaa (North side of Helsinki)

First job

So I’d gained my degree in computer games, spent quite a while refining my demo 3D game for the playstation, navigated the interview (thankfully I’d learned from my disaster with GTA makers Rockstart North) and gained my first programming role since leaving university.

My game was similar to Wipeout (above image), but without many of the fancy graphics or multiple weapons!

I was happy, excited and yet at the same time the warning signs where there. But I didn’t have the experience to see what was actually happening.

1st Warning Sign

I had to cancel my honeymoon! Yes I was in the process of getting married, booked and organised everything and as is the normal process after being married you go away for a few weeks. It was all planned, 3 weeks away, but in order to get the job I had to agree to cancel it and drop it down to 1 week!
Of course being my first role I was all to eager. I pushed all our holiday plans back from Aug to Jan.

Why was this a warning? If a place is hiring a junior/graduate developer and they need them so desperately they can’t take a pre-planned holiday, then there is a MAJOR MAJOR issue going on.
(As much as I thought my skills were the best, they obviously were not, as any senior dev will attest to)

2nd Warning Sign

Again as a junior I did not get this, but having now been in many different organisations, training doesn’t stop when you leave uni. Training, mentoring, continual learning must be the foundation of any established organisation taking on new programmers.

Did my new employers give me any? Nope, no plan, nothing. I got a desk and pointed in the direction of a code repo and a database/spreadsheet of bugs. Thousands of them!

Did anyone help me, do some pairing, give me some tips etc. Again nope! When I look back, it was so clear this place was doomed.

3rd Warning Sign

Where is my team? So the company was based in Scotland, they were making the multiplayer portion for a AAA console game for EA who were based in the States. Christmas deadlines where looming. This was back in the early 2000’s – getting GB’s of data from the States to Scotland and back each day was painfully slow. So the entire team where flown out to LA – except for me and one other – for months.
The office did have 2 other games being made, so I wasn’t entirely on my own. But the other guy on the same project I was on that I can remember was an artist. Due to restrictions on IP, NDA’s etc we had next to no interactions with the other teams. No chance for learning or gaining experience.

Could it have been worse?

Quite frankly as a junior developer it couldn’t have been worse! Other than getting a good wage, some nice benefits (worked evenings to tie up with the guys in the States – so unlimited pizza each night) and not knowing any better, I expected that once the crazy release time was over things would improve. So I coasted along, not doing very much, frankly I hadn’t a clue what I was doing and no one really to ask.

Later I found out they didn’t care, for them I was just a number, head count so they didn’t breach there contract!

What happened next?

January came around, the entire team were still away. The game had been released and the dust had settled. I went away on my delayed honeymoon for a couple of weeks. All was well – I thought. Expected to have the team come back soon, get into a new project, start fresh, learn some code etc. Nope, nope and a big fat get lost.

Arrived at our house after a great holiday, to a letter which spoke of issues and blah blah blah. That was it, game over. No longer required!
Long story short, a few months after I was let go, the company collapsed. Looking back, really not surprised in the slightest.


Would I still have taken the job knowing the future? Yes.
Was there anything I could have done differently? Yes and no.

Experience is top dog, so if you can gain anything then go for it. But do not be afraid to keep looking even if you have just started a job. If you have time, spend that time creating and experimenting on what you enjoy.
I struggled for a long time not knowing what to do. Without having people physically near it was even harder to ask questions, but I should have. Keep asking, asking asking!
Expectation entirely from myself was that I should have known what to do, asking ‘simple’ questions seemed wrong. But I know now I was wrong not to ask. Ultimately it would have made zero difference to the company, but it would have made my time better. I would have been more productive, while I’d have gained more valuable insight which would then go on to aid in future positions.

Top points

  • Ask, ask and ask some more.
  • If you have time, work on personal items you enjoy (this will let you get a new job)
  • You are valuable, even at junior level. If they are not investing in you, you are being used. Prepare to LEAVE.
  • Do not be fooled by gimmicks such as games machines, free food & fruit, playing LAN games during lunch etc! These are great and may seal the deal to keep you in a job you enjoy, but if the core (investment in you) isn’t there, these are not worth it.

This post has gone on a bit longer than I expected. So I’ll continue the learning’s from my 2nd job (and last) in the games industry in the next post. Plus what I went into after games.

What would I teach myself?

What would I teach myself?

I’m sad right now. Why?
Well many months ago, when looking forward to this week coming, I expected to be getting myself all worked up. Tonnes of nerves, excitement, anticipation etc. Yes I was meant to be at the seriously good React Finland Conference, doing my first talk!

But, as with everything right now, Covid-19 is putting the best laid plans to the side. Off course all going well I’ll get back to Helsinki another time. Beautiful city and having been twice already I’ve got some great memories already. Anyway I digress…

View from bridge in Helsinki
View from one of the bridges in Helsinki

“Notes to my younger self “

Yes that was the title of my talk – “Notes to my younger self “. So what exactly would I try to teach myself if I had the chance?

Abstract –

Want to hear about getting the most out of the company you are in, whether it’s a dead end job or perhaps the company are on the brink of sinking into oblivion? Maybe you’ve hit the apparent jackpot and are working in the most fantastic start up – is it though?
It’s also about you! Listen to this talk and hear real life lessons on why Monday mornings are not painful, but are instead something that can be looked forward to.
And of course the code, all those things I’ve done or not done over the years – would I do it all again the same? No!

To much there for a single post, so I’ll see if I can break them up into various posts.

Where to start???

Context is king. So where have I gained my knowledge from? Here is a super brief outline.

  • First 9 years of being a developer – 12 companies.
    • First few were permanent roles, later ones were as a contractor
  • Worked in games industry, creative and business sectors
  • Been in tiny start ups, and huge multi million pound teams
  • Had privilege to work all over the UK and further (not a fan of the sun, but warm countries in winter, yeah I’ll take that again πŸ‘)
  • Last 8 years, been in one company, with the ability to swap teams (essentially new job, but with same employer)

The Start

I’m going to go back to a point where I wasn’t even thinking about work!
This doesn’t matter whether you are self learning, evening courses, formal university or other means to learn to code. Find something you enjoy, make it your pet project, create it, develop it and use it for your CV.

This will be your best friend when you go looking for a job. If I was to interview two people and one had a demo and a degree (lets say a 2.1) and someone else only had a degree, but it was a 1st. Who’d I hire? The one with the demo (providing it was good πŸ˜‰).

Why? Enthusiasm and a passion will trump pure head knowledge any day. If I can see your code, I can see how you think and how well you’ll fit into a team. Coding more often than not requires team work. Working on your own, being the sole developer has it’s place, but on anything substantial you’ll have to share responsibility.

For me, I created a 3D racing game for the playstation (yes this was almost 20 years ago now). It got me a number of interviews with games companies. I can still recall my first ever interview, with Rockstar North – for a role with creating GTA! Man did I screw that interview up!!! That’s for another post! Still it was a learning experience 😎

TIP – avoid super clever code

You’ve spent two days solving a problem, you’ve been in the zone and created a masterpiece, it’s even got multiple levels of recursion in it, so elegant you want to frame it.

Now you’ve solved it – change it! Clever code, or more to the point masterpiece code, no one will be able to debug it or follow it, other than you (only after getting back into the ‘zone’).

This is why if you are one of those really clever coders that can name and use ever pattern under the sun, think about those that will follow. It’s a team effort, code must be readable/maintainable. If it’s such a masterpiece then highly unlikely to be either of these things.

We’ve all been there and we can be proud of our creations, at the time the code makes complete sense. But pull your colleague over and get them to scan it. How many attempts did it take them to understand, if at all without you telling them what each part does?

I’ve done it before, had a senior dev come over and polity tell me to change it. Was I annoyed – yes a wee bit. Was he right? Yes, completely.
Creating the ‘masterpiece’ wasn’t a waste of time though. It will give you a deep understanding of the issues and as in my case the refactor was a fairly painless exercise. End result, clean maintainable code.

Getting back to your personal project for demo purposes. Test Test Test.
It’s the phase of our times just now, but it applies to code as well as covid! Maintainable code will be tested, can you write tests? Show you can. Take time to test, doing so will get you a job and a good job at that.

If an employer isn’t interested in testing, you are going to be in for a rough role. Beggars can’t be choosers with your first job, but you’re going to want to leave there pronto.

Next post

I’ll cover my experience in my first role, which was very much less than ideal for a range of reasons. Enjoyable and not at the same time. Find out more here

Why all the changes in my Package-lock file?

Why all the changes in my Package-lock file?

So I’ve checked out a JS project. I’ve run npm install, this should create no changes. Yet I’m now seeing my package-lock.json file appear in the version control changed files list.

So what’s changed? It’s mainly added loads of caret’s (^) to the versions of required software packages!

So what?

Well, you may have removed all the ^ from the package file so that your node modules remained the same, and you wish to guarantee each build will be the same. Adding a new package to your dependencies should not change large sections of the lock file. Having some semblance of oversight into the changes going on in the lock file may be useful when committing. But if 90% of it changes, and those changes are pretty much the addition of ^ caret’s or changes to the patch versions then it’s really hard to see what’s actually changed.

Bottom Line

Straight to the point, what’s going on? It’s your node/npm version! Specifically difference between version 5 and 6 (npm). This can happen if you are running with node 10 (most contain npm 6+), and others are running with node 8 (contains various npm 5 versions).
So if your project started with npm 5, then someone else does an install with npm 6, then you will see the large volume of changes.

Check out what version of npm is contained in each node version here

More depth

I had trouble finding this information online, hence this blog post to hopefully aid someone else. Here are some of the source links where I found information. – Essentially the question I was looking for. – Answer on why.

Should this information disappear I’ve grabbed a screenshot as well.

An Honest WFH Experience – subjective routines

An Honest WFH Experience – subjective routines

In my previous post I highlighted what physical set up I use in order to get the most out of working from home (WFH). But that is only one half of it. You can have the best set up in the world, but that is no guarantee to successful remote working.
So here I’ll highlight the subjective/non-physical side to working from home which I believe makes it work, and work well.


I’m putting this one at the top of my list. Personally I think this is key to being able to enjoy working from home. You must enjoy your job, and coding is fun (when it works…), but if that’s it then even that can become dull. You’ll get those crap days where nothing works and if you only enjoy the coding, then where are you? 🌧 β›ˆ 🌨

So what can you do? Make sure to say “Hi” first thing, just like you would in the office. Let folk know you’re there, and likewise say “bye” at the end of the day.
Note – I must do this more!

Get a Camera

Make sure you have a web camera. People are very expressive and as such our face can speak without speaking, the amount of non verbal communication you get over a camera is immense. Even for those that seriously dislike cameras, or if you feel your home office is a bit messy, ignore that and turn it on. Others will appreciate it.

“no more than 30 to 35 percent of the social meaning of a conversation or an interaction is carried by the words.”

Ray Birdwhistell The Kinesics Report

Casual chats

Work is never only about work, how many times would you walk past someones desk and say hello and have a wee chat about life? Or bump into someone in the kitchen and discuss what happened the other day while making a cup of tea.
Well, make sure you do this during your WFH days. Set up a time, at least twice a day to open up a video conference chat (Zoom is great) and do just that. Discuss what’s happening and listen to others.

Stick it in your calendar

As discussed above, in order to keep it up, you must put it into your calendar. Plan it out. These things will not just happen. We, inside our team set aside time for casual chats at least twice a day. May seem a little formal setting aside time, but if you don’t, then it won’t happen.
Conversations range from the weekend to what you may be working on and that’s a good thing.

Ultimately this is extremely rewarding as a team.

Don’t underestimate being a team, when things go wrong – and they will, when you’re stuck, when you’ve created a stinker of a bug, or broken the pipelines etc, being able to have a communication channel open will save your day and keep the team together.


Having your office in your house is hard. Are you ever away, do you ever switch off? Does the room where you work now turn into a no go zone after hours?
Now the following will depend entirely on your property – but do your utmost to create an office space. You NEED somewhere that you can shut off when you are done. Maybe if you don’t have space outside like myself for a shed/cabin, set up your desk in a room you don’t use. Maybe you stay with your parents or your flat mate is in the same situation as you. Swap rooms during the day.
Make your desk in that room, so once you are done, you don’t go back to that room.
Whatever you do, try really hard to find somewhere that you can close the door at the end of the day. So the livingroom will most certainly be the worst place! If you have it here, then you’ll not be able to have a relaxing time after a stressful day.

Hopefully that gives you a little bit of insight or ideas for your own WFH set up. Below is a small capture of the benefits and drawbacks that I’ve found when WFH.

What’s great

  • No travelling. This is great as I no longer have to pay Scotrail a small fortune each day.
  • I’m using my ‘extra’ time to do some daily exercise (… πŸ˜‚, well almost).
  • Being at home for dinner with the family – kids really like this as well!
  • Having lunch/teas/biscuits brought out to my office 😎🍰
Time spent with family is a great benefit – much better than commuting!

What’s not so great

  • Missing my 50-60 mins travel each way where I can sit down and do my own thing on the train πŸš…
  • Not being able to turn around and chat to colleagues.
  • Not being part of the bigger team/office.
  • Lack of community events.