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

1. 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 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 keep the lights on.

• 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.