Estimation pitfalls
We live in a society using Gregorian Calendar - what that means is we are used to months having “around 30 days”, and weeks having “always 7 days”.
This knowledge is very useful for estimating the amount of time until someone’s birthday, it just “feels” like a short/long time when you hear the number - your gut insticts tells you “it’s soon, it’s time to buy a present”, or “you have plenty of time to sort this out, don’t worry”.
While we live for some time we get used to this “abundance” of time to sort things out - two weeks is more than enough for almost everything (except buing a house 
, but the problem begins when you try to apply this “common sense knowledge” to software estimation.
The working week - has only 5 days, and month - usually 21 days.
That is much much less than you “feel” it has!
If you’d estimate something will take “a full week”, which is 7 days, your client/boss will hear “5 days”, which already is 40% longer (7/5 = 140%)!
The same goes for the month, you think “a month, about 30 days” and he hears “21 days”, which is 42% underestimated for the same amount of “time”.
Add to that the slack caused by “getting into the zone” on Monday morning and picking up the stuff you left somewhere on Friday - and you’ll start to feel even more time slips through your fingers.
That might explain why the plumbers charge 40 pounds per hour - it seems like they can earn more than bank directors, but not so when you take into account all the inefficiencies in getting to you (physically) and getting to you (advertising efforts).
That also explains why every project takes a horribly long time - because we have a life outside work 
The point is - when doing estimates, use HOURS instead of DAYS as the “Unit of work”.
And don’t assume you’ll work effectively on Friday evenings