Structured Text vs Ladder Logic: Why "The Right Tool for the Job" Is Lazy Advice [Full Q&A]

How's it going everyone? Vlad here, and welcome to this week's discussion of the most popular and top upvoted topics in our industry, which is the industrial automation as well as manufacturing. We're here to talk about career progression. We're here to look at technical builds and have opinions on them.

If you have something that is different, if you disagree with some of the opinions, if you have questions about anything specific with regards to your situation, whether that's on the technical side, on the business side, or career side, don't hesitate to leave us a comment, leave us a question. Obviously, any likes and or shares are greatly appreciated so that the algorithms can spread the content to more people.

But regardless, happy to have the conversation around our space, industrial automation and/or manufacturing

Siemens ET 200SP and Odot remote I/O: a yarn machine conversion update

Without any further delay, we've got an update from a username that has posted before. And as we switch over, this comes from the username Froggie Mayo, and they posted an update from the spinning yarn machine conversion ET200SP. That is the Siemens Remote I/O for those who are not familiar, and Odot IO, this is a Chinese brand.

Odot has been pushing more and more hardware, at least in the North American region as far as I know. And it says, "Finally commissioned and running." We'll watch the video in just a moment. The user says, "Hey everyone, sorry for not Have a brief video about the project. Sorry for long delay on this update.

Things got hectic getting everything over the finish line, but the machine is officially commissioned and up and running. How’s it going? Performance, the machine has been running smoothly with a solid increase in productivity and zero downtime since July thirty handoff. Control and IO, the Siemens ET 200SP setup paired with Odot remote IO is handling the high density of winder monitoring and sequencing without an issue.

The HMI overview gives operators full visibility across all a hundred and sixty-eight winder stations at a glance, run status cycle times, idle count, and diagnostics. Cabinet cooling, yes, ignore the pedestal fan before anyone roasts the floor fan. It’s just a temporary stopgap to keep airflow moving during initial post-handover runs.

It will be replaced with a dedicated six-inch exhaust fan filtered louvers to seal the enclosure properly against textile dust. Huge thanks to everyone who chimed in on the original post. Going from legacy control wiring to a clean, modern PLC architecture on a machine of this size was quite the project.

But seeing it run continuously makes the effort worth it. So let’s look at the video, and again, I’ll do my best to provide some commentary for those of you who are only listening to this in audio form. We’ve got the panel. He pans over to the fan that he was describing, as well as the equipment. We’re now looking at the HMI and a couple of screens.

Obviously, it’s gonna be difficult to zoom in. I’m going to pause here for just a moment. These must be the one hundred and sixty-eight, I believe he said, stations, and we see the colors in red as well as green. Again, in many other instances, this would be extremely overwhelming, but I’m assuming that the operators know exactly what they’re looking for.

With the high density of stations, again, that we see in the background, this probably makes sense as an overview upon which you can then dig in a little bit deeper.

Panel review: I/O density, wire tray sizing, and heat

So a couple of comments. Again, it is not very common for me to see this amount of IO in the same single panel. So this is-- must have been a big project from an IO count standpoint.

We have multiple stations. Again, we obviously don’t have the information as to what’s being collected from those stations. But we can see the high density of the IO blocks at the very top, followed by the terminal strips and then cables that are simply spilling out into the panel. Hopefully, the final build is where all of those wire trays get actually covered.

If you haven't been in the business long enough, what typically should happen is as you're designing an electrical panel, you typically provision based on the wire gauge of your inputs and outputs and of course, the quantity of inputs and outputs, and you can size up the wire trays accordingly. So generally speaking, you would have had a larger wire tray.

In this case, it's a retrofit, so you're working with what's been given to you. Uh, you will see that the clearances are fairly low and of course, the inputs and outputs coming in from the field may not be ideal. So obviously, there is some leniency on that front. But what you will typically find, and this is what creates that problem of heat, is that every single cable inside of this machine, even if it's a small amount of current, but will create some heat due to resistance.

And of course, when you have these massive bundles of cables, you will need some proper ventilation. Otherwise, you just risk damaging equipment and having premature failures. Your I/O cards will start acting up. Usually, the equipment is rated, but again, there is a limit to obviously everything, especially in a dusty environment such as this one, where you have a ton of yarn.

So if you don't have any ventilation and you're constantly accumulating that dust and debris, the panel is just going to continue heating up and you will see component-level failure. So he's already addressing that. That is great. The panel build itself looks really good. I would be very curious as to why they use-- And I believe that was my commest-- comment last time that I spoke about this.

Why run two flavors of I/O in one panel

Why did they use the two flavors of I/O, which is the Siemens side as well as Odot? There might be an opportunity to save some money, I've not ordered a bunch of Odot hardware, how reliable they're gonna be in the event of a failure. And I can imagine with this high of a density, something is always bound or need replacement.

So if you're paying just a little bit extra and you have the right distributor, uh, next to you, maybe it's worth it, maybe it's not. Again, I'm assuming someone has done the due diligence, but if the customer is happy, that ultimately is all that matters.

Hi, my name is Vladimir Romanov. I am the founder of Joltek as well as SolisPLC. With a background in electrical engineering and an MBA and over a decade of experience leading projects in manufacturing and industrial automation, I help engineers, managers, and manufacturers make smarter technical and business decisions, modernize their operations, and build stronger careers.

If you're serious about manufacturing, automation, and staying ahead in the industry, subscribe and join the community

Water inside a VFD: what washdown really does to enclosures

Our second question is a bit of a safety, a bit of a joke comment, I would say, but important to address and understand within the context of our industry So this comes from a username I automate stuff, and they say this is okay, right? And there's a video and it says, "Guys, my drive is running a bit rough.

Any suggestions?" So if we play the video, we can see that there's water leaking underneath what looks like three bus bars of the drive. Again, we don't have any visibility as to how big this drive is, and so it could be multiple horsepower. And I do have a story on this front before we address the general comment.

So as some of you may know, I have been working a lot in food and bev, CPG, pharma, and chemical industries. And I still remember that when I moved over from Procter & Gamble to a food and beverage company, Procter & Gamble was very, very strict about the standards, especially in electrical panels.

Everything was done right, but also in a fashion that made a lot of sense from a safety standpoint. Now, when I went to some of the food and beverage plants, I was in complete shock, and this was ten-plus years ago. But I remember opening up panels with drive cables. And this is four-eighty volts, um, AC going underneath and being completely submerged in three inches of water.

And when I brought this up with the plant technician that was on site giving me basically the tour, he said, "No problem. Vlad will take care of this." And they drilled a hole into the panel to drain the water from the electrical cabinet. And so since then, I would say that I got a little bit more accustomed to seeing these scenarios, and I'm no longer, shocked.

But what you need to realize if you haven't worked in food and bev or any FDA-regulated environments, one of the process needs, is they're gonna go through the process of cleaning the equipment. And this is basically a process of sanitation. You want to make sure that everything in terms of the bacteria, first and foremost, is removed from the equipment.

And of course, this generally means that someone's now going to make sure that the panel is going to be outside of your-- let's say if that's a slicer, if that's even a conveying system. In most cases, you would want the panel to be, let's say, in an enclosure above the equipment or in a separate room. But in many cases, what happens is that panel is attached to that machinery, and it's going to be left there to be hosed down for sanitation purposes.

And of course, as you can imagine, there are seals, there are food-grade panels, there are food-grade sensors, there are food-grade devices. But generally, the electronics that go inside of that panel are not going to be food-grade. And so pair that with the fact that over the years, those seals are going to degrade.

No one's going to do the maintenance. In some cases, the latch to properly lock the panel in place and seal everything inside is going to fail And so what you're left with is basically water slowly seeping in inside of those panels. So this is not overly surprising to me. It might be surprising to those that haven't been in this specific industry.

But once again, if we switch over to this video, we do have some water inside of the drive. How did this happen? Again, my general guess is that the panel had some kind of a leak, or in some instances, the motors or the VFDs in this case can be mounted externally. In a lot of cases, they should be food safety rated.

In some cases they're not, so they're going to get either water, they're going to get condensation or something's going to happen which will lead to this specific failure.

Structured text vs ladder logic: where ladder actually came from

The next debate is as old as PLCs themselves, and I'm talking, of course, the discussion between structured text and ladder logic. I believe I've had this conversation over 100 times at this point with different individuals, directors of OTs, even, uh, vice presidents at some point that wanted re- to rewrite structured text back into ladder logic and to a variety of reasons And so this post comes from the username StrokingShop5393, and they say, "Structured text.

I have to admit I was wrong multiple times on the sub. I have been writing a program in structured text on a CODESYS platform the past week because that's what my customer wanted. Structured text really is the superior programming language. I'm sorry for doubting all of you nerds. I have joined you in the autism.

I need not explain myself. If you know, you know. I am prepared to be downvoted by the non-believers and uncultured." Again, this is a bit of a joke, but at the same time, it is important for us to discuss. There's a couple of points that I've made in the past. So let's start with the context of where ladder logic was created.

So in the past, we had, I would say, assembly and probably C at that time, and when we were wiring equipment. I was not part of that time, but I read into the history and I spoke to many individuals. But as equipment was built, it was generally following the electrical schematics and basically the prints that were made for the machines.

Now, in 2026, the truth is a lot of those schematics have not changed. And so that is the main reason why ladder logic just simply lends itself a lot better to structuring programming, especially when the equipment is simple, when you're not handling data, when you're not building, let's say, recipe management systems.

It is just overall easier, not only for the technician that's troubleshooting, but even for the electrical control systems engineer that's looking at a schematic that has been properly made and has been properly laid out. It is easy to see the connections between the inputs and the outputs that need to be actuated.

So there is an argument to be made as to using ladder logic for the majority of programming when it comes to control systems

Why "the right tool for the job" is the wrong framing

Now structured text, and I truly dislike the comparison of or the saying use the right tool for the job. The reality is most languages inside of control systems can be used to accomplish 90% of the tasks. You could create a function block diagram that will flow from one input to the other and actuate just as you would like or just as you would do in ladder logic or structured text.

My point here is that you can use any of the tools to accomplish this job. In certain situations, the tools are going to be easier to utilize for the specific application. So generally speaking, from my experience, I prefer to use ladder logic for the majority of discrete equipment. Once you start going into process, function blocks really make sense because you typically have continuous flow just as you would in a block diagram.

And if you're familiar with, for example, P&IDs, you will know that you have continuous flow into some of those inputs. So you as the engineer or as the human looking at that program, it is a lot easier to understand what is going on in a function block style diagram program than it is in ladder logic or structured text.

Could you have completed a P&ID implementation or PID and P&ID implementation, those are two separate different things, in structured text or ladder logic? The answer is yes, you can. But for someone that's looking at that program after you have left, it becomes a steeper learning curve. So the point is not use the right tool for the job because you can use any tool to accomplish that job.

The point is that you also need to take into account what's going to happen with that software after you have left. And this comes back to the good software development best practices where it doesn't matter if you're programming a control system, a system for web in Python or a web-based application in JavaScript.

This is simply good software development hygiene

Platform documentation decides the language more than preference does

The second argument that needs to be made here is you need to be cognizant of the platform. So if we're looking at Rockwell implementations, if we're looking even at Siemens, there's going to be variations and thus differences in how well documented some of the architectures are going to be. In this instance, the username is pointing towards CODESYS.

So naturally, people that program CODESYS are going to be using a lot more structured text because they are building some of these niche applications. And therefore, if you go online, there's going to be a lot more resources. Therefore, you can even prompt your way through writing structured text a lot better.

So it is also natural to have differences between different manufacturers of your equipment as to what you're going to use. But the reason is not because you're using the right tool for the job. The reason is because the documentation is generally better. You will have a lot more answers from your peers.

You will have more information generally available online. reason why you're saying structured text is better as opposed to ladder logic.

A customer demanded 18 AWG on every input: is the customer always right

The next post is extremely topical. I had a very long conversation on the podcast as well as off the podcast that I do called "The Manufacturing Hub," and I was debating with, Dave, my co-host, the concept of is the customer always right? If they're paying you to do the job at a certain, I would say, level of quality that they deem necessary, do you basically take the money and do the job as expected?

Do you push back on some of those items? And of course, the general answer is it depends. But I would say that in a lot of cases, as the engineering team, you come in after the decision has been made, and you just need to adhere to a set of requirements. There are times where you can obviously push back and explain something should be done in a different way, but in some situations, that time has passed, and you simply need to implement what has been asked of you

And so this question or comment comes from the username JN Foster, and they say customer demands. We have a couple of photos we'll look at in just a moment. Customer demanded everything to be in point seventy-five millimeters squared or eighteen, uh, American wire gauge. And we have the Rockwell Automation DC input cards, and we have two pictures.

We have one from the front and one from the side. Again, the complaint here for those who are unfamiliar is that when you set up a panel with eighteen wire gauge on all of your inputs, it becomes incredibly bulky. If you're not an electrical engineer or technician, the wire gauge is basically the thickness of the cable when you cut it in the middle, which allows more or less current to flow in depending on the rating.

The point here is that if you have inputs, in most cases, the current is negligible, and so you should be explaining to the customer, "Well, you don't need eighteen wire gauge for your inputs. You can probably get away with much smaller cabling," um, significantly smaller than this. But as the user said, "Well, that's what the customer wanted, so that's what the customer is going to get."

Now, again, is it worth spending the time to go and argue with the customer and explain to them, you could probably use a smaller wire gauge. It's probably going to be cheaper." You're probably not going to heat the panel as much. Again, maybe there's some dissipation of heat calculations that could be made.

The project was probably handed to this person, and they simply had to install as the system requirements were laid out to them. And again, this is a small item. I would say that generally speaking, this obviously cost a little bit more on the project, but probably an insignificant amount for the overall install, especially at the cost of these ControlLogix chassis.

Could this have led to other failures or other problems? Maybe they had to upsize the wire trays, which ultimately led to an upsizing of the panel. Is that a big issue if the customer is paying? Not really. Could they have saved some money? Probably. But I-- in my opinion, this is not something that you should be spending too much time arguing on because again, the customer is, I would say, the one making this demand.

They're not going to benefit from this either way. Again, maybe they simply don't know, and this has been just a standard for maybe some of their older systems. If you're l- running basically a higher voltage and some of those relays are going to close for the contacts, you know, maybe a couple of decades ago, then there were higher currents on these cables for whatever reason.

But in twenty twenty-six, if you're deploying very standard inputs and outputs, you certainly should not need this gauge of a cable for standard IO.

Laid off after four years, and how not to be first on the list

We've got a career question next. I know that layoffs have been very impactful on the software side. There's, of course, tons of different news of software companies laying off software engineers due to AI, due to restructuring, due to over-hiring because of COVID. It's obviously very difficult to figure out the true reason why, unless you start reading the financials and have access to some of the P&L maybe and the decisions that they're making.

But it is also, I would say, generally common maybe to see layoffs in our industry depending on the vertical. But I would say that our market is still relatively strong. If you know controls, if you know SCADA and MES, there is plenty of work to be done And so this user is by the name AdventurousGoose6485, and they say, "Recently laid off with four years of experience, looking how to avoid this in the future.

Hi all, just yesterday I was laid off without notice because our executives decided the plant's control team was making too much money. I'm still trying to process this, but I'm determined to take steps not to be the first on the layoff list in my future jobs. How would you recommend me to enhance my skills and be an engineer in demand?

A lot of my tasks in my job would get delayed because of budget reasons, but I can program PLC, have an understanding of NPN sensors and how to wire them into PLCs, have experience with OT and IT networking, Linux and most of my HMI work has been with FactoryTalk and Ignition. But I still always feel like I'm falling behind my peers in other engineering disciplines and that this experience has taught me controls engineers are looked down upon by executives who have no idea what work we do."

So there's a lot of questions and comments to unpack here. Let's start by looking at it, I would say line by line. "Executives decided the plant's control team was making too much money. I'm still trying to process this. Determined to take the steps to be the first on the layoff in my future job."

So again, I do believe that controls is very heavily misunderstood. I believe that the engineers in our space are very bad at communicating the value that we ourselves provide, and I struggle with the same. I many times would go through an entire week of troubleshooting and finding all sorts of different problems, and I simply don't have the capacity, and the willingness to go and try and put together a solid doc as to what has been done and why we not only needed electrical engineering, we also figured out process problems, mechanical problems, and all sorts of other things including, um, you know, making sure that production doesn't stop.

So I think that there is an importance and something to be said that we are, in the control space, perceived as, disposable. But again, I think that the ramp period as well as what it takes to do control systems work is incredibly difficult, and I would be surprised that these executives find somebody else at a cheaper price point than the person that is already familiar, hopefully with the equipment.

And again, I'm making this comment without knowing all of the details of the layoff, right? I'm just reading the general comment of this user. They say, "I'm still trying to process this, but I'm determined to take steps not to be the first on the layoff list in my future jobs." I guess I am really curious, and I'm maybe throwing back the question, were you the only person that was laid off?

I would say that generally speaking, if they're trying to cut back on the entire team and if they, you know, instead of let's say, having eight engineers have decided they only needed four versus if you're a team of five and they've only removed you, probably they gave you the wrong reason. They probably were just, um, not seeing the performance that they wanted and so they decided to lay you off and told you that the entire team is taking way too much capital.

So I think that it's very unclear that this is necessarily because of the steps or the gaps in your knowledge or someone that, uh, just didn't like you or it was the entire department How would you recommend me to enhance my skills in being an engineer in demand? So when you're laid off, I would say that my general recommendation is start looking as soon as possible.

Obviously, take maybe a week, maybe two weeks off, depending on your financials. Start reaching out to recruiters. Start reaching out to engineering and hiring managers. Start applying right away. Find something else. Once you are there, do obviously apply yourself for the job, but also start a learning plan.

And in this case, everyone's going to give you a lot of different recommendations. I think number one, you need to understand where you would like to go. You can create a fairly good, I would say, training curriculum by using either ChatGPT, Claude Code, Opus, pick your flavor of LLMs, and figure out what is the next step.

And I do have some comments on the next comments or statements that you've made, which will go back to the learning advice I will give you. So a lot of my tasks would get delayed because of budget reasons. Um, so to me, this is a really strange statement. Obviously, as a control systems engineer at a plant There will be larger projects.

It means that sometimes you need to be patient, but this should not be a main statement that you give, for example, to your recruiter. There's always something to do at a plant. I always, um, I always smile when I go into the manufacturing facility because for me, it's almost the opposite is true, right? And what I mean by that is the moment I want to focus on the long-term project, I get pulled in dozens, if not several dozens of different directions.

Someone wants to improve a line, someone wants help troubleshooting something, and the way you get implicated in those projects is you need to be, number one, competent, but you also need to make sure that you're available for those people. So if somebody calls for a systems engineer that can help them with XYZ, you need to be there to ansel-- answer that call.

This is not a reason that if you're delayed, you're just sitting there and not doing any projects. There's always something to improve. If there's absolutely nothing happening, go to the line, observe the people working there, either operators or supervisors, ask them questions, see if you can make improvements.

I can guarantee you, they will give you things to work on that you can then bring to your, let's say, engineering team. Obviously, make the pitch to your engineering manager, get his approval, but tell the plant that you're making things better and not just twiddling your thumbs waiting for some other projects or budgets or whatever else.

A strange mix of skills, and which layers command a premium

"I can program PLCs, have an understanding of NPN sensors and hire-- how to wire them into PLCs, have experience with OT and IT networking, Linux, and most HMI work has been FactoryTalk and Ignition." Um, this is a very strange and mixed bag of skills, I would say, and not necessarily in a bad way, but just in a strange way, right?

So if you, if you are programming PLCs, that is one skill set, and I would bundle that generally with, let's say, building HMIs on FactoryTalk View ME or SE, and then Ignition. That is one skill set. Next, you have wiring NPN sensors into PLCs. Again, I'm not sure if you're looking for panel builder work. I'm not sure if you're looking to troubleshoot devices and IO.

Generally speaking, if you're focused on programming, you may obviously do some troubleshooting, but your job should not consist of wiring NPN sensors inside of a panel. Maybe you're troubleshooting things, but the way this is worded is a little bit strange to me. Next, we have experience with OT and IT networking, Linux.

And so this, again, this is really strange because this seems like you're an IT person as well for some of these environments. And I know that a lot of our jobs are transitioning to that, and it's good to have this understanding. But if your job is being downsized and you're basically an IT admin and sometimes a PLC programmer and sometimes a technician that can wire up a panel, it is very unclear what is the actual work that you have done.

I would say out of all of this, I would probably focus on FactoryTalk View ME and SE, and the PLCs as well as Ignition. I think that those layers probably command the highest premium if you want to remain on the OT side. Of course, this experience on the networking side is good as well, but probably is secondary to your control systems.

I still always feel like I'm falling behind my peers in other engineering disciplines, and this experience has taught me controls engineers are looked down upon by executives who have no idea what work we do. I've commented on this a little bit, so I'm not going to say that much more. I agree with the statement.

I feel like I'm falling behind. Again, what is giving you this feeling? I would honestly talk with my peers and understand what it is that you are lacking. I would probably have a clear plan with the manager that you will be hired on by and discuss with them what does the learning opportunities, number one, look like?

What does the roadmap look like? And figure out what you need to learn to stay on top of things, but also not have this feeling of falling behind. It's-- I would honestly spend some time reflecting as to why might be causing this specific sentiment in your career.

Hiring junior engineers: what a degree does not tell you

Last but not least, we have an interesting recruiting and basically bringing up new talent type of a question. Over the years, I had the opportunity to interview, to hire, to mentor. I even have a story where an individual basically with a, um, degree that is completely unrelated in exercise science was paired up with me and within a couple of months was basically a fully billable control systems engineer and is extremely successful in his current career, is still doing control systems level work.

So I do have quite a few opinions as to the comment that this user brings up And so this comes from the username thanoise, uh, four, and they say: How does your company handle younger new talent? What does the process look like and how long do you spend on college certificate graduates before making hire decisions?

Um, couple of questions there. I've interviewed and hired several young college grads over the last couple of years, computer science, computer engineering, electrical engineering, and one guy who has an electrician with some real, uh, panel troubleshooting experience at his last job. My young EE has worked out.

He shows up early, learns fast, and if I hand him something, he'll teach himself how to figure it out. Maybe I got lucky. I have two others who are a completely different story. One of them wants to keep working weekends at the job he's had since high school. That's a perk to that if it's his hobby, but he's not picking up the simple things we're asked him to learn, and he gets competitive when you correct him.

He can easily afford this hobby with a house payment sometime in the next five years if he's smart. The other guy learns quickly, but he's been late about forty percent in his first two months. Maybe ten percent was legit. I had a hard talk with him about how we're not in college anymore. A customer is literally paying us to have the team where we need to be when we said we'll be there.

This was a site forty-five minutes from his house that needed to be there by nine AM. He needs to set a damn alarm or three.

The DHCP interview question, and better questions to ask instead

So I'm about to start interviewing for a junior level role again, and I'm just not impressed with the current crop. I've started asking every candidate one simple question: What does DHCP do or what is it used for?

Nobody can answer it, so I feed them a little. Can you tell me the difference between a static and a dynamic IP, or tell me about a time you set that up on your device? They don't know that either. I keep thinking about emailing somebody these schools about it. What are they actually supposed to know? Are these guys the ones who were checked out?

The only person I can really hire is someone who can figure things out, is willing to learn, and can accept that they know almost nothing on day one. Has anybody found a good way to filter for that in an interview? I'm honestly curious. I'm also willing to answer questions for those on the job hunt. I'm a small outfit in a specific market in a specific place, so I'm not looking to hire anyone from this, just looking for a discussion about how we're all hiring and what we're looking for in an employee.

Um, once again, I have mentioned that I had the opportunity, I would say, to interview quite a few people, and to be honest, I don't know if I would make the comment that things have changed or shifted over the years. I think that it has always been the same. It is very difficult to find engineers who are autonomous, are able to show up on time, and execute in a manner that makes sense in front of the customer.

And so, of course, as a small business owner, it is a huge concern bringing in someone that is fresh out of university that hasn't built up some of these skills or perhaps someone who's a little bit experienced but has some of these bad habits. And so I laughed a little bit about some of the questions that he's asking, and we'll get into that in just a moment.

But let's start with some of the obvious, I would say, like comments, right? So interviewed and hired several young college grads for computer science, computer engineering, and so on.

And I would generally say that it is a good start, but from my experience, having studied with many individuals, at least in the university that I was in, I could tell you that you could very easily basically, and I exaggerate a little bit, but it's, it's very close to the reality. You could earn the degree without having the extent of knowledge that you would need for a true employer.

Meaning that if you just showed up, if you learned the bare minimum, you would have been able to graduate and get the engineering degree, apply for the official junior engineer designation here in Canada, get your PE, and ultimately land, I would say, generally speaking, some kind of an easy role where you're doing paperwork as an engineer, maybe managing some simple projects, so on and so forth.

So first and foremost, for me, the degree alone is not the indicator that you should be looking for. I generally review the resume, and I want to see some outside work besides the degree. And what I mean by that is everyone has completed the same coursework, whether that's computer science, computer engineering, or electrical engineering.

What I'm looking for is extracurriculars. I remember when I was in university, I was doing a ton of Arduino work. I was part of the IEEE club. I was building things outside of university as part of the club activities. But the point is that no one was asking me to do those things. I was simply excited about electronics, and I was trying to learn things on my own.

I was talking to people who were in that same, I would say, headspace. And then there were a ton of other individuals that would prefer to go out and drink beers. And again, obviously, everyone has their own activity and what they want to do and spend their time on. But I think that there is something to be said about being excited about the industry and simply not caring enough, which I think shows up in some of the comments that this user is making.

And so obviously the EE has worked out. We have two others, right? So one of them wants to keep working weekends at the job since he's had since high school. The way I see things, right, if you want to be at the top level of your craft, you need to generally dedicate some of your personal time to mastering said craft.

And I know that many employers in a general sense, right, not necessarily in the automation space, but in the consulting world, having, you know, interviewed and basically talked to many individuals there will forbid you from having any other employers outside of your main job. It is extremely frowned upon.

Obviously, barring that it's something completely different, maybe okay, maybe it is a hobby. There's something to be said, but I would generally consider that a red flag. To me, this means that this person is simply not interested in the main job that they're doing, and therefore they're probably distracted.

They're looking forward to the weekend. They're probably just extremely tired since they're not able to recuperate. I'm assuming they're working five days for this person, then working the then working the two days of this weekend job over the weekend. So of course, you're coming back to work, you're dreading work, I'm assuming, every single week.

So you're dragging along, you're not necessarily learning at the fastest pace. I would have a conversation with them and understand if this... I- is this the job that they're looking to do, or if they can just go to something else and work this job that they've had since high school, but it seems like it's not really working out.

Lateness, moonlighting, and the habits that end a junior career

The other guy learns quickly, but he's been late 40% in the first two months. And this is a story that I'm going to say in a general sense. So I've worked with a variety of different engineers, managers, directors, and VPs. One thing that I generally do not tolerate is someone who is late, right? And someone who doesn't show up for a variety of reasons.

And this is even in front of myself, but more importantly, in front of customers that I'm working with. And even if I'm working on a project, and let's say I have a counterpart that doesn't necessarily report to me, if we're asked to show up at a specific time in front of the customer and I show up on time, this person doesn't show up on time, we're both looking bad, but more importantly, that diminishes the perception of the customer towards me.

So now you're not only late and are doing whatever it is on your side, you're also making me look bad, my career look bad, and thus you have a negative impact on what it is that I'm looking to achieve. I personally do not have time for such behavior. If this person is able to change, I would say, and if they, if they are able to adapt and do something else, that's perfectly fine.

What I have seen is that if it's 40% late in his first two months, to me, this is way over the leniency that I would give them. If you're late once, uh, you're going to have a conversation. If you're late twice, we're going to have a more serious discussion as to where you would like to go. Again, if there's excuses, right, if the, the...

you say that 10% was legitimate, which is still a pretty strong indicator that they've been late way too many times. But if this is a, is a recurring issue, we simply cannot afford to be, uh, put in that position. And I think that this demonstrates a very, um, strong desire not to perform at the level that most companies require, at least not to my quality standards.

If, uh, this person is careless, they're gonna be careless in front of the customer. They're going to be careless with their peers. This is not something that I would personally tolerate. I would, like I said, you've probably already had the conversation with him before, but I would simply get rid of this person as soon as possible as they are a very clear negative to your business, uh, team, project, whatever

In terms of hiring, so I had some conversations with some of my peers who are in a very similar situation. They ask the most basic questions. And again, maybe I- I'm looking back a little bit. I guess I had spent too much time on computers during my university days, so I had to know what, uh, DHCP or dynamic addresses are going to be.

I played around with routers and switches since probably I was 14 or so. I remember learning how to program in C++ to basically develop some small games way back in the day. So obviously to me, that question is easy. Um, I would say that for people that go through college and go through university without doing the actual applied work, this is hard, but I would continue asking this question.

I honestly believe that if your standard is such that they need to know the absolute basic... And this is, again, maybe this is not the right question. I think this question is a little bit, um, interesting because it's not necessarily OT based. It's more, I would say, obviously, if you need to go online with the PLC, you need to change your IP address typically to a static IP address as opposed to, uh, dynamic or DHCP based on, let's say, like your, like your home router.

But maybe I would a- start asking different questions, right? What kind of PLCs are you excited by? Do you know anything about Rockwell? Do you know anything about Siemens? Would you be comfortable, let's say, wiring in a switch, right? And I wouldn't necessarily have them do the actual work, but if you've graduated from electrical engineering, I would at least have that conversation with them.

Are they able to talk their way into connecting to a PLC? Are they excited about PLCs? Are they excited about automation? Um, I'd be curious to hear what kind of other questions do you have for these individuals. I've been asked, and I still remember these interviews. I remember, um, I was brushing up on basically equations for different drives and different motors, whether that's, uh, servo drives or, uh, VFDs, and basically remembering all the physics of motors because I studied power and renewable energy systems in my electrical engineering bachelor's.

And so I had all these equations, right? I had done calculus four, I believe, at that point. I had done control systems and MATLAB simulation. So I had memorized all these equations. I showed up to the interview, and the question that I was asked, I remember, I guess my boss at the time, who ended up being my first boss, drew a right rectangle, and he asked me, "Could you write the equation for this?"

And I, like, very puzzled, right, like, looked at him, and I, and I wrote on the, on the whiteboard, A squared equals B squared plus C squared. And he's like, "Very good." And then he asked me a follow-up question, which was, "Could you simplify this?" And I wrote A equals square root of B squared plus C squared, right?

Which is, again, this is high school, and I would say maybe second year of high school level math. But to me, it was just funny to what extent you can get a very easy question, even for an engineering-level role. And to me, it seemed like he was maybe discouraged with the candidates. And I've had interviews where I was asked to program, for example, a PLC or FactoryTalk View ME screens.

So that is not out of the question, but I would say that's more for an experienced hire. Um, the only person I can really hire is someone can, who can figure things out. I honestly think that there is a very thin supply of such individuals. I think that you need to be very clear with the expectations. I would say that, again, this is based on my experience, maybe 5% of the individuals are capable of delivering on this specific promise.

A lot of the other people are good at their craft, but they will require some guidance and a little bit more hand-holding. I'm willing to answer questions for those on the job hunt. I'm a small outfit in a specific market in a specific place, so I'm not looking to hire anyone from this, just looking for a discussion about how well-- how we are all hiring and what we're looking for in an employee.

I honestly, I believe that if this is the requirement and you need someone that is actually good at their job, maybe you look at more experienced hires, number one, and maybe you reach out to recruiters that talk to individuals still perhaps in university. I would also put some feelers out. I've had a really good I would say result building connections back with some of my alumni.

You can start talking to individuals before they graduate. You can gauge a lot of their interest because ultimately, a lot of this boils down to their, um, extrinsic, I would say, motivators. They're not just there for the paycheck. They're trying to learn and get better at electrical engineering, cybersecurity, OT networks.

They read the right publications, right? I remember buying equipment because I was simply too curious to learn and understand some of these things, and to me, that is the normal, right? If I talk to individuals who simply do not care about PLCs and automation, to me, that's the strange, I would say, like conversation when you're in this field.

Wrap up

So in any case, that's all I have for, this person as far as advice goes. Obviously, it's very difficult to find people. If you have any questions, if I can help in any way on this, hiring, I would say, journey or anything else when it comes to industrial automation and/or manufacturing, don't hesitate to reach out.

Thank you so much for watching and/or listening, and I will see you next time.