Still Programing Part 3: Why the Confusion?

“Coding” is Confusing People

The habit of calling programming “coding” can mislead people into thinking that
programmers are translating one set of instructions to another.

For contrast let’s look a look at medical coding. A patient visits the emergency
room and a doctor says their thumb has been cut off. That’s ID9 code

Another patient arrives needing treatment for recurring depression. That’s
296.3. In this sense, people are assigning a concept in the real world (the
doctor’s depression diagnosis) to something that helps classify and
organize data.

Let’s also consider secret military codes or codes for particular
mediums like Morse code. The goal here is to start with a message, “hello”, code
that word, and then get “hello” on the other end of the transmission.

It is easy to mistake programming for coding activities like these. If
someone came to me with a Java Program and said, I want a line-by-line replica
of this program written in Ruby, I suppose that would be similar to this type of
translation work but this is also something that a programmer would not
generally do.

A developer does not use a series of pictures from a designer to “code” a user
interface nor does a programmer take a list of requirements written in English
and “code” them into Java. There is no deterministic mapping between problems
and solutions and, as observed by the “agile” coding movement, a successful
software product is unlikely to adhere to all the planned requirements.
Pictures aren’t programs and neither are pages of requirements. These artifacts
are representations of ideas from the designer and from the business analyst
that need to be understood to create a new set of ideas that produce a running
program.

In Mores code, the word “Hello” and .... . .-.. .-.. --- are equivalent. If the
doctor says that your thumb was cut off, the medical coder should always code
that as 855. Any variance in these situations is a mistake. Programmers do not
code requirements into an application any more than a biographer codes someone’s
life into a book.

The Ethos of the Argument

I’ve challenged the premise that the demand for programming (or “coding”) will
decrease due to new user interfaces or advances in computing. Programming has
steadily become more efficient and approachable since it had a name and the
demand for the work has not decreased. As we make programming easier, the
incidental complexity of technology fades away, but the inherent complexity in
the world’s problems stays constant. Because of this, we are likely to see
diminishing returns as we continue to improve the state of programming.

As much as I disagree with the reasons that I’ve seen predicting the demise of
programming, I do understand the ethos of the arguments: something feels out
of balance. It seems strange that a worker could double their salary by learning
a skill that can be taught in few of months. It feels like we’ve paid
programmers to create login forms and shopping cart checkouts too many times.

It’s hard to talk about programming without discussing the venture capital
investments that helped fuel its growth in the past decade. The dream that
the next Facebook will spontaneously generate out of some socially-awkward,
20-year-old white guy in a hoodie captured the imagination of investors and
worked its way into our popular culture. When you walk into many tech startups
or even established Silicon Valley companies, you’ll be greeted with arcade
games, ping pong tables, and kegs of beer. Partially, this decor is a signal
to differentiate a startup from the corporations they plan to disrupt.
But it also plays to stereotypes – like a makeshift habitat a child might build
for caterpillar, hoping to see it metamorphosize under their supervision.

When I meet budding entrepreneurs it can be hard to tell if they want
to have a tech business or want to talk about having a tech business.
Straightforward questions like, “What was your annual revenue last year and how
many customers do you have?” yield indecipherable answers like, “we’re
consistently seeing 5 points month-over-month with 12% uplift”.

Building these environments and affecting investor jargon are superstitious
responses to the black box of software creation.

How can the same product cost $10,000, $10,000,000, or be impossible to build
based on factors that management isn’t even aware of? There is a saying that
software projects don’t fail for technical reasons but in practice it’s
impossible for management to tell why they fail. Looking back on a project the
costs seems inevitable, but they were not.

A CTO incorrectly applies an emerging database technology they read about on
Hacker News. Three years later the company has a team migrating to a more
proven solution while others deliver features at a hobbled pace.

An enthusiastic group of programmers believe they can reinvent infrastructure
while simultaneously building a product. Management asked for an online store
but got a failed JavaScript framework instead.

A project has stagnated for years without new features while competitors
whittle at the company’s market share. Millions are poured into development
and UX and there isn’t an automated test in sight.

Building the right thing is the most important part of a software project but,
like a collage freshman declaring a major, companies need a chance to learn and
change direction. The difference between a product that can adapt in a few
months and one that takes years to rewrite will make or break a company.

Despite the issues I see in software development, I’ve very optimistic about its
future. The industry eventually gets over fads like, “make an iPad app for
everything”, or “social network for x”. I used to hear from startup incubators
that everything was about having a “Big Idea”. Now the messaging emphasizes
the importance of having a great
team. More often I see leaders in
companies that value open source projects and understand the tradeoffs their workers make
in development because they’ve worked on software projects first-hand in many
different capacities. The black box is becoming transparent.

Although you won’t need to look far for nay-sayers, I believe we can build
software better and faster today than ever before. As a web programmer, knowing
every browser quirk has become less important and knowing the customer’s
business has become more important. It’s all about more signal, less noise.

To anyone exploring options for a first career or the next: if you thrive on
communication, problem solving, and craft then you’ll love programming.