And you are here why?

In  an earlier post , I described a way of making decisions based on the type of problems that you are facing. I won’t repeat it — go read  the original post   — but the key point is that the way you go about making decisions really should depend on the type of situation you’re in. /via https://www.thingsinsquares.com/comics/google-maps/ Think about directions to get somewhere. If you’ve never been there before, well, Google Maps to the rescue. But what if data service is sucky (it happens sometimes!)? Do you ask for directions? What if there is nobody to ask, d’you explore? Or go back and print out directions at home? So yeah, the specifics of the situation affect the way you go about resolving them. And to get slightly  Rumsfeldian , most situations can be broken out into the following four categories 1. Known Knowns : You’ve solved this specific problem before, and can totally do it again. Heck, you can automate the solution, or if it is a manual thing...

/via http://comics.feedtacoma.com/nutshot/nutshot-asking-right-question/ Most software engineers are well-versed in the following stages of problem solving (•) 1. Problem Recognition : aka “ Houston, we have a problem ”. Observability is all well and good, but you need to know that what you’re observing is   not   a Good Thing. On the one hand, the mundane stuff gets easier over time, as you add in monitoring (and self-repair, right?) for crashes, failures, overloads, and the like. On the other hand, “ black swan ” syndrome kicks in — as you squeeze out all the common stuff, you end up dealing with weird/edge-case problems that you don’t even notice till all hell breaks loose at 3am X-mas eve. 2. Fault Identification : This is where you figure out what exactly happened, and is, hopefully, something straightforward like “ the node crashed ”, “ we’re being DDoSed ”, or some such. It is also usually the easiest part of the process (once you get past all the alarms, flash...