Latest posts by Adam Lev-Libfeld (see all)
- “play with it”, “quick feedback” and “binary debugging” - July 14, 2017
- Cache 22 - January 18, 2017
- Trinity - January 17, 2017
To every decision there is a dark side, this an unshakable fact of life.
Tech in that perspective is no different, you often hear about “premature optimization”1 and “design bugs”2. These are merely bad choices – made without understanding the trade offs between the available options. It gets worse, Continue reading “The Trade – 4 ways to (Eventually) do the right thing”
Three giant, important reasons why you need to write good specs – and the real reason why people don’t.
Joel Spolsky explains why you really shouldn’t write even a single line of code before you wrote the specs (rudimentary as they may be). ’nuff said.
The Art of Readable Code (Theory in Practice) , Dustin Boswell, Trevor Foucher
As programmers, we’ve all seen source code that’s so ugly and buggy it makes our brain ache. Over the past five years, authors Dustin Boswell and Trevor Foucher have analyzed hundreds of examples of “bad code” (much of it their own) to determine why they’re bad and how they could be improved. Their conclusion? You need to write code that minimizes the time it would take someone else to understand it—even if that someone else is you.
No system is fault-proof, but high volume, high velocity and high throughput (or whichever flavor of HPC you practice toady) systems often are expected to be. Every time we state otherwise we either lie to our clients, our colleagues, or worse – ourselves.
The last couple of weeks I slaved over refactoring some of the code-base of one of our costumers. The task at hand was to take the elaborate spaghetti code, build with way (waaaay) too many multiprocessing queues and turn it into a functioning, debugable, decently performing piece of software.
As it turns out, most of the work is embarrassingly parallel1 but with all the different processes handling all the different tasks the code is unmaintainable. So off we went, trying to find more subtle routs to multiprocess our way out of the mess.
It was clear. we needed a map. Not the of the paper kind, not even of the google kind2, but of the parallel kind.