My freelance journey continues

It has been a couple of months since I began my adventure into the world of freelancing as a Fullstack Developer and it has been quite eventful.  

Whilst I have only been working part-time, due to continuing in my full time position as a IT Service Management Architect, I have picked up a few contracts covering Strapi CMS, ReactJS, PHP and HTM/CSS. Each of these gigs have provided good and bad experiences, which I thought it worth sharing....  

## The Good  

Being able to work on a range of projects, with clients on both sides of the Atlantic, has been amazing.  

I have worked with a Fitness Start-up, an Info Sec org, a publishers and an established legal services firm. Each has brought their unique challenges and opportunities to grow.  

I was able to \"play\" with technologies such as Strapi CMS (which I love), ReactJS with Redis-Server and MongoDB, PHP (which I always enjoy!) and use SFTP and SSH which I have only had limited experience of so far.  

I also found a solid, and completely irrefutable, reason to finally bite the bullet and buy a MacBook Pro (M1 chip of course), when I discovered a clients build would only run on one.  

## The Bad  

Picking up someone else's code and trying to unpick it can be a very hit and miss. This is just life, isn't it?  

However, what is not excusable, is a developer creating a half-arsed build with no documentation so that the next poor developer that comes along (yes, this was me...) has to waste time fixing it rather than focusing on delivering value to the client.  

If you happen to be one of these types of developers then move along...  

## The Other One  

There was one particular experience that qualified for a \"WTF...\" award.  

I had been doing some work for a client and committing to GitHub as I went along.  

Then came time to raise a PR to get the code merged in prep for deployment. It is worth pointing out that Unit Testing had not been possible at this stage.  

So, I dutifully raise a PR and let the Product Owner know so they could progress.  

The following morning I started seeing increasingly more urgent messages via Slack. An issue had been encountered in the production environment. \"Interesting\", I thought, but not for me to worry about as all I had done was raise a PR for Staging.  

Then I start getting direct messages asking me what had I done. So, somewhat bemused, I said what I had done and included a screenshot from GitHub.  

After various frantic calls and a screen sharing session the issue became clear. So I deleted my PR request and after 20 minutes calm had been restored.  

The reason for this kerfuffle was that the DevOps team had set up the pipeline to pick up all PR requests, regardless of status or target environment, and apply them to all environments in succession with no validation or sign-off.  

Well, once I had stopped laughing, I wrote a recommendation for the client on CICD 'good' practice and carried on with my task.  

Is the moral of this tale worthy of the Brothers Grimm? Assume nothing and always question what is meant to happen.  

## Summary  

I am a firm believer that we are the sum of our experiences, and that without 'bad' experiences we never really for a solid view of what 'good' looks like.  

So, treat every day as a new adventure and, even when things get stressful, try to find the funny side along the way.  

Oh, and caffeine... lots and lots of caffeine!  




I did it...

After procrastinating for a while ( ok a long while… ) I finally plucked up the courage to enter the Freelance market and these are my main takeaways so far.  

Firstly it is worth mentioning that the contracts I have picked up so far have all been through upwork.com, I chose it for no other reason than seeing people's positive experiences on Twitter.  

I also, due to still working full-time as a Service Management consultant, only put proposals in for small assignments/projects that I could do in the evenings and weekends.  

**Read the small print** – sounds obvious but most of us tend to skip Terms and Conditions. I mention this as there are charges that are not so obvious when using job listing sites such as upwork.com.  

**Be professional** – whether writing your proposal/cover letter or communicating with your client remember that you are a business. This does not mean that you cannot be convivial but at the same time try to maintain a level of detachment so you can be an objection to the work.  

**Don’t be afraid to say “No..”** – there will come times when, as I found out when you will have to take a stance with a client who is trying to change the scope of the work, on a fixed price contract, without paying extra (scope creep).  

I chose to terminate an agreement with a client after having repeated discussions where they kept trying to shoehorn extra work into what should have been a couple of hours of work at most. I didn’t feel great about doing it but the aggravation was just not worth the £££.  

**If you think you can do it, put a proposal in** – just because you are not a 100% match for the required skills don’t be afraid to take a leap of faith in yourself. Use it as an opportunity to grow your skillset whilst getting paid.  

Expect surprises – unless you get an opportunity to review the code prior to starting a project/assignment expect there to be surprises and added complexity.  

My first assignment was posted as creating a simple PHP template that needed styling to match a pdf design. What arrived on day 1 was a set of complicated and interconnected files that I spent the first 2 hours just going over to understand the data flow.  

Ultimately it was a great learning experience but initially, there was a definite “WTF…” moment.  

So in conclusion I am loving my first few weeks as a freelancer and am looking forward to continuing to learn and grow.  




My first #100DaysOfCode!


Although I was never particularly academic at school, which is a bit of an understatement considering I bombed out of secondary school with but a handful of GCSEs, I have always considered myself a lifelong learner if for no other reason than having to constantly adapt and learn new ways of doing things as a result of my disability.

I started to learn to code in the summer of 2020 and by the end of the year had absolutely fallen in love with coding and being able to build cool stuff.

I wanted to give myself a challenge in the New Year, as let’s be fair 2020 was a pretty rubbish year for most people, and having read about the #100DaysOfCode challenge on Twitter decided that this would be a good opportunity to apply some focus to my learning.

So on January 1, 2021, I formally declared my intention to start my _#100DaysOfCode_ journey and this is the story of how I got on, some of the areas I covered and most importantly the lessons I learned along the way.

If you’re reading this I hope it is of some use to you in your journey.

## WHAT DID I LEARN?

**_Read the documentation_** – it cannot be overstated, and is frequently reiterated in Twitter discussions, then reading the documentation for a language/framework/tool et cetera should be your first port of call when trying to understand what you need to do with your project. That being said the level of documentation can vary quite a lot and you will end up going down rabbit holes and tying yourself in knots when the level of documentation is substandard. Whenever I got to that stage my immediate go-to is Google, as it is very likely that what you’re trying to do has been done before and someone will come across the same problem as you and there will undoubtedly be a whole raft of information, and if you’re lucky, a fix or code snippet that you can use.

**_Pause, rewind and absorb_**… - If like me, you like to learn through tutorials and following others building projects online then you may well find yourself getting lost mostly because the speed at which experienced developers build things during their tutorials/courses is rarely at a speed at which you as the viewer can follow along with and build along with, in parallel. What worked for me was watching the tutor and then either pausing the video so that I could bring my version of the project up to the same level or pausing the video before the tutor started to build something, trying to build it myself and then watching the rest of the video and adjusting my code as needed (you need to be reasonably comfortable with the language or framework to start with to do this). One key point around this is that if you are doing online tutorials then make sure you allow enough time to do the tutorial plus whatever time you think you will need for revisions/pauses and rewinds in your learning plan. I found that I needed to add at least 50% additional time to my plan, but my typing speed is absolutely abysmal.

**_TAKING A BREAK IS NOT A CRIME!_** - Whilst the main premise of the #100DaysOfCode challenge is to get you into a regular behavioural pattern of writing code, so that it becomes second nature, what everyone undertaking the challenge should realise is that it is very important to sometimes just say “I need a break” and walk away for a day or two if needed. If you can maintain 100 days of doing anything without needing a break then fair play to you. I couldn’t and, excluding having to stop for a few weeks due to getting Covid-19, would occasionally take a day off just to recharge the batteries and not feel like I was becoming a slave to the challenge. However what I did notice is that in the last 30-ish days of the challenge I started to become more enthused and, even on a day I told myself I was going to have a break, found myself at the keyboard fiddling about with one project or another.

## RESOURCES I USED FREQUENTLY

Documentation – I have said previously but it absolutely warrants reiteration. RTFD…

[https://www.google.com/](https://www.google.com/) – although it often comes across as a bit of a joke it is an absolute truism that any developer, no matter how senior, will often be turning to Google when they either get stumped all are looking for a new shiny toy to put inside their project. Throughout my journey, I have created a library of bookmarks in my browser, but it’s always worth googling to find what else is out there as the pace of change is unbelievable.

[https://stackoverflow.com/](https://stackoverflow.com/) – I will be honest and say that I have a bit of a love-hate relationship with this website. As a source of information or fixes, it is great, if there is an existing thread on the subject. However, my personal experience, of putting new questions to the community has not inspired me to do it again.

[https://developer.mozilla.org/](https://developer.mozilla.org/) – This is literally the standard for HTML, CSS and JavaScript and gives great examples of how to use the baseline code.

[https://www.php.net](https://www.php.net) – as previous but for PHP, this is a great resource when trying to find out what the language is capable of doing. https://www.reactjs.org – the font of knowledge for the baseline react framework. As with the previous two entries, this is a great source of knowledge if you want to get into react.

[https://www.getbootstrap.com](https://www.getbootstrap.com) – the bootstrap framework is absolutely essential when you are starting out and want to quickly prototype your designs without going into all the detail of CSS yourself. Personally, I love it, and the plethora of templates and frameworks that have been built up around it.

[https://www.cdnjs.com](https://www.cdnjs.com) – if you want to include something in your project but don’t want to install the package itself and this site is a great source for the code snippets that you will need to add in your header or footer for either the CSS or JavaScript inclusions.

[https://www.imagecompressor.com](https://www.imagecompressor.com) – if you are just building little projects to test your code that will only be deployed locally then image compression is probably not going to be an issue. However, if you intend to put your project anywhere near the Internet then compressing your images down to a reasonable size is an absolute must. I tried a few different sites over the last few months and found that this one responds the quickest and gives me what I need without going through the nuisance of creating accounts choosing numerous options et cetera. It also does bulk-load which is great.

[https://www.github.com](https://www.github.com) / Github desktop / GitHub pages – if you’re going to build and deploy code in any meaningful way then you will absolutely need some sort of versioning tool. I opted for GitHub and, although I did learn the basic command lines, choose to use GitHub desktop most of the time for convenience. I also like having the ability to put up Github pages to showcase a project without having to deploy it to our hosting provider, and most of my portfolio runs straight out of Github pages.

Vscode and [https://marketplace.visualstudio.com/](https://marketplace.visualstudio.com/) – there are a lot of code editors out there and the choice of which one you use is usually based on personal preference. After having looked at a few different ones I decided to use VS Code as I like the interface and the extension management capabilities. Currently I’m running with a number of extensions active all of which make my life coding a lot easier. These are:

- **_Auto rename tag_** – which automatically changes the opposite end of a tag when you are editing your code
- **_Brackets pair coloriser_** – I found this to be fantastic so you understand where you are within different blocks of code
- **_code spell checker_** – just because…
- **_Code highlight_** – again let’s you see where you are within your various blocks of code
- **_ESLint_** – great integration if you’re using ESLint in your code
- **_Live server_** – so you can see how your code is working in real-time
- **_IntelliSense_** or code snippets for any language you’re using as auto complete saves a lot of time
- **_Prettier_** – for formatting your code into more readable structures. I found this only works, or it could only get it to work, with HTML and JavaScript
- **_Snyk_** vulnerability scanner as this will run scans against all of your public repos but can also tell you if your code is going to work or not is a will highlight code blocks that are not doing anything or will not work
- **_VScode–icon_** – gives you pretty little icons for your file types, which can be quite useful

other than extensions it is or is worth checking out the different colour themes that are available and choosing one that suits your personal preference on colourisation of syntax.

**Multiple screens** – whilst you can absolutely free amazing code on a single screen I’d thoroughly recommend investing in a least one other screen. My personal setup is a 27 inch screen in portrait mode, a 34 inch Ultra wide and 24 inch that I can pivot to landscape or portrait depending on the need. The ability to have multiple applications open and visible at the same time will help you improve your code experience no end.

[https://www.a11yproject.com](https://www.a11yproject.com) - this is a great source of information and checklists that will help you make your web project accessible to everyone.

## WHAT WOULD I DO DIFFERENTLY?

I have reflected on this quite a lot in the last couple of weeks and I think the only thing I would definitely do differently, and in fact, will do differently on my next #100DaysOfCode, is to engage more with the community and put more effort into engaging by social media channels.

From what I’ve experienced so far the dev community is excellent (if somewhat argumentative, just don’t ask which languages are the best!) and is very supportive of us newbies.

## TUTORIALS I ENJOYED

I spent a lot of time during the hundred days learning from experienced developers through articles, YouTube videos, and tutorials. The bulk of my learning came from tutorials on Udemy.com and I thought I would share the list of my top five favorite courses that I completed during my hundred days.

Each of the below helps to enhance my understanding in terms of deepening my knowledge of specific languages as well as giving inspiration as to the different ways that projects can be built.

- 50 projects in 50 days, HTML, CSS &amp; JavaScript – Brad Traversy

- JavaScript Web projects: 20 projects to build your portfolio – Andrei Neagoie

- React front to back - Brad Traversy

- Django with React an e-commerce website - Brad Traversy

- PHP for beginners – become a PHP master – CMS project – Edwin Diaz

now there are obviously many other great content creators out there so this is just based on my personal experience from what I’ve covered so far.

Prior to my hundred days, I had spent a lot of time in courses and tutorials from LinkedIn Learning which has some awesome courses done by some very passionate instructors and I learned a lot of the basics of HTML, CSS, and JavaScript from these tutors.

We all learn differently so you need to be mindful of the best way that works for you when setting out on your journey.

## WHAT NEXT?

Having finished my first go-round of #100DaysOfCode I’m taking a short break body to get this blog going, but also to think about what I want to do next. At the moment it is a tossup between delving deeper into react or learning Python.

Either way, I know it will be a good laugh I will thoroughly enjoy (most of) it!


Late to the party...?

Since starting to learn to code and spending a lot of time interacting with my peers on Twitter it is fair to say that I have had many moments of contemplation as to whether or not I am too old to change careers and get into coding as a full-time profession.  

However, from my perspective, I think the answer has to be that as long as you are open-minded, cognisant of the fact that to start with you will be heavily reliant on others for knowledge, and have a natural interest in what you are doing and is never too late to start learning anything.  

I started my journey by watching courses on LinkedIn learning, which was provided by my employer, then moving on to sources of knowledge such as YouTube videos and Udemy courses/boot camps all of which I found absolutely fantastic as both sources of knowledge and as inspiration to go forward to build things on my own.  

One of the great things about online courses/tutorials is the references to tools and frameworks, that you have not yet tried or may not have known about, which all helps to enhance your wider appreciation of quite how diverse the tools available to you are.  

I personally found all of these references to different things helped me to map out the areas that I wanted to learn and fine-tune my personal learning experience e.g. you start with HTML then you must learn CSS then to do anything meaningful you must learn JavaScript which then leads you onto frameworks such as React/Angular/Vue can then lead to frameworks such as Django/Gatsby and the list goes on.  

Even having spent the best part of the year learning to code and having built all sorts of projects, some of which even got successfully deployed, it is difficult to get away from the “impostor syndrome” mentality and that I have come into this way too late.  

However, I take solace in the fact that during my career I have changed my profession three or four times each of which meant having a very steep learning curve in order to survive rather than sink.  

Therefore I am confident that I will be able to apply the same to coding and make a success of it, or at least have a really entertaining hobby, build some cool stuff and meet some amazing people along the way. I think unless you’re an egomaniac it is always difficult to believe in yourself 100% but what we always need to remember is that we have come this far so why turn back now…

This is me...


Hi..  

I thought it best that I introduce myself so you can have some idea of who I am, although my ramblings may give that away, and why I decided to start writing and publishing articles about my journey.  

I have been working in the IT industry since the late 90s but, other than a brief stint building a very basic website for engineers to access across GPRS, I am new to writing code for websites and applications.  

I started learning coding mid 2020 partly as a way of relieving boredom and partly to have something to focus on as a way of fighting depression/anxiety.  

I don’t have a particularly technical background but do have a broad understanding of application architecture from all the various projects I’ve worked on.  

I initially dipped my toe into Python but quickly switched to front-end development starting with the basics of HTML, CSS and then delving deeper into JavaScript/REACT.  

As I started to get a reasonable grip of the basics, or so I thought, then I started building more complex solutions using the MERN stack and the Django framework.  

I’ve mostly built little bespoke projects for my own amusement or to try out something that I have learnt, as well as having built e-commerce and CMS, I am talking to you from a Next.js / Strapi CMS / Postgresql stack (migrated from a bespoke LAMP stack) site that I built, applications following online tutorials.  

As New Year’s Eve came around in 2020 I decided that I wanted to give myself a challenge and, having heard about the #100DaysOfCode challenge from Twitter, decided to have a crack at that.
Having recently completed my first hundred days, albeit with a pause of a few weeks due to getting Covid-19, and having thoroughly enjoyed the experience I thought I would start to document my journey both reflecting on the last hundred days or so and going forwards as I continue my learning and efforts to move into a development role full-time.  

So this is me…  

Hopefully will find my posts of some use to you in your journey…


Personal tales from the deep...

My freelance journey continues

I did it...

My first #100DaysOfCode!

Late to the party...?

This is me...

StevenGodson.com