Mastering Freelancers

Imagine you are creating something. It might be your personal project or a product in a small startup company. Then you run into the situation when you just can’t make a certain task, or you want to spend your time differently. So you decide to give some of your hard-earned cash to someone who can do that particular thing for you. And that’s a freelancer.

Freelancers can do any online task for you. For example build the websites, design work, proofreading, coding, data organization, and much more. And if you are not an expert in that particular area, then many times they can do a faster and better job than you.

There is one catch. If you manage them badly, then you might end up disappointed, without any useful work being done, and shorter of money. And this article is going to explain to you in detail how to prepare work, choose the right person, and manage the project so both of you will end up as a winner.

Preparation

There are main 2 things to prepare – budget and scope of work (SOW).

Regarding budget. Choose a number you are willing to spend. Remove sales tax (typically 10%). Remove 20% from the rest. This is to cover fees, possible up sales, and other costs you are not aware of yet. Convert the number to USD (many times) and the result is your budget.

For example, if you are willing to spend $500. Then remove 10% to get $450. Remove another 20% to get $360. Since it’s already in USD, then $360 is your final budget.

Now, let me give you a rough idea of what you can expect at certain price levels. This is coming out of my experience.

Less than $100 – simple, fast, and non-perfect work. People at this level are usually trying to be as cheap as possible. They don’t have time to do work well, because they need to rush for another gig. You can ask for simple tasks like photo correction, little translation, quick sketches, or a few WordPress pages with a lot of placeholders. I usually don’t ask for any work at this level.

Lower hundreds $, roughly up to $500 – decent work under a standardized process. Here I found a lot of people specializing in a particular area. For example, creating fashion products, 3D models, building websites, proofreading, translations, designing logos, and so on. They can do a great job for you because they have a process in place and probably already did the same thing many times. You just have to make sure that your requirements are aligned with their framework. I like this level because it’s good, easy to reach, and I am not much worried about making mistakes.

Higher hundreds $, roughly up to $1000 – take the previous level + creativity or tedious work on top of that. For example, you can get a new blog + migrate the posts from the old one. Or get a unique graphics created just for you, can be pretty complex. Or a sophisticated piece of code.

Thousand and more – the sky is the limit. Here you can expect very high quality, custom made stuff or a lot of work to be done.

Unfortunately, more players are appearing in this game. They are consultant companies and speculators. Many times they try to offer you significantly overpriced solutions. And sometimes they are able to give you a 60% discount if you point that out. I have never taken that (; Maybe they can do a great job as well, but I prefer to pay a fair price to a guy who is a real freelancer and honest from the beginning rather than sponsor such people.

Finally, if you are working with thousands of dollars (and have appropriate work for that), then it might make sense to start thinking in a different way. You might split work into smaller pieces and hire more people to do the job. And if your budget goes beyond thousands, then freelancers might not be the right choice at all.

Scope of Work

Now you have the money and a rough idea of what is realistic to ask for. The next piece is to prepare the scope of work (SOW). I will describe SOW for a fixed price project type, which is commonly used in a freelancer world. You specify what you want, and then negotiate a fixed price tag to get that. Here you can download an example of such SOW.

This is a real SOW I used to launch my other site – Tyracorn. You can use that as a template. Honestly, some training is required to create these. I personally made a terrible job a number of times. The most disaster was when I just had a single call and said something like ‘basically, eee I want something like…’. Taking that as a necessary scholarship. I want you to be better than me right from the start. Please write down at least some SOW. Anything in writing is better than nothing. Here are a few guidelines to make it easier.

Study a topic. You need to have an overall knowledge of the topic. For example, if you want to build a webshop, then you need to decide what platform to use, what payment gateway to integrate with, knowing how the checkout process works, have an idea how you would like to manage your products, and so on. These are the decisions that only you can make. So start by research, open test accounts in various services, and play with that. Don’t worry that you can’t make it look pretty or fully working, that’s the part freelancer can help with. Learn what various options, constraints, and conditions you have.

Write everything down in a plain language. If it’s not in writing it doesn’t exist. Your next freelancer might be from Indonesia, Egypt, or Mexico. These people don’t have chance to speak in English on a daily basis. Therefore help them by using a simple and clear language.

Prepare a list of requirements. Ideally long list of small and simple requirements. Idea is that you can look to the work submitted by the freelancer, run it against this list, and easily say which points are satisfied and which are not. Then during reviews, you can either adjust problematic points or deal with them in some other way.

Prepare supportive content. Anything like images, sketches, real data, content, and others is good. Put it into a place for sharing. This gives reality to the result. For example, freelancers normally won’t create the actual content for your web site. You either provide that, or end up with a web site which is full of ‘Lorem ipsum dolor sit…’. Happy cleaning then.

Mention paid products and services. I found this interesting. Many freelancers are shy to recommend the paid product or service. Make the decision you want and write the note into SOW.

Write down what you don’t want. For example, I don’t like, when someone is putting hacks into standard frameworks to satisfy 100% of the requirements. Therefore my SOW usually has a point that I am open to negotiate requirements down if they can’t be reached in a clean way.

When you should avoid freelancers

Freelancers are not always the right choice. Here are examples of when to avoid them.

  • If you are a cheap ass and want to have everything for free
  • If you can’t write what you want on a piece of paper
  • If it takes you longer to write down what you want than actually do the job by yourself
  • If you are under a contract which prevents you to do so (e.g. NDA, or employment)
  • If you have secrets required for the job (e.g. you can’t show medical data to third parties)
  • If your project is too big

Selection

With budget and SOW is easy to start looking for people. You can find them on the specific portals, there plenty of them and each of them is a little bit specific. Let me share the ones I have personally used.

  • 99designs.com – this site is for graphical work. Good point is that you post your project, and designers posts their sketches. You can then talk to them and choose whoever you like the best.
  • guru.com – here you can post any type of project. Then freelancers are bidding to do the work. So far, I have a good experience with this site. You just need to be careful. Since there are no limits in terms of work standards and prices, then this is exactly the site where price speculators and consulting companies are very active. So take some time to review and compare the offers.
  • Elementor experts – focused on work with WordPress and Elementor. If you are dealing with these technologies, then this is a perfect place. I was able to look through various portfolios, choose the guy I liked, contact him directly, and get the job done in better quality than what I would be ever able to do by myself.
  • Scribendi.com – focusing on proofreading and editing jobs. You don’t choose a particular person here. Just submit the text and describe what you want to do with that. They give you the price and find the editor for you. I had a great experience with them during editing my Robust Java Standards book.

Register to the site which matches your project, post it there. You might need to do some copy-paste from your SOW, attach only thumbnails instead of high-res graphics, and so on. Also, don’t share your budget unless the site requires you to do that. It’s better when people come up with their numbers first. Once you post the project, then get away from the computer and go for a workout, or date, or whatever.

Once you are done with your workout and date, then the next morning you can look at the offers. There will be plenty of them. If not, then you have posted something terribly wrong, so get back to the preparation and try it again. Now it’s time to make the first screening. This is about answering three basic questions. Is this a scam? Did he really read my post? Can he do a great job? And these are the indicators to look at.

  • Personal portfolio. Even if that person is just starting, then having something to show is a must. It has to be related to whatever job you are posting. If you can’t find it, or you find something broken, then move on.
  • Prove that he really read the SOW. Some people just put a generic bid to anything which appears on the portal. Luckily it’s easy to recognize. If someone truly reads the SOW, then usually react on it somehow. Many times, they write how they can approach the task into a bid. Sometimes they even make a little proof of concept without asking for anything. Or they constructively complain about a particular point in your SOW. Anything like that is a good sign.
  • Easy communication. Freelancer must be responsive to the messages (please be aware of time differences). In addition, his language (usually English) must be good enough to understand. Willingness to make a video call is also counted, but not always necessary. A good test for this is to send a few messages and see.

The process above helps you to select a handful number of people with potential. Pretty much anyone can do the job. Now it’s about choosing the one and making the deal. Simply order them from who you think is the best and try to make a deal one by one, until it actually happen.

One important note here. Make sure everything is written, and if the deal is under some freelancer site, then use whatever chat is there. The most important points to have confirmed in writing are SOW and price for the 100% delivery. Even if you use video call to agree on everything, make a written follow up and ask for a written confirmation.

This is the process to make a deal.

  • Agree on the SOW. Provide a copy, attach it to the system, and ask the candidate to read it first. Be open to questions, or a video call to explain the details. Answer all questions. Sometimes this might lead to a small change, which is ok as soon as it’s recorded. If there is too much friction in there, then it’s better to walk away to the next candidate. If you walk away like 3-4 times, then it’s likely something wrong with your SOW.
  • Agree on the total price. This is what you are going to pay once 100% is done. Every freelancer should be able to give you the number based on agreed SOW. At this point, SOW is fixed and you are not going to change that. You can negotiate as you like, or always walk away to the next candidate.
  • Agree on the payment and delivery schedule. This is usually pretty straightforward. Many times it ends up paying a deposit upfront and rest on delivery. The schedule is usually measured in weeks with expectation that once a week you can see the updates (some people even provides daily updates, but I don’t like to micro-manage).
Once you have completed an agreement with the required follow-ups, then the work starts.

Management

I found this part to be the easiest. All the hard work has been already done and all you need to do is sit back and review whatever your freelancer gives to you.
How to do a review? Take the proposal and compare it with the requirements in SOW. Write down the list of things that don’t match, or are missing. If you are working with things like design, then it’s completely ok to also include points which you just don’t like. People in these areas are used to pivot a little bit, so no one takes that badly. If you can include for example screenshots, or guidance how would you imagine that correctly, then even better. Send that back to the freelancer and wait.
Next, you get a second review. Here you revisit all the points from the list to see whether they are resolved. If the point is resolved, then ok. If not, keep this open in the second review. Then make sure that there are no new points. The goal is to resolve all points on the list (sometimes it’s ok to relax on some of these). From experience, it usually takes me 2-3 reviews to get it right.
Once your list is good enough, then Congratulation!!! Your project is done.

Failures

Unfortunately, not everything is easy in life. There are projects which fail. It happened to me several times, and there is a chance that some of my feature projects will fail as well. In nearly all cases, I can track the failure back to the point where I skipped or simplified something in preparation. Then it hit me back later. Let me share with you some of the stories.

What to do when a project is done? So I made the SOW, hire the guy. He made an amazing job. I thought it’s cool. But… I didn’t have any idea what to do next. If you are hiring a freelancer, make sure to see beyond his work.

Poor quality job. One time I hired one guy to do the particular coding job. I have to admit, that I skipped the point to verify his ability to deliver, and didn’t set up a proper review schedule. That was my mistake. He took forever, always busy in other projects. Then he delivered something which didn’t work and even the quality of the code was very bad. So I pointed this out and wanted to fix that. A few weeks later, same problems. After about 2 months back and forth, I had to cut off the losses and did it by myself. And the deal wasn’t done under any freelancer platform, so the money was gone for good.

These were valuable lessons. The first point I learned is that you can always walk away and find someone else. Don’t be shy to walk away. The second point is that the money you send is almost always gone. Doesn’t matter whether the transaction is done privately, or through some platform. So don’t put too much into a risk, until you see the results.

Conclusion

Freelancers can save your time and supply the skills you don’t have. You just need to give them money and manage them well to have a win-win deal.

As a bonus, work with them gives you a real boss experience. If you pay them from your own pocket, then each mistake hurts you directly. This is a great point to your resume for any leadership position.

So happy freelancing (^_^)

How to successfully apply coding standards

Many teams and companies are terrible at following coding standards. Then the code is written in a messy way, without meaningful tests, and nobody even thinks about the documentation. Excuses are always the same. Tight deadline, our case is too special, or bad management. Results are delays, overtimes, reoccurring bugs, stresses, and failed projects.

Luckily, there are teams which does pretty well. They are writing pretty code with a lot of bulletproof unit test, and awesome documentation. And they can do that only because every team member works in the same style. They follow the coding standards. I know this doesn’t sound sexy. But it works.

Therefore in this article, I am going to explain to you how to prepare, actually use, and maintain coding standards. This text is mainly intended for senior developers and team leaders. It might take you several months to go through all phases.

Preparation

This is hard work and at the same time necessary for success. Good news is that once you make the preparation, then you have your personal asset which you can reuse for years. I am successfully using the same standards, with updates, again and again for more than 6 years.

The main goals for preparation are the following.

  • Make your standards great.
  • Remove every possible excuse to not follow them.
  • Get ready to defend them.

Write it down

If it’s not in writing, then it doesn’t exist.

Start with writing down everything you have in your head. A form doesn’t matter. You can start in the word, google docs, or even plain text editor. I personally prefer Notepad++ and use Pandoc markdown syntax for this type of texts. If you have never done this before, then you will discover that it takes time to tidy things up. Let me give you some tips for writing.

Start with these 3 main topics.

  • How to code
  • How to test
  • How to document

Be imperative. You are defining standards and expecting other people to follow them. Say it straight and in a clear way. One way to do this is by boxes with rules. Like this one.

Add extra rules for negotiation. This will be especially useful if you want to apply the standards to the existing team. Chance is that someone will start complaining. Then you can use such rules for negotiation.

Include a lot of examples. When you make an example, make sure they always comply with your text. For example this one.

Keep it short, under 100 pages. If your standards have 300 pages, then most people won’t be able to even read them. And then it’s impossible to ask anyone to understand and follow such text.

Focus on priority. Choose that, and structure rules for that. Everything else needs to be just reasonable good. An example of the priority is a safe code with guaranteed low amounts of bugs. Speed, memory optimization, or code compactness are not a priority (as long as they are good enough). This is suitable for projects with very complicated logic, where other factors can be solved by scaling up the environment. Another example is the super low latency code. Direct access to the array has more priority than code safety. This is suitable for real-time processing on the embedded devices, where ever microsecond is counted.

Don’t waste real estate on things which can be automated. For example code formatting. There is no need to write down the details about every bracket. This can be done automatically by IDE. Therefore, in your standards make a single rule specifying what is considered as a “proper” and make an export of such rules. Then attach it to the standards so other people can just import it in their IDE. Following an example of the formatting rule.

Use minimal language syntax to reach your goal. Coding standards are not a textbook to teach programming language. The less language features you need to cover, the easier is for the reader to understand and follow. In fact, it is good to prohibit some patterns or language features by rules.

Make it easy to read. This is easy to say, and hard to do. Just realize that you are not writing a novel. The purpose is to make sure everyone can understand and follow the text. You don’s want to entertain, be super polite or sexually neutral. If you have some money to spend, then it’s worth to let a professional editor to help you.

Finally, if you are working with Java, or just want to have an inspiration, then Robust Java Standards be a good fit for you. I have put serious effort and many years of coding, testing, and team leading experience into this book. And these are the actual standards I am using on a daily basis.

Testing

You have written everything. This means you are ahead of most other people.

The next step is to verify that you can follow your standards easily and that they cover everything you need. You need to master your own standards.

And one more important point. The whole point of the standards is to create the long term benefit for the whole team, comparing to the situation without them. When you finish testing, you have to be truly sure, that this is the case. And you have to be able to explain why. If you can’t do that, then get back to the writing phase and improve.

The best way to start testing is by writing a private side project. It’s all about writing a big volume of various code exactly according to the standards. More is better. The bare minimum should be approximately equivalent of 1-month full-time work.

While doing this, watch for these points.

  • Do you need to break any rule to reach a goal?
  • Is there any unacceptable hit caused by standards (e.g. performance, memory or logical)?
  • Is there any rule which is already bothering you?

If you answer yes to any of these questions, then get back to the writing phase, tweak it, and do the testing again. Seriously, it would be a miracle if you make everything perfect on the first shot. Feel free to make a number of iterations here. In my case, it took roughly 4 months to produce a useful version.

If you can clearly answer no to all these questions, then congratulation!

Now you have the following.

  • Text with standards, which is tested.
  • You are sure that the team as a whole will benefit out of it and you can clearly explain why.

Therefore you are confident to use the standards in real projects and stand behind. Once someone will try to put them down (this will happen sooner or later), then you will be able to defend.

Provide early access

Readers need to have easy access. Otherwise, this could be a good excuse. The simplest way is to share the link within the company system or tools like google docs.

Once you are done with all these, then you are ready for the next phase.

Applying

This phase really depends on the situation you are in. The best case is that you are starting a new project as the leader. Here, I will present several strategies. Then you will need to adjust and combine them to fit into your situation. If you are creative and hardworking enough, then sooner or later you will be able to have your standards in place.

Strategy 1 – enforce from the beginning. This strategy works if you are on the leading position and project is at the beginning. Set up a meeting, walk through the standards and ask everybody in the team to follow that. Be ready for the questions. Strongly shutdown any attempt to break any priority point. If you don’t know what to answer, then the universal answer is that you are the boss and you have the responsibility for that decision. Don’t use this too often. In the end, ask everyone for the commitment.

Strategy 2 – follow for new code and update on touch. This strategy is helpful when you are a team leader of the running project. Call a meeting, and walk through the standards. Then ask everyone to write new code to comply with that and update any portion they touch to the standards. Same as in strategy 1. Be ready for the questions, and ask everyone for the commitment in the end.

Strategy 3 – grow it up. This strategy is suitable when you are a regular team member. And for this particular case, it’s actually even better when the project is struggling. Understand that’s a bad situation, but it’s an opportunity to step out of the crowd. By the way, that’s how I applied my own standards for the first time. Start by finding the isolated part of the code and taking exclusive ownership. A smaller portion is better. Then make the change. This should, after an initial investment, save a portion of your time. Then just do it again. And again. Until other people start recognizing you. Then you have an open door to scale up.

Strategy 4 – rewrite all. This is suitable when you are the leader, or your standards get recognized as a better way of coding. Here you take the whole project and transform it into the form which complies with standards. Many times this is the final step after you start with strategy 2 or 3.

Strategy 5 – don’t ask for permission. This involves some risk, so be ready for the case it won’t work out. The advantage is that you can do this anytime unless there is a gatekeeper who is constantly reviewing your work. Simply write your code according to the standards, without asking anyone for permission, and take it as a normal way you work. Do it until you get to the conflict with someone else. Then this is the time to put on the table what you have and prove that it’s for the benefit of the whole team. Now it’s about the conflict resolution.

Strategy 6 – wait for another opportunity. Hopefully, the reason is the project is going really well and there is no point to change anything. Therefore instead of introducing anything brand new standards, you can improve the existing ones and grow up on it. That’s pretty good because you can build up your track record and use the knowledge for your next big thing. The other extreme might be that leadership shuts down any effort for improvement, while the project is struggling. I know this sucks, regardless of the reason behind. In such a case, it’s better to minimize your effort on this ship and look for another opportunity.

Regardless of the strategy choice, you can consider this phase as successful as soon as some reasonable piece of the product is written according to your rules. And other people must respect that. You don’t necessarily need to be their boss. But you need to have a definite word about that concrete part.

If you have that, then you are ready for further expansion. And it makes sense for you to go for the next phase.

Long term maintenance

The whole work up to now is useful only if you can benefit out of it for a long time. In order to do this, there are 2 things to care about. Make sure that rules are not fading out, and make sure they stay actual.

Code reviews

Code reviews are the primary instrument for making sure the rules are being followed. Naturally, this requires more effort at the beginning, which gradually decreases when people are learning.

Some background. Common project layout is that people are committing to the repository (to understand the following text, you will need some knowledge about Mercurial or Git). These repositories support branches, where people are typically making their commits. Later branches are merged into the main branch as a set of commits which implement the particular request.

I prefer to separate people into 3 groups, based on the way how the merge is done.

  1. People who are verified and doing great. They can merge to the main branch without asking. Typically these are people I work with for a long time and we have mutual trust.
  2. People who need guidance. They need to ask for approval before merging. I review the code and give them permission, or list of things to change. Then repeat the process until necessary. Eventually, these people will move to group #1. This setup is typical for people who are new in the team.
  3. Always review. This is the group which requires review all the time. I use the repository set up which prevents these people to merge. Then do the same review as #2 and merge on my own (or ask someone from the previous groups). This setup is handy for vendor type partners when I even don’t know who is doing the actual work. And these people might switch very often.

How to write a list of things to change. Make it simple, just location and comments. For example this way.

  • UserService – line 54 – input parameter XYZ cannot be used in the interface
  • Account, Car – consistency validation is missing
  • Account – line 123 – getter returns an unsafe object which might cause the side effect, make the defence copy or return it with an unmodifiable wrapper
  • … other points

If the list is long, or some priority points are there, then it’s a good practice to walk through it with the person who is doing the work. And in some cases it makes sense to make this in the formal way, so you can track the difference between in code quality between the reviews. Over time, this list should shrink significantly and shouldn’t contain any priority point.

Finally, it’s good to know when to stop. Wasting too much time on a minor stylish issue which has nothing to do with the actual quality of work is not good. So tolerate that 1% (these are that extra rules you prepared up front). People are not robots.

Making exceptions

Time to time you might get into the situation when you have to make a decision whether to make an exception or not. And here I mean that type of exception which breaks one of the important rules. Here is how to handle this.

  1. Take time to think about it. Never allow exception right away.
  2. Try on your own to figure out how to satisfy the goal while keeping the standards in place.
  3. If you succeed, then your answer is no and you need to support it with your solution.
  4. If you can’t make it, then figure out the minimal possible break of standards and allow just this in that particular case. Nothing more.

And remember, making an exception should happen very rarely. If you are thinking about making an exception once a month or so, then there is something wrong with the standards.

Hiring process

This is the best. If you can, give the candidate your standards to read and then let him write a little bit of code following that. You will quickly know whether he is capable and willing to code according to it. If yes, then you can invite him for the interview. During the interview, cover the topic of the company standards and ask him to respect that. If he says yes, then you just made a great deal.

Updated and improvements

Updates and improvements are the nature of every living product, coding standards are the same. Therefore I recommend to constantly looking for ways how to make things better.

Tip: Good candidates are the ways which reduces the amount of code while keeping quality.

Before you do an update. Realize that you already have a solid base. Don’t rush for an update.

Test first. Every update can be tested in the separate project, or at least in the limited scope. If the update turns out to be bad, then it’s easy to rollback. On the other hand, if the update turns out to be good, then you are ready to spread this across everything.

Making update. First, write it down. Then announce the update. During the announcement, demonstrate the new update and ask everyone to write new code according to that, and update the old code when a particular part is touched. You might do that by email or in person. In the end, ask for everyone to confirm the message.

Conclusion

Having quality coding standards in place is really a great investment. You need to make the hard work at the beginning, and then you can live from that for years.

While protecting all the rules, please stay human and be grateful for the people who are working hard. Words like thank you, reasonable praising, and time to time nice surprises to your teammates are helping to make a nice environment.

Just do it, and enjoy your life!