Category: Working

Contractor Chronicles 4

Another week contracting, this one spent working on a tricky bug and some thoughts on the new Angular features

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.

 

2016 – Wasn’t to bad

2016 wasn’t too bad for me, considering that a few years ago around this time I had just got out of hospital, I had blood clots in my legs and a kidney that hardly worked.

2016 started with me getting 2 Ionic freelance projects. I’ve always wanted to go 100% freelance specialising in Ionic mobile development. So getting 2 projects at the start of 2016 was a great start.

Unfortunately the bad side of freelancing soon followed after these two projects finished. Late paying clients, and no other work on the horizon meant that my freelancing ‘dream’ soon died as I had bills to pay and no income.

So I went back to contracting. I spent about 4-6 weeks in mid-2016 looking for a new contract, eventually I got a new contract in central London, but unfortunately it was a terrible contract and I left 4 days after starting.

The people I was working for were working in a terrible way, they had all their developers in one small room, with Project Managers asking for updates every 5 mins. There was no sprint planning or anything in the way of good development practices. I had a bad feeling about the place after one day, so I was glad to be out of there as soon as I could.

This did mean I still had a few more weeks without being paid. Thankfully some of the late payments from my freelance work came through so that helped.

Eventually I got a new contract working for a great company, building their new Angular based website. As part of the team we managed to get the new version of the site out, but then went straight into a long cycle of bug fixing.

Generally bug fixing can be fun, it’s a challenge to find the cause of the problem, then working on a way to fix the issue. But 5 months of solid bug fixing meant I wanted to look for something new.

So now I’m working on a large Angular 1.5 project for a well known brand, when the site’s live I’ll be posting who they are. This is my first project using the new Angular 1.5 components based approach, which I really like. Being able to moduralise everything, making everything a separate component is a challenge to get started (especially unit testing components), but once past this using components seems like it is the best way to build apps. Lookign forward to getting into Angular 2 very soon.


So 2016 was alright, a couple of hickups with late payments and taking on a terrible contract, but the end of the year has got a lot better.

My plans for 2017 are continue on this large contract (which should take me to mid-2017) I’m also planning to build a Ionic 2 app as a side-project in order to learn Angular 2 and hopefully get some Ionic work towards the end of the year.

Chasing your own tail

Working on the internet is great, it gives people around the world a level playing field in which to achieve their goals. A single developer can start a simple project with only a laptop and a internet connection and within a few years they can be in charge of a massive global company. But the internet is also a crazy place with it’s rush to get the latest technology out there, the newest framework, the ideal way to build an app or the latest social network.

As someone who works with the web I find that somedays I am spinning around like a dog chasing it’s tail (which is always funny) trying to keep up with what’s new or to find out how a new technology works. For example here’s a list of technologies I currently have an interest in:

  • Angular 1
  • Angular 2
  • Ionic 1
  • Ionic 2
  • NodeJS
  • ExpressJS
  • Sass
  • Less
  • Firebase
  • Bootstrap
  • Responsive Web Design
  • Mobile app development

Some list, it looks like one of those job ads that list everything but really tell you nothing about the role. This is another list of technologies a modern web developer could look at:

  • React
  • React Native
  • NodeJS
  • Express
  • HapiJS
  • Angular 1 & 2
  • Ionic 1 & 2
  • AppCelerator
  • NativeScript
  • Sass/Less
  • RWD
  • Native iOS
  • Native Android
  • jQuery
  • Ember
  • .Net framework, all of it
  • Git
  • PHP
  • Rails

This is a long list, it’s taken me a whole day coming up with the list let alone spending time learning these technologies.

The problem that the web has is that it’s become a massive marketing playground. Large technology companies are telling developers that there technology is best, that it does everything a developer will want or that the latest version of their technology is coming out with these amazing features.

Then there is social media telling developers about what they should be looking into, what is going to be the next big thing over the coming year. Or which technology/framework all new projects will be built it so you ‘must’ be using this or you’ll miss out. Then there is the recruitment industry that likes to tell developers that their clients are looking for developers who can do this (see list above).

It’s crazy.

I remember when I started working on the web all you needed was HTML, CSS and JavaScript, that’s it. These three technologies are still around, see central to working on the web.

In order to stop feeling like a dog chasing it’s tail (see it’s mad) I need to focus on a few things, Angular, Ionic, JavaScript, Sass, HTML and GTD. By narrowing down what I’m looking, by specialising what I do it’ll make me a better developer.

So now I need to go into my RSS reader and Twitter and remove the feeds and accounts of things I think I should be interested in and just have a few feeds on these technologies and a follow a few Twitter accounts.

The web is great, but it is also crazy being able to specialise is better than trying to learn everything, that’s impossible.

A great book about this is Philip Morgans – The Positioning Manual