Posted on ::

I remember the first time I included tensorflow in a python project I was working on. I was fascinated by how accessible the ability to process voice recordings into text had gotten. I had built a tool to transcribe some old audio recordings I had so I could make their full text indexed and searchable.

Machine Learning has been around for a very long time. Producing prediction models that can perform speech-to-text conversion, optical character recognition, detect fraud in financial transactions, or auto complete terms on your phone's keyboard. These were all very useful applications of applying vast statistical models to use cases that reliably solved very hard problems with pattern recognition.

In November of 2022, OpenAI made available ChatGPT and the entire world's relationship with machine learning changed overnight.

What can I add to this discussion?

AI, specifically Large Language Models (LLMs), are the single most discussed technology in the past few years. They have become ubiquitous in almost every discussion. AI has become a core factor in our economy, is shaping wars and politics, and is driving vast changes in education and business.

Like with any new technology, political topic, or financial opinion, there is divisive discord on the subject. Some people see AI as the future of every piece of our lives and you need to adapt now or die, while others believe AI is destroying our economy and environment while centralizing power in billionaires. All of these topics have been discussed to death.

So, why try to add my two cents? When giving my opinion could put me in a box of being an "AI detractor" or a "curmudgeon"

Because I started seeing a trend that is frightening me before ChatGPT and it has now become super accelerated.

Before I get to that, let me ask you a question.

How does a junior engineer become a senior engineer?

My career in technology started on a helpdesk as an intern. I was still attending my local community college in their networking course, learning Cisco IOS and the basics of network administration. I loved computers, but looking back on it, my understanding of how technology works in an enterprise was zero.

Anyone that started their career working on a helpdesk probably remembers the anxiety they felt when they're sitting at their desk and their phone rings for the first time. Perhaps it was as simple as someone's account was locked, or needed their password reset. Perhaps it was a folder they couldn't access or a website that they couldn't reach. There's a certain anxiety that comes with having no idea what they're about to ask you.

When you're new at a company there's a high likelihood that they ask you something you don't know. They tell you a service you've never heard of is down, or a tool they rely on isn't working correctly. Perhaps its urgent. How many users are effected? What if it's a contact center of hundreds or thousands of agents unable to work. Here you are, a teenager holding a phone and no idea what they're talking about. What do you do?

You turn around and ask someone who knows.

Of course, right? Someone more experienced can help you. You have an escalation point. Someone with knowledge you can ask for help.

When this happened to me the first time, I picked up the phone and got told that a piece of software that hundreds of agents used stopped working. It was 8PM and I was the only helpdesk person staffed at that time. I could hear the urgency in the supervisor's voice that was reporting the problem.

While there weren't any other more senior helpdesk people working with me I did have a Tyler.

The small IT room I worked in was empty except for me and one of our system admins. Tyler is what you imagine when you think of a Linux sysadmin. He's one of the smartest people I know and I respect him greatly. At the time, he was a new person to me. I didn't know him well. But my boss told me he was who I would ask for help.

I put the call on hold and turn around.

"Hey Tyler, they say $application is down."

He looks up only for a moment to say "Huh, that sucks." and goes back to work.

Expertise and Experience

It's easy to say that the difference between a junior engineer and a senior engineer is experience, but I don't believe that's the whole story.

I've worked with people in their early twenties that blow my mind with their creativity and resourcefulness in solving problems. At the same time, I've met people in the twilight of their career with decades of experience, that couldn't explain the basics of how their system works.

Experience alone isn't expertise and expertise doesn't come with time.

While there are a large number of reasons someone could gain experience without gaining expertise, I want to focus on where I believe the most common problem is, and how it relates to AI.

How do we learn?

Through my career, I've been fortunate to have some extremely creative and smart people to learn from. Some of these people I still have the pleasure of working with and seeing how they approach problems.

In recent months I've been reflecting what made some of these people good mentors. What I've so far concluded is this:

The best mentor will never tell you the answer

To some reading this, that statement seems obvious, but what I'll say is that I'm not repeating it for you.

When we encounter something we don't know, whether it be a problem we're troubleshooting, a program we're writing, or a design we're drawing, we begin a process which we've been working on developing since we were kids. You begin using the tools you've acquired over many years to try and discover the answer. Tools, like reading books, reading standards documentation, resource discovery like search engines.

At some point in your life, you used Google for the first time. Since then, you've learned ways to word your searches, search operators, specific sites to look for, and ones to avoid. You didn't seek out, originally, to learn these things. They're tools you acquired in pursuit of something else.

Think about any other tool you know to use to troubleshoot something. A debugging library, a linter, packet captures, SysInternals tools, WinDbg. Even something as sticking print() statements in between lines of code to see where the program stops. All of these tools, at one time, you discovered and learned to troubleshoot one problem or another.

Now let me ask you this:

Would you have learned these tools if someone had given you the answer?

If, instead of having to troubleshoot that permissions issue on that Windows server and learning procmon and how to filter events, what if someone just told you where the application was trying to access and what permissions to give it? Or instead of learning how to read TLS handshakes in packet captures, someone told you there were mismatched ciphers configured?

As I see it, the differences between a junior engineer and a senior engineer are:

  • The tools they have in their toolbox
  • The process they have to discover new ones

You probably see where I'm going at this point, but we're still getting there.

If you follow with me that an expert in any field is judged by the number of tools they have in their toolbox along with the understanding of how to use them, and that these tools are most often acquired by discovery when they're needed to solve a problem, how is it that someone can spend a long time in a field and have less expertise than someone newer to the field?

We come to the main constraint of learning: time.

The Problem of Time

Learning takes time. Discovery takes time. Applying new tools takes time. The first time you used a specific tool on a problem, it took a long time. Once you have those tools and that understanding, however, they're at your disposal for the rest of your career.

However time is a resource. A resource that is scarce on its own and, by virtue of being a resource understood by non-technical managers, is one that will be artificially restricted for you.

When you're tasked to solve a problem, whether that be adding a new feature to an application, troubleshooting a broken system, or designing a new solution, you are operating under pressure of a timeline. Expectations are placed on you to work as fast as possible and to arrive at the solution.

So, if you're stuck on a problem, if you don't know the answer, what makes more sense?

Spend hours researching and understanding the problem
OR
Escalate

If you ask anyone in a non-technical role - incident managers, product owners, your manager, VPs, executives - you'll be told that the important thing is to solve the problem as fast as possible. Because that's their metric. They have absolutely no vested interest in your professional development or career progression - regardless of what lies they tell you in your quarterly check-in.

If one of these non-technical roles hears you are working on a problem you will hear some variation of

  • "Who can we pull in to help?"
  • "Who can we page out?"
  • "Who is the SME on this we can ask?"
  • "Have we contacted the vendor for support?"

Time to resolution is the only metric. So we get told to escalate rather than learn. Rather than discover. Rather than take more time now to develop our professional skills in order to solve and prevent future issues.

This is the number one issue I've seen with engineers that are held back in their professional development. They're told to escalate rather than learn. They're given answers rather than developing tools.

So now, what happens when you add AI?

AI Supercharges Empty Toolboxes

As discussed earlier, many of the best mentors I had early in my career didn't give me the answer. They would say "no" when I tried to escalate to them.

ChatGPT will never say "no"

Today, we're entering a time where young kids are going through college, are entering their first internships, starting on a helpdesk, landing their first role as a sysadmin. They're doing all of this in an age when their first mentor will never tell them "go figure it out yourself."

This is stunting the careers of millions of young people.

Instead of spending hours learning tools to gather information, learning adjacent systems and tools in the process, and even learning how to learn, junior engineers are delegating this to LLMs.

I want to be clear though: it's not entirely their fault.

The Culture of AI and Enterprises

Right now, the message from the select billionaires that control the global economy is clear: get onboard with AI or die.

C-level managers at small and medium sized companies - which are the companies junior engineers will start their careers at - worship the opinions of the Musks, the Nadellas, the Huangs, the Cooks. When those recognizable billionaire names say something like "work from home is bad," "you must embrace AI," these managers listen.

Right now, the conversation going on at nearly every major company isn't "can AI help us?" it's "how can we use AI more?"

I've even had first hand accounts of people in my network telling me that companies are reviewing token usage of employees to make decisions on who to lay off - not looking for who is using too much, oh no. Who is not using enough.

None of us had a say in this, but because those in power made a bet, a bet that AI would revolutionize every piece of our world, we have to find uses for this tool. If we don't, your 401k drops to $0. We enter a spiraling recession that threatens to destabilize the global economy. I assure you, though, if AI fails to deliver on what's promised, Jensen Huang won't be in line begging for bread like the rest of us.

What can we do?

When I solve a problem, or deliver a project quickly, or pick up a new tool fast, I will on occasion get asked how to up-skill others on solving that problem. They'll ask me what training, what classes, what books, what can they tell junior engineers to do to learn.

I respond to them with exactly what I've spent this whole post explaining, but in shorter words: "Tell them to figure it out for themselves"

For managers

Stop letting people escalate. Stop letting them ask ChatGPT, stop letting AI write their software for them. Hold your employees accountable for solving a problem on their own.

Your job as a manager is to run interference and give your team space to figure a problem out. They cannot do that if you simply pull in a senior engineer for every problem, or escalate to another team, or tell them to ask someone else.

Acknowledge that the first time an engineer does something it will take longer. The next time will be faster.

For junior engineers

I know, I have to be reasonable. I can't say "stop using ChatGPT" because, with the current landscape being how it is, that would be a death sentence.

What I will encourage you to do is to stop giving the AI chat bot your problem and asking for a solution. Use the LLM as a tool to find resources. Ask it for how to go about finding information. Or maybe a direction to look. Avoid letting it give you the answer.

If you are forced, because of timeline or pressure, to let an LLM solve a problem for you, once the problem is solved, work the problem backward. Write down the information you originally had and work on finding the tools and resources that would have led you to the same conclusion. You could even use the LLM to help with this. Ask it to help you find the resources for discovering the solution on your own next time.

For senior engineers

For anyone in a senior level position, I expect we're still in a point in time that all of us have worked in a world without LLMs. This won't be that way forever.

Right now, you are the mentors. People entering this field are going to watch what you do, they're going to follow your lead. Many of us are in this career path because we love new technology. We're fascinated to play with new toys and see what we can make them do.

Remember that the junior engineers are watching. If you delegate to an LLM for "small" tasks, that's what the junior engineer will do.

Encourage junior engineers to ask questions, but never give them the solution. Push them in a direction to figure it out themselves. Answer their question with questions of your own that lead them to learn new tools to answer your questions.

Use your position to push back on managers that escalate to you. Tell them to let their junior engineers work.

Final Thoughts

I hate that, in my circles, I've developed a reputation of being "anti-AI"

I love new technology. I was fascinated the way ChatGPT responded the first time I used it. How fluid and lifelike its prose was - nothing like the AIM chat bots I remember when I was a kid. I've been blown away watching it spit out whole applications or websites in a matter of minutes. I've had friends and family tell me of problems they had solved in minutes.

My concern is that I've also watched as more and more people have delegated their opinions to a fancy auto-complete. Their own ability to learn and troubleshoot is being replaced. I've watched the centralization of this technology to the same monopolistic companies that have proven time and time again to abuse whatever power they find themselves with.

I'll leave with a quote that is a profound foresight. One that I think is more relevant now than when it was said.

We’ve arranged a society on science and technology in which nobody understands anything about science and technology, and this combustible mixture of ignorance and power sooner or later is going to blow up in our faces. I mean, who is running the science and technology in a democracy if the people don’t know anything about it?
Science is more than a body of knowledge, it’s a way of thinking. If we are not able to ask skeptical questions to interrogate those who tell us something is true, to be skeptical of those in authority, then we’re up for grabs for the next charlatan political or religious leader who comes ambling along. It’s a thing that Jefferson lay great stress on. It wasn’t enough, he said, to enshrine some rights in the Constitution and the Bill of Rights, the people had to be educated and they have to practice their skepticism and their education. Otherwise, we don’t run the government, the government runs us.

— Carl Sagan, 1996

Table of Contents