It’s useful to look back; it helps you know where you’re going. 2020 has not been a fun year, but we’ve made it through, and I’d just like to give a bit of a retrospective regarding what I’ve done and what I’ve learned. I’m hoping writing this out will help to guide my own future as well as provide some helpful hints and lessons for others. Be warned, though – this post is going to be a little bit self indulgent (even more so than usual). If you’re OK with that, then let’s jump right in.
A History (Thanks COVID)
Entering into in 2021 means that I’ve been in the industry for coming up on 15 years. For most of that time, I’ve held the dream of running my own business, but thanks to a slew of good roles — first as an employee and then as a contractor — the risk never seemed to be worth it. Additionally, I’d always heard that being a contractor was risky anyway, but I had always found myself lucky enough to find work when necessary, or had no need to leave a position other than by choice.
That changed in about April this year. Thanks to the nationwide lockdown and ensuing economic uncertainty, the company I was working for cut my contract short. This proved to be the impetus I needed to jump into this business with both feet, after realising that I needed to diversify and not have all my eggs in the one basket. Luckily, things have been working out so far. There’s been ups and downs, feasts and famines, but we’ve made it to our second year; hopefully, the second of many more to come.
Saying Yes to everything
When you’re starting out, and you need cashflow, what should you do? Say yes to everything and take on every project, of course!
This is not an ideal situation and can lead to a trial by fire, and to a lot of late nights of work. To protect the guilty I won’t say which projects these were, and thankfully there’s only been a couple. The problem usually stems from underquoting in order to win the job. Even in these cases though, I make sure to see the job through to the end and completed to a high standard.
Thankfully as we get more regular clients with ongoing and familiar work we no longer have to pick up such jobs. My advice to younger me would be: make sure to value your time properly. Don’t assume that you’re “too expensive”. And, even if you are, sometimes the client just has a specific budget they need to stick to, and it never would have worked out anyway. There’s always going to be something else, and it might just be around the corner.
Get all the requirements in writing
Lots of projects can start out looking like they’re going to go smoothly, only for extra features to creep in, review cycles to turn up new issues, and, well, for memories to fade and blur, until you and the client are no longer seeing quite eye-to-eye on the requirements. And that assumes that both parties didn’t misunderstand one another from the start. To go into (obfuscated) detail, here’s a specific example:
A while back, I was working on a minor part of a larger project; for this part, the customer wanted the ability to generate a list of data (The List). Due to the nature of the project (data extraction/transformation) they knew it would be difficult (if not impossible), but suggested that it could be done using method A. We discussed this on a video call.
I implemented the solution using method A. It worked OK, but admittedly the resulting list was not as good as it could have been.
In my mind, I had agreed to implement the solution as per method A. From the customer’s point of view, they’d asked for The List with better data results – and were paying for this result, not the method.
They then suggested the data could be extracted using method B instead, which was both more difficult and time consuming to implement. I ultimately redid the implementation using that method without any extra cost to the client, and in the end they were happy with the result.
Now, I’m not the kind of guy to prioritise getting the job done over fulfilling the client’s needs. In this case, though, both sides made bad assumptions and ended up speaking past each other. The client never specified what benchmarks the solution would have to meet to pass muster; meanwhile, I jumped to the conclusion that they wanted that specific solution, rather than a higher-performance solution. Getting the requirements in writing might not have caught these mix-ups, but it would have made both of us think about the terms and given us a shared reference to work off of.
We continued to finish the project with amicable resolution, but it was another lesson for me. Get all the requirements in writing, and be clear if the customer is paying you for a specific result or to undertake a specific task. Customers usually care about results, not methods. If you’re unsure if a method is going to work, be prepared to redo it until you get the desired result.
Throw in the towel (sometimes)
In the trifecta of programming projects, along with great projects that went by quickly and projects that took longer than expected, there are the projects that you just have to stop working on. I’ve run into one or two of those myself. Of course, I’d much prefer to put in the extra hours and get a project over the finish line, but sometimes you and your customer’s visions are so misaligned it’s just not possible.
In one case, the customer was trying to save money and bring some of the work in-house. Specifically, the UX and UI design. This is something I see quite often; given how much the average person uses one every day, even smart people often say, “how hard can it be to draw a user interface?”
Well, it’s harder than it seems. The uninitiated may think that UX and UI design consist of just drawing a picture of what you want the end product to look like, but the difference between poor and great UX design is in the communication. Good UX designers will make developers’ lives easier (and the implementation process quicker) by including navigation flows, interactive elements and commentary on their thought process. Great UX designers can design the elements to fit within the parameters of the chosen CSS framework, working with the dev to hit the ground running.
In the end, the customer was unhappy with the speed of the progress, as I was spending too long trying to decipher and design instead of develop. While I had invested a lot of time, ultimately there was nothing delivered to the customer and we never submitted an invoice.
The lesson here is to make sure you know what you’re building before you start. Sure, you can make a start on the project with some lower level work, on the promise that the UI will come – that’s what I did. But I shouldn’t have begun until the UI that I had to implement was finalised.
Django vs. Javascript
In case you can’t tell, I still like Python more than Javascript. The past year hasn’t done anything to change that; mine is an informed preference, rather than an arbitrary one. Here are some of the takeaways that I’ve come away with over the year:
| Python | Javascript |
|---|---|
| Frameworks There's a good number of Django-using projects available, but very few pure Django projects. |
So many frameworks. Proficiency with React is a great skill to develop; it has been one of the top Javascript frameworks for years, and it continues to grow in popularity beyond Vue, Angular and others. |
| Learning Curve Getting up to speed on Django projects is easy, thanks to PEP8 and the widely-standardised project layout. |
None of the JS projects I've worked on this year have used the same combination of build/package methods (yarn vs npm), code style (line-ending semi-colons or not) or even component style (class vs functional for React). |
| Upgradeable Old Django projects can be brought up to Python 3 and Django 3 without too much difficulty – even legacy projects originating several years ago. |
A Javascript project I'm working on right this minute needs some very significant refactoring because soon, it will no longer be able to compile due to a bad combination of third-party libraries. |
Javascript is vast, sprawling and all-inclusive. This has turned it into something of a “Wild West”, so full of packages, libraries and toolkits that it’s become hard to navigate. Give me the clean orderliness of Django any day.
Other Thoughts and Observations
There’s still a ton of people who want to make use of web scraping, and it’s never been easier to set up wide-ranging web scraping systems.
By default, AWS won’t let you scale infinitely, but if you ask nicely they’re pretty responsive at giving you more resources. You’ll have to pay for your upgrades, of course.
The development barrier to entry is low and getting lower; it’s quick to learn a new stack and build something that works on your computer. Getting it reliably hosted somewhere seems to be where people are more likely to start needing expert advice.
I’ll use this section to list out some of the more interesting work I’ve done this year too, outside of the standard “full stack web dev” work:
Web scraping, web scraping, web scraping!
Building automatically scaleable systems for the above, using a bunch of AWS technology.
Setting up hosting infrastructure.
Zero-downtime site migrations.
Mobile development with React Native.
And written courses. Seriously, keeping up with the times has never been more important.
So many fun projects across different industries. Even when it’s the same tech stack, it gives a fresh new feeling to pick up a project for a different client that’s changing the world in their own way.
What’s in the pipeline for 2021?
Tera Shift is now tracking in a good direction. We’ve got ongoing work with good clients now and in November we hired our first employee. This year we will begin by focusing on projects that fully align with our strengths, while slowly expanding and growing our skills in a sustainable way.
It’s been a long hard year for all of us, and a lot of people are looking to the new year as the start of a global turnaround. Me? I’m really looking forward to writing the 2021 retrospective this time next year.