Engineers and Electricians

When I did my undergraduate education in electrical engineering, the difference between being an electrical engineer and an electrician was obvious. Electricians are experts at applying the rules of their trade. They know the codes, the standards, and the safety requirements, and they make sure that homes and businesses are wired correctly. Electrical engineers, by contrast, are trained to understand and develop those standards. We design systems, create the models that determine what is safe, and explore how electrical principles can be applied to new technologies.

One isn’t better than the other. Many (most?) electricians enjoy more lucrative careers than engineers, since skilled trades are in constant demand and command high wages. The focus of the work is simply different. An electrician may know immediately which gauge of wire to run in a house because the code mandates it. I may not have that fact memorized, but I can compute it from first principles, though my calculation may not align with what the law requires and my work will fail the inspection. That illustrates the distinction: one role emphasizes compliance and safety, the other emphasizes design and underlying theory.

Shifting to Computer Science

I did my graduate studies in computer science, which shaped the course of my career. Here too I found a similar divide. Roughly speaking, it is the difference between certifications and a university education. Certifications emphasize the ability to apply existing standards and tools. A Cisco-certified network technician or a security professional with a CompTIA certification demonstrates that they can configure systems correctly and in line with best practices. University programs, on the other hand, emphasize why those standards exist, where they came from, and what their limits are.

Frameworks provide a good illustration of why this matters. In the past few decades alone, we’ve seen waves of popularity: Java Servlets, then J2EE, Ruby on Rails, Django, Spring, Angular, React, and countless others. Each had its moment, and each is still used somewhere (as are COBOL and FORTRAN). But betting everything on a single framework is risky. The underlying concepts -- client-server models, separation of concerns, distributed state -- are what endure. A university education is designed to ground students in those fundamentals rather than in the rise and fall of specific tools.

When All You Have Is a Hammer

There’s another nuance here. It’s the old saying: when all you have is a hammer, everything looks like a nail. If you are an Oracle DBA, many problems start to look solvable with a database and a few stored procedures. If you spend all your time programming in Python, Python will look like the best tool for every problem. Certifications and tool-specific training can reinforce that tendency, while a university education is meant to expand the range of approaches you can imagine and evaluate.

Lessons from Teaching

The distinction showed up in various courses I've taught:

In computer security, we look at why specific cryptographic algorithms were developed, what makes certain key establishment protocols secure, the full range of access control mechanisms, and the fundamental vulnerabilities of network routing or email. That is very different from being told you must enable SPF, DKIM, and DMARC for email, or that specific regulations demand 256-bit AES encryption for data at rest.

In distributed systems, we have the same distinction. A university course examines the foundations: how distributed consensus algorithms guarantee agreement across unreliable networks, the mechanisms that make remote procedure calls work, how large-scale file systems are implemented, and the algorithms that drive distributed computing. Industry training, by contrast, might focus on how to use a suite of AWS tools or Microsoft Azure frameworks.

In operating systems, the goal is not to learn how a particular version of Linux works or how Windows is architected. It is to understand the mechanisms that span many systems and the abstractions that evolved to solve problems: managing growing amounts of memory, providing different access control models, hiding device-specific details behind common interfaces, and optimizing storage for new technologies such as flash memory. Those principles apply whether the student works with Windows, Linux, iOS, or something entirely new. And some powerful abstractions never made it to any mainstream operating system.

Students, Employers, and the Tension Between Them

The academic approach provides long-term, flexible skills that prepare students to adapt as technologies change. But it can also feel disappointing to students who expect a course to hand them a checklist of frameworks or standards that map directly to job descriptions.

That disappointment is amplified by today’s job market. The long-term employment contract is gone; companies rarely commit to nurturing employees over decades. Instead, many employers look for plug-and-play skills: someone who can administer a Palo Alto Cortex XSIAM platform, configure AWS IAM roles, or show a Google Cloud certification. Those credentials demonstrate that you can be productive immediately, which has obvious value to a hiring manager.

But they also tie your career to the lifespan of a product. Just as Ruby on Rails or J2EE once seemed indispensable, today’s hot framework will eventually be replaced. A career built only on vendor-specific skills risks becoming obsolete with the next wave of technology. A career grounded in computer science fundamentals, by contrast, equips you to pivot as the landscape changes.

I see students wrestling with this tension all the time. They want to be job-ready, and understandably so. My hope is to help them recognize that while certifications and platforms may open doors in the short term, it is the fundamentals that will sustain a career over the long haul. Just as the world needs both electricians and electrical engineers, our field needs both practitioners who implement today’s standards and computer scientists who understand, question, and extend them.