Liking Computers Is Not the Same as Studying Computer Engineering

There is a very understandable way to choose computer engineering.

You like computers.

You like the internet.

You spend a lot of time in front of a screen.

Therefore:

computer engineering.

The logic feels almost perfect when you are eighteen.

In June 2010, I wrote a warning to students choosing a university major:

Do not choose computer engineering just because you love computers and the internet.

And if you really dislike mathematics, think very carefully before choosing it.

The entry became more dramatic after that.

I described a version of professional life in which you might spend eighty hours a week at work, sit inside laboratories without internet access, try to bring hardware boards to life, write drivers, fight defective hardware, explain yourself to customers who are never satisfied, drink two liters of coffee a day, prepare presentations for the following week, wait for subcontractors who answer email only when they feel like it, and train users who may know more about backgammon, okey, and pişti than the software you built for them.

Then I ended with the emotional conclusion of a tired engineer:

To hell with computers and the internet.

It was exaggerated.

It was also rooted in experience.

And behind the frustration was a useful distinction I had learned the hard way:

Enjoying a technology is not the same as enjoying the work required to build it.

This distinction exists in many professions.

Liking cars does not automatically mean you will enjoy mechanical engineering.

Liking airplanes does not mean you will enjoy aerospace engineering.

Liking video games does not mean you will enjoy writing game engines.

Liking films does not mean you will enjoy twelve-hour shooting days.

Liking food does not mean you will enjoy running a restaurant kitchen.

The consumer experience and the production experience are different worlds.

From the outside, computers were fascinating.

Software.

Games.

The web.

New hardware.

Programming.

The feeling that almost anything could be built if you understood the machine well enough.

That fascination was real.

But professional engineering introduces another reality.

Sometimes the computer is not even a computer in the familiar sense.

It is a board on a lab bench.

No monitor.

No browser.

No convenient development environment.

Maybe no internet connection in the room.

You are trying to make hardware initialize correctly.

A device is not detected.

A driver does not work.

A vendor document is incomplete.

The board revision is not exactly the one described in the manual.

A signal exists but not where you expected it.

The software works on one configuration and fails on another.

At that point, the romantic image of “working with computers” becomes very different.

You are not surfing the web.

You are negotiating with reality.

This was especially true in embedded systems.

Embedded work can strip the word “computer” down to its essentials.

Processor.

Memory.

Interfaces.

Timing.

Drivers.

Operating system.

Hardware.

A board sitting on a table may be more educational than a polished desktop computer because nothing is hidden.

Unfortunately, when nothing is hidden, nothing is easy either.

At university, many students imagine programming as the center of computer engineering.

It is important, of course.

But the field is much larger.

Algorithms.

Data structures.

Operating systems.

Computer architecture.

Networks.

Databases.

Compilers.

Signals.

Electronics, depending on the program.

Mathematics.

A surprising amount of mathematics.

This can disappoint someone whose original motivation was:

I enjoy being online.

The internet is a product.

Computer engineering studies and builds parts of the machinery beneath products like it.

That difference matters.

You do not study “using computers.”

You study abstraction, computation, representation, systems, constraints, and problem solving.

Sometimes this is enjoyable.

Sometimes it is painful.

Often it is both.

The same was true after graduation.

Professional work introduced a different set of difficulties.

Technical difficulty was only one category.

There were customers.

Schedules.

Presentations.

Subcontractors.

Documentation.

Meetings.

Delivery pressure.

Hardware procurement.

Dependencies you did not control.

People waiting for answers.

People not answering you.

A university course rarely captures the emotional effect of waiting three days for a response from someone whose component is blocking your entire project.

No algorithm fixes that.

There is no elegant data structure for:

The subcontractor will reply whenever they feel like it.

Engineering is full of problems that are technically simple and organizationally difficult.

This surprises young engineers.

We expect difficulty to come from the hard technical parts.

Sometimes it does.

But a great deal of professional frustration comes from coordination.

Your code is ready.

The hardware is late.

The hardware arrives.

The driver is wrong.

The driver is fixed.

The customer changes the requirement.

The requirement stabilizes.

Someone else changes the interface.

The interface works.

Now you need to prepare a presentation explaining why the schedule moved.

The system is not only software and hardware.

The system includes people.

This may be the most important systems-engineering lesson of all.

People are dependencies too.

Less deterministic ones.

My old entry mentioned spending very long weeks at work.

I would not present an eighty-hour week as something admirable.

If anything, it is usually evidence that something in planning, staffing, scope, or organizational culture has gone wrong.

But young engineers can easily normalize long hours.

There is always one more thing to fix.

The work is intellectually engaging.

The deadline feels important.

Everyone else is still there.

Coffee appears.

Dinner appears.

The evening disappears.

You tell yourself this week is exceptional.

Then the exceptional week repeats.

Work has a strange ability to expand into all available time when the boundaries are weak.

Technical people are vulnerable to this because unfinished problems are psychologically sticky.

You leave the office.

The bug comes home with you.

You think about it in the shower.

At dinner.

In bed.

Then at 2 a.m. an idea appears.

This can be satisfying when it is voluntary.

It becomes exhausting when it is constant.

My “two liters of coffee” line came from that atmosphere.

Coffee is practically a supporting character in engineering stories.

Not because caffeine is a technical requirement.

Because fatigue gets converted into ritual.

Coffee before the meeting.

Coffee during debugging.

Coffee while waiting for a build.

Coffee because someone else is going.

Coffee because there is nothing else to do.

At some point, the mug becomes part of the workstation.

Again, none of this is visible when a student says:

I like computers.

The sentence is not wrong.

It is simply incomplete.

A better question is:

What do you like about computers?

Do you like solving problems?

Do you like programming?

Do you like understanding how systems work?

Do you tolerate long periods of confusion?

Do you enjoy building things that fail repeatedly before they work?

Can you spend hours on a problem whose solution may be one wrong bit, one bad assumption, one missing semicolon, one misconfigured register, or one undocumented hardware behavior?

Can you learn continuously?

Because the field changes continuously.

That last part matters.

Computer engineering is not a degree you finish and then possess permanently.

The degree gives foundations.

The profession keeps moving.

Languages change.

Libraries change.

Processors change.

Operating systems change.

Tools change.

Best practices change.

Entire categories of work appear.

If learning new things feels like an interruption, the field becomes exhausting.

If learning is part of the attraction, the change can be energizing.

Mathematics deserves special mention because my old advice emphasized it.

Students often ask whether they need mathematics for computer engineering.

The honest answer is not:

You will use advanced mathematics every day.

Most engineers do not.

The answer is that mathematical thinking appears throughout the discipline.

Logic.

Discrete structures.

Probability.

Complexity.

Signals.

Optimization.

Graphics.

Machine learning.

Algorithms.

Formal reasoning.

The exact amount depends on the field.

But mathematics also serves another purpose in education.

It trains you to remain in a problem after intuition stops being enough.

That is useful.

A difficult proof and a difficult bug are not the same thing.

But both require patience with not knowing.

This tolerance is one of the hidden skills technical education develops.

You look at something.

It makes no sense.

You do not leave.

You break it down.

Try an approach.

Fail.

Try another.

Eventually the structure appears.

That process is far more representative of engineering than “being good with computers.”

People used to describe technically inclined students that way.

He is good with computers.

What did that mean?

He can install Windows.

He can fix the printer.

He knows how to use the internet.

He can remove a virus.

Maybe he built a PC.

Useful abilities.

Not the same as engineering.

Engineering begins when the problem no longer has a known menu item.

There is no button.

No tutorial that exactly matches.

No person who already knows the answer.

You have to reason.

That is the attraction.

It is also the pain.

The other part of my old entry was about customers.

I wrote about customers who never found anything good enough.

This is another early-career frustration that looks different later.

Engineers tend to fall in love with correctness.

Does it work?

Does it meet the specification?

Is the implementation sound?

Customers care about those things, but they also care about whether the product solves their actual problem.

The difference can be annoying.

You show a technically impressive system.

The customer asks why one button is in the wrong place.

You want to say:

Do you have any idea how difficult the part behind that button was?

They do not.

They should not need to.

The invisible complexity belongs to the engineering team.

The visible experience belongs to the customer.

Learning not to resent that is part of becoming professional.

The user judges what the user sees.

A person using your system may know nothing about the architecture.

That does not make their frustration invalid.

This was harder for younger me to accept.

If I had spent weeks solving the technically difficult part, I wanted that difficulty recognized.

The customer wanted the thing to be easy.

Those goals can conflict emotionally.

A mature product hides the difficulty.

The customer says:

That was simple.

The engineer should often take that as praise.

Young engineers sometimes hear it as an insult.

This took time for me to understand.

The same was true of training users.

My old wording was dismissive and unfair: I joked about explaining software to people whose games were limited to tavla, okey, and pişti.

What I was reacting to was the gap between the person who built a system and the person who had to use it.

The builder knows every assumption.

The user does not.

So the user asks questions that seem obvious.

But if many users ask the same “obvious” question, the problem may be the design or the training.

Expertise creates blind spots.

Once you know a system deeply, you forget what it looks like from outside.

Teaching is one of the best corrections for that.

If you cannot explain the system simply, maybe you do not understand the user’s mental model.

That lesson later became useful to me in education too.

Students do not see what the instructor sees.

What feels obvious after years of experience may be the exact point where a beginner gets lost.

So I would rewrite my 2010 advice differently today.

I would not tell students:

Do not study computer engineering because you like computers.

Liking computers is a perfectly good beginning.

I would say:

Do not stop there.

Investigate what the field actually is.

Write some code.

Study a little discrete mathematics.

Look at computer architecture.

Try Linux.

Build something.

Break something.

Debug it.

Read about operating systems.

See whether curiosity survives frustration.

Because the real question is not:

Do I enjoy using technology?

It is:

Do I enjoy understanding and creating systems even when they resist me?

That is closer.

And I would add another warning.

Do not choose the field only because someone told you there are jobs.

A career is lived in hours.

Not salary charts.

Not rankings.

Not headlines.

You will spend thousands of hours doing the work.

The work matters.

The same applies in the opposite direction.

Do not reject the field because of one terrible mathematics course, one frustrating programming assignment, or one exhausted engineer writing an angry Ekşi Sözlük entry.

Every profession looks ugly when described on its worst day.

My entry was written on one of those emotional frequencies.

No internet in the lab.

Hardware problems.

Drivers.

Customers.

Coffee.

Presentations.

Subcontractors.

Long hours.

Enough.

To hell with computers and the internet.

Yet I stayed in the field.

That is probably the most important footnote.

Complaining about a profession does not necessarily mean you chose the wrong profession.

Sometimes people complain because they care.

You want the system to work.

You want the project to succeed.

You want the tools to be better.

You want the customer to understand.

You want the work to make sense.

Indifference is quieter.

Frustration often means investment.

The field gave me plenty to complain about.

It also gave me problems worth thinking about.

Systems worth understanding.

Things to build.

Things to teach.

Experiences I could not have had otherwise.

So the conclusion changed.

In 2010:

Do not choose computer engineering just because you love computers and the internet.

Today:

That may be where the interest starts.

Just make sure you also like what happens after the screen stops being friendly.

Because sometimes computer engineering is not a beautiful laptop, a fast connection, and elegant software.

Sometimes it is a board in a laboratory that refuses to boot.

A customer asking why it is late.

A subcontractor not answering email.

A presentation due next week.

And a cup of coffee that stopped being hot two hours ago.

If that still sounds interesting,

then you may actually like computer engineering.