Remote WordPress Development Work Individual VS Team & Clean Code

Quality WordPress Code

If you ever hired a freelance developer to develop something for you, and then if you had to switch developer to resume the development, What is the first feedback you get when the new developer starts coding based on the old developer’s code?

In most cases, they say, Its spaghetti code. If you don’t have that experience, then I can confirm that being a Freelance WordPress developer who is actively coding for the last ten years, it is the majority. I know it because I had to say the same thing to my clients many times. Scraping the entire old code base and re-developing from scratch. Notably, it happens more often when you work with an individual freelancer, and you are not tech-savvy. The question is, is it really spaghetti code/lousy code, or we developers just made it up to avoid understanding someone else’s logic/implementation.


The truth is, we don’t always make it up. As a software developer, one of the most important soft skill is understanding someone else’s logic or thinking process by just reading the code. Tho, it’s being labelled as “Soft Skill,” but I think it is a critical skill that every developer should have. It is fundamental yet essential. Developers can code; that’s why they are developers. But there is a vast difference between coding alone and coding with a team. Let me point those out one by one.


I started my career with freelancing, being a single man army. Then I managed 2-3 development teams as well. The difference in code quality and efficiency is quite significant. From my understanding, a few key factors create all the difference.

  • When working as a freelancer, alone, developers tend to focus more on the completion of the project instead of spending time thinking about the project’s extendibility, code complexity. Developers try to deliver fast because clients don’t see the backend. They want the result, and in most cases, fast!
  • Being an individual developer, handling a whole project alone (assuming the project has database, backend logic, front end integration with backend) is quite tricky. Only a few developers can do it. Even fewer developers want to do it. Most of the developers are very good in one or two particular areas. Not in all areas.
  • Working alone means, the developer decides or build the workflow from his/her point of view. There is very little or no scope of solving a problem with 3-4 different approaches, compare those, and then pick the best method.
  • About fast delivery. To achieve that, most of the developers don’t follow the standard practices. It might not seem like a problem as long as the system works. But this practice puts serious vulnerability to the project in terms of security as well as performance. 


Now the MOST crucial point,  about code readability. We, developers, expose our thinking process with code. So when it comes to a point, I need to read some other developer’s incomplete code, I expect that I will be able to understand the intent without having any conversation with the developer. We, developers, really want it. But we don’t always get it. I pointed out a few notes already why we can not find it that often. Now let’s see how the development process works in a typical development team. I am going to use my development team virtue5 as a reference as I spend most of my coding hours with this team


  • In the team, we only do what we can do best. It creates a few departments (an individual can work as a department). So, for example, My teammate Arthi can do both front end work & quality assurance. But she is much better at QA than the front end. So she passes all front end work to her teammate Shiplu. Shiplu, on the other hand, works both at the front end and backend. The front end is easy for him, and he does it comfortably. At the backend, when he gets stuck something, he discusses that problem with teammate backend developer zaman and me. So, in the process, we manage to get different input to solve a specific problem.
  • As a team, we often need to work with someone else’s code. For that, It is crucial to maintain the code standard. That’s where clean code comes in. As a team, we maintain a style where codebase itself is documentation. 
  • Working in a team enforces Test-Driven Development (TDD). Frankly, No one wants to take the blame if the overall system doesn’t work correctly. So, before even, we say “it is done” we make sure first ourselves that it is tested AND done.
  • Documentation is important. Your codebase may change over time. In some cases, your codebase might be re-written with a different language. As a team, when we write code, we try a playful approach to make our codebase as a document. The approach is like; we think some characters who are doing different things (as code does). While we write code, we write a story as well. That enables us to understand better how the system will work. Even tho this storytelling thing is very casual, but it improves the code overall. 


The reason I am writing the post is to share a file (a class) that we have coded at Virtue5 to implement some feature. All I wanted really say is how a complex idea or thinking can be passed to others with a little trick of making a story about it. However, I ended up writing about individual vs teamwork, and how that affects our codebase. So, now as I have already discussed that part, I will just share a codebase, a class, which is written to invite users to an e-commerce based platform. For each referral, both users will get some discount. So, I managed to think this whole invitation think as a “party” and coded like that. Now, I understand you might not be a coder and you don’t understand code. But that’s the whole point of this post. Just read the code and comments top to bottom and then you will find out that you actually get an idea what is going on here. The whole point of this post is to point out how we should do code, and how we can pass our thought via code to someone else, without creating a separate document for the code. Take a look at this, and you will know 😉