Kill Procrastination : How to become a finisher


Procrastination is a career killer.

It’s the easiest way to fail in life. Just say, I’ll do it tomorrow. Tomorrow never ends.

A lot of software developers (especially beginners) are extremely lazy. Maybe except for those that work with software companies where they’re forced to be disciplined. Many of us have loads of abandoned projects.

Well, maybe you’re not lazy. You’re probably too busy.

However, to be a successful software developer, you must learn to be a finisher. It’s great to birth an idea and to start developing it. It’s also good you finish it. No matter how tough it might be.

I’m super excited to have Caleb Mazalevskis, the creator of the not so popular phpMussel. A PHP-based anti-virus, anti-trojan, and anti-malware solution for web applications and website here with me.

He’s a finisher and a lover of clean code. Caleb has developed loads of other projects such as CIDRAM. He’s the kind of person that doesn’t want you to write:

But will like you to write:

Or even something like Password validator.

Well, this is not supposed to be a technical interview. Caleb is going to be telling us how to actually be a finisher. I just wanted to let you know how obsessed he is with cyber security.


Let’s get started…

Me: Hi, Caleb. Good to have you here.


Thank you, Eze.

Me: First-off: Are you a self-taught software developer?


Yes; I’m self-taught. Of course, I’ve had help along the way from others (developers, programmers, coders, et al) in the field, and some people that have given me great advice over the years.

Of course, I’ve learned from those I’ve worked with in the past, but I’ve never received any formal lessons in programming or I.T. development, nor taken any formal studies in the field.

Me: Have you had abandon projects before? If yes, why did you abandon them, and what lessons did you learn?

However, if NO, what’s your strategy to always complete what you’ve started?


Yes, I’ve abandoned projects before.

Although ideally, and especially when it can’t be avoided, I don’t like to abandon projects. However, there’s been a few occasions, on careful consideration, where abandonment felt to be the best course of action for some specific projects.

On several occasions in the past, I’d worked alongside others for some ambitious projects that envisioned the development of large-scale services akin to some of the more popular services known today dealing with things like social networking, search engines, public databases, certain niche interest areas and so on.

Most of these projects were abandoned due to differences in opinion between team members in regards to the future direction of these projects, where they should go, what they should become, things like that.

More so, in some cases, reasons were more pragmatic, such as the long-term viability of the project, who’ll pay for ongoing costs, infrastructure concerns, etc.

In most cases, we started some projects because we perceived it was a need in a particular industry.

Which is good. But we later abandon the projects because obvious, the need of the users changed along the line —- lack of proper research.

Always conduct proper market research and be sure your product is in demand before starting the project.


Again, in some cases, bad management played a role. There are three occasions I can think of at least where I was brought onboard as a developer for the project by the project manager or someone that had an idea for a project that sounded great on the surface.

And when he brought it onboard, they described to me what they wanted me to do.

Although it was within my capacity to do those things, then, things like feature creep and scope creep would enter into the picture. The project manager would ask me to do things that weren’t in my capacity to provide.

Or ask for things that weren’t possible. Sometimes, the intended nature of the project would radically change during the development cycle, and at those points, I’d feel that it was no longer appropriate to remain onboard, and would take my leave.  

Bottom line: There are many reasons for abandoning projects, and in each of these cases, there was lessons to be learned. I’ve learned from failure and success alike, and all experiences beget their lessons.

Me: Why did you start phpMussel, why should we use it, and what’s your projection for it into the future?


At the time, when the idea for phpMussel was first conceived, I’d already been a member of a number of online communities and discussion forums related to I.T, security, PHP, web-design and so on.

And had been actively contributing to a number of other projects. The idea for phpMussel came quite by chance and was the direct result of one very specific discussion that took place on one such discussion forum in September 2013, about ClamAV Anti-Virus.

Another member of that forum had recently seen some traffic to his website from a source claiming (falsely) to be from ClamAV. He shared his access logs with us, and some of us were looking into it to investigate further and also to learn the nature of this traffic so as to determine whether anything could be done about it.

At that time, although some of the other members already were familiar with ClamAV, it was the first time ever heard of ClamAV. So, I began looking at their website, learning more about who they were and what they did.

I soon discovered that they were releasing their signatures database with the GNU/GPL license (and still do), were (and still are) receptive to the open-source community, and that they included lists of software on their website for derivative software, bindings, etc.

I also knew at the time that although there were already plenty of anti-virus solutions available for PCs, laptops and so on, there wasn’t much available in the way of pure, PHP-based anti-virus solutions for protecting websites.

With that, I saw an opportunity to create one—-A simple, low-end anti-virus scanner that could be used to protect websites. Something not necessarily as powerful or comprehensive as a traditional anti-virus solution used on laptops and PCs.

But something that could detect and protect against some of the most common, simpler, basic threats. However, one of the biggest problems with creating your own anti-virus is the question of research into emergent threats. How you’ll build your database to deal with detections and such things.


I wasn’t quite prepared to go as far as starting my own company and paying employees to work for me for the sake of building my own database from scratch.

There are already numerous companies in existence that do this, they’re experienced and know what they’re doing (most of them).

So, taking it to that level wasn’t something I was particularly interested in doing at the time anyway. However, the fact that ClamAV licenses their signatures database as GNU/GPL, meant that I could rely on theirs, and could build something simple based around theirs if I wanted to do so.

Thus, a way was provided for me to spend some of my spare time away from my job and other hobbies towards building phpMussel.

In fact, the name itself, too, is a play on words. Pays homage to its origin, and was an effort of various members partaking in the original discussion that conceived the idea in the first place.

If not for that original discussion, phpMussel probably would’ve never come into existence. As for why you should use it (or any similar package, for that matter): Sure, users have a responsibility to install an anti-virus solution onto their own machines.

And generally, if you ensure that any data that are uploaded to your website is non-executable, and ensure that you properly sanitise data and control it at every step of the way (what can be uploaded, by whom, to where, etc), the chances of a true “infection” occurring on your website isn’t particularly high.

However, if something infected is uploaded to your website, even if it won’t infect your website, it could result in your website being flagged as malicious and/or dangerous by Google, by WoT, and by other services that similarly check websites for malicious and dangerous content.



Additionally, it could reduce the trust that users have in your website, and surely, I imagine that most people would agree that, even if a user’s anti-virus is able to detect most malicious/dangerous content upon downloading it, the possibility of detecting malicious/dangerous content before downloading it would improve standing with users and help reduce the risk of infection for end-users further.

It should be noted, however, that phpMussel is not a substitute for a fully-fledged, system-level anti-virus solution.

If you’re able to install an actual, fully-fledged, system-level anti-virus to your server, and execute it as either a daemon or a system service, that’s something you should do, and in that situation, there won’t be much need for phpMussel.

Additionally, if your website doesn’t allow users to upload files of any kind to your website (e.g., if your website is static, or doesn’t accept user content, etc), there won’t be much need for phpMussel.

However, phpMussel serves as a great solution for in the event of not being able to install daemons or system services (hence why it is described on its website as being ideal for shared hosting services), for when a website needs to accept file uploads from users.

In short: If you operate a website if you can’t install daemons or system services to your server, and if you allow users to upload content to your website, phpMussel could be useful for you and you should consider it.

Of course, I always recommend possible future users that they read through the documentation before making any final decision.

To ensure that it’s the right solution for them and for their needs. As for future projections: At this point, I’m no longer working alone on the project.

I have others working with me collaboratively to see phpMussel reach its full potential (Daniel Ruf and Matthias Kaschubowski are two people in particular that I’d like to mention in that regard).


Although there’s no specific deadline for it and future plans are somewhat fluidic at this time, we’ve been discussing various ideas for where to take phpMussel into the future, and I highly doubt that phpMussel has reached its full potential yet.

Due to that we don’t have a specific deadline yet and that future plans are currently somewhat fluidic, I’m wary of mentioning anything specific, but those interested can follow us on GitHub to keep updated on future changes and to see where the project goes into the future.

Question: Some programmers are lazy, they basically don’t want to sit down and learn how to solve problems with programming the right way.

They just want to get that app up and running but at the end, they get stuck when they can’t find enough tutorials to help them finish up the project or create a crappy app no one wants to use.

What’s your advice?


“You can lead a horse to water, but you can’t make him (or her) drink”. Or, if you don’t mind the melaphor;

“You can show them all the data, but you can’t make them think”.

In other words, if someone doesn’t want to take the time to think about a problem, and to figure out an appropriate solution, where can you go from there? Not too far, I imagine.

I would ask them, “do you, or don’t you, want to do this?” You can’t force a person to want to do something if they don’t want to do it, and if they don’t want to learn, or if they’re too lazy to learn, they won’t learn.

“Learn” is a self-applied verb. At school, did your teachers “learn” information to you, or did they “teach” you? They taught you lessons, but you did the learning for yourself, based on what they taught you.

Likewise, a teacher can’t teach a student who is unwilling to learn. This same principle applies to most fields. Think of your favorite musician, artist, inventor, writer: They didn’t just magically gain their knowledge from nowhere.


They spent time and effort towards learning the knowledge and skills necessary to hone their craft.

It might sound rough, but truthfully, if someone doesn’t want to spend the time and effort required for learning the knowledge and skills required for completing some particular task or job, then they should probably be doing something else instead.

In regards to tutorials, it’s also important to remember that there was always a first: Whoever wrote those tutorials, had to learn their knowledge from somewhere. How did the first person to learn that knowledge learns it in the first place?

They knew how to think for themselves, how to study the problem, how to try different solutions, and through trial-and-error, how to arrive at an appropriate solution. At some point, then, someone decided to share their knowledge with others by writing tutorials.

Not all problems will have corresponding tutorials, but perhaps, if you can find a solution to your problem without using any tutorials, you could think about writing a tutorial for others, to share your newly acquired knowledge with others.

As for apps that nobody wants to use: This is always a risk when writing new software and new apps. Sure, not everything is something that others will want to use. We accept this risk when we begin writing new software and new apps. Some of that risk can be mitigated by doing thorough research before starting a new project, into market interests and so on.

Ultimately, though, if you begin a new project, you’ve either not thought about it beforehand, or you thought about it and felt that others would be interested in using it.

If the latter is the case, what changed? Why do you now think that nobody would be interested in it?

How will you know for sure, unless you complete your project, and give others a chance to decide for themselves whether they want to use it? Don’t allow self-doubt to get in the way of your own opportunities.

Me: Wow, great points. that sounds thick and overwhelming. That said, What are your best tips to stay on a project and not procrastinate?


1. Don’t be afraid of failure

If you give up because of fear of failure, you’ve already failed due to giving up and due to not giving yourself a chance to succeed.

Keep working towards your goals, and maybe you’ll surpass your own expectations. Even if you don’t, it’s a learning experience, and maybe your next project will benefit from the experiences you’ve gained.

2. Don’t be afraid to take a break once in awhile

Rome wasn’t built in a day. Sometimes, working too long on the same thing can cause stress, or we run out of ideas, or our mentality stagnates. Taking breaks can help give us a fresh perspective and help to reduce stress.

3. Prioritise

Is it really important for you to be watching YouTube or playing games right now? Does your project have a deadline? Know what is important, and plan your schedule accordingly.

4. Build a strong work ethic and stick to it

Set yourself goals and rules, and follow them. Make them realistic and reasonable though (don’t set unachievable goals).

5. Challenge yourself, and keep things interesting.

If the project bores you, it’ll be difficult to keep interested in the future. Of course, be wary of things like feature creep and scope creep, too.


6. And finally, I’ll say: Celebrate small achievements and share it with others.

You can get lots of encouragement that’ll push you to do stay on your project, you’ll also get critics that’ll help you improve.

This is super ducker interesting. Thank you so much for your time, Caleb. I hope to have you here in our future interviews.

Have you installed phpMussel on your website or web app?

Install phpMussel on your website and web apps Now to protect your web apps from viruses and malware attack

Here is a tutorial for the installation

Connect with Caleb on Facebook

Follow him on Github

Got more tips on how to become a finisher? Please share your comments.

Eze Sunday Eze on FacebookEze Sunday Eze on GithubEze Sunday Eze on Linkedin
Eze Sunday Eze
Eze Sunday Eze is the founder of The Growthbar. He's a web developer, inbound marketer, and Freelance Content Writer. Let's connect. Hit me up. On Linkedin.

Leave a Reply

Your email address will not be published. Required fields are marked *