Are You a Slave to your Software Knowledge?

I lean back in my chair and stare blankly at no particular ceiling tile.

“Oh my God.”

“What?” says the contractor across the desk, not looking up from his screen.

“I'm reading about Kubernetes, and I just realized that I'm almost 30 and I don't know how to tie a trucker's hitch.”

Here's an extistential crisis for you: Recite every technology that you've used to build an actual application or incorporate in a system design. Include languages, libraries, frameworks, IDEs, and utility apps, plugins, conventions, standards, or text editors that have a learning curve and aren't redundant with another entry. Tickle your brain and blast out every acronym you know in one sneeze.

Could you do that and know it's a complete, correct answer?

I can't, but here's my attempt: C, C++, DevC++, Code::Blocks, Visual Studio, Conitec 3D GameStudio, Maya, Valgrind, Win32, DirectX 9.0c, HTML, CSS, JavaScript, SVG, jQuery, PHP, MySQL, Yii, Backbone+Marionette, Bootstrap, Markdown, Sass, d3.js, LESS, Python, Mongo, DD-WRT, Proxmox, Common Lisp (SBCL), Emacs, Vulkan, Racket, Vagrant, Mocha+Chai, Jasmine, Puppeteer, Sikuli, pip, npm, raco, Scribble, Node.js, NGINX, my elbow is locking up, Apache, Handlebars, Mandrill, Flask, Travis, Jenkins, Azure Devops (Pipelines, Repos), AWS (S3, Route53, Docker, CloudFront, IAM, Lambda), pytest, Git, Mercurial, JIRA, Confluence, Bamboo, LaTeX, XML, OpenXML, JSON, Babel, Polyglot, Unlike-Assets, Webpack, Gulp, Grunt, Bash, Neo4J+Cypress, Restify, Express, Kendo,, yarn, BEM, Linux (via LFS), Mithril.js, React, Redux, MobX, Make, CMake, Boost.

Done? Okay, now ask yourself two things:

For me: No, and about 50-60%.

Something's wrong here.

My Knowledge Isn't Really Mine

After years I've found that most of what I know serves to appease my industry's sense of relevance. The rest makes me a specialist. To me, the life of a specialist does not count as a life.

The time you spend in any rat race should not dwarf the time you need to become the best person you can be. Writing software is a process of constant learning, but how many ways do you really need to know to make a web page or REST API?

Say you learn React to get a job. You practice React enough to see flaws. If you prefer a leaner alternative, you're still stuck attending talks about React, reading blog posts about React, and hosting Lunch & Learns about React. You're keeping up with what's behind you.

But this isn't about React, this is about the fact that your education is defined by employers' needs, not your weaknesses. You're not paid to know more than what they need you to know. Even if you take the time to find better ways to work, you can't rewrite everything or change how other people work. Depending on your contract, you might not even be able to practice new skills without oversight. Even incremental improvements can be tough when you basically have an HOA in control of your mind.

What's Your Point?

My point is that you should strictly limit how much employers dictate what you need to know. This means taking time to learn skills outside of software that serve you directly, like making your own detergent, investing, and eliminating debt. You can also learn software skills that your employer doesn't care about but open up new avenues of creativity and productivity. This includes learning a Lisp or writing a small OS. You know, something that actually makes you use concepts related to a Computer Science degree. That kind of work might not seem rewarding because you don't get paid for it, but you'll eventually find new ways to cut costs and find shortcuts that reduce your dependence on your employer.

And reducing your dependence on your employer is the only way to get your mind back.