Category: tips
How to get a big break – Notes to my younger self.

How to get a big break – Notes to my younger self.

By | | Comments 0 Comment

Getting into the positive territory of my talk! A turn for the worse, ended up being a turn for the better! Why, how, this is what happened and how I got my ‘big break’.

This is a direct carry on from the previous post and is as the others have been based on my talk that was given at the Finland React JS conference. If you’ve read the previous post, it wasn’t a terribly happy ending. I did create a good number of items, but over time that one main item which was a failure ultimately meant that more work wasn’t coming through. Due to previous experiences, what I could see happening and also the fact that I was really enjoying messing around around with Adobe Flex/Actionscript I took matters into my own hands.

Direct Action

Work was drying up, getting zero direction from management, even after asking about creating work for the client that I knew they could use – after all why not give them something when I wasn’t working on anything. Nope…

So time to take matters into my own hands. I was busy doing little demos, experimenting with new libraries, new techniques, answering questions on Stack Overflow, while also reading some common questions and creating examples based on those questions. What did I do with these demos/snippets? Well I created a simple WordPress blog (yes this blog) and every now and then I’d put up my examples and source code.

This wasn’t done to get coverage, but purely to help share my knowledge. In turn my actions on sharing my knowledge allowed me to extend my knowledge. My site way back then used to be rather popular – I even made a little bit of money at it via Google ads and some free merchandise! Which was a nice bonus when you expected nothing.

The Point

What am I getting at. Well, by experimenting, keeping things small and simple allowed me to learn the intricacies of the language, learn the lifecycle of the flashplayer, find out where the memory leaked, the add-ons, as well as the latest and greatest releases. This really mattered.

In todays market, this would be like me taking the latest hooks coming out in React 18 and creating demos against each one. Comparing it to what went before. Figuring out where and when lifecycle methods were being called and why. So dig in, create the smallest of demos and tinker around.

The Breakthrough

First place I worked while in London

So not to far down the line, the inevitable happened and redundant once more. Even though it wasn’t the first time and not a huge surprise, it doesn’t make it any easier. While hunting for jobs, there were zero in my local area. Quite a few down south in London and in the end I got hired by a high end consultancy company who worked with a range of leading banks.

While I can’t say for sure why they exaclty hired me, I know my blog was a big selling point of my coding abilities (yes, it’s very much lapsed now – this was around 15 years ago) and when it came to the interview as I now knew the code framework inside and out, then that certainly got me through multiple stages in the interviews.

In the end, each week I’d fly to London on the Monday morning, and fly back home on the Friday. I was renting a place in London while there and even with those extra expenses I was still coming home with way more than I’d ever done in the past – not to mention it was great fun being involved in such a large project. But there was a cost, but that’s for another story…

Now that I’d entered the contract market, that gave the outlook on doing work a completely different feel. Again that’s for anther story. Something that for those that can, I’d certainly recommend as long as you are aware of it’s drawbacks.

Gotcha
Works on my machine! Notes to my younger self.

Works on my machine! Notes to my younger self.

By | | Comments 0 Comment

Thanks for that, good to know – Works on my machine! It’s such a common issue, hey lets ship your machine then 😁 How did we get to this situation. A lack of Ownership & Trust, that’s what! Part 3 from my series on the talk I gave at React JS/Finland. You can watch the talk directly here – https://youtu.be/zE8PDM_7xoQ?t=11404 This part covers my discovery that coding, isn’t always about coding. Read on…


For this one, I need to set the scene to highlight what I did and why it was wrong. Being more experienced now, I certainly wouldn’t have done what I did all those years ago.

The story

I was in a new role, one the main reasons for me being in that role was to fix an application that someone else had created that wasn’t functional. This application was created by a web developer who hadn’t written any web applications before. The process of designing/creating a web page is drastically different to creating a web application.

So I come in to this role, get shown the application, asked my views on it and how to improve it. After a while digging into it and running it, my conclusion was that I needed to re-write it from scratch. So that’s what I said. Like would I not say that – after all that was what was needed!

The answer to my request was a No. As it was my manager that said no (also the same person that wrote it) I was OK, fine I’ll get to work with trying to fix the issues. And yes I did improve it, I got it down from rendering a view in around 2 minutes, to being usable in under a second! I was like brilliant! Every time you make a large leap forward in getting that time down was like a huge win. So all was good – yeah?

No it wasn’t all good

I’d gotten the app down to an acceptable speed, pushed to production, then got the client to use it. They were still not happy? Why on earth were they not happy. It worked just fine (on my machine!). Anyway after a call, I go up to the clients office (for the first time), and within moments of being in the office it was clear why they still had issues. Their machines were archaic, super slow, well out of date machines. There was next to nothing left to optimise now, not a great situation.

What went wrong?

Firstly I should have understood that even though the guy that created the application knew it was rubbish, it was still his rubbish. It was his personal thing and as such someone coming in and suggesting it be started from scratch wasn’t going to fly. People don’t like to be corrected, even when they know that they are wrong. It’s human nature. You have to work at providing the evidence in a clear and balanced manner. Not just – it needs scrapped. Must understand the human element of coding.

Secondly, I should have found out what the client wanted. I should have found out what type of system the user was going to use the application on. After all the first pass of the app was out. The client may have loved it’s look and feel, or equally they could have hated it. Who knew? Not me anyway, and no one else seemed to care either.

STOP

Before doing any large scale of work, you need to stop. Never jump straight into the code, you will more often than not regret it in the long run. Unless your piece of work is for something short lived then you need to plan. I should have done an analysis of what was wrong with the existing app. The cost of fixing it, the timescales required to fix it, the risks associated with fixing it etc. On the other hand I should have done the same, but the risks etc for creating it from scratch using a new framework suitable for the requirements of the client.

With the existing, but broken app being considered a prototype and a stepping stone to making a better application, along with the raw data on risks/benefits etc given and shown to management (not just direct manager), then it would have been much more likely to have been successful when I suggested it needed to be redone.

Even on the basic needs that the users machine and monitors were so outdated, they needed a different solution. It would have cost the client a heck of a lot less to upgrade their PC’s and monitors, but that wasn’t an option. Why I’ll never know. Well I do know – but the reason made no sense, not a bit of it.

Key learnings

Ownership/Trust – I should have trusted in my ability to re-write from scratch the app to make it better. I knew I could, but when it came down to it I still didn’t have the belief to force my opinion to re-write it. Documenting the risks/benefits would have given that mental safety net, as carrying on with the old one wasn’t a viable solution at all.

Know your customer/client – Learn what the client has and what they use. Far too often I hear, it works on my machine. It needs to work on the clients machine.

Stop – Think about why you are doing something, what’s being planned, where is the future of the code going to be.
Life Sucks! Notes To My Younger Self.

Life Sucks! Notes To My Younger Self.

By | | Comments 0 Comment

As a developer, especially as a junior developer things can take a turn for the worse and you probably won’t have seen the blinding obvious coming right at you… Life can seem to suck at times, but like everything, it depends what you take from it.

This is part 2 from the React JS/Finland talk that I had the opportunity to give on the 14th Sep 2022 (https://youtu.be/zE8PDM_7xoQ?t=11416). This sections goes to show that even though I had what seemed like the ideal first job, it really wasn’t.

My first role was to help with the creation of this game! 😎

First Job

So after a year of job hunting, I got my first role in a AAA games company. Exciting – yes, very much so. A large company with 3 separate games being made (in conjunction with other studios). Each team had around 30+ people in it. The place had it’s own arcade booths, we got fresh fruit every day, people would play online games during lunch. Variety of the latest consoles laying around the office. What wasn’t their to like!

Downhill

So in the door and on the whole, people were busy, very busy. They had headphones on and coding away – in the zone so to speak. I recall being shown a list of literally 1000’s of bugs that needed fixing before the game was suitable for release. Of course in those days, you couldn’t update over the internet. What shipped on the disk was what shipped into peoples homes and of course if the game didn’t make the Christmas deadlines for being created that was not a good thing!

So with everyone being so busy, support was next to nothing. I only recall a single meeting with management to see how things were going, and that was early enough for me not to really give a good opinion in it. Recall many times scratching my head, wondering what was happening with the code, but everyone had headphones on and ‘in the zone’. As a junior, certainly didn’t feel like I could/should be interrupting the other dev’s to ask ‘silly’ questions. None of the senior dev’s would ask how I was going, or if I required assistance.

Could it get worse?

Yes it could! Due to the main team being in the states (we were based in Scotland) and infrastructure issues (20 years ago, transferring 2-3GB of data nightly was problematic at best) the whole team had to fly out to the states in order to complete the game on time. But I was about to get married, so I couldn’t go…

So now I was working US hours, essentially on my own in a mainly empty office. But I was getting free food/dinner as I was working late, and I was still doing some dev work, just nothing really meaningful. Trying being a jnr in a code base many 1000’s times bigger than anything your experienced from university, it’s not documented in any way, PR’s and unit tests were not a thing, even source control was very sketchy.

Coasting

But did I see any of the above as an issue – NOPE! Why not, well I just didn’t have the experience. I thought once the team get back from the States, I’d get properly into the code, be able to ask questions, do some learning etc.

I knew things weren’t great, but at the back of my head, I was sure it would pan out and be fine!

Did that happen, nope… Redundant soon after Christmas 😢

Hard lessons

Looking back it was clear from the start that the company wasn’t interested in me. I was a number to allow them to get what they wanted. A decent company that hires a junior dev will never just leave them to flounder on their own. They will mentor and guide them. The simple fact that there was zero support was a simple and clear warning. So if this is your experience right now or at some point in the future – what to do?

You need to invest in yourself. They will not care, so you have to make the time to pull apart the code base. Dig into it framework, put tests around items and generally if anything looks different/new learn why. This is hard, but take it in small chunks. Create a small app and slowly copy parts of the larger code base into it to get them working in a context you know and control.

Managers

Always support a junior developer. If you happen to be a workplace that loves music to code (most of us do). Then make sure that you take off those headphones to ask how it’s going. Don’t just accept a – ‘yeah all good’ response. It’s easy to do so, as you’re busy and if they say they’re fine, then great, you can carry on with your important jobs… Make sure that they are good. Junior dev’s are the people that come with energy, enthusiasm, new ideas etc, you need to channel that into something meaningful.

As an aside, over the years I feel that the gain you think you get from being in the zone with headphones on and banging out code – is actually a downside. Yes being focused is great, but often being out of reach regularly from your fellow developers is not good. One place I worked got the balance right, but that will be explained in part 4 of my talk review.

Junior devs

You can’t learn effectively in isolation. You need a team around you, you need a variety of experience. If that isn’t there then it’s time to look for an exit strategy. Be preparing your CV, go looking to see who’s looking to hire etc. Get preparing small demos, learn the usual interview questions as so on.

At the same time you should and need to be more vocal in asking questions. Never stop asking questions, don’t keep asking the same questions, but do keep asking questions. It’s not only good for you to learn, but at the same time those you’re asking the question off will also learn. If something isn’t clear – is it a good bit of code? If it isn’t, then perhaps it needs refactored. Sometimes it’s good to discuss an area of code that hasn’t been touched in years as you’ll have forgotten it’s purpose. Either way it’s not a one way street when you ask questions. So as a senior developer, I welcome questions.

Spread and Exclude

Spread and Exclude

By | | Comments 0 Comment

The other day I wanted to log out some values of a large object. But one particular property was massive and not needed. So how could I pass all of the original object minus that one property that was going to get in the way?
As in how to exclude a single property from a object.

Solution:

It’s a very simple and I think elegant solution. so here it is.

Using the spread operator you can list the specific items to copy first (these will then be excluded) then use the … rest operator to copy the remaining items.

That’s it! It telling your code what to specifically copy first, those will then not be included when you use the rest operator. Brilliant!

const bigObject = {a: 1, b: 2, c: 3, d: 4, e: 5, f: 6};
const { a, ...copiedAndExcluded } = bigObject;
// copiedAndExcluded is now the same as bigObject, expect it doesn't have the property 'a'.

Also in my case the bigObject was a property of something else, which at times may have been undefined. This will cause an error, as you can’t spread undefined.

const parentObject = { a: 1, bigObject = undefined, c: 3, d: 4};
const { a, ...copiedAndExcluded } = parentObject.bigObject || {};
// 'a' and 'copiedAndExcluded' will be undefined

The `|| {}` will make sure that the code doesn’t try to spread the value of undefined (as that will throw an error). You can however spread an empty object. The values that come out will be undefined, which in my case was just fine.

Cycles of Life – A Cautionary Tale!

Cycles of Life – A Cautionary Tale!

By | | Comments 0 Comment
“Those who do not learn from history are doomed to repeat it.” (George Santayana)

Having been around the software world for more than a few years you see the same cycles time and again. That rather old phrase of “those who do not learn from history are doomed to repeat it.” comes to mind.
Teams grow and shrink and all going well grow again, prepare for it, so you can mange it.

More appropriately this should be called –
Cycles of Life a Software Team – A Cautionary Tale!

Software and the teams around them are on the whole very versatile and nothing is really doomed. It will probably just slow (hugely) you down or cost someone a shed load of cash to sort out 😛

We’re entering a new year, all going well your team is looking forward to growing, so keep the following in mind!
When you know what to look for then hopefully you can do something about it.

Team growth

  • How big is your overall team?
  • How big are the individual teams within the overall team?
  • How quickly has the team grown?
  • How quickly do you want it to grow?

These questions are key to figure out what will happen. The following has happened on more than one occasion and in completely different teams.

How quickly have you grown?

You are an awesome start up, your idea is a massive hit with the investors, it’s time to grow, grow, grow!
BRILLIANT!

Here’s the thing, the software industry has a HUGE staff churn rate. Even the best companies will struggle to keep staff for a long time. You must be prepared for this.

Your team has grown from 10 to 30, maybe even 50+ in a very short period. The buzz around you encourages others to join. Nothing better than a greenfield project to work on.

Here’s the rub, all those new staff will be very likely to leave in very quick succession after 18-30 months, once the first goes. Sure some will stay on longer, but also some of the core team may also leave. Through no fault in the team or the project, but just to go experience something else. This is completely normal in software teams. Especially once a senior long standing member goes – look and plan immediately for other to leave.
There is virtually nothing you can do to stop the flow, just accept it will happen and deal with it.

So what!

I’ve hired before, I can hire again. It’s all fine. It’s just a coupe of people.
If it’s not already clear, the short life span for a developer in one place, means if you hire lots in quick succession, they will leave in the same fashion. Unless you are still actively growing, you’re in for a bump!

It’s the wave effect

This point in time, you are no longer a start up, you no longer have a greenfield project, you no longer have the ability to just hire another dozen developers.
Also notice and look for a bit of a build up, like a wave really. Their is a feeling of general minor grumblings. Nothing major, but then once someone goes, curiosity and a question of ‘is it greener over there’ without something to cancel out these thoughts means that inertia to leaving is broken.

Managers, why?

I have to admit failing to understand this point, but senior management never wish to replace a member of staff leaving right away. They seem to like the thoughts of, well it’s only 1 person out of 40. We’ll make do without them.

Sure enough, the team does, it’s only 1 person. But that wave is building up in the rest of the team. Then the 2nd, 3rd go. By which time those leaving encourage others to go, maybe even taking there mates with them.

Know your market!

Depending on how quickly you can hire. Every market is different and you need to know where you are.

  • Maybe your company is in a software hub of a city and hiring isn’t an issue.
  • Maybe your company is in a software hub, but part of a structure that makes hiring a labourious process
  • Maybe your company is in a remote area as far as getting a pool of developers is concerned

Essentially how quickly can you get people back in that door. Are you ready to take staff out of their day jobs, plough through CV’s, then do a fair amount of hand holding to get the new staff up to speed?

Even in the best situation where your company has a low bureaucratic process for hiring, you develop in a good cultural hub/city and you have the finances to pay a potentially larger staff bill (generally a case of the best way to get a raise is to move on). You will have to take team members of active duty for transitioning in new staff.

Recommendations

  • Plan for people leaving – it will happen.
    If you quickly back fill a space, it will reduce the desire of others to look around. Anything fresh is a good thing, even a new face aids.
  • When you know it will take a 3 month minimum period to hire someone, never leave it for 3 or more people to leave. If you do then then even if you start hiring, those seeds of change will have sunk in already.
    Really if 3 people have left and you’ve not started looking, then you’re guaranteed that others will be on the way out (and in quick succession too, esp if they we’re all hired within a similar time frame).
  • Do not ignore unhappy staff – they’ll just leave quicker.
    You may well, and quite possibly completely disagree with your staff members reasons for being unhappy, but it’s often an open market.
    Do you want them to stay or not? If not, plan for them to go. If they stay, great, if not, then you are ready.
  • Ideally always look to the weaker area in the team. Have a range of CV’s coming in and keep the top ones for reference later. If you have potentials ready to roll, then anything you can do to reduce a gap is crucial.
  • Most importantly it can take a number of months to gain enough domain knowledge. The longer you leave it to re-hire folk,this will increase the risk of crucial knowledge being lost, which will likely lead to a major issue that could be solved quickly, but only if the domain knowledge was retained.

Finally…

Stop focusing on just the technical. You need to be a team, personally as much as just work colleagues. This is SUPER hard, sometimes you want nothing more than to just do the work and go, but…

  • The grass isn’t always greener on the other side! So keeping your staff happy, when they go, they will spread the good knowledge and practices of your team.
    This can even aid in then getting new staff in, but it can also mean that staff can and will come back! Having been in many different companies, the programming world can feel like small circles at times. Just because someone left doesn’t mean they won’t wish to come back.
Array’s – Reducing all duplicates

Array’s – Reducing all duplicates

By | | Comments 0 Comment

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.

JSON.stringify

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
"{"brand":"Ford","colour":"Black"}"
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

By | | Comments 0 Comment

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.

VS Code Version
Moving from IntelliJ to VS Code

Moving from IntelliJ to VS Code

By | | Comments 0 Comment

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.

Coverage

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.

WARNING/TIP

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

Intellisense

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.

Why all the changes in my Package-lock file?

Why all the changes in my Package-lock file?

By | | Comments 0 Comment

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.

Explanation of the Caret

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.

https://github.com/npm/npm/issues/20891 – Essentially the question I was looking for.
https://github.com/npm/npm/issues/20434#issuecomment-402988364 – 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

By | | Comments 0 Comment

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.

Communication

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.

Routines

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.