Tag: freelancing

Update your package.json file for better tests

By default Angular gives you a couple of commands to run:

npm run start
npm run build
npm run watch
npm run test

These commands get you up and running, you can run the app in the browser, build the final version and run tests in run once.

I like to add a few more commands to my package.json file, these extra ones are:

npm run test:watch
npm run test:coverage
npm run test:ci
npm run lint

These commands give me more options for running my tests, in watch mode, with code coverage and in both watch mode with code coverage. There is also a linting check, which is always helpful for code quality checks.

The full commands in package.json look like this:

"test:watch": "ng test --watch",
"test:coverage": "ng test --code-coverage",
"lint": "ng lint",
"test:ci": "ng test --watch=true --browsers=ChromeHeadless --code-coverage"

Out of all four new commands the most essential one is the test:ci one, which runs my tests in headless mode (which is great as I don’t want to have the Karma runner opening the browser all the time) gives me an overview of all the code covered by tests.

While something like NX will give you more options and use Jest, being able to run these commands in a Angular CLI based project does make running tests easier leaving no reason not to write tests.

Top 10 tips for contractors

Here are my top 10 tips for contractors. I’ve been lucky enough to be contracting now for over 10 years, working with a number of great clients. Over that time I have learnt that there are a couple of tips that I feel contractors should know. They are:

1. Have good interpersonal skills – no matter what tech stack you work with or the type of companies you work with. One thing that you will always work with is other people. You may think that you can just sit at your computer and write the best code ever without being disturbed, but that won’t happen. You need to work with others, discuss ideas with others, listen and maybe advise on how to solve problems at work, maybe help developers who are just starting in their career. You will need to be able to speak to stakeholders and project managers, explaining what it is you are doing, and the most important reason you need to have good interpersonal skills is you need to come across well in the interview. Usually the interview stage can be a one step process so you have that one chance to convince the client that not only can you help them but you will fit within their team.

2. Be good at communicating – this is related to the first tip, showing how important I feel it is, but being good at communicating is essential. You need to be able to speak to all the members of the team you’ve joined, explaining how you are going to solve their problems. You need to show that you are engaged and enthusiastic about the project and the work and this is done through how you communicate with the team. Engaging in meetings, being happy to talk to non-technical team members all help show that you are a real part of the team, even though this maybe be for a short while. I’ve found that contractors who are good at communicating usually get their contracts renewed and other members of the team enjoy working with.

3. Always be learning and willing to learn – while soft skills are extremely important the technical skills you have are as important. If you can’t do the job you’ll soon be found out and the contract will end. A big part of contracting is keeping your skills up to speed, meaning you know about the latest techniques, you have the skills you say you have (there is nothing worse than a contractor who has lied on a CV and can clearly not do what they said). You also need to be willing to learn from others while working on a contract, don’t expect to expect your ‘way’ of doing things (how you build an Angular app for example) be the only way things should be done, yes you have been brought in to help the client but this may be on an existing project and you need to learn and adapt to how things are done. You can’t rewrite everything just because it’s done differently.

4. Be flexible in your approach to work – this, again, is related to the previous point. As a contractor you are basically brought into a project to provide skills that a team currently doesn’t have or augment a team working on a project. If you are there to provide skills that a team doesn’t have chances are you will be working on the part of the tech stack no one else is working on. So you can then approach the work the best way as you see it, that’s why you are there. If you join a team to augment it then you need to be flexible in your approach to work to fit with the team as they are now.

5. Treat contracting as a business – while contracting can lead to working with a client for months at a time, you aren’t a full-time member of staff and you need to treat your contracting as a business. That means you need to keep on top of invoices, submit timesheets on time, email recruitment agencies, keep your accounts up to date, and pay your taxes on time. You also need to work on promoting your business, making sure that your staff (which is you) is paid on time. There is a lot more to contracting than just the coding so see it as a business that you are the owner, the CEO and a member of the staff.

6. Work with agencies, but don’t be completely reliant on them – working with recruitment agencies is a big part of contracting. It will be, at the start, the only way you get work. There are a lot of negative things said about recruiters, but as long as you realise that they are trying to make money for themselves as part of their business and that it is just a business then you shouldn’t have any problems with them. All they want is to see if you have the skills and experience to fit the job spec they have, if you don’t or the client thinks you don’t then they will move onto the next application. Communication is usually one way, you send your CV and wait. If you hear nothing, don’t wait before moving on to the next application. Unfortunately applying for contracts is a numbers game you need to keep applying and if you do fit a role the recruiter will work with you. This doesn’t mean that recruiters are the only way to find work, staying in contact with old clients helps (again these communication and interpersonal skills come in handy) being part of freelancing and the wider tech community can lead to work. Also open source development can lead to work, but this is a long process. So while at first recruiters are the main way of getting work, as a business owner you need to work on the longer game and how you can get work via other methods.

7. Use downtime to learn and develop your skills and business – there will be time when you finish one contract and there isn’t a new one ready to go. This happens, but this time can be used productively. Obviously you will be looking for the next role, but you can also start learning something new, something you’ve seen that you’d like to know more about, something that may eventually lead to a new tech stack to contract in. Or spend the time writing blog posts or eBooks if that’s something you’ve ever wanted to do. Take the time to get organised ready for the next contract, get all your paperwork in order, emails sent, things you planned to do around the house or conference talks you always planned to watch. Anything that helps grow your skills and your business so you are ready to go when the next contract comes around.

8. Help other contractors, they may help you – as you go through your contracting career you will work with other contractors, and it’s always important to stay in contact with them (LinkedIn is ideal for this). If you are contacted about a role that you might not be suitable for but you know someone else who might be. Then put them in contact with the recruiter, it may work out or not, but helping others means that if they see a role you are suitable for they will think of you. This can lead to another way of getting contracts. While contractors are independent doesn’t mean we can’t work together and help one another.

9. Get an accountant – seriously, get an accountant. You might be the best developer or project manager in the land, but when it comes to the finances of your business you need an accountant to guide you through the complex landscape of tax. It’s too much to know all about the things you do, stay on top of the business side of things and be able to do the work an accountant can do for you so you need one. If however you feel the accountant isn’t providing the advice you need, especially at the start of your contracting career, make sure you have one that does even if this means changing accountant. Remember they work for you, you are paying them, so they need to help you, answer your questions, explain things to you to keep everything on track financially as you will have to pay taxes.

10. Eventually focus on one area to specialise in – as time goes by in your contracting career you will need to think about specialising in a certain area. For example, I work with Angular and other developers work with React or Vue. You need to have a skillset that you are known for, so when someone is looking for a contractor to fill a need they have then your name is top of the list. This specialism also means that you can focus on that, learn more about that than other technologies, you can be an expert in everything. Specialising allows you to market yourself around it, for example you can say ‘I am a Go developer’ or a ‘AWS developer’ this can then lead to specialising further to ‘I am an AWS developer working in the communication sector’ or ‘I am a Go developer specialising in API development for large enterprises companies’ or ‘I am an Angular developer who help companies upgrade their projects and architecture allowing new features to be easily developed ‘. Specialising isn’t something you can start with if you are new in your career as a developer, but if you have been a developer for a while and have experience in the area you are going to specialise in, if you start contracting then you can set yourself up as a specialist from the start. This can lead to people being able to find you, know what you offer and know that you are right for their project.

So this is a top 10 list of things I think you need as a contractor. There probably are more I could come up with and more I could go into depth on these, but if you are thinking about contracting then these are somethings I think you should consider.

  1. Have good interpersonal skills
  2. Be good at communicating
  3. Always be learning and willing to learn
  4. Be flexible in your approach  to work
  5. Treat contracting as a business
  6. Work with agencies but don’t be completely reliant on them 
  7. Use downtime to learn and develop your skills and business 
  8. Help other contractors, they may help you
  9. Get an accountant
  10. Eventually focus on one area to specialise in

Back in the Angular World

After a year-long contract with Vue, I’m just starting a new contract working with Angular again.
It’s strange coming back to Angular from Vue, the Angular eco-system is far more mature than Vue. Angular is more of a platform than Vue, so when you start working with Angular, you find that the framework provides you with a lot more ‘out of the box’ than Vue does.
Does this mean that Angular is ‘better’ than Vue? Well no, they offer different things. Angular is ideal for larger-scale applications and teams, while Vue is great for applications that might not need an entire platform to get started.

The Being Freelance podcast

A few years ago, after working for myself for a couple of years I found these vlogs by a freelancer called Steve Folland. These vlogs showed his life as a freelancer, and the hard work it involved, not only doing the day-to-day work of his business but also managing his business along with managing his family life. It was a great insight into what life really is like for a single-person business owner.

Along with these vlogs, Steve also has a podcast, the Being Freelance podcast, in which he interviews a different freelancer each week to see what it’s like for them to be freelance. He’s nearly (at the time of writing this) at 300 episodes. There are episodes with copywriters, designers, sound engineers, web developers, and all sorts of jobs, but everyone is a freelancer, someone working hard to make a go at running their own business.

In each episode, Steve discusses with the guest how they got started working for themselves, what it’s been like since they started, how they go about finding work and how they balance the amount of work needed to run their own business with having a life. Each episode is full of fantastic advice and helpful tips from each guest. No matter what they do, even if it’s not what you do, you can still get a piece of helpful advice from each episode.

Not only does Steve run his own business and a podcast, but he also runs the Being Freelance Facebook group, where freelancers can get together to talk about freelancing, ask questions, help one another and occasionally arrange meet-ups with one another. He also runs another podcast called the Doing it for the Kids podcast where he, along with his co-host Frankie, talks about running your own business when you have young children and how to balance the two.

I’ve learnt many things from listening to the podcast, from the importance of being consistent with the message you put out there, to making use of sites like LinkedIn and Twitter to promote yourself and your business. How important it is to connect with others and be as helpful as you can, as you never know what effect that can have in the future. Many times a freelancer has helped on a project, which has led to other work opportunities.

So if you are thinking of working for yourself, going freelance, or just started, or have been freelance for a while I highly recommend the Being Freelance podcast, it’s full of great insight and stories from people who may have just started or been working as a freelance for years. It’s all great advice, as Steve says, it’s not about what they do it’s all about being freelance.

(As a bit of side note I was lucky enough to be a recent guest on the podcast, so if you want to hear me um and ah and learn about how I went freelance, then you can.)

Further thoughts on using Vue

I’ve been working exclusively with Vue for the past year, and my thoughts on Vue have changed over that time.

When I started using Vue it was when Vue 3 was beginning to be released and there were many changes to how you should build your Vue3 apps. First, you could use both options API and Composition API, which you still can, but the documentation on how to use the new Composition API was still fresh and there were many questions about this new approach. I found myself refactoring a few components in my application from the Options API approach to the Composition API approach, which while fairly straightforward, was a bit of work to do.

Then there was the introduction of the <script setup> approach within the Composition API, this approach now seems to be the preferred way of creating components in Vue 3, but unfortunately, I’ve used the original approach of the Composition API and refactoring again to the script setup approach isn’t something I can justify. I do think that going forward the script setup approach is the way to go and thankfully Vue allows this mix of approaches.

The second major change in Vue has been Vite and the move to this being the preferred approach to building a Vue app over the Vue CLI. You can still use the CLI, but with Vite and the improvements in its speed of it over the CLI, I think that Vite will soon become the default way to start and run a Vue application. Going forward I will use Vite over the CLi for any new Vue applications I create.

The final change I’ve seen since starting to use Vue is the replacement of Vuex with Pinia as the main state management approach within Vue. The application I’ve been working on does use Vuex and has a few Actions, Mutations and Getters from Vuex, which according to the Pinia documentation can be refactored into a Pinia-based approach, but again like the refactoring work needed to convert my Composition API components to using the Script setup approach, this is a large refactoring piece of work that is difficult to justify to my client at this time. Again thankfully Vue 3 still supports using Vuex even though it is no longer being actively updated and should be replaced by Pinia.

Since starting with Vue, the stack I started with and the stack I would use now has gone from Vue 3, Composition API, Vue CLI and Vuex to Vue 2, Composition API (script setup approach) Vite and Pinia.
This to me, seems the ideal approach for building a Vue app.

Now I’ve been working with Vue for the last few months I’m really enjoying working with it and I think I’ll continue working with it, learning more about using it and the best practices for building Vue apps.

Working with Vue

For the last few months I’ve been working with VueJS instead of Angular and I’ve honestly been enjoying using a new framework.

For the last few months I’ve been working with VueJS instead of Angular and I’ve honestly been enjoying using a new framework.

The things I like about Vue?

Well, there’s the component-based architecture, which I know other frameworks have, but Vue’s approach is very straightforward. There are now modules, Angular had just released a new version which means you don’t need modules, but I haven’t used it yet to compare. So starting with Vue it was nice to see how another framework handles not using modules.

I really like the Composition API pattern for writing components, it is ideal for creating reusable components and writing reusable code through the concept of composables.

The routing library is very good, similar to Angular’s approach, but with the scope to replace it with another version if one comes out ( so far I’ve only seen one library that is for managing the routing in a Vue app).

There is a great ecosystem built around Vue, with a few people in the community doing some fantastic work around Vue. This means if you want to add a new feature, there might be a library or a composable (I recommend looking at the UseVue site for the list of composables that can be helpful in any project).

A couple of things I’m not too keen on

First one is single file components. I prefer the way Angular handles things with the three separate files. If you have a lot of HTML and CSS in your file, along with the Typescript, I find that I am scrolling up and down the file a lot as I work on it. Now that could be because I’ve put a lot in the component and it could be broken down into smaller components, and I know there is a plug-in for VS Code (Volar) that splits the component across two panels making it easier to work with, but I don’t use VS Code I prefer Webstorm. So single file components are not my favourite feature.

Another thing that I’ve found is, that when I started working on this project we were on the beta of Vue 3, and as I continued developing the project Vue 3 was stabilised. As part of this, some of the preferred approaches were set out by the Vue team. For example, the Pinia state management library is the preferred choice, I’m using Vuex. The script set-up tag is preferred to the setup function in Composition API, but I’ve implemented our components using the setup function approach. Now, these aren’t big issues, but it does mean that our application will need to be refactored one day with these changes to match the preferred way of developing Vue apps. That’s not a major problem, just a pain.

Generally, I like Vue, I think I’d like to use it more. I think with Vue 3 you can build really stable enterprise-level applications without having to buy into a large organisation’s way of working. If you want to build an enterprise application but don’t want to use a product owned by either Google or Facebook, then Vue is the framework for you.

Continuing With Vue

I’m looking forward to continuing with Vue, seeing where it goes and using it more in the future. As an approach for building web applications, it’s extremely good, well thought out and supported. As long as there is a community to support Vue I think it will continue to go from strength to strength.

What painting a shed can teach us about writing software

What can we learn from painting

With the world being on lockdown I recently had time to finally get around to painting my garden shed. It’s a job that I kept putting off because I wanted to do other things (like playing Ghost Recon Breakpoint).

Anyway, I finally started to paint my shed and as I worked away on painting the shed, I thought to myself how we approach something like painting a shed can be job could be applied to software development.

Thinking about it there are five rules that you need to apply to paint that also applies to software development. These rules are:

  1. Always prep before starting
  2. Have the right tools
  3. Plan before starting work
  4. Don’t move on to working on a new section until you’ve finished what you started
  5. Practice makes perfect, well better

Always prep before starting

Before starting any project you have to prep. For painting a shed, you have to make sure the shed has been swept, removing all dust and dirt. Then you have to smooth down any splinters or rough edges and then make sure you have planned how you are going to tackle the work ahead.

Have the right tools

If you start trying to paint a shed with a small paintbrush, one that you’d use for painting a small picture. That would take you ages, and after a while, the brush would be useless through it not being the right tool for the job ahead.

The same can be said for the tools you use to build your software. In the Angular world we have tools like the Angular CLI, Karma for tests, WebStorm for writing your code. You can write an Angular application using Notepad, by why would you. Use tools that not only help you write code, but enable you to write the best code you can.

Plan before starting work

I’m not the best painter in the world so I need to spend a bit of time before throwing paint at a shed I need to make sure I’ve spent a bit of time planning what I was going to do.

So Ive learnt of the last few attempts at decorating that it I need to put in some planning before getting started. This involves working out what part of the shed I was going to paint, where I was going to start and what section of the wall I was going to paint.

Having a good plan for what I was going to do before getting started helped me do a better job this time than I had before.

This planning before you get started on a piece of work should be applied to development as well. Whenever you’re about to start a new feature or implement a new section of an application, spending a bit of time planning what you’re going to do before diving straight into the work is always recommend.

This planning , even spending a few short minutes thinking about how you’re going to tackle the problem in front of you, will save you so much time and probably lead to better written code.

Don’t move on to working on a new section until you’ve finished what you started

One thing I decided to do this time was to paint the shed section by section. This way I could keep track of where I’ve painted and move from section to section once a section had been completed.

Again this approach can be applied to development as well. When building a new application, it can be easy to start on one part of the application then quickly move on to the next, just to get the basics of the app setup. To give you the impression that you’ve got a lot of the application up and running, but this is not a great idea. Say you have a target of having 80% of unit test coverage for your app, but you’ve gone off creating screens, adding services and setting up routes. You’ve done all this work and no tests. Now you have to go back to where you started and try adding tests. But in your rush to get a lot ‘done’ you’ve written code that is hard to test!! So now what do you do, spend more time trying to work out how to write tests for code that is hard to test. All that time you think you’ve saved get all these sections done, now you have to spend more time trying to setup tests.

So it’s worth making sure that you have the section your working on completed before going on to the next feature. Yes, from a project perspective it can look like you’re getting a lot done. Your sprint tickets are being moved into In Progress and Done really quickly, but is the quality of the work you’ve done that good? Making sure you’ve finished to a decent level a section or feature of the app before moving on to the next will save time in the long run and the quality of the work you do as a developer is more impressive than moving tickets on a sprint board.

Practice makes perfect, well better

Finally, the thing I did learn while painting my shed was, while I don’t paint sheds as a living I did notice that this time I was doing a better job than the last time. Each time I had to do some decorating at home, it was a perfect opportunity to practice my painting skills and the more times I did this the better I got.

Now I admit my painting skills are not great, but that shouldn’t stop me from trying. The more times I try, the more times I could practice and through this I was getting better.

The same can be applied to web development, the first website or web application you build won’t be perfect, but only through trying over and over will you get better at writing good quality apps. It’s better to keep practicing and trying this leads you to learning new and better ways of tackling problems. Leading to better apps for your users.

A great book on this idea of practising and getting through this barrier of thinking that you’re working isn’t good enough is Steven Pressfield’s book The War of Art where he talks about the resistance we feel putting our work out there, but through getting through this resistance and keep putting work out will we get better at our work.

So while I’m not a great painter and decorator, though taking my time, working bit by bit, using the right tools for the job and not putting off getting the work done. I’ve managed to do a decent job on my shed. Taking this approach can also lead to good quality code, leading to good quality applications.

Freelancing Websites

Over my last few posts I have been talking about contracting and why I personally like contracting. There are two main ways of finding work as a contractor either through recruitment agencies or via freelance websites.

There are many of these freelancing websites, Upwork, Freelancer (UK), PeoplePerHour and Toptal. Sometimes I have shied away from these sites and they are usually swamped with developers offering very cheap services that I cannot possible compete on, full websites for £100 or a complete mobile app for £250. Now I’m not to sure about the quality of the work that these offer would receive, but I can see how a client with a small budget can be tempted with offers like these.

For me to use one of these sites at the rate I’m looking for I need a site that both has a high number of users and has a high level of entry. So the clients who look for freelancers on this site know that the quality of developer they are looking at is at a high standard, and they are willing to pay for this high standard.

One site I have looked into that fulfils these two requirements I have is the Toptal Web Developers group who, on their website, say ‘hire from the top 3% of freelance web developers’. The main reason I like Toptal is that there signup process is very thorough, you have to complete a signup form, give examples of work and even write a blog post about them, which is actually a good idea. Because sitting and writing out your thoughts on why you want to signup to Toptal makes you really think through the process and what you are looking for from a freelancing website.

I’ve seen a fellow Ionic developer Julien Renaux who is on Toptal, I contacted him via Twitter to see if Toptal was a good service, he said that it is and he has had no problems with it.

So if you are looking to become a contractor/freelancer and want to find work from places other than recruiters (who are still a valid and useful resource) then one of these Freelancing websites maybe an option.

Here are some links to podcasts where people have spoken about how they have succeeded using one of these freelance marketplace websites: