First and foremost, this is not an article to brag about how cool it is to be a freelancer. This is just the cold truth about the issues no-one is talking about. What it can be like, what you need to prepare for, if you consider becoming one. The views expressed here are exactly my own, you are free to disagree and post your ideas in your own blog or another public resource. The goal is to help other developers who are struggling in their career. Help them understand they are not alone with those problems. So let us get started, shall we?
Freelancer’s Public Image
An image of a senior software developer working remotely as a freelancer typically comes with the perks of being able to set their own hours, choosing work and its type. The reality is that in many cases daily responsibilities can only include 10% of writing code and 90% of other churn that nobody wants to deal with. Just like a regular full-time job. So why would you spend 90% of your time working on something you do not want to do? To make the remaining 10% enjoyable.
You see, when you just write code 100% of the time, you do not really know if that code ends up being useful. All correct code is useful, right? Not exactly. It will likely be useful if you understood the requirement correctly. But did the person, who gave you the requirement, understand what they want? Can they explain their thoughts clearly? Is it possible they want one thing, but explained another? Is it possible that two developers listened to the same requirement and understood it in two different ways? Totally, each of these and all of them combined are possible.
So what do I spend my 90% on, to make sure the remaining 10% is actually fun? Here is a list.
Code Reviews
Doing code reviews for all teams, explaining to senior developers with 20+ years of experience, why this code, despite being correct, should be changed, to keep junior developers happy and prevent future rewrites or performance issues.
Why some old code, despite being correct, should not be used as a base for future work. Why code, despite being published online as a correct solution, is wrong in the current context. Why a solution that worked for them 20 years ago is largely outdated and does not fit user expectations in 2020.
That having a wall of text is a bad programming approach despite this is how most code was written 20 years ago. Why certain programming patterns cannot be carried from one language into another (example: working with types in C# vs Typescript).
How it is possible to look at code for <5 seconds and know it is wrong, even if it took them a week to write. And how to easily fix it in 5-10 minutes after them spending a few hours on it and finding it impossible.
Coaching
Coaching other developers, this includes talking to people in writing (review comments, slack) as well as verbally over slack or meeting software, to explain why their first and only working version of code is not the best in the world. Even after 20 years of experience. That if they make the same mistake 3 times in a row and I noticed it 3 times in a row, I am not picking on them.
It is just that others only made the same mistake once. You know, those who actually learn from their mistakes. Maybe it is time to stop waving the “20 years of experience” flag and start paying more attention to work and less attention to self. Think twice, cut once.
Requirements
Talking to analysts / product owners and convincing them to change requirements in order to decrease scope and speed up feature delivery. Explaining user interaction patterns common in 2020, and hinting that their expected behavior is not just difficult to implement and impossible to maintain over long term, but also users will not be happy to work with it. Because all other software is doing it one way, and this is another.
Why we need to document requirements as a state change process, from A to B, vs “it should work like this”. Why a requirement should include typical workflows associated with it. Adding screenshots, UI mocks and any other graphical context to requirements text. People tend to think more when they produce drawings, probably because one picture is worth a thousand words.
Estimates
Analyzing requirements in regard to estimates for work, finding gaps and ensuring work can be completed correctly, from the first attempt, without blockers due to missing acceptance criteria (AC) or common sense / mutual understanding. Telling someone to document their findings after spending 50 hours on a task. With 0 result. At least one paragraph (what have you tried?). Anything helps me on that 1 hour journey to the fix.
Knowing when to insist on bumping up the estimates, despite everyone else considering it a simple task. Using project’s past successes and failures to correct estimates, predict outcomes and course correct. Make sure strong coders are not pulling the blanket towards their experience, past successes or charisma.
Meetings
Sitting in architecture meetings, mainly listening, and trying to understand the gaps, i.e. what is that one thing that everybody does not understand / realize and it is crucial for a successful implementation. Knowing whom to pick for a 1 on 1 discussion after a meeting to ensure a productive outcome (things moving forward).
Knowing whom to consult if I have a seem-to-be good solution, to bounce off ideas and figure out if it will be accepted by everyone as a way to go. It might be perfect, and it might live the test of time, but no-one will approve the code to find it out. So trying to be proactive with those issues that usually come up in a code review, before today becomes the delivery date.
Leadership
Encouraging team members, often very talented developers, who are artificially belittled and slowed down by more senior folks, only because they cannot properly explain their ideas. Showing how to come up with a better solution and keeping them happy when they fail to produce one due to time constraints, lack of experience or otherwise.
Helping QA when they are stuck on a task due to missing information. Helping team and/or scrum master classify a task and thus avoiding generic triage queue.
Helping point to a workflow that despite looking legit, using empirical evidence, ended up totally worthless and wasting everyone’s time. Leaving more time for important things. Letting everyone decide, not just the loudest folks.
Final Words
The list can go on. The point was highlighting the pain points that everyone has a gut feeling about, but either afraid, or do not know how to say, or when to say it, or finding the right audience. This is an internet resource with free and anonymous access, and hopefully by means of google and other search engines, you have found what you were looking for and can resonate with it.
