And you are here why?

/via http://geek-and-poke.com/geekandpoke/2016/11/27/good-questions So there I am,  trying to figure out WhyTF something is working. Because it shouldn’t. Really. Don’t ask what, but trust me, it…just…shouldn’t. Anyhow, after a lot of painful Banging-Of-Head-Against-Problem, I get around to the “ Google it and see what turns up ” phase. The first few hits are, of course, StackOverflow  . As I’m going through them, I suddenly realize that  one of the questions actually explains my problem! Getting an answer from a question on StackOverflow — this timeline has definitely gotten seriously weird 

/via http://www.commitstrip.com/en/2014/03/05/what-you-would-never-admin/ It is just a way of life with  vi . Somebody, somewhere, is always figuring out a new and even more cryptic (yet easy to use!) way of simplifying my development life. Then, of course, there is  emacs . Every time I pick it up, I spend the first week or so re-remembering everything I used to know… PyCharm  (and the rest of the JetBrains ilk) are just about the same. Mind you, given the amount of time that I’ve spent getting the development environment working Just Right with it, I could probably have re-learnt emacs. Guess I should go pick up  SublimeText .

/via http://www.commitstrip.com/en/2017/12/19/no-git-blame/ You’ve probably all done the “ git blame ” thing at some point or the other, right? You know, the one that goes something like 1. Spend a few hours tracking down a bug 2. Discover code that is … “interesting” 3. “Interesting” rapidly turns into “ WhatTF  is  this? ” 4. “ git blame ”, followed by “LOL,  of course  the code was written by Bob” 5. Hilarity ensues as you (and your buddies) laugh at Bob Now think of your postmortems. If you’re doing them — and I hope you are! — you’re probably striving for  blameless postmortems . As  The SRE Book puts it A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had. If a culture of finger pointing and shaming individuals or teams for doing the “wrong” thing prevails, people will not bring issues to light for fear of punishment. … When post...

“ We use levelDB because it’s fast”  (followed by incoherent rambling where ‘ fast ’ is never actually defined)  —  #CowboyDeveloper If you’re doing any kind of development, you’ll eventually run into a situation where you need to persist data. At this point, you’ll probably end up doing one of three things 1.   Files : Easy one right? Just write your data to a file, and it’s there when you need it. That is, until you need to   find   stuff, which is when you discover 2.   SQLite : Which gives you all sorts of fun query capabilities, and is great till you suddenly realize that you need to “scale”, or store “documents” (scare quotes because you usually don’t, but whatever). That’s when you discover 3.   MongoDB : Ok, that’s a joke, and a bad joke at that. The thing is, you end up writing data to   some   sort of database. For most people, that seems to be the point at which all rational cogitation ends. For whatever reason, the choice ends ...

“I hand-tuned the code till it was reliable, we won’t need to worry about it any more”  —  #CowboyDeveloper When you’ve got a product thats’s been around long enough, you eventually run into an (unfortunately, not at all rare) member of the species known as  #CowboyDevelopers . You know the type, the guy — yes it is usually a  TechBro  — who knows it all, and even worse, is the only guy who knows how  that one critical component  works. The funny thing is, if you dig deep enough, you usually find something like the following 1. He’s the only guy who knows what those cryptic logging messages mean. (“ expired secondary return in previous ack not found ”) 2. The log messages don’t actually refer to a specific error, but are indicative of some meta-condition. (“ Oh, that actually means that one of the ACK buffers on a remote node has filled up ”) 3. This meta-condition refers to something that most everyone else doesn’t even know exists (“ Wait,  why ...

It only matters whe it affects me  — Every #CowboyDeveloper Ever Isolation Levels You know about that the default isolation level in Postgres is “ Read Committed ”, right? You do? Well good for you Genius, ‘cos I sure as hell didn’t. But first, a digression. Isolation Levels , in a database, refer to the various ways in which concurrent transactions can impact each other. Say I’m  read -ing a bunch-a data from the database, and database, and during this you  update  one of the records, what happens? • Do I see the data  before  your  update ? • Do I see the data  after  your  update ? • If my  read  is actually a couple of table scans inside a single transaction, what happens? Do I get  both  the  before  and  after  version of the data? • Does my  read  just bork with a “ somebody is updating this table ” error? • Do I get a  NullPointerException ? (Sorry. PoorJava humor. M...

Me: “Hmmm,   that’s   a weird bug” ( spend hours debugging, and narrowing it down to one section ) Me: “That’s weird, whereTF did he come up with   this   way of doing it?” ( Google, find stack overflow page with same code, including typo in comment ) ( Gaze in awe at realization that the lifted code came from the question, not the answer ) Update 1:   To be fair, the code did two things, one correctly (which was needed here originally), and one wrongly (which, because   Hyrum’s law rules , means that eventually the wrong stuff ended up getting exercised…) Update 2:   Of course,   Geek-and-Poke already said it .

With a sufficient number of users of an API, it does not matter what you promise in the contract, all observable behaviors of your system will be depended on by somebody.  — —  Hyrum’s Law Or,  to put it differently , “ given enough consumers, the interface will eventually exactly match the implementation ”. A quick story here — a developer I know (of eponymous  #CowboyDeveloper fame) built out a complicated  thing  whose main job was to process incoming messages. There was an entire eco-system of queues — queues to handle messages, queues to handle ACKs, queues to deal with transactions, queues to deal with queues, and lord knows what else, but the whole thing was wrapped in a fairly simple interface. As fate would have it, this  thing  ended up in widespread use, as part of a larger mission-critical system. If you registered the “ lord knows what else ” bit above, you probably spotted the problem, that nobody other than the #CowboyDevelope...

“Quick, how many FSMs are there in your code?” Zero, right? (Yeah, I didn’t need to say “Quick” — you already knew the answer) A better question might have been “ How many places in your code could benefit from using an FSM? ”. This, one is a lot more discuss-able, with pro-FSM and anti-FSM camps getting into the usual thing (if you’re hankering for entertainment, grab some popcorn, and then ask a group of erlang devs about  gen_fsm ). Rephrasing the question yet again into “ How come there are no FSMs in your code? ”, you usually get responses like “ I didn’t need them when I started ”, and “ They’re too complicated ”. And  now  we get to the heart of the matter. Let’s parse these two responses “ I didn’t need them when I started ”: We’re all trained to incrementally add behavior to our code, and, when you’re starting out, it just doesn’t seem like the system is worth the time, energy, and effort associated with using an FSM. “ They’re too complicated ”: Rem...