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

/via http://www.commitstrip.com/en/2018/11/26/if-its-not-broken/ Funny cartoon, but the whole " Don’t refactor  craetionDtae ”, thing is a bit far-fetched, right You’d probably fix that typo without thinking twice about it, right? Wellllll, maybe not. After all, this might actually be something that is exposed to users (it’s in the API. Yay), so you need to refactor this  and  the documentation, but that’s OK, you can do that, right? Wellllll, maybe not. Because, now that you look, you notice that you’ve got  two  sets of typos,  craetionDtae  and  craetionDate , which means that refactoring means that you need to update  both  of these in the code  and  the docs, so now it’s  4  things that need to be changed, but it’s ok, you’ve got that, you can do it, right? Wellllll, maybe not. Because, now that you really look, you realize that  craetionDate  also exists as  craetionDates  (becaus...

So yeah, do  you know what your company's goals are?  Yes, of course, “ Increase shareholder value ”, but do you know  how  your company plans on doing that? Stuff like • “ Increase the number of baby-strollers we sell by 67% this year ” • “ Convince at least 3000 people to buy our hand-selected peppercorns this month ”, or even • “ Get the work, do the work, get the money ”? /via http://rhymeswithorange.com/comics/april-6-1998/ You’d think this would be stuff that —  obviously!  — would be shared top down, but, then again, you’d probably not be surprised to know that this stuff  doesn’t  trickle down.  Mind you, it’s not necessarily malice. If you’re a tiny company, it’s just assumed that you know this. If you’re large, then there are just so many layers between you and the CEO/CFO that the message never makes it to you. And if you’re somewhere in the middle, everybody is just too busy to actually pass this information on 😠. ( And then, there...

It was my first day on the job. This was a wee bit back, and the company I had just joined was having … issues … getting stuff out the door. “ Any day now ” had turned into “ It’ll ship in two weeks ”, and that was a cool 3 months in the past, and eventually, I got called in to help get stuff unstuck. So anyhow, it was my first day on the job, and I was poking around the repos, trying to figure out what was what. After a couple of baffled hours, I figured out that the development process seemed to be  eventual-consistency-git  — everybody developed against their own branch, and cherry picked from each other to get updates. A “release” involved nominating one developer (and their branch!) as the primary, and having everybody else stop work. The primary would then painstakingly merge in all the other branches,  maybe  resulting in something that worked. And yes, this was utterly bat-s**t crazy, but whatever. I put a little bit of order in place, just to ge...

It’s a great line, isn’t it? “ Software is an Art ” tells us that we’re doing is Craft, that we’re Creative, our work is Unique, and we’re all snowflakes. The problem, however, is that so much of our day-to-day work in the field is just so bloody mundane, there just doesn’t seem to be all that much Craft to it, let alone Art  . Think about it — so much of our work is some combination of looking stuff up on StackOverflow, adding in all the boilerplate around what we found to make sure it complies with whatever the internal guidelines are, and then adding in a metric ton of instrumentation, logging, and whatnot to deal with the inevitable late-night debugging sessions when it turns out that StackOverflow Is Not Infallible. This isn’t entirely an accident though — the Edison quote about genius being 1% inspiration and 99% perspiration has a tremendous amount of truth to it. Even more importantly, we tend to forget that so much of what we consider “craft” is actually mind-num...

Let’s wind back — way way back — to the early days of the InterWebs. The year was 1994, and a bunch of us were building out some of the first commercial “web sites”. ( Quotes because a decent chunk of the sales process actually involved explaining WTF was a “web site” was in the first place, why you should care, and just give me the damn money. But that’s a story for another day… Anyhow, back then we had a limit of 50KB per page. And even  that  was something that we had spent days — weeks even! — arguing about amongst ourselves. After all, 50KB? That would take  forever  to load! Also, how could you possible have that much stuff on a page in the first place? And then you had the other side, whose argument basically could be translated to “ As long as it looks good, I don’t give a shit about size ”. Of course, yes, there was a bit more about  aesthetics , and  the integrity of the design , and a whole bunch more. This argument, as far as I can tell...

There is a persistent myth — particularly prevalent amongst control freaks— that if you get the  requirements  detailed enough, you can assembly-line your way through  development . Dig deep enough, and you’ll find that to them,   Agile is the same as Iterative Development   . Oh, they absolutely get the bit about “ user feedback ”, “ short sprints ”, “ incremental releases ”, and so on. However, in their minds, all of these steps apply   only   to the development process, i.e., you do all of these things   after   you’ve nailed down all the requirements, as shown below From their perspective, you just iterate through the development cycle in a succession of sprints, in what is basically a linear progression. In each sprint, for example you cycle through  Design → Development → Release → Review  for 10% of the requirements, and at the end of 10 sprints,  voila! you’re done! Oh, if you want to get a little pedantic, t...

/via https://www.monkeyuser.com/2017/steps-to-reproduce/ This, tragically, is entirely true. It takes you weeks of fiddling around with increasingly arcane maneuvers to replicate the precise set of circumstances in which that extremely weird edge-case that you didn’t account for shows up. But, and this is key, your end-user replicated it just a few femto-seconds after you deployed the release. Sigh…

“I don’t need requirements — I know what I’m doing” —  #CowboyDeveloper A paraphrased version of an actual PR-related discussion I had recently follows. And yes, I’ve had this conversation more than once in my career — there are a  lot  of #TechBros out there  . Hey Bob (let’s just call him Bob), I wanted to talk about this PR you just submitted. Specifically, this bit in the config file —  e nable_network_console: # Yes | No  — care to explain it?¹ Oh, I see, most of the users don’t want the network console, but some might? So you’ve got that in there, just in case anybody wants to enable it? Cool, cool. One more question though — why do we even have a network console in the first place? I mean, I was looking at the requirements behind this PR, and I don’t actually see anything about network consoles, let alone enabling/disabling them, y’know? Oh, right, you thought it might be a useful feature, so you put it in there. Make sense. And they’re not in the requ...

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