What is your SHTF value?

IDPA matchI’ve spent hundreds of weekends at hunt clubs and outdoor shooting ranges competing in IDPA and USPSA shooting events. I’ve met characters from other weekend warriors (like myself), and hard-core former-military, SHTF preppers. Including people from all walks of life, from farmers to dentists to cops and even other computer geeks.

Right after the common “so what do you do for a living“, the top follow-up is usually something like:

If it all fell apart tomorrow, what would you do for a living?

What they’re really asking here is:

“What skills do you have that don’t require a USB outlet?”

How would I contribute to society, or for my family, if there were no more computers?

Now, I’m pretty handy with tools and those of you who follow my blog know I’m a bit of a car/bike/racing nut, so I feel like I’d manage to get by and feed my family just fine. But it is an interesting question and I like to consider it from time to time, as unlikely as the TEOTWAWKI scenario actually is.

Well, that’s how I thought about it until today.

Right around lunchtime, one of my contacts at a local staffing company we use reached out to check in. Like the rest of the country’s corporations, we recently had a bunch of layoffs and furloughs take place. “So far”, I told her I was still employed (albeit at a reduced salary), “but the show goes on”. I followed up with a curious “are you guys still placing people in all of this?”, and her response was what got me thinking.

“Yeah surprisingly. There are a few companies still hiring and some banks are thriving with bringing in contractors for customer service type roles. Not for higher level development roles or management level”

And there it was. Hiring phone jockeys and service reps to deal with increased customer needs, but no leaders or developers.

Companies are reinforcing their front-lines and critical systems are staffed with technical skeleton crews, just enough to keep them running. Can’t say I blame them. A good developer can cost as much as four or five customer service reps.

If Covid-19 becomes the first in a long line of successors, as some are predicting, it might be worth considering returning to the old days of turning wrenches…

On tattoos and programming

I like thinking about software.  From a nitty-gritty hashing algorithm all the way to release deployment and branching strategy, I revel in considering architecture, searching for patterns and losing myself in the ever-changing sea of technology.

At my core, I’m a programmer.  I’ve been writing code since I can remember, starting with Basic on my dad’s old Trash-80 back in the early 80’s.  When I screw up, which is actually a key part of my coding process – I learn, use the backspace key, and I move on.  My life is affected only in that I spent a few extra minutes, and maybe learned a lesson I’ll hopefully be able to apply to future problems.

I’ve always been a programmer, but I’ve never been a tattoo artist.

By contrast, a tattoo artist doesn’t get to use the backspace key.  There is no ‘refactoring’ a tattoo.  Once ink has been applied to skin the decision is permanent, and the affected life belongs to someone else.  The artist’s design, decisions, and tiny movements literally etching his or her intent into another human’s life.

At best, the freedom to just throw it out and start over gives programmers the ability to try outside-the-box solutions, or solve problems with methods we don’t well understand, learning as we go.  This I think, has been software development’s greatest enabler.  With no real permanence and carrying the potential windfall of massively successful (and lucrative) products, the stakes are low and the prize is huge.

At its worst however, this disposable-design-methodology introduces an innate lack of applied value to technical solutions.  Unrecognized, this leads to poorly thought-out designs and less maintainable implementations.

FACT: The Earth’s servers are littered with proof-of-concept code that became production implementations.

There are tens of thousands of lines of unmaintainable, misunderstood, and often unreadable code carrying out financial transactions, travel plans, medical insurance claims, and top secret military correspondence.  Developers know this, because we wrote it.

It’s unfair to ask software developers to treat every line of code they write as production level.  The beauty of software is that it can be refactored.  But, we need to consider the implications of the “just fix it for now” mentality in every method we create.  What you build today can become the bedrock of a mission-critical system tomorrow.

Why I didn’t hire you

Rejected!This blog post is the result of a combination of the original post here (February 2016), a very similar post on Linked-In, and the comments and conversation resulting from them.

For those of you who don’t know me personally, I’m a development manager.  The most important part of my job is to interview and hire software developers.  With mediocre software developers, you get mediocre software.  No one wants mediocre software.

I like to believe I’ve become pretty good at identifying talent and weeding out less-than-desirable candidates.  During my career I’ve interviewed many candidates, possibly in the hundreds, and built successful development teams from scratch more than a few times.

Last week I received an email from our HR recruiting manager about a young, fresh out-of-college candidate that we really didn’t have a position available for, but had an internal referral and really wanted the opportunity to talk to us.

Our resulting conversation, or rather, the fact that I’ve had this conversation at least 3 times in the past year, is why I decided to write this post.

Here was my feedback to the recruiting manager:

This was a nice conversation, he’s a pretty smart kid. As I expected, his answers were wordy and rehearsed, pretty standard for someone fresh out of school with only scholastic experience.

That being said, after a few softball tech questions I drilled into his knowledge a little bit and really uncovered how junior he is. When I asked him about Agile, he recited a Wikipedia definition that most likely would get him a “B” on a test, but he couldn’t give me any specific examples of how he and his team used it or why it was “better than waterfall for modern projects” (his words).

We spoke only briefly about his PHP experience (it was on his resume), but after he couldn’t tell me how to concatenate a string or name any of the methods for dealing with databases I assumed he’d fall short on design patterns and implementation standards outside of what was written in a book.

Education is important, but more important than what you know is how you’ve taken what you learned and used it.  I don’t care if you got an ‘A’.

When I talk to programmers, especially young ones, I’m looking for eager curiosity and self-taught experience. You can’t get this in a college classroom, it’s a personality. You either have it or you don’t.

As I interview more and more of our millennial generation I am finding that interviews like this are becoming more common.  And that concerns me greatly.  Somewhere along the line, our formal educational system evolved into a series of rewards for memorization and regurgitation of facts and definitions. Practical application and self-paced (self-motivated) curiosity have been replaced with the promise of

“Good grades = Good career”

To add complexity to the issue, the interview process itself is flawed. I could write a book (probably not a very good one) on interview questions and techniques and still not scratch the surface of every candidate’s true potential or knowledge. The sad fact is, I have 60 minutes (at best) to try and extract the complex answer to a simple question: “Should I hire this person?” I’m judging talent and aptitude, while trying to avoid knowledge and vocabulary.

As a software engineering student you are exposed to projects and deliverables, just like you will be in the working world.  You were educated, ad nauseam, about waterfall, agile, branching and merging, and continuous integration.  How did you use them in your project?  Which of them worked for you, which didn’t, and why?  How will you change your approach for your next project?

Everyone knows what a stone is. We can describe a stone and draw one, but only the great minds saw it as a building material and constructed great castles and cities. This is the skill I’m looking for, and it often hides itself well.

What I really wanted to say during the interview was “An interview and an exam do not share the same purpose, therefore they do not have the same answer. I’m not asking you about agile SDLC because I want to know if you know the definition.  Frankly, I don’t care if you know the definition.”  But I did not.  Maybe I should have.

Many of the best programmers I’ve worked with have no formal college education, and many of them have no certifications of any kind, but they are still brilliant developers. Getting a degree in Computer Science does not make you a programmer any more than wearing feathers makes you a chicken.

Walk into your kitchen, unplug the toaster, take it apart and find out what makes it work.  If this activity doesn’t interest you, maybe you should pick a field outside of engineering.

What is a browser?

First, watch this video:

The reason this video is shocking (to those of you who know what a browser is) is because we assume that the proliferation of internet use has, in some way, educated people about the fundamental workings of the web and software. This is, clearly, completely untrue.

Don’t forget developers/site designers/UI folks, just because your mom can use Facebook to send you messages, doesn’t mean she has any idea of how the tubes really work…