DEV Community: Dan Spratling

Reusing ideas to supercharge your projects

Dan Spratling — Wed, 20 Jan 2021 13:28:33 +0000

Don't waste time creating the same idea over and over again. Here's how I work smart, not hard, by reusing ideas across many projects.

This article was originally posted over on danspratling.dev, where you can see more articles about going freelance and my career.

Any idea only used once, may as well be not used at all.

Working in the tech industry is hard. This isn't news to anyone. Having good ideas are also hard, so why should we make our lives harder by forcing ourselves to think of new ideas all the time?

But copy and paste is bad, right?

Well, sometimes.

As a designer, developer, copywriter or in any other creative job role we'll always find that there are things which are very similar. Copying and pasting content has its uses, but when we decide to do it should depend on what we're doing.

When we should

When we are reusing an idea in the same project, it makes sense to ensure that that idea is easily repeatable
When we are reusing ideas across multiple projects, we can also repeat what we've done before to save time and allow us to create a better overall product

When we shouldn't

We shouldn't ever copy and paste while learning new techniques, as it will hinder our understanding.
We obviously shouldn't copy and paste others work unless we've been given explicit permission to do so. If in doubt, check
We shouldn't try and reuse ideas which don't fit with what we're trying to do. Forcing a square peg into a round hole won't work.

How we can use it to our advantage

So if we can repeat ideas within projects as well as across projects, how do we make the most of this?

Saving time in advance allows us to compound improvements. This means that the first time we make something it will be fairly basic, but the more we reuse it the more we add until it has a lot of features which apply to a lot of scenarios. Depending on what we're working on, we might even get to a point where we can say we're "finished", which means that copying and pasting that thing provides us with almost everything we could need.

And having this set up in advance makes us faster. We can deliver requests faster spending more time on new ideas rather than always having to reinvent the wheel. More free time means we can spend that learning new approaches, making improvements to other areas and advancing our careers or businesses.

Applying this to real workflows

I've been using this approach for years to help enhance my workflows. I've worked in agency for years and having my own component library which I could reuse across clients made making changes substantially faster.

Since starting freelancing, I've noticed the power of reusability even more and regularly use

Email templates

Whether we're sending out invoices, , or just setting a professional email footer, or a variety of other repetitive tasks we can use email templates to speed up our workflow by having preset text which only requires minimal changes. We all wish we could get less emails, so we can at least take the effort out of replying to many of them.

Component libraries

Buttons, heroes, banners, navs. Websites all share a lot of similar components and often (especially when working within a niche) these sites will use these components repeatedly. So there's no reason for us to rebuild them over and over. If lots of websites use a similar style we might even share the libraries between sites.

Website templates (themes)

Even whole websites can be reused and we can select prebuilt themes from many website builders like WordPress, Shopify or Webflow, and we can even create our own. This means websites can easily be spun up in as little as a few hours if we're working with approaches which are very similar, such as informational sites.

There are many more things which can be reused if we search hard enough.

The real benefits

Of course, just reusing elements isn't a benefit, but it sets us up to make far more improvements down the line, and take advantage of them.

We can spend more time focusing on our career
We can learn new techniques further improving our knowledge
We may be able to take more time off
We might earn more by reducing the time taken

These wont apply to everyone. Some apply more to freelancers. But regardless of who you are, what you do or where you work there will be some benefit for optimising your workflow.

Work smarter, not harder.

If you'd like to keep up to date you should follow me on Twitter where you'll be the first to see my newest blog posts (and more).

Is Import or Require better for JavaScript Modules?

Dan Spratling — Wed, 13 Jan 2021 13:46:02 +0000

Import and Require are both valid ways for including JavaScript Modules, but which is best? Find out what the differences are and which to use in your project.

This article was originally posted over on danspratling.dev, where you can see more articles about going freelance and my career.

I've been creating websites for years, but have never thought too hard about how i actually include my libraries. Is there even a right option? Which approach should you use?

The different ways to include

There are a few different ways which you can include files in javascript. You probably use whichever approach you're most familiar with, or whichever the documentation tells you to use.

We can require modules which includes them in our application

const path = require('path')

but we can also import them

import path from 'path'

After importing via either method, we can use the library in our app which works the same way for both include methods.

//join is a function offered by the path library
path.join(__dirname, filename)

In terms of usage, there isn't much difference here.

How including can affect performance

Above, we are including the entire path library just to use a single function, but path has a lot more functionality than just that one function and including the entire library to use a single function is inefficient.

We can include just the functions we need with both methods

const join = require('path').join

import { join } from 'path'

Both of these again will work in the same way as before, but now we can drop the library. When using either method there's no size difference (both will include just the join method from the library as well as anything join may depend on).

// now we don't need to specify path.join as join is included directly
join(__dirname, filename)

One thing to consider is if you have a library with a lot of functions you need to use, the include can be cleaner using the import approach.

// each require is indivudial
const join = require('path').join
const parse = require('path').parse
const sep = require('path').sep

// but we can group includes when using import
import { join, parse, sep } from 'path'

This may be something which impacts your project, especially if it's extremely large but for most projects this will be a fairly minor difference, and there's no file size difference between the two.

It's worth noting that the import above will include the entire library instead of just join if the library doesn't take advantage of modules, making it much less efficient. Be wary of this. If you run into this issue but still want to use import you can instead include only the module using import join from 'path/join'

Compatibility

This is where we start to see some real differences. import was only introduced in es6 (2015), with require being the main way to include packages before that.

This means that if you want to ensure compatibility with older browsers then using require is a safer choice, though most modern browsers support import and you can transpile back to older versions with babel too.

If you're writing in node.js rather than for the browser, then support for import has only been included much more recently, with official support for import only coming through in node 14 (2020), and with experimental support in node 12 (2019).

Futureproofing

As you can imagine, with import being the more modern standard it is built to allow more functionality for your app.

Asynchronous importing

import allows files to be read asynchronously, which can help improve performance when compiling and reading the files. You probably won't notice significant improvements in a standard app, but if your app includes a lot of external files, or the files you use are on a significantly slow connection, this may help

Dynamic importing

import also allows files to be imported dynamically, so instead of including everything you need when the file is first read which may cause a bloated first load it will only include libraries when you need them. For an application which has a lot of functionality behind the scenes like many modern SaaS products, delaying the import of specific functionality until it's needed can have a serious performance benefit for the user

Tree shaking

Another benefit of import is tree shaking. Tree shaking is a term for pruning modules which aren't being used in your app, ensuring that only the code you need is included. While included methods will often rely on other methods under the hood, you likely won't need everything. Using import allows anything which is completely unused to be shaken out so you're only left with useful code.

Of course, all of these approaches will only work if you don't transpile import to act like require so you'll have to give up compatibility on older browsers to gain these improvements.

Conclusion

There isn't really a correct way of including files, but the way you should use will depend on what you're trying to achieve.

require is better if you need to ensure compatibility with older browsers, especially if you aren't sure what your browser targets are.

include is better for most other scenarios, especially if you're trying to heavily optimize your app.

Regardless of which approach you choose, consistency is important as it helps other developers understand what you're aiming to achieve while avoiding

If you're just starting out, and you're not sure which to pick, I would suggest using include. It's the more modern standard, which means you won't be sacrificing anything by using it but if your app needs to support older standards it's fairly easy to convert import > require using a transpiler like babel, which means this is probably the way to go for most users. Just beware of including the entire library like mentioned above when doing this.

Here's what I recommend as the most flexible approach that avoids performance issues regardless of your config.

//for external modules
import { Link } from 'next/link'

//for your internal modules
import Hero from '../../components/Hero.js'
import ArticleFeed from '../../components/ArticleFeed.js'

If you'd like to keep up to date you should follow me on Twitter where you'll be the first to see my newest blog posts (and more).

2020 - The good. The bad. The ugly.

Dan Spratling — Tue, 05 Jan 2021 17:02:05 +0000

It's been a tough year filled with lots of emotions. Here's how the year has been for me - special thanks to all those who helped me through it.

This article was originally posted over on danspratling.dev, where you can see more articles about going freelance and my career.

2020 has been a wild year.

It's not uncommon to think of those in the technical industry being kept inside the whole time, but this year has taken that to a whole other level, where many of us switching to a forced work from home environment with very little reason or ability to go outside.

Not quite how I imagined the remote working revolution to go down.

Career

My career has had a lot of ups and downs this year. I started off the year working for a company I hated, which was stuck in the past with no confidence in any of its employees while expecting them to work themselves to the bone.

I left there in february and moved to a new company working in app development (a new concept for me) which I enjoyed as a new learning experience but the consultancy aspect of the company was strange and it was a very fend-for-yourself kind of environment.

So in summer time, after the start of the pandemic and talks of the company potentially being forced into making me redundant I decided to go freelance. It was something I'd been thinking about for a long time. It might not have been the perfect opportunity, but it was the one I took. I began hyping up the change on social media and finally took the leap in July.

That's 3 different roles in a single year, if you weren't counting

Since then, I've been working on defining my niche and expressing my User Experience focused skillset, but it's been more successful than I'd have ever hoped with loads of freelance enquiries and a lot of work coming through too. A rocky start to the year changed my career path for the better - I don't think I'd ever go back.

And on top of that all, I released my new portfolio in the beginning of December to help boost my freelancing career even more. I'll be continuing to work on this for the foreseeable future. If you haven't seen it yet, take a look.

Social

I started posting on my social media accounts back in March, and since then I've grown to nearly 10,000 followers. I don't post much motivational content, or even memes. I just post what I'm thinking when I think it and still thousands of people enjoy what I have to say, and I'm honestly so grateful.

I never imagined having any kind of social media presence before and I'm still getting used to it. I started off trying really hard, but that's now toned down and I'm being more true to myself on twitter, posting more about things I'm doing and what I've learned than posting things for likes. It's slower growth, but I prefer it. It's more me.

You can find me on Twitter, LinkedIn and Instagram, and I've recently started posting regularly on Dev.to and Medium. Be sure to follow me on each if you like my content.

Personal

With being in on-and-off lockdowns throughout most of the year, my personal life has mostly been put on hold, so not much has changed, but I'm currently looking for a larger apartment to rent - hopefully being able to find something in the beginning of the new year.

Friends, Family, & the outstanding developer community
I would be remiss to not mention a ton of people who helped me get through this year. I wouldn't have made it this far without any of these people.

My girlfriend has given me constant support and that has been extremely helpful, especially in the periods of time where I was unsure about my working situation.

My friends and family have also been extremely supportive and even though I haven't been able to see them much (or for some of my friends, at all) it's been really good knowing that they're there for me.

Chris has been my mentor since my second job. He built up my confidence to where it is today and that's the most valuable asset I retain to this day, and even though we no longer work together we remain great friends and he still gives me support when I need it!

Tom is a more recent connection but has taught me a ton of stuff about the freelancing world. His advice is outstanding, but even in private conversations he's always happy to help out with specific questions I might have. His book, pricing freelance projects, helped me understand the value I could bring as a freelancer and while I'm still figuring out the more specific aspects of that, I would not have gotten off to such a good start without his help.

Annie is one of the kindest people on twitter and has helped me in numerous ways, from using her designers eye to help me make hard decisions on my portfolio, to cheering me up and being an amazing friend.

And there are so many more people who I've become friends with and have made this year much more bearable.

Ro, Devin, Luc, Stefan, Danny, Lors, Eddy, Vadim, Francesco, Simon, Kass, Chris, Tadas, Laura, Sarah, Anna, Mads, Jack, Marc, Catalin, Nehemiah, Florin, Adrian, and the elusive "Frontend Dude" and there are so many more I interact with regularly who I'm so grateful to talk with. Give everyone in the list a follow - I promise you won't regret it.

Round-up

This year was a tough year, and I know that I had it better than many. What with the Black Lives Matter movement, #ENDSARS, and of course the pandemic there are a lot of emotions going around. Whether you're struggling with being kept inside, furious at the world or have even lost a loved one you haven't been able to see, my heart goes out to you. This year was tough. Hopefully next year will be better.

If you'd like to keep up to date you should follow me on Twitter where you'll be the first to see my newest blog posts (and more).

I rebuilt my portfolio website twice this year. Here's why.

Dan Spratling — Wed, 16 Dec 2020 16:39:00 +0000

I rebuilt my portfolio website twice this year.

I know how that sounds.

So why did I build my portfolio twice in one year when there are so many other things I could have been spending my time on?

There are a few reasons...

This article was originally posted over on danspratling.dev, where you can see more articles about my website, design and development process and other projects I've worked on.

Learning how to design

I often use my portfolio website to test out new ideas and concepts, and one of my biggest challenges this year was learning how to design.

And what better way than to redesign my own website?

Specifically, I was learning how to use figma - an awesome cloud-based design tool

Using Figma to design a full website from the ground up helped encourage good working practices like theming & componentization.

Could I have done a better job? Absolutely.

But I learned a lot

Understanding the core of how figma works will only make my design process faster in the future and allow me to practice more complex skills next time around

And for a first attempt using figma, it turned out pretty well with the finished website clocking in at over 700 likes on Twitter
// Detect dark theme var iframe = document.getElementById('tweet-1335897887427923971-50'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1335897887427923971&theme=dark" }

Learning new technologies

A portfolio is the perfect place to try out new technologies which are interesting.

It's large enough to get really stuck into the new tool (or tools) but small enough to not be overwhelming or too complicated to understand what's going on.

I build my new portfolio using NextJS, TailwindCSS and DatoCMS and before starting the project 3 months ago I'd only used each of these a little.

Using my portfolio to practice new skills means I'm able to demonstrate my experience to clients with a real project to back that up so while I was never too worried about learning these tools, practising with a project which matters helps encourage me to understand each tool deeply as I care more about the results.

Skills which can then be passed on to my other work resulting in even higher quality builds.

Going Freelance

This was the primary reason I decided to rebuild my website from the ground up.

Going freelance meant a big change to my primary audience, where potential (and repeat) clients become the top priority for my website. My new website needed to show clients exactly what I'm capable of and make it easy for them to hire me.

Fellow developers are still a core part of my audience, but they became my secondary audience.

And this change meant my old website was almost entirely useless for my new focus, so if I was ever going to rebuild now was the perfect chance.

Combine this with a need for a new design and a desire to learn new technologies and a rebuild was the obvious choice.

When should you rebuild your website?

If technology has progressed a long way since your website was created and you haven't been actively maintaining it, it's worth considering a rebuild. A fresh start always feels great but it likely isn't always the right choice.

Benefits to rebuilding from scratch:

You'll likely clear off your technical debt, making the solution far more manageable
It's an opportunity to try out new things, especially on smaller non-consequential projects

Downsides to rebuilding from scratch:

It's a lot of effort and very time-consuming!
It's harder to test where problems have been solved when you start from scratch

If you need help rebuilding or maintaining your website, or deciding which option is best for you then get in touch

If you'd like to keep up to date you should follow me on Twitter where you'll be the first to see my newest blog posts (and more).

How I make $10k per month after only 3 months freelancing

Dan Spratling — Fri, 11 Dec 2020 10:49:10 +0000

It's rare that freelancers talk openly about money preferring to keep our experiences to ourselves. I'm different. Here's how I grew my business to earn $10k per month within my first few months freelancing.

This article was originally posted over on danspratling.dev, where you can see more articles about going freelance and my career.

In the 3 months I've been working as a freelancer I've gone from working 1 week in a month to earning double the salary I made at my last job, and I wouldn't have been able to do that without understanding my value and taking the risk required to create a business on my own.

Disclaimer: My earnings and expenses WILL be different from yours, and many things can factor into these figures including experience, location, industry, and project type. Trends are far more important to understand than figures, so focus on that more than the actual monetary value. Figures are converted to USD for easiest comparisons but note that I am based in the UK so tax and other figures will reflect that.

How did I get here?

I started freelancing in July 2020. We were in the middle of a lockdown at the time, due to the Covid pandemic, and I was on the verge of being made redundant from my current firm. I'd been considering freelancing for a while, so I'd been doing my research and figuring out the best way to approach the change, which I've written about here.

For context, my salary before going freelance was £40,000 per year, which is around $53,000 (both numbers are before tax).

Breaking down my financials

Income

So far I've worked for 2 clients. One as a once-off project and one which is a continuing long-term relationship. For my first 2 months, I only worked for a single week, but for the third month, I worked most days which you can see in the graph below.

Month	Income
July	$1,451.00
August	$0
September	$2,852.00
October	$9,705.00
November	$8,296.00
---	---
Totals	$22,304.00

While these numbers look great, keep in mind that we're only looking at the good part. We still need to consider all of the expenses which come with running a business.

Tax & Insurance

As with all businesses, I am charged tax on my income. This means that I do not get to keep everything I earn. A good estimate is to keep 30% of your income aside to pay for tax and other government expenses. I like to be cautious so I actually save slightly more than that, as I will not know the amount to pay until the end of the tax year.

Month	Income	Tax (est 30%)	Income after tax
July	$1,451.00	$435.30	$1,015.70
August	$0	$0	$0
September	$2,852.00	$855.60	$1,996.40
October	$9,705.00	$2,911.50	$6,793.50
November	$8,296.00	$2,488.80	$5,807.20
---	---	---	---
Totals	$22,304.00	$6,691.20	$15,612.80

Business Expenses

Of course, no business is without expenses. Especially one starting from nothing. Most of the expenses incurred were "optional", by which I mean I did not need to purchase them immediately and as you can see, I waited until I had work (and therefore, income) lined up before buying the larger purchases. I could have delayed these purchases until I had more income if required, at the expense of some performance or ergonomics.

July - Largest expense: Learning materials at $24
August - Largest expense: Software Licenses at $131
September - Largest expense: New laptop at $3315
October - Largest expense: New desk/chair setup at $530 each
November - Largest expense: Learning materials at $53

(All expenses have tax included in their price)

Month	Income	Tax (est 30%)	Income after tax	Expenses	Income after expenses
July	$1,451.00	$435.30	$1,015.70	$35.00	$980.70
August	$0	0	0	$183.00	-$183.00
September	$2,852.00	$855.60	$1,996.40	$3,513.00	-$1,516.60
October	$9,705.00	$2,911.50	$6,793.50	$1,133.00	$5,660.50
November	$8,296.00	$2,488.80	$5,807.20	$106.00	$5,701.20
---	---	---	---	---	---
Totals	$22,304.00	$6,691.20	$15,612.80	$4,970.00	$10,642.80

Of course, business expenses are not the only expenses to worry about when working for yourself. You also need to consider personal expenses - you need to buy food and pay rent after all. Just covering your business expenses isn't enough. Ensure you are earning enough to cover both your business and personal expenses.

On average, my personal expenses are around $1600 (£1200) per month so it's essential I earn more than this. Personal expenses are always something to consider when calculating how much your freelance business needs to earn, as you still need to earn enough to pay your bills and effectively pay yourself a wage. Below is a new graph, taking personal expenses into account.

Month	Income	Tax (est 30%)	Income after tax	Expenses	Income after expenses	Income after personal Expenses
July	$1,451.00	$435.30	$1,015.70	$35.00	$980.70	-$619.30
August	$0	$0	$0	$183.00	-$183.00	-$1,783.00
September	$2,852.00	$855.60	$1,996.40	$3,513.00	-$1,516.60	-$3,116.60
October	$9,705.00	$2,911.50	$6,793.50	$1,133.00	$5,660.50	$4,060.50
November	$8,296.00	$2,488.80	$5,807.20	$106.00	$5,701.20	$4,101.20
---	---	---	---	---	---	---
Totals	$22,304.00	$6,691.20	$15,612.80	$4,970.00	$10,642.80	$2,642.80

Summary

These graphs may look like they are getting worse and worse, and over the course of 5 months, I've not made a lot of money considering how flashy "earning $10k in a month" sounds. I earned very little for the first 3 months due to the time and effort required just finding the work. These are only the first few months of freelancing, and this is why starting any business is hard, and it's always possible for there to be more periods where I don't have much work.

I needed to improve my setup and order some new equipment (an ergonomic chair, desk and a new laptop) which were a significant cost but could also have been delayed if necessary and did not have to be as expensive as the ones I chose. I could have opted for cheaper equipment or delayed the purchases if I was worried about the expenses. These are expenses which won't occur for another 3-5 years, however, so this upfront cost doesn't concern me.

With the major expenses now paid for, all further income can be used for future business growth and ensuring stability.

If you'd like to keep up to date you should follow me on Twitter where you'll be the first to see my newest blog posts (and more).

How I found my first freelance project

Dan Spratling — Mon, 21 Sep 2020 11:40:47 +0000

Your first project is always the hardest to find. This is the story of how I found mine.

I've been working as a freelancer for 3 months now and I get asked a lot of questions about how I found my freelance work and how others might find work for themselves. I've decided to share the approach I took finding my first project, my experience with it and the results.

How to find freelance projects

There are many ways you can go about finding freelance projects, and each might work for different people. When I started freelancing, I made it known across my network. I reached out to friends and family asking them to recommend me to others. I spread the word on social media, showcasing my skills through the public development of a new portfolio website. I got in touch with previous workplaces offering my services on a freelance basis.

There's no right answer on how to find freelance projects, and some people have success with many different approaches.

Close friends and family
Previous workplaces
Social media
Cold calling, either in person or via email outreach
Freelancing platforms (upwork, toptal, etc)
Referrals

You can use any or all of these to find your first project (and many projects after that).

My first project came through twitter.

My first project

It took me a few weeks to get my first project. After reaching out to others on the channels I mentioned above I had a lot of feedback, with people getting in touch wanting help with their projects.

So I had a lot of calls and talked through the ideas proposed (I used Calendly to schedule these). Some projects I could help with, some I couldn't. For those where I could help, I wrote proposals demonstrating how I'd approach fixing their specific problems.

Some people dropped out at this point, which is expected. Some just want to know how much their idea would cost. After a few calls, I found my first client.

The project was Pigeon Loans, which you can read more about in the Pigeon Loans Case Study on my website.

How to choose the right project

When going for your first freelance project, you want to make sure you pick something which is right for you. Whether you get a lot of interest or just one person, if the project isn't right for you then you should be wary of taking it.

There's something to be said about learning on the go, and a lot of projects will present you with opportunities to learn new things, but if something is far out of your comfort range it might not be the project for you, or you might spend far longer than expected actually delivering what you promised.

Becoming a Freelancer

Dan Spratling — Mon, 27 Jul 2020 18:43:08 +0000

It was time to make a change.

I've been struggling to thrive in corporate environments for a while. Lots of meetings, very little team-play, or having poor leadership. Some of the workplaces I'd been in had been toxic, others just couldn't accommodate the growth I was capable of. Whether big or small, I'd been held back working for other businesses and I'd had enough.

It was time to take back control.

This article was originally posted on my blog. Some of the links contained within are affiliate links, and I would be extremely grateful if you choose to support my content if you find it helpful.

I started researching, as we all do when making a life-changing decision (I hope!). I gathered as much information as I could, looking for ways to make a living as a freelancer. Many of my friends had been freelance at some point so I asked them for help, either by asking for advice or through referrals.

Finding clients

Asking for clients through friends and family was a great way to get started. I only found a couple of clients this way, but it's a great boost into the freelance world and gives you a little more freedom to try things out as friends and family are more likely to help you find your feet (mistakes matter less).

Twitter (and other social media platforms) can also be a great way to find clients. This is likely to be more successful if you have a larger following, but reaching out and offering assistance, showing expertise, and proving yourself will help you gain a following very quickly if you don't already have one. Social media can be free advertising for you if you use it wisely.

Some of the most helpful tips

I managed to garner a lot of help from the freelancers I knew, as well as from the reading I was doing.

Always make a great impression.
As a freelancer, one of the best ways to find more work is word of mouth. Doing a great job attracts more jobs.

Code is only a part of your value.
As a freelancer you aren't just writing code. That's not where your value really lies. Your value is in your expertise. For me, this is my ability to really understand users and find solutions that others aren't able to.

Don't charge hourly.
Similar to before, charging hourly presents you as a commodity. By charging hourly, you communicate the message that your value comes from your price, and not the impact what you deliver has for your client.

Take payment upfront.
Where possible, take complete payment for the job upfront. Everyone's heard stories of various contractors doing a bad job and then running, but it happens in reverse too.

Make contracts.
They're boring, I know. But if a relationship does go south, then having a contract in place means both parties know exactly what was meant to be done, for how much, and by when. Nobody complains about a little security.

Always be marketing.
When you start out, this is obvious, but as you gain work it can be very easy to forget that there will be no work lined up later. Always make new connections.

Always be networking.
At some point, I guarantee that you'll be asked to utilize a skill you don't have (or have no interest learning). Finding people who do have these skills in advance makes it extremely easy to work with them later.

Work a regular routine.
Even when you don't have work on right now, you should still stick to your usual routine. Routine helps keep you efficient, and working when you have no contracted work means you can do your own side projects, more marketing, or any other business requirements you're missing.

Don't forget to take breaks.
The whole point of freelancing is freedom, so don't get stuck working 12 hour days, and remember that you can take breaks whenever you want without feeling guilty.

Some helpful resources

As with all new experiences I undertake, I did some reasearch beforehand to understand better the leap I was about to make. These learning materials helped me greatly to gather a deeper understanding about freelancing or helpful skills around freelancing.

Becoming a Better Freelancer.
A free & quick guide giving you crucial tips on how to become a freelancer. Also check out Tom's super helpful thread or his book on how to price freelance work.

Start Freelancing Today.
Kelly's personal study on her journey into becoming a freelancer.

Study Web Development.
The all-inclusive guide on how to become a freelancer, including everything you'll need to start.

How to get followers on Twitter.
Not strictly a resource for freelancing, but given how important twitter was for my new career path, I'd be amiss to leave out Danny's excellent guide to Twitter and the benefits it can bring you.

My experience so far

So far, my experience with freelancing has been great. It's definitely proven to be the lifestyle I want. The freedom and flexibility it brings are excellent, and I don't think I'll be able to go back to working for a company.

Just a little of my experience so far:

I've made contact with 8 clients in less than 2 weeks.
Over half of these leads came through Twitter.
I've agreed to my first contract after excellent discussions with the client, and received payment.
I've lost 2 leads, but it can't be expected that every lead will be a perfect fit.
I've had the freedom to work on my own projects.
I haven't had the frustrations of poor management or hangups from other developers.

Conclusion

Going freelance is a scary experience. You no longer have the safety net, and you're entirely in charge of your own destiny.

Having control over your career, who you work with and what you work with is an amazing feeling.

If it's something you've been thinking about doing, consider taking the leap. It might just pay off.

If you'd like to keep following my story, I post regular updates on Twitter, so follow me to keep up to date. Newsletter subscribers get early updates so if that interests you then sign up for updates.

Understand recursion in 2 minutes

Dan Spratling — Mon, 06 Jul 2020 10:27:15 +0000

Whether you've been in programming for a long time, or just starting out, you'll have heard of recursion, but it can be hard to wrap your head around.

Recursion is the act of something repeating itself until an escape is found.

Let's create a function which we can use recursively. I'm going to create a function which allows us to multiply a number exponentially - multiplying a number by itself.

const multiplyExponential = (number, power) => {
  return index !== 0 
    ? number * multiplyExponential(number, index - 1)
    : 1
}

Recursive functions don't have to be complicated, though they can be harder to write as it's a different way of thinking. So what's going on?

// create a function and pass in the number we want to multiply, and how many times we want to multiply it.
const multiplyExponential = (number, power) => {
  return power !== 0 
    // if the calculation hasn't completed, we return the number multiplied by the value returned from the function
    ? number * multiplyExponential(number, power - 1)
    //if we're at the end, we just want to multiply by 1 so nothing changes
    : 1
}

multiplyExponential(7, 4)
// 7 * 7 * 7 * 7 * 1
//<- 2401

Warning! When writing code you don't want to create an infinite loop, you need a way to stop eventually. Make sure you always have a way to escape.

Recursive functions have a fancy name but aren't too different from regular functions. The key difference is that it is a function which calls itself - and that's it!

Mathematics is a great place to start learning about recursive functions but they can be used in other areas of web development too. I've used recursive components to create navigation menus with nested menus.

Fix your portfolio: Common issues I found reviewing your portfolio websites

Dan Spratling — Mon, 29 Jun 2020 15:39:40 +0000

This article was originally created for Twitter. If you like this, you'll probably like my other posts too, so go ahead and give me a follow on twitter.

I spent this weekend reviewing your portfolios, from developers of various skill levels.

Dan Spratling 🚀 UI & JavaScript Dev

@dan_spratling

I've had a lot of compliments about my portfolio site.

Thank you so much! 💕

Today, I'm here to give back.

I'll give you a quick review of your site and tweet replies with improvements you could make.

Share your site below 👇

16:01 PM - 27 Jun 2020

It was great fun, and I got to see a lot of awesome sites. Unfortunately, I couldn't get to everyone so I compiled a list of the problems I found.

Dan Spratling 🚀 UI & JavaScript Dev

@dan_spratling

This weekend I did a lot of portfolio reviews for people of various different skill levels.

There were a lot of small problems with easy fixes which occurred a lot.

So, in order to solve them for everyone, here are the most common mistakes I saw, and how to fix them.

🧵👇

10:05 AM - 29 Jun 2020

These are mostly small issues across a broad range of topics, and they are things that won't take long to improve but will give your site that extra polish making you stand out from the rest.

This is what I most people needed to fix.

Accessibility (a11y)

<button> and <a>

<buttons> and <a> tags are not interchangable.

<a> tags are links to pages, documents, or positions within a page

<buttons> are interactive elements within the page.

Typically, you want to be using an <a> if you have a URL to go to, while you would use a <button> for an element which is interactive, but doesn't go somewhere, like a form submit, carousel arrow or tab heading.

The confusion comes from the class name .button or .btn. It's commonly used to represent something which looks like a physical button.

Using the class .button does not mean the element should also be a <button>.

Semantic HTML

If you're still using <div> to represent everything. Stop.

There are elements which can represent your intention better.

<nav></nav>
<main></main>
<aside></aside>
<article></article>

Screen readers announce what the type of content will be if you use these. In the case of some things, like <button>, they come pre-configured with all the interaction states you might need.

It also helps you navigate your code, as these names are so much clearer than 10 nested divs.

outline: none;

When you click on something interactive, you'll see a border appear. It's big and blue (in chromium browsers) and doesn't fit with your design.

It's also very important.

Could you navigate your screen without a mouse?

Keyboard only users use outlines to show which element is the current focus. You can change it to match your design, but if you remove it entirely that's effectively the same as disabling the mouse.

Don't do it.

Try using a keyboard to navigate any website. Don't touch the mouse. You'll see how important an outline is.

Colour contrast

Whether you have a light or dark theme on your website, or you've filled it with lots of colours, make sure everything is readable.

Colour contrast is exceptionally important as colourblindness is one of the most common disabilities faced.

Both chrome and firefox offer colour contrast checkers in their inspectors. Use them. Make sure you get that AAA rating.

Content & Copy

Getting in touch

Do not underestimate the power of a contact form.

It's quick. It's easy. Users don't have to leave your site, and they can't mess it up.

It always beats all other forms of contact.

Make sure you're using a contact form as your main form of communication.

Avoiding spammers

You'll want to be a lot more selective about which other forms of contact you choose to use.

An email address is fine.

But for a personal website, you don't want to be adding your mobile number or home address.

Don't make it easy for spammers or malicious people to get ahold of your personal info.

If you're going to give that information out, make sure you've established a connection via another means first.

Stop hiding your projects

I was reviewing portfolio websites, but in a lot of cases when viewing the portfolio section of the site I was seeing images covered in an overlay, or no images at all.

You're hiding the thing I want to see most. You're a developer. I want to see your work.

So show it off.

Add images which show the work at its best.

Add links to a live view of the project.

Add links to the GitHub page to see your code.

Pick a (vernacular) lane

You need to pick how you want to present yourself to people and stick to it.

In the case of a portfolio, it should be written almost entirely in the present tense in the first person.

You're trying to sell yourself, so you want to feel like a real human being.

This may change slightly if you have a blog (first or second person) or if you're talking about your projects (past tense) but as a general rule, you need to be consistent.

You're in charge. Act like it.

One thing everyone seems to forget is a portfolio is a way to sell yourself.

You're an expert in yourself, and the things you've created.

But many people present themselves with too much modesty.

This translates to uncertainty and if you're unsure about yourself, so is the person who's looking at your site.

Write with purpose

Your website has a goal. For a portfolio, this is likely to be used to get job offers or to get freelance work.

All of your copy should be written with that in mind.

You are taking your users on a journey and your contact form is at the end of that journey.

Make sure you convince your users to fill it out.

Design

Responsive design

It's 2020. Make sure your sites work on mobile as well as desktop.

Don't over-do it

It was immediately clear which users were confident with their designs, and which weren't.

Those without design experience did everything to the extreme.

Too many layers. Too many colours. Too many borders.

Minimal design is a beautiful thing, and for developers who are new to design, it's quite straightforward to implement yourself and make look nice.

Having a clean minimal site is far better than standing out with a bad one.

If you want to create something awesome and unique then go for it but start off simple and work your way there.

I'll often use resources such as Dribbble or UI Design Daily to find designs I like to take inspiration from for my own.

Utilize whitespace

Another beginner design issue. Many of the designs had as much crammed into as small a space as possible.

15 projects on a screen. 40 icons showing all the technologies you know & the tools you use all squeezes into a small panel.

It's much better to give things space to breathe. 4 of your best projects displayed in a space large enough to fit them is better than showing everything at once.

Don't overwhelm your users. Give your content space to breathe.

The importance of consistency

Your users will build mental models of how your site works as they navigate the site.

Headers are large and a different colour. Links are rounded buttons with uppercase text.

Changing this breaks their mental model, making it harder for them to use the site. Changing these models often leads to frustration.

Keeping the design consistent makes your life easier too. You only have to think about one design for each element type.

Don't forget the small things

Small alignment issues, spacing issues or colour differences build up.

Your users might not be able to explicitly point out what the problem is, but their subconscious will notice that things are slightly off.

Giving your site that final sweep and making sure that everything lines up nicely and is as you intended makes a big difference.

Make it shine. Your portfolio is intended to impress.

Performance

Image optimisation

Images are often the largest files we load on our websites.

In order to make sites load quickly, we need to reduce image size as much as possible.

Don't serve users images 4x too big. Don't add in unnecessary detail they won't appreciate.

I always recommend using Cloudinary to optimize images. It has a free tier & works great with any site. (Plus, you'll support me by signing up, even for the free tier)

User Experience (UX)

Take your users on a journey

Your portfolio is meant to get you leads or job offers.

Many people often put the expectation on the user to find their way to what they need.

They won't. You have to guide them.

If you want to convince them you're the right person for the job, you might lead them to your projects. From your projects page, you should make it extremely easy to find your contact form.

Your users shouldn't have to think about navigating your site. You should do that for them.

Social media isn't a goal

Social media and contact forms are often mixed together in one place, but social media is not a good way to contact you.

You're assuming they have social media accounts, and you're leading them away from your website before they've reached their goal.

Social media is more like a newsletter. It's how they keep up to date with your content regularly, and continue being reminded that you exist.

They won't use it to get in touch with you. Give them a contact form.

Don't overwhelm your user

People have short attention spans. If you've made a lot of things, or know a lot of things that's great!

But as a user, I only care about what's relevant to me.

Let me filter your projects. Start with your favourite technologies.

Focus on what you want others to see to give them the best impression.

Give me too much to look at and I probably won't look hard at anything.

Wide content

Wide paragraphs are hard to read.

Lots of eye movement leads to fatigue and makes it very hard to track your position on the page.

Users also have short attention spans and won't focus on your content if you don't make it easy for them.

Consider shrinking the widths of your paragraphs, making them taller instead.

Typically, the rule is if your copy is wider than 2/3rds of your container width, or 800px, it's probably too wide.

Is it ever a good idea to design in the browser?

Dan Spratling — Mon, 02 Mar 2020 16:43:14 +0000

This article was first written on my blog. You can find the original post here: https://danspratling.com/2020-03-02-is-it-ever-a-good-idea-to-design-in-the-browser/

Designing for the web is often a long process. First, you have to establish the goals of your site, the potential users, the theme, and the content you want to display, and you haven't even started creating the designs yet.

Then you dive into each webpage and work out how the content you have will fit on a screen, where to draw attention, and how to get the user to click the button which gets them to buy your product (or whichever type of conversion you are going for).

Then, after all that, you finally start building. Any developer could tell you, even after all this planning, things still go wrong. Things don't work as expected, get missed, or are just impossible because they work on paper but not in code. It isn't anybody's fault, but it happens and is frustrating.

Why are there inconsistencies between design and code?

Often designers aren't developers and don't have any insight into how programmers create things or what limits us. They learn from their experiences, as do we, but are picking up knowledge second hand. They design in grids, but probably don't know the nuances of CSS Grid. They aren't at fault for this, but it does mean there's always going to be some creative control given to the developer to try to match the designs as best as they can.

Designing in the browser

To fix some of these problems, you might take the approach of designing in the browser. You skip the design step (or most of it) and create the site based on wireframes. You would work much more collaboratively with your designer and start adding in customisations after the wireframes are complete. Think a pair programming approach but with a creative instead.

It's faster to implement as a large part of the process is cut out, and prevents you from having to deliver (or backtrack) on promises which can't work in code. The collaborative approach also means you can quickly make changes to things which don't work or look right, instead of waiting for a response (or forgetting about them). Feedback is immediate.

The downside is that it's harder to change once built. Designing in a program like Sketch or XD is faster than writing up code, and when you're handing over a flat design, there's no expectation that the user can navigate around or that things will be functional. On the other hand, clients will often expect a website to be fully functional upon viewing it, even if it's only in the design phase.

Using traditional design

Traditional design methods are still a great approach to take. They're more flexible and more suitable for nailing down precisely what the client without the complexity of coding the site as well. It's easier to make significant changes as none of the functionality is affected at the design phase, which causes drastic changes to be less costly too.

The traditional approach also gives you a definitive end goal, where you know what you have to achieve before you even start building. That can be very reassuring, especially for more junior developers.

On the other hand, that also means the developer has less creative freedom. It's much harder to suggest design changes after the designs are finished and sometimes that makes it harder to be flexible, especially if the client has already seen it.

Which should I use?

As always, you should use the approach which is best for you. In most business scenarios, this will probably be traditional design methods. Still, if you're a freelancer or you're working on a personal project, you could see benefits from designing directly in the browser.

Designing in the browser is an excellent approach for developing side projects. If you're creating a site for yourself, or somebody you know well, then it can save you time and energy. It also means that you don't get blocked as a developer by not knowing how to use a design tool.

Choose the approach which is best for you. Both can be good, and both can be harmful. You need to have a good understanding of your client's needs and maybe most importantly, know how well they understand the development process.

If you enjoyed my article, please leave a like or a comment. You can follow me on twitter to keep up to date with my latest posts & discussion within the development community.

Writing proper documentation. Why is it so hard?

Dan Spratling — Tue, 25 Feb 2020 17:19:27 +0000

We've all been there, searching for a new pattern, UI element, or method. You remember seeing it before somewhere but can't quite remember where, or you've got a great idea that you can't quite realize, or you want to try out a new library. When the documentation doesn't live up to the software it's based on, it drags the whole product down.

Why does poor documentation exist?

There are many reasons we can get documentation that isn't fit for purpose. Project deadlines, developer turnover, or merely leaving documentation until it's too late all lead to poor documentation. On top of this, writing documentation can be hard because developers typically want to be coding, not copywriting. At the same time, documentation is too technical for copywriters to be able to create alone. There are lots of reasons why lousy documentation exists, but it's so critical that there's no excuse good enough not to do it. If you want your software to grow, you have to document it well.

How do you write proper documentation?

Well written documentation ultimately starts right at the beginning of the project. You need to think of how you're going to document what you do, and your goal for the documentation afterward. If you want to share it publicly, you'll probably need an external docs site, some tutorials, and some examples, but for an internal project, you might need less (or you might not). How you create the documentation is up to you. However, two popular solutions are creating a website specifically designed for documentation, or creating git a repository containing lots of well-formatted markdown files.

Content

All well-written documentation should comprise a short tutorial to get up and started with the software and a more robust set of documentation explaining and more in-depth docs showing all the options you have available, what they do, and your choices (if applicable). The best documentation shows instances when you might use these, things to know beforehand, and a few cases with expected results to help you get started. Inadequate documentation only lists functions that are available to you, but not how or why to use them. As a user, you shouldn't come away confused, so document everything you can think of and always give examples.

Navigation

When a user is reading your documentation, they only view it chronologically one time, while they are first learning how your software works. After that, they'll be jumping in and out at different points, trying to remember how things worked, but the order of this won't be logical or even predictable. So navigation should be simple and well structured to allow quick access to what is needed. Links between pages and content within the same page are needed to make finding specific elements just as easy.

Previews

While documentation can be excellent on its own, sometimes it's just not enough. People learn in different ways, and for some, reading isn't the answer. There are lots of different ways you could preview your code, and they differ depending on the software. A playground to test out what you're building without having to set up a code environment, or pre-created apps stored in a repo allowing a developer to reverse-engineer your code can be great, allowing users to see the end product before using it themselves. But don't sacrifice well-written documentation to create previews as previews enhance your documentation but can never replace it.

There's ultimately a lot to think about when writing documentation, but neglecting it is a mistake. It's as important as writing code itself, and a skill to admire among developers. If you're the only person who knows how to use your code, it's useless.

Switching to native app development - Week 1

Dan Spratling — Tue, 18 Feb 2020 13:28:56 +0000

Last week, I started a new job working on mobile apps. Before this I’d only worked on websites so this is a substantial change for me. As you can expect, after only a week I’ve not done too much - some setup, a few bug fixes, a lot of perusing already written code.

Note: I’m creating apps using Vue.js and NativeScript. This may not apply to every development flow, but should apply across all NativeScript projects.

What I've learned so far.

App structure looks almost exactly the same as website structure. node_modules, package.json, webpack.config (and all the other .config files) still exist. App replaces src but contains components, pages, images, store, which you’d also find in a web app.
You still have the ability to use everything you used in web development if you wanted. JavaScript frameworks and libraries, css compilers (sass, less, etc), state management tools. If you can do it on the web, you can probably do it here too.
Emulators are fiddly to set up (but not painstakingly so) as they require changes to your system config. Guides are really helpful.
Other than the visual rendering of the apps (which you can’t use browsers for, but will need to use emulators or connected apps on real devices), your code
Code is not written in HTML, despite looking similar. Instead it’s compiled down to XML which restricts what you’re able to use. <div> doesn’t exist any more but the built in components work in a very similar to way to what you’re used to (GridLayout = css Grid). Here’s a code example which creates the image below (ignoring styling).

<GridLayout rows=“auto, auto” columns=“*, auto” col=“1” row=“1” class=“status-wrapper”>
  <Label row=“0” col=“0” class=“title”>This is the title</Label>
  <Label row=“1” col=“0” class=“subtitle”>This is the description</Label>
  <Label row=“0” col=“1” rowSpan=“2” class=“icon”>Icon</Label>
</GridLayout>

NativeScript Docs

Originally written on https://danspratling.com
Twitter | Github