Comparing output

I recently looked at someone’s GitHub account because I saw that they had recently been sponsored by someone I follow on BlueSky.

Their GitHub account (https://github.com/shuuji3) is very impressive, and I believe that this developer is worthy of the sponsorship they receive. They have been working on documentation for several large projects, made over 1,475 commits in the past year, and contributed to Elk, the Mastodon client.

It’s all really impressive and did make me think: how do they find the time to do all this? Then I easily fall into the trap of comparing my GitHub output with theirs.

It’s easily done, especially now with GitHub being such a big part of the web industry. But does it show a true picture of how someone works or the type of work they have done? And should we really compare our output with someone else’s?

Is working from home working

Today, I came across a news story that caught my attention. It mentioned the ex-head of ASDA claiming that working from home isn’t “proper” working and is causing a decline in productivity. I have to say, I strongly disagree with this perspective.

For me, working from home has been a game-changer in terms of productivity. Let me paint you a picture: Instead of standing on a freezing cold train platform for 15 minutes (or longer if the train is delayed), I can start my day feeling fresh and ready to tackle my tasks. Train operators, who certainly don’t work from home, often fail to deliver on time, which in itself contradicts the argument that physical presence equals productivity. And the experience doesn’t get better once the train arrives. Imagine standing in a packed train, overheating from the stifling heat, only to rush onto the tube and squeeze into another packed train for another 30 minutes. By the time I would reach the office, my energy is already drained—and I haven’t even started working yet.

This isn’t just about convenience; it’s about efficiency. The time saved on commuting can be invested in meaningful work or even in personal well-being, which ultimately boosts productivity. I believe the issue here isn’t that working from home isn’t working. Rather, it’s that some people are still clinging to outdated ideas of what “work” should look like. For decades, we’ve been conditioned to believe that being productive means traveling into the same building, having endless meetings about work, and then heading home only to repeat the cycle the next day. But the world is changing, and so are the ways we work.

I’d be willing to bet that the ex-boss of ASDA never had to endure the kind of commutes I’ve described or tried to code an application while six colleagues stood nearby having an unrelated meeting. If they had, they might see the value in remote work. Working from home is new for many people, but that doesn’t mean it’s ineffective. In fact, it works remarkably well for certain types of jobs and individuals.

The key takeaway here is that we shouldn’t dismiss working from home just because it’s different from traditional office work. Instead, we should embrace this shift and recognize that productivity isn’t about where you work but how you work. Remote work isn’t a one-size-fits-all solution, but for many people and industries, it’s a powerful way to achieve better results and a healthier work-life balance. The real challenge is for leaders to adapt to this new normal and support their teams in finding what works best for them.

Contractor Chronicles 4

This week I’ve spent working on a very tricky bug, not one that required a complex rewrite to solve, but instead one that was hard to find the cause of.
It was on a Angular app that uses a third party system to generate forms for the application. The issue was that where this third party system had been updated it required a change to one of the forms in the application.

It was tricky to solve due to the fact that it needed a lot of comparing files and lines and lines of JSON to find the issue. Thankfully another developer helped me see the issue and I had been looking at it for hours.

It does go to show that it is always a good idea to get a ‘second pair of eyes’ to look at an issue. There’s no shame in asking for help in the end it helps get the problem solved and the work can continue.

The current contract I have should be ending at the end of April, so I’m going to start looking for the next one soon. Changing contracts is always a interesting time, mainly it’s stressful looking for the next role, but it is also a time to think about maybe trying something different.

If I look around on the job boards and LinkedIn it looks like React is the main choice for building web apps. So when this contract is up it might be time to look at getting into React development.
Having said that, Angular is going through a bit of a change. It now has stand alone components, like React and Vue. It has a new system called Signal coming in the next version, which is a new way of adding Reactivity to your application. These two changes alone mean that Angular apps can soon be written using the same approach as React and Vue, but still have all that Angular provides a complete framework with many of the tools you need for an application (like built in testing, routing, an http client and the CLI).

So is it worth looking at React when Angular could be having a resurgence? I’m not sure. I think at the end this contract I’ll spend a few days building a React app to see what it’s like to work with.

What’s been happening at CGCSoftware

We’re into September now and I thought I’d give a small update on what’s been happening behind the scenes at CGCSoftware towers.

The main thing that has happened is I’ve started a new contract working for Cambridge Assessment. Working in one of their teams on a large scale Angular application. It’s an interesting project working with NgRx and Angular Elements to create a more loosely coupled application allowing different developers work on individual sections of the application, but still access the APIs that run the application in a consistent way.

I’m finding working with Angular Elements really interesting, they have real scope to give so much more flexibility in how Angular applications can be set up. Not only are they great for gradually upgrading an AngularJS application to Angular. They allow teams to create individual parts of a large scale application in separate pieces which can be slotted together in the main application.

The second big thing that has happened is that my book, Getting Started With Angular 8, has been released.

Writing a book has been a massive project, it’s taken far longer than I thought it would, but I’ve learnt so much through writing the book.

Not only have I learnt more about Angular, but how to create content for the book. Originally you think that it’s just a simple case of writing out you thoughts on the topic of the book (in this case Angular) but there is so much more that you need to think about. How to structure the chapters, how to make sure the reader is left feeling that they have learnt something, how a section you felt made sense when you originally wrote it, didn’t make sense at all.

Having published the book through Leanpub I can make further updates to the book as newer versions of Angular come out or new features are added.

So August has been busy, I did manage to get a holiday in as well, which was great. Now we’re into September and got another busy month ahead. Looking to work some more with NgRx, while still getting up to speed with how things work at the new contract. Also looking at ways to be involved in some more open source projects in the coming months.

Weeknotes #2

This week has been manly working on getting a first internal release of the client project. So as part of the internal team I’ve been working on a lot of small CSS changes to the Ionic application, giving it that extra polish to make it look as close to the original designs as possible.

What Went Well

The internal app is getting close to being released to real users, even though internal users it’s going to be good to get the app on devices and used by non-developers hands.

Book writing is still going, half way through and it’s clear that writing a book is a slog after a while. Being at the halfway point must be the toughest part. But it has been a great learning experience getting into the depths of Angular.

I also emailed Pete Bacon Darwin, who is a member of the Angular core team, after I heard an interview with him on the My Angular Story podcast. In the podcast he mentioned how working on open source has really helped him and opened a lot of doors in this career for him. So I thought I’d email him to say how I enjoyed the interview and if he had any advice on getting started with open source. And amazingly he emailed me back and said that there are so many ways to get involved, working on projects, writing documentation, answering others questions on Stack Overflow.

So after finishing the book I’ll be working on getting into a few open source projects.

What didn’t go well

Not much really, has been a good, but quiet week. I need to start working on using social media more in order to start promoting myself and business getting ready for my next project.

The business management of my freelance business needs to be something I need to focus on a bit more. Instead of going for one contract to the next, I want to build a lifestyle business instead of having a Limited company for contracting purposes.

As part of this I have been trying to be better organised with both work and personal life. So trying to work on that, but not there yet.

Things I’ve Read

I have read many articles this week, but I have been watching a few YouTube videos. One series in particular is the [Overpass](https://www.youtube.com/user/OverpassApps) Apps channel. Where the owner of Overpass Apps makes a daily video about running a mobile app development business.

Why you should allow developers to write tests for existing code

Is it possible to add Unit Tests to an existing application and if you do decide to add tests to a project, what benefit will this have to an existing application?

I’ve worked on a few projects where the application has been started, the first few features of the app come to life and before the developers realise the application is nearly delivered to the end user, without any Unit Test coverage.
One of the main reasons for this is when an application is started there is usually a tight deadline, or a push to get something out to the end user within the first sprint and there isn’t time considered for the writing of tests. The unit test theory is that a test should be written before any code is written, but with time pressures writing tests is always something ‘we can do later’.

But can unit tests be added to existing code? And what benefit will this bring?

It is possible to write tests for existing code, it is, in fact, a good practice to go through this process for a number of reasons.

It provides confidence that new changes do not break what is already there

First, it stabilises the codebase of the application, providing confidence that any further changes are not going to break the existing code. Once tests have been written for the existing code, developers know that there is a quick way to check if the new feature they are adding is not breaking what is there already. As they go through developing this new feature having the test runner going in the background running all the tests the developer will see straight away if the change they are making is stopping existing code from working as it did before. They will get a red warning, telling them exactly what is no longer work and why.

It highlights areas to developers where code can be improved

The second reason is when writing tests for existing code developers will notice areas where the code can be improved, optimised. When writing a test you need to know exactly what the code you are testing is doing and how it works. Through this investigation, developers will see ways it can be refactored to make improvements. Once this code has been refactored and improved the test will ensure that any further changes don’t break this improved codebase.

Its a great way to onboard new developers to a team

Another reason that allowing your developers to write tests on existing code is it is an excellent way for new developers to a project really understand how an application works. If for example, you have a large enterprise business application, that has many business rules. It can take a new developer to the team to both understand the business rules, but also understand how the application currently supports these rules. If for their first few weeks on a project they are given the task to write the tests for a certain section of the application, maybe an API the application provides or a set of services that the application uses to process user orders. Through writing tests, the new team member will learn, in depth, how the current application works. They will also be involved in how the application is built, deployed, how the processes the team has for committing code, what rules there are in place for writing code. All this they can do through writing tests without affecting the code of the application.

How can tests be added to your existing project?

If you are a project manager or the business owner of an application and your team have said that the Unit Test coverage for the application needs to be improved. There are some things you can do to help this.

Writing tests should be defined as Sprint stories

You don’t need to stop development on new features just to have your team write all the unit tests for the application. This can still continue, but you need to add time to each sprint (if that’s the method you use) to allow the developers time to write tests for part of the application. When it comes to sprint planning have a few stories for writing tests. Prioritise areas of the application where test coverage is low, maybe focus on areas that are more stable, an existing API for example or the data model which isn’t going to change for a while. Assign these write tests user stories to the newer members of the team, so all they can go through all the development processes the team uses.

Improving test coverage can be a gradual process

The existing application doesn’t need to have 100% code coverage straight away. It’s better to add tests gradually as the project progresses, tests can be bought in for existing code. This does mean there is a risk that changes could break another piece of existing code, but if the tests are being written this risk will get less and less the more coverage your application has.

Allow your developers to write tests

When you are planning some work with the team, a new feature to be added. Allow time in estimates for the developers to write tests. If this time is not in the estimates developers will find that they don’t have enough time to not only write the new feature and write the tests. So the tests will start to be left, this will cause the test coverage to reduce over time and you’ll be back to where you were before, with an application that has a lot of functionality and existing code, that isn’t covered by tests.

Your QA team and clients will thank you

Finally, an application that has a higher test coverage, will have fewer bugs. New features won’t cause new bugs to appear in the existing application.
This makes the QA team happy, for them it means that they can be confident that what is already in the application still works as before. They don’t need to thoroughly test the entire application every time there is a release. They can quickly test the existing application and then focus on testing the new features. Any bugs that crop up should be caught by the developers during the development phase when they have their test runner quietly running along as they write code and then warning them as soon as any issues come up. Instead of the QA team raising a new bug.
Having the QA team raise these minor bugs which could have been caught by unit tests, takes time. It adds delays to the latest release of the code being allowed out to the end user.
So if your end users are waiting for a new feature that will greatly improve their experience of an application and this new feature is delayed due to the release not getting past QA because they have to raise a bug for something that has broken in an existing part of the application. The end user will be disappointed, and a happy end user is what we all want.

Unit test coverage is important, it vastly improves the quality of an application, but if due to time constraints an application has been delivered without a high level of test coverage, it’s not the end of the world. By allowing developers to write tests for the existing code, the coverage will grow over time and the quality of the application can be guaranteed when a new feature is released to your happy users.

Why Contracting?
I was asked the other day ‘why I was a contractor’. For me contracting is perfect in many ways. It gives me a good income, as the main earner of a family, this is really important. I also get to work with a variety of clients including football clubs, startups and councils.
I started contracting in 2012, so next year will be my 6th year. This is my longest job to date and I can’t see myself going back to permanent employment (unless Nrwl.io come calling).
Getting started as a contractor is relatively easy. All you need is a Limited Company (though you could be a Sole Trader, a Ltd company is better). An accountant or some type of online accounting software and a job.
Well, this sounds simple, but it’s not.
When I started getting my Limited company involved completing an online form, making a small payment and that was it.
One of the things I did need to consider was a company name. You need something that matches with the services you’re providing, with some flexibility in case you try something new. You don’t want to be called WideWeb Solutions if after a year or two you just make iOS apps.
I wanted something that covered me for web development, but I have always been interested in mobile development. So I went for something that had the word software (either web or mobile) plus the initials of my wife and children. That’s how I came up with CGCSoftware.
So I had my company name and limited company setup, next getting some work.
The reason that I started contracting, I was working for a startup in London as a Flash developer (good times). It was all going well then the company decided to move to America, and get a new development manager. So we had this new manager and half the team went to America, but still, the work was ok.
But soon the new development manager started letting people go, and get in new people that he wanted. Well, eventually it came to my time to go for a quick chat at lunchtime.
So that was the end of that, can’t say I was too bothered as I wasn’t getting on too well with the new members of staff. It did remind me that I don’t want to work for someone ever again. (If you work for yourself, it’s hard to fire yourself).
This is why I started contracting. I wanted to be in charge of my career, and have that flexibility of working on different projects with the technologies I wanted.
AngularConnect a review

Recently I went to AngularConnect, this was my third time and probably my last (well for a while). The main problem with the conference this year was it just seemed like it was going through the motions. It seemed that there was nothing new and exciting in this years conference, maybe I’ve been to too many, maybe I was expecting more from the conference.

Last years conference was great. The new version of Angular was almost released, there was loads of great talks about the new and exciting version of Angular. This year we had version 5, with service workers and server side rendering. Both great features but not the biggest features ever.

I also found that some of the most interesting talks, one about NgRx and strategies in Server Side Rendering in Angular, both great talks, but they were only given 25 mins. These were just not long enough. I wanted to learn how to write better Angular apps, learn from the industry leaders on how to create great Angular apps.

Unfortunately I felt that I didn’t learn enough from the investment I made in going to the conference. These great developers come over, but weren’t given enough time to go into depth about Angular. There were some other talks that didn’t need to be there, they just seemed like fillers.

AngularConnect does offer a lot of other things, yoga sessions, meditation sessions, both great things, but I’ve never taken advantage of them. (I can go yoga classes outside of the conference). They also have office hours, what ever they are, and panels. But I’m not interested in those.

For me a conference should have talks from the best developers, great food and a place to sit down, eat and discuss the topics discussed in the conference.

Maybe I’ve been to too many AngularConnect in a row. A break from it might be in order. Next year I’ll watch the talks when they are online.

Keeping your skill set up to date

As part of life as a contractor one of the most important things it managing to keep your skillset up to date. This was fine when all you had to worry about was just HTML, CSS and maybe jQuery, but now with the explosion of JavaScript frameworks keeping your skill set up to speed is getting harder and harder.

When you look at a job description you usually see a whole list of ‘technologies’ that are required for the role. Angular, Node, React, Sass, CSS, UX/UI skills and maybe ‘if you also know PHP, that’ll be an advantage’. But keeping up to date with all these different technologies is nearly impossible. Two of these are entire platforms and not just frameworks.

So how is a lonely developer supposed to know all these frameworks, platforms and technologies inside and out, as well as work fulltime?

Well one way, and what a lot of freelancers are doing now, is niching down to a certain skill set or role. For example, is being known for creating offline first apps using Angular or creating Progressive Web Apps using Node or front-end development using HTML and Sass. These are all examples of how a freelancer/contractor can narrow down what they do in order to really understand well the technology they use.

Of course, the first thing that goes through peoples mind when thinking of narrowing down their skill set, what we use as contractors to get work, is the fear of missing out on work. If I don’t have the skill set for a certain job, then I can’t go for so many roles, I’ll miss out on work. But if you do a quick search on Google for ‘niching down + freelance’ one of the first articles you’ll find is ‘Overcoming the Fear of “Choosing a Niche”‘ by Brennan Dunn.

In the article he shows why having a niche or being a specialist is actually a good thing for your business/career:

When you go from being a generalist — that is, a provider of some commodity service, like web design — to being a specialist, who solves a specific type of problem for a specific kind of client, three things almost always happen:

  1. You’re able to charge more.
  2. Your clients give you more creative latitude and freedom, and a lot more respect.
  3. It’s easier to close deals.

In the rest of the article, Brennan goes through all the different issues with niching down, about the fear people have of doing this, the fear of picking the wrong niche to work in, dealing with the boredom that might come with only working with one technology.

If you want to read about how other people have found their niche and what it has done for them, this article Top 16 Freelancers Tell You How They Found Their Niche gives some interesting insight.

There are also some great books on this:

 

So in order to keep your skill set up to speed in today’s ever-changing web industry, instead of trying to be a master of everything and ending up a master of none, it might be work just narrowing your focus a little. Finding out what you enjoy working with, what projects you have enjoyed working on and becoming a specialist in those types of projects, using that type of technology in order to really learn and know that skill set.

It something I’m going to focus on doing over the next few weeks months.

 

Freelance Podcasts

I’ve been looking for more podcasts to listen to especially freelancing podcasts. Some of the ones I’ve found include:

I’ve also gotten into watch some freelancers vlogs on YouTube. I started watching more and more after Steve Folland from Being Freelance started one, which lead to finding others to watch.

Currently I’m watching:

While all these vlogs are great to watch, there are a lot of designer ones out there, but not so many by freelance developer ones. I suppose no one wants to watch someone coding with their headphones on.