Ashes of Technology Giants

We live in a time of rapid change. Things happen so quickly that many of us don't have time to reflect on the present, much less the past. Many don't seem to realize that DevOps, APIs and interface generation, Internet of Things (IoT), edge computing, code linting, test-driven development, prototype-based inheritance, and a whole slew of other state-of-the-art stuff isn't new. The names might be, but the ideas are not. The details have changed, but most of the underlying concepts are the same. We in the technology industry do ourselves a great disservice when we ignore — or don't understand — the past. 

My family recently took a trip to London, England. We all got something different from the experience. For my daughter, seeing two shows in West End theatres was a highlight. My wife had always wanted to see Stonehenge. My sister-in-law checked off a bucket list item — visiting Harrods department store. I just wanted to spend a few uninterrupted days with my family.

I was very surprised to find myself choking up one day as our guide pointed out the Westminster Abbey tombs of Isaac Newton and Charles Darwin. How nice that these great minds were honored in such a way. Then I looked down to see plaques for Michael Faraday and James Clerk Maxwell on the floor. That's when I realized that I was standing, literally, on the ashes and bones of giants. The feeling stayed with me as we continued the tour, passing kings, queens, authors, poets, politicians, soldiers, sailors, and more. The astronomer Edmond Halley has a nice memorial tablet on the wall out in the cloisters.

If I have seen further, it is by standing upon the shoulders of giants.

Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it.

The software industry is young compared to, say, manufacturing, but we're well out of our infancy. Here are a few examples of things we seem to have forgotten, or never learned:

"Callbacks are a mechanism in JavaScript..."

I read this recently in some poor sap's blog. Callbacks aren't new, and they're certainly not specific to JavaScript. They're a generations-old, well-understood mechanism for connecting run-time mechanics with application-specific behavior. Anyone who thinks they're new, and JavaScript is new, is missing out on a lot of useful knowledge.

"We need more women and people of color in ..."

Agreed, but what changed in the last 20 or 30 years to decrease diversity? Yes, you read that right. There were a lot more women in tech in 1998 than 2018. Those women were already established in technical and management roles, neither recent grads nor administrative staff. Where did they go, and why weren't they backfilled?

"Good life/work balance"

The meaning of this has shifted over time. Now it means either, "Let me work when I want from where I want," (the employee side) or "You're always on call" (the employer side). It used to mean something else — "When I'm working, I'm not doing other things; when I'm doing other things, I'm not working; and we agree on an appropriate measure of productivity." Big stories in the news these days tell us the newer meanings are counterproductive. But... anyone who read the collected wisdom of the 90s already knew that. Ask the psychiatrists and management gurus.

"Open workspaces encourage interaction"

Yeah, no. Variety of workspace sizes and shapes encourages interaction. Counterintuitively, so do doors. By allowing people who need privacy to keep it and letting people who need to work together do so, office spaces with actual offices, meeting rooms, larger conference rooms, etc., encourage higher productivity.

I could keep going with more examples of lessons we've lost and are relearning. Instead, here's some advice:

Read an honest-to-goodness book, on paper. Not an e-book or someone's blog, not watch a video or webinar. Get a pound or two of actual paper between cardboard planks. Pick something from an earlier generation.

Here's why:

• Books are absorbing. A well-written book on paper can keep your attention for hours.
• Everything else is distracting. That same book on a screen can't hold your attention, for the very reasons we love our screens: immediate notification of emails, buzzes from incoming calls, temptation to send a link or a screenshot, ... ooo something flashy.
• Learn from the people who invented the techniques and tools you're using now. You might be surprised by what they thought about and what they prepared for.

I'm happy to share a few book suggestions:

The C Programming Language, 2nd Edition (Kernighan and Ritchie)

Everything you needed to know to write a C program in 1988 was wrapped up in less than 300 pages, including examples, language reference, standard library description, grammar, and index. C has changed since then but the basics still apply.

The Elements of Style, 4th Edition (Strunk and White)

Basic English grammar and guidance on good writing style. The ideas here apply to anything you write, including user documentation, specifications, letters home, and code.

A Pattern Language: Towns, Buildings, Construction (Alexander, Ishikawa, Silverstein)

This book from 1977 spawned both the Design Pattern movement in software engineering and the Not-So-Big house movement in architecture and construction. If you really understand what's in here and apply it, your software will be better organized, your software company will be better managed, and your home and hometown will be nicer to live in.

Software Tools (Kernighan and Plauger)

Another classic from the folks at Bell Labs, Software Tools shows how you can take a few basic assumptions and build a suite of programs to help you be more productive. The code is here for you to read. These are the ancestors of tools that many developers, particularly in the UNIX and Linux world, use every day.

These are just a few of the giants on whose shoulders the software industry currently stands. They deserve our respect and attention because they still have a lot to teach us. We have an obligation to ourselves and our users, customers, and employers to learn from them.