How Can I Help?

I was asked to come talk to second-year IT programming students. I wasn’t quite sure how I would approach it, and it wasn’t until the other panelist, a recent grad from the college, started telling their story about the cool things they’re doing in IT operations, that I really started to gel on what I wanted to talk about and how I wanted to frame things. And it does come down to taking an attitude of service and craftsmanship to the job. And here’s what I told them.

I have hired 100-plus people in my career, and I’ve interviewed probably north of 500. And a lot of the people that I’ve hired for have been in entry-level positions. I use credentials as a weeding exercise to get to a pile I can read. Because in certain seasons, especially for term positions, I would get hundreds of applications.

But when I do a detailed read of the resumes and the cover letters, I actually look at the adjacent experience. For example, if you’re early in your career and you spent five years in Army cadets, then I already know a bunch of things about that individual, or that they’ve done a bunch of volunteer experience, or that they’ve worked in retail. Working in retail tells you a lot about their ability to provide customer service and work with people. Because there’s no such thing as a technology sector. Every sector is a technology sector. And you will inevitably pair up your IT skills with a business or domain skill set.

I know every student who’s about to enter the workforce, and particularly those in development fields, all of them have the exact same question. Is AI eating entry-level jobs? Am I fighting robots?

Maybe it’s true in this moment because the technology is new and people are still learning how to actually make things work. And yes, displacement happens as it always happens when technology comes along. But it always brings with it opportunity. And even in the AI era, it does. So, is AI going to eat entry-level jobs? Not really. AI has just changed what an entry-level job looks like.

I use AI every day in my work and in my personal pursuits. I use AI to help me plan so that I can create stuff. I build stuff and I experiment. And this is what it looks like.

I recently had to build a Power Platform solution. I don’t know Power Automate very well at all. I mean, I build all kinds of other things with SharePoint and such, but I mean, Power Automate, what the hell is this? Well, it’s the tool I had to use because it had to live in the Microsoft ecosystem tied to the Microsoft Graph and in a trusted secure framework. I didn’t want to just try and get Copilot to build it for me. Because I’ve known from past experiences that it was really important that I understand the code and what I built. So that if it came down to trying to troubleshoot it later, or if I had to hand it off to someone else, they could figure it out. I wanted to make sure that it was well documented, and that I actually understood what was going on. To that end, I deliberately resisted getting Copilot to build the damned thing for me, and rather used Claude as essentially a talking book or talking manual.

I built it by hand, following the recipes from the spec document that Claude helped me with. And every time I ran into a problem, I’d have to take a screenshot, toss it over there, and then say, “Hey, Claude, this ain’t working.” And that felt like a genuine way to build something that’s somewhere between vibe coding and actual coding. Because you’re actually doing it yourself, with a wizard on the shoulder to try and help.

I don’t think about vibe coding pejoratively. I mean, vibe coding is an approach. At least when it’s done right, you start with what you want the user experience to be and what you want the outputs to look like. You talk through all of those things first, and you come out with an outcomes-based specification document. And then you let the agent cook. Just make sure you do the planning and specification up front to as much detail as possible. That’s key. Vague intents and goals beget sloppy results.

Now, because I come from a developer and IT background, I was able to produce solutions that were genuinely useful. I know what good looks like and it makes all of the difference in the quality of the code I build and the quality of the solutions I ship. Learning real skills does make a difference, even in this age of AI.

In the context of working in the technology trades, you really only have to worry about a couple of things. Did you do good, honest work with a sense of craft and quality? Or did you just rush through and bang it out and get it done? And of course, you always have to ask the question whether or not you’ve added value and helped people.

I’m not going to pretend that I’ve had a perfect career. I screw up often. Sometimes it’s embarrassing, and sometimes it’s just plain funny. It depends upon the stakes. A couple stories:

GroupWise was an interesting enterprise mail system that was made by Novell before Microsoft Exchange had its stranglehold on the market. It is a horrible feeling to be two in the morning sitting in a server room with a broken set of mail servers and you don’t really know how to get it back together again. Because you didn’t write the assembly instructions down the first time when you built the thing. When you’re tired, and you have to go and reconstruct your thinking from a year ago from scratch, it’s pretty close the dumbest thing I have ever done. Now I generally build specification documents and document as I go and maintain a build log for nearly everything I do that counts.

One evening a few years ago, my boss and I were trading emails about a flaky reporting system someone in the business had built. And it was a mixture of different enterprise technologies and a reporting engine running on a machine with a sticky note that said, don’t turn off.

Classic, did I click reply or did I click reply all?

Anyway, you know how that went. I thought it was an email direct to my boss. But it was an email direct to my boss that had the client, the solution owner, on the email. And I had called the person’s thing that they had worked on for many, many years. Their baby. A contraption. I had to go meet with a person, buy them a coffee, and apologize. The relationship did get better, but it did require me to own my mistake with a certain amount of humility. One of the things you’ll have to learn is the art of apologizing in a professional context. No small skill.

Okay, enough war stories. What students were looking for is how not to step on rakes.

Early in my IT career, I spent way too much time working and driving forward. I missed time with my family, my other interests, and stuff like that. And you don’t get that time back. Nobody rewards that kind of effort. They reward the results. If you find you’re in a job where you’re working sixty hours a week on the regular, then it’s possibly time to change jobs. Of course, I’m a big old hypocrite. I did the preparation for the student panel session, and I’m writing this blog post while I’m on vacation. So in classic dad fashion, do as I say, not as I do.

End of the day, you don’t have to take work personally. I mean, yes, you do have to take it seriously, but you don’t have to take it personally. And you don’t have to have your ego on the line all the time. One of my rules of work is “don’t be a hero, heroes die.” I’ve observed in people, across my career, that the IT ego is real. The sense that you are the sage, you are the one that has to have the answers. One of the students asked about imposter syndrome, about how it felt like they were faking it all the time.

Which I totally get. I might not have all of the answers, but I have an IT lens and an IT predilection towards understanding things, an IT view of the world. But I know I can help fill in the gaps. My perspective matters. And so does yours, because it’s different and reflects what you’ve learned and experienced. That’s how you can help. When that is your approach, you don’t have to worry about imposter syndrome so much.

I usually participate in these panel sessions in front of students a couple times a year. And very often, I don’t get a lot of feedback from the room. And that’s fine. I just hope there was a nugget that they could take away.

As always, I put the offer out there for students or anyone at any stage of their career. If they want to chat with somebody who’s been through the wringer a couple times, I’m always available and willing to chat. Willing to coach, willing to listen. Send me your resume and I’ll give you some pointers. Just reach out. LinkedIn.

It’s how I can help.