And you are here why?

“It might be useful” as a reason to not delete code, in the Past : " I don’t want to wade through git " Present : " It might break something " Future : " I might need it someday " /via http://www.commitstrip.com/en/2013/11/08/la-boite-a-cables/

Every software project ever ends up in this place — you end up using code from a previous project (or developer, or organization, or developer, or StackOverflow, or…) which you  don’t quite completely understand . But thats ok, because it mostly,  mostly  does what you need it to do. And thats the rub — because the really interesting stuff is happening in those edge cases…

/via Tomas Petricek

/via Vijay Gill Artifacts are easy to copy. Culture and process that allows you to easily make new artifacts, that’s a lot harder to duplicate. This leads to cargo cults like agile, microservices, containers, open plan offices and saying “but it worked for google” while crying (And no, ping-pong tables are not the answer)

Rolling Your Own Consensus  is clearly the blockchain version of  Rolling Your Own Crypto. Reasons for doing so that I have seen include, • I have a Better Way To Do Things  (No. You don’t.) • It shouldn’t be hard, therefore it isn’t  (Why? also, Yes, it is.) • What could possibly go wrong?  (Yup) • We’re on AWS, so net-splits aren’t a thing  (Oh yes they are) • Or outages  (Ha. ha. ha. ha. ha) • Who cares what the academics think, this is the real world  (Yikes) • We use redis for co-ordination  (Sigh) • Actually, redis-cluster  (Double sigh) Next time you’re faced with one of these, I recommend running away. Immediately. With vigor. Mind you, if you  can’t  run away, try asking some combination of 1) Is it proven? 2) Really? 3) With Math? 4) And peer-reviewed papers? For extra credit, ask if they redid Paxos or Raft,  without the un-necessary parts. And  then , run away. Immediately. With v...

(yes it is a bad  idea...) / via @mshelton

/via Bubba Hines

You know, when you said  "Its a simple little patch, won't affect anything, don't worry about it! " Yeah, that one. Commit Strip is all over it

Go here , and check it out! 

/via CommitStrip  

The original There are only two hard things in computer science - cache invalidation, and naming things The variant There are only two hard things in computer science - cache invalidation, and naming things, and off-by-one errors The distributed systems variant There are only two hard things in distributed systems -      2. Exactly-once delivery      1. Guaranteed order of messages     2. Exactly-once delivery Humor thereof /via CommitStrip

This took me a moment 😊 /via CommitStrip  

/via CommitStrip

/via  @jlouis666 " Making software go fast is a result of investigation into why it is slow. Not rewriting the software in new language X. " /via Douglas Crockford "The making of good software takes time.  If you try to make it take less time, it will take more time."

Or, heck, look at anything I wrote over 6 months ago /via CommitStrip

/via CommitStrip

via CommitStrip

OK, some bugs are the developer's fault, but if you eliminate the n00bs and the idiots from the test demographic, then I stand by my statement. OK, fine, we'll also eliminate syntactical errors (you are using syntax checking in your development environment, aren't you?  If you aren't, go away.).  But that pretty much is it. I've used a plethora of languages and platforms - C, C++, erlang, java, objective-C, perl, python, ruby, and javascript (if you can call that a language.  And yes I'm joking.  Mostly.).  Its pretty much a best tool for the time and the place kind of existence, and AFAICRemember there has always been the persistent underlying frisson of fear , forever,  around bugs/errors.  And they all share one commonality. Errors are, always and every-time, considered to be a fault on the part of the developer. Pity you, the poor java developer. You begin by writing defensively. You absolutely infest your code with fun stuff li...