. My personal bias is that I really dislike under-estimating, and I typically over estimate how long tasks will take (by design) – but usually it’s pretty close (i.e. not an order of magnitude off).
1. Usually, the smallest unit is a week. When people say something will take a day, it’s usually wishful thinking – they forget about meetings, other commitments, etc.
2. Think about what “done” means for individual tasks when estimating. Often more junior engineers will give estimates where “done” means the code is submitted to source control – but really think about the work that it’ll take to get that code into production. Testing, configuration, documentation, monitoring/metrics/alerts, etc. I think a lot of under-estimating comes from this, where the estimates are just for writing the code, and all of the other stuff comes either as a scramble at the end, or a ton of time to actually launch as tons of bugs and missed features are discovered late in the game.
3. Think in latency and throughput. Estimates typically have both baked in – if something takes a week of “at-keyboard’ time, it might take a month to get done because of other commitments. Both estimates are important.
4. Think in probability distributions rather than absolutes. I usually set my threshold around 90% confidence – i.e. my estimates are based on where I am 90% confident I can have something done. When you think about how long something takes, if the stars align, a 10 day task might take 5 days, but if things go wrong, that 10 day task could take several months or more. Things can only go a little bit better than expected, or a lot worse than expected. But when people make estimates, I think they are often biased toward the “stars align” case, and forget about this fat tail.
5. With team estimates, add a friction value to longer term estimates to account for vacations, sick days, distractions, etc. Usually around 30% seems to work. So that one month task (20 days) I plan for it taking 20 * 1.3 = 26 days.
6. Work backwards from the end goal. This forces you to factor in things like testing and productionalization. This also helps with coordination too, as you can figure out when to parallelize tasks to get to the end goal.
7. Write estimates down, and go back and reflect. When something that you thought would take a week took a month, sit down and really think about why. This will help you recognize and refine your biases.
In this week’s screencast we will be covering creating documentation from scratch using sphinx! As well as getting your code repository hooked up to readthedocs.org, to automatically build and publish your documentation!
Canonicalize the given url by applying the following procedures:
- sort query arguments, first by key, then by value
- percent encode paths ; non-ASCII characters are percent-encoded using UTF-8 (RFC-3986)
- percent encode query arguments ; non-ASCII characters are percent-encoded using passed encoding (UTF-8 by default)
- normalize all spaces (in query arguments) ‘+’ (plus symbol)
- normalize percent encodings case (%2f -> %2F)
- remove query arguments with blank values (unless keep_blank_values is True)
- remove fragments (unless keep_fragments is True)
The url passed can be bytes or unicode, while the url returned is always a native str (bytes in Python 2, unicode in Python 3).>>> import w3lib.url >>> >>> # sorting query arguments >>> w3lib.url.canonicalize_url('http://www.example.com/do?c=3&b=5&b=2&a=50') 'http://www.example.com/do?a=50&b=2&b=5&c=3' >>> >>> # UTF-8 conversion + percent-encoding of non-ASCII characters >>> w3lib.url.canonicalize_url(u'http://www.example.com/r\u00e9sum\u00e9') 'http://www.example.com/r%C3%A9sum%C3%A9' >>>