
Why Computer Programmers Should Stop Calling Themselves Engineers - haZard_OS
https://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/?single_page=true
======
andymoe
We are building billion dollar software products that take hundreds or
thousands of “man years”, with rigorous processes. So, respectfully, you can
complain all you want but engineer is a fine title and description even if the
software variety does not have the same gatekeepers you’re used to in other
engineering fields.

~~~
jcrites
Yep. Not all computer programmers are software engineers, but there definitely
are software engineers. Building high-scale systems that also achieve high-
availability with no maintenance windows yadda yadda is a challenging problem
that requires navigating tradeoffs using scientific principles in the same way
as other branches of engineering.

Related: the article "They Write the Right Stuff", about the software
engineers who worked on the Space Shuttle [1].

In the United States, the National Council of Examiners for Engineering and
Surveying (NCEES), which is the organization of engineering licensing boards
in all states, recognizes Software Engineering as a discipline of Professional
Engineering [2]. Our industry does not ordinarily require certification as a
professional engineer, and it is not normally required by law; however, if you
look at the topics that the certification exam covers [3] -- intended for
people with 4 years minimum industry experience -- they are all ones that I'd
expect senior software engineers to have down pat.

[1] [https://www.fastcompany.com/28121/they-write-right-
stuff](https://www.fastcompany.com/28121/they-write-right-stuff)

[2]
[https://ncees.org/engineering/pe/software/](https://ncees.org/engineering/pe/software/)

[3] [https://ncees.org/wp-content/uploads/2015/07/SWE-
Apr-2013.pd...](https://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pdf)

~~~
pseudalopex
NCEES is discontinuing the PE Software exam because fewer than 100 people have
ever taken it. In my experience, maybe 10% of people in the field have even
heard of it, and most of them think it's useless.

~~~
irundebian
It's maybe just not cool to be a true engineer and true engineered products.
It's more cool to participate in a startup and build crappy software.

------
phs318u
Agreed. 'Software engineers' are not actual engineers for the same reason that
bridges and buildings don't come with an end-user license agreement that
disclaims liability for a faulty product.

"BY SETTING FOOT ON THE BRIDGE YOU ACKNOWLEDGE AND AGREE THAT THE BRIDGE IS
PROVIDED ON AN 'AS IS' BASIS AND THAT YOUR USE AND RELIANCE ON THE BRIDGE
THEREBY IS AT YOUR SOLE RISK AND DISCRETION. COMPANY AND ITS AFFILIATES,
PARTNERS AND SUPPLIERS HEREBY DISCLAIM ANY AND ALL REPRESENTATIONS, WARRANTIES
AND GUARANTIES REGARDING THE BRIDGE WHETHER EXPRESS, IMPLIED OR STATUTORY,
INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTY OF FITNESS FOR A
PARTICULAR PURPOSE. FURTHERMORE, COMPANY AND ITS AFFILIATES, PARTNERS AND
SUPPLIERS MAKE NO WARRANTY THAT (I) THE BRIDGE WILL MEET YOUR REQUIREMENTS;
(II) THE BRIDGE WILL BE STRUCTURALLY SOUND, RELIABLE, SECURE AND ERROR-FREE;
(III) THE QUALITY OF THE BRIDGE WILL BE AS REPRESENTED OR MEET YOUR
EXPECTATIONS; OR (IV) ANY FAULTS IN THE BRIDGE WILL BE CORRECTED."

~~~
aerotwelve
THE FOLLOWING SETS FORTH ATTRIBUTION NOTICES FOR THIRD PARTY COMPONENTS THAT
MAY BE CONTAINED IN PORTIONS OF THIS BRIDGE. WE THANK THE OPEN SOURCE
COMMUNITY FOR ALL OF THEIR CONTRIBUTIONS.

------
psyc
I've written this a dozen times, but 'software engineer' has pretty much never
been a sub-category of engineer. It's a title internal to the software
industry, and need not have any relation to Engineering beyond a metaphor. I
genuinely don't understand why people find the distiction between a title and
a kind of engineer such a problem. Why doesn't 'software architect' get the
same criticism for not being an architect? If you're at work, everyone knows
what 'software engineer' means. If you're at an engineering convention, don't
call yourself an engineer unless you have the credentials.

This title sometimes accompanies pretension toward traditional engineering,
which is fine as far as it goes - usually not very far. I realize that there
are some efforts in some jurisdictions to get something like engineering
credentials for programmers. Ok, maybe that's not misguided, but I've yet to
be convinced. It depends on how you conceptualize software. I don't think of
it like engineering, I think of it like math. But more than that, I think of
it as computer programming! If you think of it like engineering, I don't have
a huge argument with that, but I have a hard time seeing is as more than an
ill-fitting metaphor. I think that is one step better than the manufacturing
metaphor.

~~~
kerr23
> Why doesn't 'software architect' get the same criticism for not being an
> architect?

I'm married to an Architect, it bugs them too.

In most states - Legally they can't call themselves Architects until they've
passed the AREs. You can't take the AREs until you have enough IDP hours
(which takes about 3 years). You can't start IDP unless you have a Masters (or
more recently a "professional bachelors"). Oh, and you have to take a new test
for every state / country you want to practice Architecture in (Reciprocity is
getting better but not quickly)

So it's that sense that they have to scratch and claw to get the title where
we can just sort of make it up that bugs them.

I think we should switch to a different title scheme. I'm going to be a Doctor
of Site Reliability (you know since I'm already doing operations....)

~~~
psyc
Personally, I never call myself an engineer. Partly for the reason it annoys
engineers, but partly because I don't think of what I do as engineering in the
first place. And I think the reason for _that_ is I have studied the hell out
of CS, programming, and math; but I have not studied a lick of engineering!
Learning a few engineering approaches by needing to stress-test software,
because it's too complicated to grok, does not qualify one as an engineer in
my mind.

I do however wish that people were better able to make the distinction between
titling oneself 'software architect' and claiming to be a sub-type of
architect. Perhaps it's too subtle. What I mean is, 'software engineer' and
'software architect' are singular roles, peculiar to _this industry_ , that
happen to be made of two words.

------
skookumchuck
One theme in the article is that regulated, licensed engineers don't produce
buggy designs. Of course they do. Deepwater Horizon, Fukishima, to name a
couple. Engineers produce buggy, bad designs everywhere you look.

The reason bridges don't (usually) fall down is because most of them are
copies of other successful designs, and because they are way overbuilt.

I seem to recall a bridge collapsed just a couple months ago squashing cars
and killing people. It was a new design.

~~~
bostik
I am unsure about Fukushima being a buggy design. To me it has sounded more
like mismanagement and negligence than anything else.

Case in point - the plant disaster happened because the tsunami was higher
than what the sea walls had been designed for. From what I have learned, Japan
has plenty of evidence that magnitude-9 earthquakes and the following tsunamis
have happened in the past. The protections in Fukushima (and Daichii) were
designed against less.

To fail under expected peak load is bad engineering. To ignore evidence and go
with insufficient safety margins is something worse.

~~~
skookumchuck
There were numerous design errors that enabled the flooding to destroy the
plant. For example, venting the hydrogen gas into an enclosed area, which
resulted in an inevitable explosion. There's plenty more, if you read a step-
by-step account of the disaster.

Engineers iterate their designs based on past failures just like software
engineers do. It's just that the life cycle is so much shorter for software,
the iterations come thick and fast.

~~~
bostik
Thank you, those details definitely make a case of consistently bad
engineering.

------
brianpan
This is completely backwards to me. Instead of changing the name because it
doesn't provide enough civic value, how about _provide more civic value_?
Software is increasingly part of our infrastructure. The Internet is becoming
utility.

There are engineering companies of all sorts that are only trying to make a
(zillion) bucks and not interested in "an explicit responsibility to public
safety and reliability". This isn't unique to software.

~~~
zaksoup
I really like this view. GetCalFresh[0] receives 30,000 applications for food
stamps in 33 out of 58 counties in California _each month_. Not only is this
absolutely a necessary utility but when it breaks or doesn't work the
repercussions are far more sever than "somebody can't post a cat gif to reddit
for a few hours".

Plug for Code for America[1], if you're interested in civic tech and want to
contribute reach out. We're hiring, and there's almost guaranteed to be a
local brigade working on cool stuff near you.

[0] [https://www.getcalfresh.org](https://www.getcalfresh.org) [1]
[https://www.codeforamerica.org](https://www.codeforamerica.org)

------
yawaramin
The author seems to think that today's software is all created in short,
barely-planned bursts of activity. They've heard of agile and scrum, and
decided to lump everything together in there. The truth is there are high-
assurance systems out there which go through extreme vetting and safety
checks. Techniques like formal verification, model checking, and design by
contract are all used to engineer safe systems.

There's no doubt that, at a certain level of quality assurance, what software
developers do is truly engineering.

~~~
psyc
I'm generally opposed to the software-as-engineering metaphor, but I actually
agree with what you're saying here. The problem is that in 20 years, I've
never worked on a team that came within 100 miles of what you're describing.
On every team I've been on, at software companies of all sizes, it goes like
this:

"I like SOLID." "No, I don't like SOLID." "I think exceptions should only be
thrown in truly exceptional circumstances." "No, I think you should throw at
the faintest whiff of the unexpected." "I like short methods." "No, I like
long methods. You can see the whole flow."

And so on. And the resulting standard for the team might as well be chosen by
coin flips.

------
skookumchuck
It's true that software engineering doesn't require licenses like other
engineers, and is not regulated unlike other engineering professions.

But after that the article goes off the rails trying to draw a distinction.
Programming above a certain level _is_ engineering, just like being a mechanic
above a certain level is engineering.

Unregulated, unlicensed software engineering has also produced stupendous
advances in programming in the last few decades, not remotely matched by
advances in other heavily regulated and licensed professions.

~~~
starpilot
> just like being a mechanic above a certain level is engineering

And therein lies the confusion. There is no level at which a mechanic becomes
an engineer. You can be both a mechanic and an engineer, but these are
separate tracks with separate skills and training. A skilled mechanical
engineer can be an inept mechanic, and vice versa. The fact that you don't
understand traditional engineering shows why you consider programmers to be
"engineers."

~~~
skookumchuck
> you don't understand traditional engineering

The first rate engineers I've known were competent mechanics as well. A
traditional engineering course of study involves lots of time in the shop.

A mechanic becomes an engineer when he goes beyond merely implementing "book"
solutions - when he starts understanding the "book" solutions, why they work,
and where they come from.

------
jalberts72
I completely agree with this. I have a degree in Electrical Engineering;
however, I've chosen a career in technology. I've had titles like: systems
engineer, devops engineer, build engineer, automation engineer. I've hated
every one of those titles because I'm NOT an engineer. I explicitly chose not
to follow the engineering path and instead start a career in technology. Funny
thing is, any time I tell a coworker how I feel about being called an
engineer, I just get a funny look.

~~~
subway
Same boat. I'm still close friends with, and have mad respect for the folks
who stuck with proper engineering when I realized that sort of work doesn't
really align with the way I naturally think.

They've demonstrated years of diligence in earning that steel ring.

~~~
sanderjd
I also have friends who I have mad respect for who are proper engineers and
have demonstrated years of diligence in earning that steel ring. But I also
have lots of programmer friends who have demonstrated years of diligence
without there being any steel ring at the end to save them from programming on
a white board every time they apply for a job. I think our way is better for
talented but inexperienced young folks just breaking in, but worse for
experienced folks whose years of success would have earned them a universally-
respected credential in pretty much every other profession.

------
koonsolo
> Engineering claims an explicit responsibility to public safety and
> reliability, even if it doesn’t always deliver

I think this is really funny, because I worked with actual engineers on
multiple projects. The 'real programmers', or however you want to call them,
had to clean up their mess and introduce proper standards and processes. I
also worked with some good engineers, so I'm not claiming they are all that
bad. But stuff that I saw from real engineers:

\- Express distance in some unknown number (we called it 'werners' because
that guy was called Werner). We introduced mm.

\- Instead of copy pasting parts of previous projects (going on for about 20
projects), we made a reusable library.

\- Disabled/circumvented safety system on a robot. We were all amazed.

\- Release things untested to end users. We tried to convince them to hire a
tester, didn't work. So we tested our own stuff a bit better, but never
officially got time for that.

So please leave the snarky comments that 'real engineers' are somehow better
than us mortal coders. Any decent coder who worked with real engineers can
tell you that the difference is not really there.

It's not the people or processes or whatever. Writing software cannot really
be compared to anything else.

------
threatofrain
The requirement that engineers be related to the public interest is wrong. No
more than the petroleum engineer is obligated to think of the ecology or
energy politics. And when there are big oil spills, I doubt it's extra
criticism about engineering obligations that will do the trick, as opposed to
billion dollar penalties.

Engineers often don't own priorities. So as long as the people who set company
priorities don't care, nobody will either. Moral yelling won't disrupt a
business model, and if neither consumers nor legislators punish companies for
spilling externalities around, then what do companies care?

If the activity continues to be profitable...

------
textmode
Related question: I was wondering about the origin of the usage of the term
"build" when programmers describe what they do. To be clear, I am not
referring to "build" as in compiling, assembling and linking to "build"
binaries, but "build" as used in statements such as "I like to build stuff." I
believe it may have originated from a 1993 book called "Code Complete". This
book used a "construction" metaphor to describe programming. This is only a
guess.

------
WheelsAtLarge
There are Software Engineers but just because you are a Computer Programmer
does not mean you are an Engineer. Engineers are defined as "individuals who
uses scientific knowledge to solve practical problems." Most so-called
engineers are software programmers.

But Language is fluid and changes with time, so at this time "Software
Engineer" is the term so it's no good fighting it.

~~~
avs733
The difference here is that, while language is very fluid, ENGINEER is a
legally controlled term.

Engineering as a profession has licensure- as does a doctor or nurse. There
are potential legal consequences for calling oneself an engineer when one is
not.

There should be some effort to fight ambiguity masquerading as fluidity. They
are not the same thing. This ambiguity literally got a child decapitated
recently.

~~~
jack9
> ENGINEER is a legally controlled term.

It's a classification, so I don't think that's so. "Driver" is an equivalent
term.

~~~
avs733
I'm sorry, but this is incorrect.

[https://www.nspe.org/resources/licensure/resources/faq](https://www.nspe.org/resources/licensure/resources/faq)

[https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...](https://en.wikipedia.org/wiki/Regulation_and_licensure_in_engineering#United_States)

~~~
closeparen
According to your Wikipedia link:

>Since regulation of the practice of engineering is performed by the
individual states in the United States, areas of engineering involved in
interstate commerce are essentially unregulated. These areas include much of
mechanical, aerospace, and chemical engineering—and may be specifically
exempted from regulation under an "industrial exemption." An industrial
exemption covers engineers who design products such as automobiles that are
sold (or have the potential to be sold) outside the state where they are
produced, as well as the equipment used to produce the product.

According to the other:

>Engineering licensure constitutes an integral part of the program of
professional development of many companies; so much so, in fact, that many
progressive companies have specific policies encouraging licensure and
providing concrete assistance to engineers taking their first steps toward
licensure

This implies that they are engineers even before licensure.

------
nickpsecurity
What most programmers do isn't engineering. However, there are programmers
that do engineering. Here's two that were used to make software that was
consistently low-defect that sometimes came with warranties. I picked them
since they had acceptable cost/timing vs the methods with full, formal
verification.

[http://infohost.nmt.edu/~al/cseet-
paper.html](http://infohost.nmt.edu/~al/cseet-paper.html)

[http://www.anthonyhall.org/c_by_c_secure_system.pdf](http://www.anthonyhall.org/c_by_c_secure_system.pdf)

~~~
irundebian
Hi nickpsecurity, I always like your posts, that's why I bookmarked your
comments page and check it every few days for changes.

What stands out, that these papers and articles are pretty old. It seems to me
that these are pretty academic examples. I don't understand why we can't see a
lot of software in the wild, following the state of the art practices of
building secure software. Maybe these practices are still relatively
impracticable to the average programmer.

Maybe research on secure software development should check their ideas more
for psychological acceptability (Saltzer/Schröder).

~~~
nickpsecurity
Glad you enjoy it. If you like that kind of stuff, you should keep an eye on
Lobste.rs since I submit most of the CompSci stuff there. Mainly because they
like it more over there but some people occasionally build on it. Mostly about
formal methods filtered down to most interesting work but also do other stuff
here and there. Here's a link to my submissions if you want to go through
them:

[https://lobste.rs/newest/nickpsecurity](https://lobste.rs/newest/nickpsecurity)

Far as old, it's important to remember that many things we're doing today
started in some form a long time ago. Certain principles are timeless. For
instance, the Burroughs B5000 was checking for overflows and argument matching
on every operation at the CPU level back in 1961. That thing was immune to
common, coding attacks until maybe when ROP was invented. The newer thing was
C language designed for efficiency on weaker hardware. People still argue
today if we can defeat the vulnerabilities in our legacy systems without
realizing some in 60's-80's were immune to them. Occasionally, a current team
will learn from or reinvent that older research to find it's still useful like
crash-safe.org and Cambridge's CHERI did for secure CPU's w/ CHERI running
FreeBSD. So, don't judge by age: look at what was done, why it worked, why it
would/wouldn't today, if changes in context matter, and esp how practical it
might be.

Far as that, Cleanroom worked even on first try on real projects for
commercial teams and students. I just got the book recently where I'll be
trying it sometime in near future. It looks pretty good so far with it just
being careful structuring and thinking about things in algebraic way. Why did
it disappear? Likely bandwagon effect where some New Great Method got popular
like it did, displaced it as project managers wanted to look like they were
doing something new, and now it's a relic of history. Lots of stuff like that.
Happens more if there's big companies with enterprise tooling backing the
newcomers like the 4GL's, UML, etc. Even more when tool promises to remove
human from equation as much as possible vs Cleanroom that built on human
talent (i.e. time).

Now, SPARK is entirely different. I got that book, too. :) It was always
marketed at a niche group of people building stuff that should never fail.
They have to be willing to spend a lot of time using specialist techniques to
make that happen. They also must do it in non-mainstream language with
proprietary tooling. Needless to say, adoption was small. However, AdaCore's
site shows quite a few companies are using it in safety-critical work. I also
have some case studies in my Lobsters submissions involving SPARK with
keywords being "SPARK," "glider," and "cubesat" if you want to try to just
Google them. Altran Praxis, who originally developed it, has been using it in
government and commercial projects for one or two decades. The book supposedly
makes it easier. I figure a combo of spec-based tests, automated solving, and
runtime checks for what's left is still gonna be easiest approach.

Aside from those two, another nice example is Design-by-Contract which is
quite accessible to average developer. It just says what the component expects
to receive, maintain, and deliver. That can be turned into tests, runtime
checks, or verification conditions for a prover. One can also combine the
runtime checks with fuzzing like AFL to make it zero in on the specific error.
Eiffel Method brought that to significant adoption in industry even though
small in larger scheme of things. We have seen increased adoption of some of
those principles with more contract implementations in mainstream languages
and property-based testing getting popular. Anyway, here's a nice description
of that I saved as much for managers as developers:

[https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-b...](https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-
by-contract/index.html)

"Maybe research on secure software development should check their ideas more
for psychological acceptability (Saltzer/Schröder)."

Oh, I've learned so much about this angle. I couldn't begin to tell you.
Mostly pessimistic but there's some hope. We've been solving the wrong
problems. Most of the security problem comes from political maneuverings
through lobbyists, market preferences which rarely value security, and
business incentives that are similar. There's strategies for each which have
potential. My best hypothesis for now is to keep pushing methods that are
productive with the tech designed for verification [later] with lightweight
methods used up front. You sell the approach as much as possible on _non-
security_ benefits with a certain amount of money funneled into improving
security of the project or its dependencies. Rinse repeat. Also, better to
invest in projects that improve security on things with same language, API,
ISA, etc as things with huge, bandwagon effects. Gotta go with the flow.

------
finnthehuman
> “I’m not a programmer,[] —oh, engineer, in tech-bro speak. Though to me,
> engineers are people who build bridges and follow pretty rigid processes for
> a reason.” His indictment touches a nerve.

No shit it touches a nerve. It's cliché both in sentiment and presentation. No
laboratory could design a sentence more tailor-made to light up an American-
left cultural-critic writer's brain.

It's almost a work of art that in so few words the speaker postured
themselves, namecheked this week's scapegoat and even snuck in a bit of a
humble-brag.

------
mnm1
Where software is highly regulated, it is of much higher quality. This article
is so badly researched, they use the example of a late model car starting
reliably as an example of good engineering. Well then, I suppose the people
who wrote the millions of lines of code that run that car shouldn't be called
engineers either. Or should they? Clearly the article's author is too stupid
to understand the technology. What about people who write airplane software?
If this idiotic author doesn't want bugs in his Google docs, he should be
pushing to regulate such software in the same way that airplane software is
regulated. Sure, it doesn't make sense to do that. What would make sense is to
realize that regulations and laws are the only difference between flight
software and some buggy internet app. If you remove regulations from flight
software and car software, planes and cars will crash and kill. At least
Google docs might only lose your document in the worst case scenario. And
don't even get me started on the outrage of train engineers at their title
being co-opted. /s

------
AdieuToLogic
Engineering is a discipline in which new endevours are undertaken with
repeatable processes defined by the knowledge and experience learned from
previous engineers' efforts in the same domain, codified in "professional
standards."

For problem domains whose solutions are manifest in well-known artifacts, such
as bridges and buildings, these standards have been established over several
centuries. Still, failures persist which cause refinement in said standards,
though at a low enough frequency where the failures now are seen as aberrant
conditions.

Where software practitioners study the techniques and/or practices reified by
accomplished predecessors, assimilate lessons learned from the practitioner's
own efforts/failures, and refine a documented repeatable approach that
incorporates the aforementioned, there is little cause to refute the title of
"software engineer."

------
pishpash
The term "software engineer" I believe came out of the engineering schools of
various universities taking on CS disciplines and naming majors in this way.

Anyway, by analogy to fintech and adtech, programmers should probably honestly
style themselves as software technicians, unless they get themselves qualified
as a real engineer.

------
alacombe
Why am I an Engineer ? Because my school, based in Europe, is accredited to
deliver a proper recognized _engineering_ degree. Last time I check, I could
get a P.Eng (proper engineer order here in Canada), but don't see the point
forking the $400 annual subscription.

------
pishpash
And data scientists are not really scientists.

~~~
boznz
I call them Data Scientologists

------
kevintb
Most software "engineers" barely think about the societal consequences of
their work, and CS students have no "do-no-harm" oath that engineers have to
take. I would say that in comparison to engineers who build things for public
interest (infrastructure that can kill people), physicists (history of the
nuclear bomb), biologists (unethical medical experimentation from WWII), etc
... software engineers barely think about societal consequences of their
actions the way other scientific professions do.

------
timrichard
Even though my degree certificate says "....Software Engineering", I usually
refer to myself as a Software Developer. Mostly to avoid any tedious arguments
with mystic folk that have sacred oaths and magic rings.

But it is noticeable that when a commercial lift/elevator or Espresso machine
develops a fault, people quite casually say that "an engineer is on the way"
and nobody bats an eyelid. Don't most software bugs require a much deeper
diagnosis and more elaborate fix?

------
gcommer
The author arbitrarily decides on "number of failures" as their measure of
reliability, as opposed to a much more reasonable "number of failures" * "mean
cost of failure". There is also no attempt to correct for the confirmation
bias of software being so popular, no attempt to present non-anecdotal
evidence, and no attempt to provide comparative data for other engineering
disciplines.

------
itsmejeff
This article climbs the HN ranks once every few months... I'm a "real"
engineer who chose to make my career in software. There are obviously things
that this author does not know about software engineering and there are things
that software engineers don't know about "traditional" engineering. Both have
their strengths and weaknesses. Everybody chill out

------
alphabettsy
There are certainly developers that are not doing any “engineering”, but as
far as the software engineer title goes there are many cases where there is a
distinction without a difference.

Are the people working on autonomous driving, vehicle safety, infrastructure
management any less important than the guy who designed the plastic housing
with the title mechanical engineer?

~~~
pishpash
Not less important, but not held to the same standard, which is the point
here.

~~~
alphabettsy
That’s changing rapidly. The VW engineer that was charged with implementing a
software defeat, the current Tesla controversy is entirely based on software,
as is the woman killed by an Uber vehicle.

As software becomes ever more a matter of life and death I think we’ll see
software engineer used maybe more specifically. Maybe some or many programmers
and developers should stop calling themselves engineers?

------
mattykay
I guess Atlantic doesn't need that website it software it runs to reliably
help them do their business and make money...

------
kevinSuttle
I’m not sure which is worse: “engineer”, or “architect”.

~~~
skookumchuck
Who cares, what matters is which pays better :-)

------
himom
A programmer is a computer code writer. A software engineer aims to be a more
efficient, elegant and scientific programmer.

------
bribroder
Why Journalists Should Stop Calling Themselves Writers

~~~
notacoward
Why Academic Hacks Should Stop Calling Themselves Journalists

