The project is dragging on a bit and you are beginning to wonder if the client is getting a little itchy and wondering why in the world you are still not done.
It's Thursday and you are pretty sure you could finish this with one more push.
So you preemptively send an email to the client.
"Hey just sending a status update. I'm looking to get this delivered by Monday morning at 10am."
The client replies and thanks you for the update.
Well, now it's Saturday evening and you already worked one day of the weekend and you ran into an unexpectedly difficult part of the new feature that's adding 5 more hours of work to the project. So, you grit your teeth and spend another 5 hours on Sunday.
It's now 8am on Monday and the feature still needs more time. The client has woken up and is looking forward to a 10am announcement of completion. Oops.
Stop volunteering what you are going to do in the future
But wait, the client didn't even ask you for an exact deadline. You gave the deadline yourself! There's nothing special about 10am on Monday, other than the client is expecting completion because you told them it'd be done.
How to actually do time estimation is a subject for another letter, since you do have to give your clients some sort of indication of how long things will take (I was unsuccessful when I once tried to put on my proposal "estimates are impossible so I can't give a timeline"). But here I'm mostly concerned about self-imposed deadlines.
Most of the times I've shot myself in the foot with estimating were times when no timeline was even asked for. In the cases where a timeline was asked for, it definitely didn't need to be so precise.
Programmers are generally optimistic and really bad at estimating time
If I had a quarter for every time I told a client, "I'll have this feature completed at precisely 9:42am on Tuesday," or "Look for a pull request tomorrow by the end of the day," or "I've reached the end of the difficult parts and am just finishing up things for Friday," and then ended up not actually having it completed, I'd have at least enough money to buy a houseplant, and maybe even a couple depending on the size and species and fanciness of the pot.
Any sort of knowledge work, especially programming, is rife with unexpected complications that just don't lend to precise estimates. I've even heard it said that the only amount of time a programmer can actually estimate is exactly 4 hours - anything less than that and you'll underestimate how long it'll take since seems so small, and anything above that you'll also probably underestimate because too much can go wrong.
You want to please the client, so you give a best case estimate. But the client would have been happier with a realistic timeline that was met than with an optimistic timeline that was missed.
I am the worst at this
This letter was on my mind mostly because I've been doing this some myself lately. And it's embarrassing and has the potential to frustrate people. I did this with a client not too long ago and I also did it with this email list.
I recently started a series called "Building a Freelance Practice From Scratch" and optimistically and enthusiastically laid out 10 titles for the next emails. I promptly released a single email of the 10. Then after thinking on this series for a few weeks over Christmas, I realized that of the set of 10 emails, I no longer thought some were as relevant, and there were also other topics I wanted to add.
But nobody had asked me for a 10 part series, and nobody would have even noticed if I had just written the first letter without announcing 10 parts, realized these things, and written something else!
So I'm going to take this opportunity to shelve the 10 part series and return to writing self-contained articles. I'll probably be hitting on some of the same topics just because getting you from zero to freelancer is the focus of this list, but I haven't fully fleshed out a curriculum from start to finish.
Most of the time clients are understanding but don't lie or ghost
But when you do underestimate the complexity of a project or over-promise and under-deliver (and you probably will), be honest about your mistake. Time and time again I've experienced clients who completely understand when I am upfront and honest with them about missed deadlines or mistakes or whatever, even if I caused some problems.
In school timelines were pretty fixed and deadlines were precise. School projects were also comparatively much simpler than real world programming projects, and someone else (the professor) was imposing a timeline on you. Part of your role as a freelancer is to provide your expertise in setting the timeline and expectations.
What is met with less understanding is lying about things or ghosting. It's so tempting to hide when you've messed up, and I'm guilty of doing it sometimes. But I really try not to, and pretty much the worst thing you can do to a client is to disappear.