And you are here why?

It’s a pretty nifty saying, isn’t it? Unfortunately it only works for when You don’t understand how it works, and/or You’ve got too many other things to worry about. The problem, of course, is that  if you don’t understand how it works, how do you know it’s not broken?  Murphy’s law being what it is, you know that the break will reveal itself at the single most inopportune time, right? Ok, that’s not actually fair to Murphy. Broken parts tend to fail under stress, and fail disastrously at that. And stressful situations are typically the situations in which you need the largest amount of cognitive bandwidth to deal with the ongoing chaos, and the last thing you need is something (critical!) rupturing on you. So yeah,  of course , the break will reveal itself at the worst possible time. And that is kinda the point he re - if you don’t understand the mechanism, saying “if it ain’t broke, don’t fix it” ‘cos it  seems  to work is, quite possibly, the worst possible t...

Are you a "tidy plate" kinda person? Or one who pretty much just loads the plate up willy-nilly, because, hey, "eating is where it's at!"? I'm actually being serious. I mean I know people who are extremely clear about their food - the potatoes can't touch the peas, and god forbid the ragù overflows and ends up touching the bread! And then again, there are those for whom "plating" basically translates to " put it on the plate, that's all there is to it! " I know, you're sitting there thinking "And, pray tell, what does this have to do with software?" Well, very broadly speaking, software folks also tend to fall into these two categories. On the one hand, you've got folks that like clarity. Give them a task list, a well documented requirement, a bug to track down, or some such, and they're happier than clams in a bake. On the other hand, you've got the folks who thrive in chaos. Ambiguous requirements, flak...

Ever been a Systems Administrator? I have (first job I ever had!), and I have to tell ya, it’s a pretty thankless gig. I mean yes, there is the satisfaction of a job well done, the joy of knowing that everything is up and working to spec, etc., but, behind all of this, you are left with the knowledge that  Nobody Cares Till It Breaks  😔. Mind you, it’s not that they don’t care at all. It’s more like, from their perspective, “It’s Working” is normalcy, steady-state, the way things should be. You don’t get into a Toyota Camry, and say to yourself “ Hmm, I wonder whether the engine-block will fall out of the car on the way to work ”. Engine-blocks remaining in the car is the default state of existence, and if one  does  happen to fall out of the car, then hey, it’s definitely Bizarro-City! And that, my friends, is what SysAdmins — and software engineers in general — deal with all the time. As far as users are concerned, systems are Toyota Camrys, and are supposed...

"Seniority" is a pretty loaded term, which depends on the organization one is in, and what that organization wants to get out of it. After all, at Alice’s Software Factory there might be a bajillion gradations involving all possible combinations of [ junior, senior, systems, lead, principal, etc. ] and [ developer, engineer, analyst, architect, wizard, etc. ]. And additional combinations too —  senior principal systems analyst  wouldn’t be out of the question. If you ignore the labels, there is a much more basic question at hand here, and that involves the people attached to the titles. To wit,  what allows people to climb up these ranks?  Mind you, this is more abstract than just straight up software engineering — it’s about pretty much any field, and how you differentiate “seniority” in that field. Me, I tend to break this up at a very high level into a few basic categories, viz.  Junior ,  Mid-Level , and  Senior . The difference? I’m glad yo...

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

/via http://www.commitstrip.com/en/2013/10/09/la-pire-sensation-du-codeur/ It was a glorious Friday night in Hoboken, back in 2008. Ok, this  is  Hoboken we’re talking about, so it wasn’t all that glorious, but we’d been out for dinner with friends, friends who appreciated wine, and, thanks to the wine (and friends!) it was a glorious night. Our taxi had  just  pulled up by our house, and everyone was trooping up for  MOAR WINE YES LETS SEE WHAT WINES THERE ARE YES , when I got a call from one of the SysAdmins. Him: “ Uh, dude, I think I did something ” Me: “ ???? ” Him: “ I may have shutdown our primary DB ” Me: “ !!!! ” Him: “ I  shutdown  the DB on my desktop when I left, but now that I think of it, I may have done it in the wrong window ” Me: “ !!!! ” Him: “ And I’m on the freeway, which is backed up seven ways to Sunday… ” Me: “ !!!! ” Him: “ And I don’t think the secondary took over, because Customer Support is getting slammed ” Me: “ !...

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