The Curious History Of Coding: How Engineers Think

What is Coding? The History That Governs Its Meaning

Coding is a phrase associated with things that seem really different. Its meaning throughout history has gone through many different eras. Times that would cement its meaning till this day.

Coding as obfuscation.

Back in the early 1940s, during World War 2, "Coding" really did mean Cryptography. The Nazis would communicate using complex ciphers like the Enigma machine, which scrambled messages to make them unreadable. These coded messages were then often transmitted using methods like Morse Code.

This way of communicating was fast and hectic, one would need to be trained to understand the language. The Allies eventually cracked the language and understanding it was pivotal to their victory. In a sense, coding was more about obfuscation. That wouldn't last for long as code would no longer be a language of secrecy but a language of instruction.

The Women's era of Coding

Because 'Software Engineering' as a term hadn't been coined yet and hardware engineering was much more prevalent, the perception around coding was that it was clerical work. Something the women needed to do while the men did the 'real' engineering work. This is why, the first modern programmers were all women. Kay McNulty, Betty Jennings, Betty Snyder, Marlyn Wescoff, Fran Bilas and Ruth Lichterman.

They physically wired up machines and developed programming concepts we still use today. They were dubbed the ENIAC programmers. As the war ended and the 1950s came around, the perception hadn't changed yet. Grace Hopper, pioneered the first compiler and developed the COBOL language. She even found the first computer 'bug', a literal moth that had snuck into the wiring of the computer. She ended up taping the dead bug to her operational logs.

This continued into the early 1960s, where Margaret Hamilton officially coined the term 'Software Engineering' in an attempt to lift it to a level of prestige. She also led the Apollo Guidance Computer programming.

By this point, the perception around coding as a whole had begun to shift and all it would take to push it to the mainstream was one spark. What we got instead was an explosion. One that would push it to heights it wasn't ready for.

The Software Crash: Crisis or Catalyst?

As the 1960s rolled on, projects had begun failing in dramatic fashion. Computers had grown exponentially more powerful than the humble ENIAC of the past, although good for the possibilities they presented, it came at the cost of exponentially more challenging tasks for a programmer to perform.

Going over-budget, inefficient software, Vaporware and difficult-to-maintain code were the primary reasons. In short, programmers had to improve to use the gigantic computers that were now being created.

What was a crisis for an unprepared market, became the catalyst for programming to break out from pre-placed stigma. Software Engineering had to be treated like real engineering. But it wasn't as if this is when we transitioned from 'Coding' to 'Engineering'.

In truth, this had happened long ago dating back to the days of the ENIAC. What would go on to follow the crash of the late 1960s wasn't some new-found knowledge being discovered. It was the knowledge, once considered trivial, now considered a matter of grave importance. So important that in some ways, it overtook its adversary in hardware or rather, the adversary many associated with it.

Coding is just a method of communication. Engineering is a way of thinking. And as the crash proved, a combination of both was immensely important.

How To Think Like An Engineer

In a sense, just like how Software Engineering didn't need to be a recognized term for it to be performed, engineering as a whole is a state of mind more than a profession. It is the ability to look at a problem and understand it deeply enough to come up with a solution for it.

That's why the transition from just coding to engineering is a slow, gradual process. But the point when you cross the line is very... subtle. For such a great shift in mindset and approach, it's hard to catch onto when exactly you transitioned into this state of mind.

Invention from Tedium

Take the ENIAC Women, the ENIAC back then needed to be programmed in a very manual way using literal wires and switches which could take weeks of effort just to calculate one missile trajectory. Kay McNulty, realized that very often, they'd find themselves repeatedly "programming" the same set of instructions repeatedly. To prevent the tedium, she devised a way to set up a "block" where this specific of instructions could run and then return control to where it left off.

She invented the idea of functions or methods as we call them today.

If/then statements were also invented during this time, allowing the program to branch out and make decisions based on the info it receives. Due to how massive the ENIAC was, over 18,000 vacuum tubes, it had frequent failures in its design. Miscalculations, program's stopping midway through were common and the final results would often be wrong. What was the solution? To physically race along this monolithic machine, checking every step and ensuring it was correct as the machine kept going. This was the earliest form of 'debugging'.

There's still plenty of things that the ENIAC women invented, like the idea of breakpoints in a program, or finally getting rid of the archaic form of manually plugging cables and flicking switches to a set of instructions that could be fed directly into the machine as data or even the first ever sorting algorithm.

Throughout all this work, the transition to engineering is subtle in the moment. Of course, in hindsight, we can see how significant these discoveries are, the very system you're on is built on these discoveries but it's hard to appreciate the greatness of your work in the moment, especially during a time when your work isn't given the respect it deserved.

The Common Thread

I know what you're thinking, how does this help us get closer to the mindset of an Engineer? The stories we've explored so far, you might find something common in all of them. Love. Reading through the stories of the ENIAC women, Grace Hopper or Margaret Hamilton, you'll quickly realize how much they loved their work.

Even during a time when their work wasn't considered important, they held on and really fought back not with words but with their work. They didn't give up on their work. Their stories are one of determination, it didn't matter what the perception was, they always were engineers. They worked on problems and developed noble solutions for them. They knew the importance and greatness of their work.

And that's the most important lesson. To know the worth of your work. But embracing that worth is rarely a linear path.

Not a Linear Path

I can go on and on about how Software Engineers should think about systems, not code. Or that they should build projects, not follow courses endlessly. Learn X language first, Y language later, find a goal to work towards while programming etc.

There's plenty of wisdom that I will not repeat here because I am sure, if you've stumbled onto this website, you've heard it all. My goal here is to give you a story that inspires you to continue your work.

You can only start thinking like an engineer by doing your work but in the modern world, very often, you'll find yourself lacking purpose.

Stuck building some trend-chasing software for a company, in fear of being laid off because the shareholders don't see that 1 percent growth, I want you to look back on the stories of these people.

To look back and see the importance of your work, its worth and most importantly, the love you have for it. And if you're losing that love, its time to move on.

Because giving up is the most fatal blow to the mindset of aspiring engineers.

Conclusion

You might have noticed how I haven't talked in this post in my usual, anecdote heavy personal tone, that's for a good reason. As I am now, I am not exactly the person to be giving heartfelt advice. I don't even have a job or any real 'work' experience. But that does not mean I wrote this post entirely from a disconnected perspective.

In truth, I have felt in recent times how I have started thinking really differently about programming. Despite developing this skill for 4 years, it's only recently that I feel completely in love with it. I feel connected with my line of work now but really, I couldn't explain why I felt this way.

It's not as if I have done something truly extraordinary yet unlike the people whose stories we followed. But despite my lack of experience, I couldn't help but pursue it every day, constantly working on something new.

That's why I wrote this post. To find out why I felt this way. And exploring the stories of all these incredible people, I feel justified in my love for my craft. That's why, the real hero of this post is not me. Just like you, I am merely a spectator to the greatness, determination and love the ENIAC women, Grace Hopper and Margaret Hamilton had for their work.

Seeing their struggles and their determination, I feel inspired to continue doing my work. Because I justifiably love my work.

And one day, I hope to love my work as much as the brilliant people we talked about in this post did. Until that day comes, I'll be here grinding away.