Skip to content

Category: Musings

My Career’s Been Replaced by AI!!!

Okay, that title may be a bit click-baity. But I was watching a video blog recently and it made me think a little, though not quite in the direction the blog may have intended.

There’s a group of streamers I’ve become somewhat enamored with and the particular video blog that started this line of thought was “Being Competent With Coding Is More Fun” by the ThePrimeagen. Or, in this case, his alter ego, TheVimegean.

The short form of the story is he tried using AI to shortcut his prototyping and then ended up spending even more time debugging. His punchline, just read the docs.

Oddly, rather than validating my own thoughts on AI, it got me thinking in a different direction. For those who don’t know, I’ve been unemployed for some time and quite confused by it. Everything about my experience and resume that once worked so well for me when job hunting in the past, now seemed to literally be working against me.

Shortcutting some of the thought process, it made think about what job I really did. Not what my resume says. I’ve always said my “real job” was Troubleshooter. This manifested itself in a variety of ways. Sometimes it was doing a prototype or proof of concept. Sometimes a version 1.0, also known as an “honest” prototype because it was created in the same manner as a prototype but always intended to release. Sometimes, it was actually solving a problem that had the current team stumped.

The one thing in common with most of my “solutions” is they were incomplete. In fact, the work I did was very likely headed for the bit bucket. What it did, was get the team past their current dilemma and put them back on track. It answered the question of “why” it wasn’t working. But the actual code itself, was not worth keeping.

This is when I realized my superpower might actually have been outsourced to AI. It was an interesting concept.

Part of the problem with all the discussions on AI is that results vary. Some folks have very good experiences with AI, others, very negative. Currently, there is not a lot of in between. This suggests to me the hype, on both sides, is obscuring the real value. And, perhaps, like my own efforts, sometimes may be hard to appreciate.

As The Primeagen found out, AI doesn’t actually save you time. But what it CAN do is get you past that point of just plain not knowing what’s going wrong. But the expectation SHOULD be that what is produced by the AI (like the solutions I usually provide) should provide understanding, but not an actual solution. You’re still going to have to read the docs. But perhaps now, you’ll be able to make more sense of them.

Give it some thought, while I re-write my resume…

Smacking the Code Interview

I don’t spend much time on social media.  To be honest, I’m not sure yet of its value.  Democratizing news is a noble goal.  Making and keeping connections is a noble goal.  Communication is a noble goal.  All three of these things are messy though and a continuous flow of low value content and constant reposts and shares with no value add is just noise.

But I watch, and wonder.  Sometimes, certain things continue to bubble to the top.  One of these things is the current hiring methods for technology professionals, particularly programmers.  

I spent the first fifteen or more years of my career as a programmer, then the next fifteen or twenty in a variety of IT roles, literally spanning the entire spectrum of IT.  So when I decided to return to my roots, to start programming again, I was blindsided by the change in hiring methods.  I was completely unprepared for the modern interview.

Until now, I’ve purposefully avoided adding my own angst and commentary to the noise.  I wasn’t sure of the noise to signal ratio of my own thoughts.  For one thing, hiring technical people is hard.  It always has been.  Just because we did it differently in the “old days” does not mean we did it any better.  So I understand the intent.  Additionally, like it or not, if I want a job as a programmer today, this is the hurdle I face.  I can complain or I can adapt.  Finally, I cannot really say I have a better idea.  Making my commentary likely high on noise, and low on value.

But I am a programmer.  Solving problems is what I do.  In particular, my specialty, if that word is correct in this case, is troubleshooting.  I am not the one who draws up your initial design.  I am not the one who keeps your project on track.  I am not even the one who reels it all in and plans the after-party.  I’m the guy you call when, despite the best laid plans and designs, it just does not work out.  If I succeed, the project gets back on track and I move on.

And that’s what this is.  A plan that doesn’t work as intended.  I mean it sounds sensible right?  If you want to hire a programmer, watch him program.  But the obvious answer is not necessarily the right answer.  And, at the risk of grossly over-generalizing, the easiest answer is usually not the right one either.

Before we go too much further, we should state the obvious.  The claim the current interviewing process is a failure is one sided. It comes from the many experienced programmers who find themselves stymied by such interviews.  I cannot say I have seen companies complaining about low quality results of their interviews.

That being said, it seems more than passing strange when experienced programmers cannot get past the current gatekeepers.

To keep this short, we will not break down and examine the failures, perceived or otherwise, of the current hiring methods.  Perhaps in another article.  For this one, let us just assume it is broken and re-examine our goals.

We want to hire good programmers, so I guess the first thing we need to define is what makes a good programmer.  We will not list everything, but need something to start from. First and foremost, we have always said IT professionals must be in a constant state of learning and re-learning.  We have also said programmers must be multi-faceted.  No one-trick ponies.  Less commonly admitted, a programmer needs to be a team player (my personal example notwithstanding).

While I do not want to delve deeply into it, I do want to state what should be obvious to everyone.  That being, the current mode of over-the-shoulder code interview involving a Leet Code like algorithm challenge hardly demonstrates any of the above.  In fact, the only thing it demonstrates is that the candidate managed to pass a Computer Science class on Algorithms and the challenge you gave him was one of his homework problems.

Let us revisit our goals.  Find someone with a proven ability to learn, who is multifaceted, and a team player.  Starting from there (rather than what we can easily implement), I finally get to the part I did not have to offer up, even a few days ago.  I will not go so far as to say I’ve solved it, but perhaps I have a new starting point for our conversation.  Again, without offering a complete analysis, compare the above goals with the following scenario.

Choose an algorithm or challenge, but describe it completely.  Do not actually assume the candidate knows what a Bubble Sort is.  Write it up in detail.  Hand them the textbook description.  Like, requirements one might say.  Then, make a random choice.  Roll some dice, pick a name out of a hat, spin a wheel and choose a programming language.  But here is the switch up.  The language cannot be one listed in the job description.  In fact, it should not even be a mainstream language.  Think Smalltalk, Eiffel, Forth or any of the many experimental languages.  This does a certain amount of level setting across the candidates.  

Here are the expected deliverables.

  • Document the development environment.  Tools, downloads, configurations, integrations, etc.
  • Working code
  • Automated tests
  • Documented code, written as if it were a code review
  • Deployment documentation
  • User documentation
  • Blog post

Then, send them away.  Give them a time frame to return, but consider being flexible on the deadline.  Ask for updates.  

When complete, the interviewing team attempts to recreate the work from the documentation supplied.  Before even talking to the candidate a second time, they evaluate the delivered package.  Obviously, the code will not be “expert” level.  Ideally, the candidate just learned the language being used.  But the package as a whole can be evaluated on a variety of levels.

Should the delivery evaluation be favorable, the next interview can occur.  This one is old school.  Technical skills are not even discussed, having been established by the code challenge.  This discussion is the team fit assessment.  Feel free to discuss favorite cartoon characters, the validity of pineapple as a pizza topping and even VI vs EMACS.

To sum up, “Ask not what your candidate can do for you during the interview.  Ask what they can do for you once hired…”

Time Travel

As some of you may know, I’ve been spending time learning Unity and C#. You see, I found myself to be an old dog, with nothing but a bag of old tricks. Those old tricks, it seems, no longer impressed anyone. I could have chosen many things, but this was what I chose.

But that’s not what this story is about…

Birds flying high…

The other day I was driving around when a bald eagle flew over me. Not way up high in the sky, but right down in the trees where I could see him. Not only did he cross my path once, but twice; as if making sure I took note of his presence. He left the tree he was in, flew across my path, then turned back to his perch. So, you know what that means.

Babelfish…

What to do, what to do, oh what to do… sigh… I want to get back into programming, ideally professionally. But I’ve been out of hard core programming long enough I have taken on the appearance of an old dog learning new tricks. Even so, an If statement is still an if statement and a while loop is still a while loop. Thus, I’m not particularly worried about jumping back in. In fact, if I didn’t want to get paid for doing what I love, it would be easy. It’s that getting paid part that is tripping me up.

Truth be told…

How often do you have to hear something before you decide it must be true? As I recall from my High School English class, you need to back up any claim with at least three credible sources. Ideally, these three sources should have different pedigrees for their research. Their conclusions should derive from different sources. In other words, they should not all just be repeating the same rumor. In today’s world, that means three re-tweets do not make a truth. Neither does three Facebook shares or re-posts.

Paradise Lost

I am sure if we looked hard enough, we would find someone, somewhere who has not been “affected” by the COVID-19 pandemic. For the purpose of discussion however, let’s just go with “everyone.”

Unfortunately, we are not yet to the point we can talk about what effects the pandemic had on everyone because we are still having them. The whole thing has been going on long enough even the ripples are making news. Even the most pessimistic of doom-sayers are scratching their heads wondering just how much longer this will go on. When, everyone is wondering, will we return to normal? When will we finally get a break and be able to heave that much needed sigh of relief?

Winds of Change

All things change. We know this inherently, even though we try to deny it. Sometimes these winds are gentle breezes stirring our hair and cooling our skin. Other times it seems there is no wind at all. Things are changing, but only under the surface. Then there are times when the wind comes in like a hurricane.

Generally speaking though, these changes are not very interesting. After all, if a tree falls in the forest and you are not there to hear it, will it make the Starbuck’s Drive-Thru line move any faster?