And you are here why?

/via http://mibt.edu.au/certificate-iii-in-concreting-cpc30313/ You’ve heard of “ concreting ”, right? No, I’m not referring to the verbing of the noun “concrete”, I’m actually referring to  the construction process around laying concrete . It’s a term of art, referring to getting the concrete  as close as possible to its final position , as quickly and  as efficiently as feasible , to ensure that  it can be fully compacted , and that  there is no segregation  . The thing about concreting is,   it’s Engineering . You don’t just wake up one day, and say to yourself “yeah, I think I’m gonna pour foundations”, and start doing it. More importantly, even if you   were   to start doing it, nobody in their right mind would (or should!) actually hire you to actually do it. Most importantly of all, if you’ve come up with (what you believe is!) a new and improved way to pour concrete,   the burden of proof is on you to show that it works ....

/via http://www.commitstrip.com/en/2012/03/14/whatever-it-takes/ I was supposed to be on vacation. Well, technically I  was on vacation, but the point here is that I should have been doing the stuff one does on vacation, like eating (and drinking!) too much, hiking, waking up late, and so on. Instead of what I actually  was  doing, which was trying to figure out how to bring our servers back up from where I was in the middle of nowhere. Let’s rewind this story a little, and put some context out there. At the time, I was the CTO of a phone company¹. Not just  any  phone company, we were one of the CoolAndInnovative™ ones — so cool that I had been named one of the “Top Influencers in VoIP” (which basically meant that people laughed openly at me, instead of behind my back). Anyhow, we had a bajillion VoIP phones scattered around the country, each of which connected to our data-center over the InterTubes.  Our  data-center mind you, as this was be...

A friend (call her Alice) shows up at our local pub everyday at 6pm and has a glass of Albariño. It’s like clockwork, to the point where the bartender (Bob) pours a glass out around 5:58, so that it’s ready for Alice when she shows up. The fun part here is that every now and then, Bob pours out something  different —  say, a Vermentino, or a Pigato, or some such — and Alice is quite OK with this. The reasoning being • The “fuzziness” around a routine : Alice likes a little variety. Not too much, but every now and then, mixing up the wines gives her a little jolt of satisfaction. Doing the same thing over and over may be efficient, but it can also remove some of the color from life. Deviation from the mundane can make life just a little bit more happy. • The lack of self-knowledge that we all have : Alice used to think that she only liked Sauvignon Blanc, till she accidentally had an Albariño, and now she’s hooked. Sometimes you need to be thrown a curve-ball to waken you to ...

Irreducible Complexity Swapping out your monolith for micro-services — or just using micro-services in the first place — is, in theory an obvious thing to do. After all, the larger your monolith (“one big thing”!) gets, the harder it is to for you to keep track of everything in it. The architecture eventually get to a place where you just can’t visualize it all in your head. Oh, loose-coupling helps, as does componentization, layered architectures, queues/service-buses, and whatnot, but, in the end, you’re limited by the irreducible complexity of the system. So, you do the obvious. You extend loose-coupling to the breaking point, by, literally, breaking apart the individual components into distinct micro-services. Now, each of these micro-services can be visualized in entirety by  its development team, and you can task somebody else with visualizing how all the individual components fit together. So simple, right? You’ve basically  decoupled  the individual compo...

/via http://turnoff.us/geek/my-adorable-useless-code/ There probably are other reasons that you ended up re-inventing the wheel, but the most common ones are —  1.  You just didn’t know : Common in the early stages of one’s career, when the amount of stuff you don’t know that you don’t know is practically infinite. Or, to put it differently, you didn’t even know what you should be Googling for. 2.  You can’t be bothered to Google : This is particularly true of  #CowboyDevelopers , who have made  re-inventing the wheel into an art form . If they didn’t already know that something exists, then it a)  needs to be written from scratch, and b)  if they find an existing implementation, it’s clearly inferior (because  they  didn’t write it) 3.  It Evolved : You didn’t actually intend to re-write  slice() . You were, in fact, going somewhere quite different, e.g.  extract_nonce_from_entity() , but as the requirements evolved, so d...

/via https://money.cnn.com/2014/07/31/pf/vacation-days/index.html You’ve probably seen variations on this theme by now. They might go by different names — “ Unlimited PTO ”, “ Flexible Vacation ”, etc. — but the underlying system tends to be somewhat the same. On top of the usual Bank Holidays, you get to take however much vacation you want, as long as your job gets done. Straightforward, right? Well, actually not. As with most things, the devil is in the details. If you, or your company, is offering this as a benefit, ask yourself the following questions 1.  How does this map to your team/company values? If everybody around you is burning themselves out working 7 days a week, any time off you take will might feel like a betrayal — both to them,  and to you!  That kind of high utilization and high stress environment not only precludes you from taking full advantage of the “unlimited vacation” policy, when you’re actually  on  the vacation, you’ll alway...

/via https://xkcd-excuse.com/ “ Training takes time ” ← That’s just the way it is, and the way it’s always been. The thing is, it’s not just the time you spend waiting for that bloody model to train, it’s the knock-on effects thereof. It is exceedingly common to spin off multiple workflows at a time, each with it’s own tweak, and that leads to any amount of chaos when it comes to keeping track of what exactly changed.  Reproducibility is, well, a bit of a PITA in this field   . In fact,  you can even get tooling just to work around the chaos of tracking all these pipelined workflows . Ouch! The underlying issue here is that typically training is done in one of two ways 1)  Throw everything at a single server/GPU (what you do if that’s what you’ve got) 2)  Throw it at a server farm (AWS, GCE, whatever) with their concomitant GPUs/TPUs/whatever Take  ResNet-50 . You’d typically break the images up into “minibatches” of 256 images each, and then have...