What Should a Professional Chamber Actually Do?

In July 2012, I wrote about the newly formed Chamber of Computer Engineers.

My first reaction was not philosophical.

It was financial.

I wrote, roughly:

I will love this chamber as long as nobody comes to my door saying, “Hands in your pockets.”

In other words:

Please do not ask me for dues.

That was the joke.

But underneath it was a more serious question.

What exactly should a professional chamber do for a computer engineer?

At the time, I was skeptical.

Computer engineers, I argued, were not exactly starving or universally unemployed.

I did not believe separating from the existing electrical engineering structure and forming a separate chamber would automatically create some great personal benefit for me.

What I could imagine more easily was another institution collecting money.

That suspicion came first.

Then the entry became more combative.

I argued that people often exaggerated the idea that software work was being taken over by cheap, unqualified labor.

I said that serious companies cared about strong educational backgrounds.

I named a few universities I considered prestigious.

I complained that too many weak computer-engineering programs were graduating too many students.

I suggested that if someone could read two books and do exactly the same work as a formally educated computer engineer, then perhaps the formal education had failed to create enough distinction.

I even made a broad remark about computer-science and computer-engineering departments abroad that, read today, was far too casual and imprecise.

It was a classic young-engineer entry.

Confident.

Categorical.

Partly right about some structural problems.

Far too certain about how the market worked.

And very interested in protecting the meaning of the title “computer engineer.”

That last part is the key.

The whole entry is really about professional identity.

Not the chamber.

Not dues.

Not even employment.

Identity.

What makes someone a computer engineer?

The diploma?

The curriculum?

The university?

The ability to solve certain kinds of problems?

Membership in a professional body?

The market?

The work itself?

In 2012, I was still trying to answer that question by drawing boundaries.

This counts.

That does not.

This education is serious.

That one is weak.

This kind of work belongs to the profession.

That kind does not.

Boundary drawing is common when a profession is young, expanding, or changing quickly.

Computer engineering had all three conditions.

Software was becoming central to more industries.

People entered programming through many routes.

Formal degree programs multiplied.

The internet made technical knowledge dramatically more accessible.

A person no longer needed to sit in a university library to learn a programming language.

Tutorials, forums, open-source projects, documentation, and books could take someone surprisingly far.

That created anxiety.

If knowledge is accessible, what exactly is the degree protecting?

This is still a useful question.

But I would answer it differently now.

A good engineering education should not protect itself by making knowledge scarce.

It should justify itself by developing depth.

Foundations.

Abstraction.

Mathematics.

Systems thinking.

Tradeoffs.

Architecture.

Algorithms.

Operating systems.

Networks.

Computer organization.

Software engineering.

The ability to learn unfamiliar technical material.

The ability to understand not only how to make something work, but why it behaves as it does.

That is a stronger defense of education than saying outsiders should not be allowed into the field.

Knowledge becoming easier to access is not a threat.

It is good.

The profession has to become deeper, not more defensive.

The old entry shows that I had not fully reached that position yet.

I was still partly thinking in terms of scarcity.

If everyone can do this, then what makes my education valuable?

That question quietly assumes that value comes from exclusivity.

It often does socially.

But professionally, value should come from capability.

A degree should not be valuable because others are prevented from learning.

It should be valuable because the education gives you tools that are difficult to acquire accidentally.

That distinction matters.

It changes how you think about self-taught programmers too.

In the old entry, I was dismissive.

Today I would separate several things that younger me compressed together.

Someone without a computer-engineering degree can be an excellent software developer.

Someone with a computer-engineering degree can be a poor one.

A degree and professional capability overlap.

They are not identical.

Formal education can create a strong foundation.

It cannot guarantee curiosity, discipline, judgment, communication, or continuous learning.

Those still belong to the person.

At the same time, saying “anyone can learn programming” does not make engineering education irrelevant.

Programming is only one part of the field.

Writing code is not the entire profession.

This distinction becomes more important as systems become larger.

A small script can be written after a short period of learning.

A safety-critical system, compiler, distributed database, operating system, embedded platform, network stack, or complex large-scale software architecture demands broader knowledge.

The difficult question is not:

Can somebody without the degree do this?

Of course some can.

The useful question is:

What competencies does the work require?

Then:

Who actually has them?

That is a much healthier professional standard.

It is also harder.

Diplomas are convenient.

Skills require evaluation.

This brings me back to the chamber.

What should a professional body protect?

The title?

The members?

The public?

The quality of the profession?

Employment?

Salaries?

Ethics?

Educational standards?

All of them, perhaps.

But the order matters.

A professional chamber becomes weak if its main message is:

Pay your dues because you belong to this category.

Membership should mean something.

Not only administratively.

Professionally.

If I were asking my 2012 question again, I would frame it this way:

What problem exists that engineers cannot solve individually but can solve collectively through a professional organization?

That creates a much better test.

There are several possible answers.

Professional ethics is one.

An individual engineer can behave ethically.

But shared standards matter when technology affects the public.

Privacy.

Security.

Safety.

Accessibility.

Responsible use of data.

Conflicts of interest.

Professional organizations can help define norms before courts and markets do it for us.

Continuing education is another.

Technology changes too quickly for graduation to be the end of professional learning.

A useful chamber could create training, technical seminars, mentoring, local communities, and knowledge-sharing opportunities.

Not ceremonial conferences.

Actual professional development.

Educational quality is another legitimate area.

In 2012, I complained crudely about “low-quality” graduates.

The complaint was elitist in wording, but it pointed toward a real institutional question:

How do we maintain educational standards when programs expand rapidly?

The answer cannot simply be:

Only graduates of universities I personally respect should be hired.

That is lazy.

A stronger response would examine curriculum quality, faculty resources, laboratories, student preparation, accreditation, learning outcomes, and graduate competencies.

If a professional body wants to help, it can contribute evidence.

What should graduates actually know?

Where are the gaps?

What does industry need?

What foundations should not be sacrificed for fashionable tools?

That conversation is useful.

Ranking people by university name is much easier.

It is also much less informative.

Another function is representing the profession in public policy.

Software and computing increasingly shape law, infrastructure, education, finance, government, health, communication, and security.

Decisions about technology are often made by people who understand its social importance but not its technical mechanics.

Engineers need a voice there.

Not a voice that says:

We are engineers, therefore listen to us.

A voice that can translate technical consequences clearly.

What happens if a proposed regulation is technically impossible?

What security risk does a procurement decision create?

What does data retention actually mean?

What should public institutions require in software contracts?

How do we evaluate digital infrastructure responsibly?

These are areas where collective expertise can matter.

Then there is labor.

My old entry dismissed this too quickly because my personal experience suggested computer engineers were doing relatively well.

That was a narrow sample.

A profession is not represented only by the people currently comfortable inside it.

Students.

New graduates.

Contractors.

People working unpaid overtime.

People facing discrimination.

People in weak labor markets.

People doing work under misleading titles.

People pressured to accept unsafe or unethical practices.

Their conditions matter too.

A professional organization does not have to become only a labor union to care about professional working conditions.

It can publish salary research.

Career data.

Employment trends.

Guidelines.

Legal information.

Model contracts.

Professional standards.

Evidence is useful even when direct intervention is limited.

The point is not to guarantee everybody a job.

No organization can honestly promise that.

The point is to reduce information asymmetry.

That would have answered part of my 2012 skepticism.

Give members something more valuable than a membership card.

Give them knowledge they could not easily produce alone.

This is where dues become easier to justify.

People do not hate paying for things.

They hate paying for vague things.

A fee feels different when the value is visible.

Good documentation.

Useful training.

Professional insurance.

Legal support.

Career resources.

Standards.

Networking that produces actual collaboration.

Public advocacy grounded in expertise.

Then the question changes from:

Why are you taking my money?

to:

Is this service worth the money?

That is a normal question for any institution.

Institutions should survive that question.

Professional organizations sometimes rely too heavily on moral language.

You should join because solidarity matters.

Maybe.

But solidarity becomes durable when structures produce real mutual benefit.

Otherwise people participate symbolically for a while and gradually disengage.

Young engineers are especially skeptical of institutions that seem ceremonial.

Technology culture rewards things that work.

You can give a beautiful speech about professional unity.

An engineer will eventually ask:

What does it do?

That instinct is healthy.

The challenge is applying the same standard fairly.

Not every benefit is immediate.

Standards work slowly.

Policy work is invisible until a bad policy is prevented.

Professional reputation is collective and difficult to measure.

Mentorship may help one person years later.

Institutions often create value through infrastructure rather than transactions.

That makes evaluation harder.

But not impossible.

Transparency helps.

What did you spend?

What did you achieve?

What are you trying to change?

What failed?

What did members actually use?

Show the work.

The old entry also reveals how strongly I identified educational prestige with professional quality.

I named universities.

I implied serious companies selected heavily from a small group.

That was my perception then.

It should remain in the archive as my perception.

But I would not preserve it as a principle.

Prestigious institutions can create advantages.

Networks.

Selection effects.

Resources.

Strong peers.

Faculty.

Recruiting pipelines.

Those are real.

But they do not create a permanent monopoly on talent.

The technology industry has repeatedly demonstrated that strong people can emerge from many places.

A university name can be useful information at the beginning of a career.

It becomes weaker information as actual work accumulates.

After enough years, the more interesting questions are:

What did you build?

What did you learn?

How do you think?

Can you explain difficult things clearly?

Do other people trust your technical judgment?

Can you handle ambiguity?

Can you recognize when you are wrong?

Can you help a team become better?

These are harder to print on a diploma.

They are also closer to professional maturity.

This does not mean university quality is irrelevant.

It means educational quality should be discussed as education, not inherited status.

What did the program teach?

What resources existed?

What did students actually learn?

What intellectual habits did it develop?

Those questions are more useful than brand loyalty.

The old entry’s harshness toward weaker programs can also be read as fear.

If the title “computer engineer” expands too quickly, does the title lose meaning?

That fear appears in many professions.

More graduates.

More programs.

Lower barriers.

New pathways.

The instinct is to defend the label.

But labels cannot maintain quality by themselves.

If the market encounters enough weak professionals carrying the same title, the market learns to distrust the title.

Protection then fails.

The only durable defense is competence.

That is why standards matter.

Not standards designed mainly to exclude.

Standards designed to clarify expectations.

What should a computer engineer understand?

Not which framework is popular this year.

Frameworks change.

Foundations travel.

Complexity.

Data structures.

Concurrency.

Memory.

Networks.

Security.

Architecture.

Testing.

Failure.

Tradeoffs.

Ethics.

Communication.

The exact list can be debated.

The existence of a serious list should not be.

A professional chamber could help that conversation.

Not by declaring a monopoly over knowledge.

By creating a shared language around competence.

There is also an uncomfortable question my old entry did not ask.

Who benefits when a profession creates barriers?

Sometimes the public.

A bridge should not be designed by someone with no understanding of structural engineering.

Sometimes professionals.

Restrict supply and status may increase.

Sometimes institutions themselves.

More mandatory procedures can mean more institutional power.

These motives can coexist.

That is why professional regulation should always justify itself through public value.

Not only professional self-interest.

Computing complicates this because software covers an enormous range.

A person writing a personal website and a person writing control software for medical equipment are both “writing software.”

The risk is not comparable.

Applying one regulatory model to everything makes little sense.

Professional responsibility should scale with consequences.

This is where careful engineering thinking is useful.

Do not regulate the label abstractly.

Understand the system.

What can fail?

Who gets harmed?

How severe is the harm?

What expertise is required?

What accountability mechanism is appropriate?

Those are better questions than:

Who is allowed to code?

The internet made the second question impossible anyway.

People will learn.

They should.

The profession should welcome competence.

Then insist on responsibility where responsibility matters.

That is a more confident identity.

It does not need to protect itself from every outsider.

It knows what depth looks like.

Reading my 2012 entry now, I recognize the impatience.

A new institution appears.

It claims to represent me.

My immediate response:

What exactly are you going to do for me, and are you going to charge me?

Fair questions.

Then I moved too quickly from skepticism into gatekeeping.

Also recognizable.

Young professionals often defend the value of their education by defending the exclusivity of their category.

Years later, I think the stronger position is almost the opposite.

If your education is good, open knowledge is not a threat.

If your profession is strong, talented people entering through different paths are not automatically a threat.

If your professional chamber is useful, it should not need to rely only on obligation.

It should create value that engineers can see.

And if thousands of graduates are leaving universities without enough depth, the answer is not contempt.

It is educational responsibility.

Who admitted them?

Who designed the curriculum?

Who taught them?

What resources were available?

What incentives encouraged expansion?

What does the market actually require?

Institutional problems should not be dumped entirely onto young graduates.

That is another thing age changes.

At twenty-something, it is easy to judge individuals.

Later, you see systems.

Not every outcome is explained by personal merit.

Opportunity is uneven.

Education is uneven.

Networks are uneven.

Starting conditions are uneven.

People can still be responsible for learning.

But institutions are responsible for what they promise.

A university offering an engineering degree is making a promise too.

So is a professional chamber.

So is an employer.

The interesting question is whether those promises mean anything in practice.

That brings me back to my opening line.

“Pamuk eller cebe.”

Hands in your pockets.

Pay.

The joke remains good because institutions eventually become concrete at the moment they ask for money.

Mission statements are free.

Membership fees are not.

The request for payment forces the relationship to become measurable.

Why should I belong?

What are we building together?

What do I receive?

What does the public receive?

What improves because this organization exists?

Those are healthy questions.

I would ask them today without the same hostility.

I would also ask more of myself.

A professional organization is not a vending machine.

You do not always insert dues and receive a personal benefit.

Some value is collective.

Standards.

Representation.

Community.

Professional memory.

Public responsibility.

Those require participation too.

The mature question is therefore not only:

What will the chamber do for me?

It is also:

What kind of profession do we want badly enough to maintain together?

That is a harder question.

And a better one.

My 2012 self was worried the institution might take money from my pocket.

Fair enough.

Today I would be more interested in whether it can put something into the profession that no individual engineer can build alone.