One advice in this pdf is that on designing first before implementing. I think iterative cycles of design / implement / use / design /implement use yield better results.
Iterative cycles take advantage of the regularity of change. APIs shouldn't change once public, hence the emphasis on Big Upfront Design. However, change still needs to happen so versioning comes into play.
Personally, when it comes to APIs, you can tell those that have been designed upfront rather than iteratively; they are generally better IMHO.
The API that appears to be well-designed up front was probably preceded by many not as great APIs either done by the same designers, or that could at least be learnt from. That is still quite iterative, just in the long term sense. Real waterfalls don't exist.
If you have an API that does something well known, find and learn from existing APIs that do that. If not, then he prepared for lots of trial and error, scenarios you didn't think of, and so on. It might make sense to put out a "worse is better" API first so the learning and feedback loops can start.
What I would advice is to design the API (public part) without considering the internal code (private part).
We often change our point of view on how to solve a problem (private part), but rarely the problem itself changes (public part).
Iterate away your (internal) architecture as much as you want, but when dealing with the API (your external world interface) make sure to put yourself in your user shoes.
I was expecting the same.. read to the end.. nothing. Jesus, that is not healthy. Maybe he should try going outside and socialising instead, the boost to productivity will more than negate the time "lost".
alright, I just got the thought when reading about elbow protectors.
I would caution with giving advice for taking vitamins and other supplements as a non-MD. Medical advice based on a sample size of N=1 is not a good idea. Apart from clear harmful vitamin deficiencies, studies show mixed results on the benefits of vitamins supplements.
Setting up a python project with a sane layout can be challenging, thats why I like pyscaffold. It takes away the pain of writing your own setup.py and googling for all the different ways of configuring your setup. Especially the setup.py subcommands which are kind of hard to get right.
One advice in this pdf is that on designing first before implementing. I think iterative cycles of design / implement / use / design /implement use yield better results.