And you are here why?

I know this is straight from  The Department of Belaboring The Obvious , but yes, the Big Picture matters. It matters regardless of where you are in the organization, it matters regardless of what your job is, and it matters regardless of what your responsibility is. /via https://www.monkeyuser.com/2018/priorities/ Think of this from the perspective of  Aligning Priorities . The thing is, we’ve all got our own priorities. In an ideal world, all our priorities align harmoniously, and exist seamlessly within the global priorities of the company, but, well, this is not that world. The reality is that, everybody is one step away from fizzing off in some random direction like some kind of bottle-rocket gone horribly wrong. And that is at the best of times! Mind you, this is where it helps to  not  have the big picture — after all, if you don’t know what the corporate goals are (and division goals, etc. etc.), you can’t be blamed for spending the best part of ...

Hiring an expert is (somewhat)) straightforward when you need a very specific solution to a very specific problem i.e.,  you need  point expertise . For example, if you need a forensic accountant to figure out which one of your suppliers is short-changing you, well, you know exactly what to get. Mind you, I’m not saying you  can find the person — especially at the price point you need — but the pool of talent is very clearly defined. The thing is, most of the time you’re not looking for that kind of expertise . You’re probably not hiring a new Product Manager to build the same damn thing that they built at their previous gig — your people are different from the previous lot, the market has changed, the customer requirements are probably different, etc. What you’re looking for in them is what they learned in their journey at their previous company, how they juggled the competing pressures of scale, speed and scope, their interactions with stakeholders, and so forth. ...

/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...

“An inch wide and a mile deep” —  this is a pretty good description of most of the  #CowboyDeveloper s out there, people who know a lot about one thing, but not a lot about anything else. What I find particularly fascinating about them however, is that their remarkable lack of intellectual curiosity around anything that isn’t their area of expertise. As far as I can tell, they only (maybe!) pick up new things when they’ve been bludgeoned with it repeatedly, with pretty much the entire universe showing them that it is relevant and important. And,  even then , it’s probably going to get ignored by them. A fairly common reason for this is insecurity, which tends to manifest itself in two ways • Need for Respect : Admitting that there is something else — and  new!  — out there is tantamount to admitting that there is something they don’t know. And if there is stuff they don’t know, people won’t respect them (after all,  they don’t know things !). And then, they w...