The long way through Software Craftsmanship

Jan 1, 0001 - 2 minute read - Comments

published: false curiosities - so early, they talk: * about testing, reproducing cases: ensuring quality * store documentation and update it incrementally (in paper) * store versions of the software: version control system (VCS) ideas to talk about: * no silver bullet - essence and accident - how to measure performance without control groups? - candidates: - the social coding (not silver bullet, still) - higher-level languages and frameworks (scala, play; python, django; ruby, ruby on rails) - open source packages * brooks’ law * nine women cannot make a baby in one month: the non-parallelizable tasks of a project * chapter #2: the idea of the waiting patrons on the french menu * investing a part of your time to sharpen your tools * * hypothesis: was the book (the mythical man month) a precursor to the agile movement?

Jan 1, 0001 - 2 minute read - Comments

published: false categories: - clean-code - startup-weekend - tdd In an epilogue in Clean Code, Robert C Martin talks about the “commitment to writing the best code I could write” This is an interesting proposition, as to never “lower the quality bar” induced by constraints such as resouces. This clicks with an idea that I heard some months ago, during the Startup Weekend, where you have 54 hours to develop a business idea out of the building.

Jan 1, 0001 - 1 minute read - Comments

published: false categories: - sample - unfinished - clojure - algorithm - mathematical-notation - paradigm - comparison I’ve been doing some code jam exercises, some on paper, some on the computer and I generally use “pseudo-mathematical” notation: FOREACH, BELONGS, etc I have realised that this is much simple for algorithm rather than start thinking on data structures and then adding behavior on top of it. Also, that once the algorithm is outlined into this notation, is relatively straightforward to convert to clojure notation.