Earlier this year, I almost left the tech industry entirely. I won’t go into the event that lead to that decision, but it was painful enough that I stopped caring. People who have worked with me will know precisely how serious of a deal that is. My biggest advantage as an entrepreneur and a software developer is that I care really deeply about the people I work with, and the clients our software serves. And I lost that.
Then, I had a fortuitous drink with an old friend where he started sharing a product vision with me. More drinks were consumed and in my drunken stupor, I told him that I would build him an MVP. Long story short, other developers had quoted himm $300,000 for the project. I delivered in nine days and working with him brought me back.
I used Docker for that project because I always greenfield projects with Docker. Fact is, I’ve been in the industry for long enough that I have some seriously old code to maintain. And while it would be nice to be able to rewrite everything, the budget isn’t there and I have some EOL stuff to maintain. I’d rather not have an EOL version of Node anywhere on my machine, but if I have to, I’ll use Docker. From there, it just makes the most sense to install as little as humanly possible, keep my development machine thin but beefy and build up entire environments with Docker. So Docker is a big part of my personal workflow - I use it because it gets me productive far faster than I could be without it.
Another joy of having been in the industry for a long time is that I know a lot of people and we’re all available to help each other when need be. So, as sometimes happens, another fortuitous event came up and a really old friend emailed me late one night needing some Docker help. Without going into details I’m not allowed to give, his organization ran into a pretty awful Docker problem and I was awake anyways, so we logged into Discord and solved their problems overnight.
As genesis moments go, this was a more stressful one than usual because it was about an outage. But it was still a genesis moment because I got to see a really good example of questionable Docker patterns in practice. Armed with those patterns, I started to dig in and do some research. Even with really advanced Google skills, I still found a lot of top search results that propagated some of these less helpful patterns.
So, we’re going to open source a bunch of our development containers. We know they aren’t perfect though, so we’re digging deep and running some tests. Hell, after I finish writing this, I’m going to finish planning out an experiment that I plan to run before we launch.
The process has taught me some interesting things about Docker internals and how to eke out better performance with some really simple changes. I’ll be writing about many of those lessons over the coming weeks. But more importantly, this deep dive into Docker has shown me a lot about how we teach people to write code today. Since industry has changed and there are a lot of unemployed web developers out there, it’s a good time to think deeply about how we taught them and what kinds of tools we provide to help them teach themselves.
Resume driven learning has created a cesspool
As I dug into some of the less helpful Docker problems, I found something alarming. I understand where it comes from, but it doesn’t make it any less alarming. The modern advice is that in order to get a job, you need projects and they all need to be on Github. That advice makes sense and it’s a good way to break into the industry.
The problem is that it seems like a lot of new developers are going straight from tutorial to Github. Searching through Github, I sometimes found hundreds of copies of the exact same project that included the exact same patterns as the flawed tutorial. The projects are all identical, to the point that often misspellings from the tutorial end up in the portfolio project.
I understand all of this. Most of us need jobs and we all deserve to be paid fairly for the work we do. So it makes sense to combine your learning time with your job search.
But there is a huge problem with this. In letting resume driven learning thrive, we have taken away the right for people to be really bad when they’re learning. Let me provide another example of this from my personal life. My child is in French immersion and mi francais es muy mal. So, I’m learning French again. And guess what? I’m horrible at it. I’m so bad that my poor child’s eyes threaten to permanently roll back in her head. My accent is so bad that I can see it cause her physical pain. And my comprehension is so bad that my kid usually switches to English out of frustration.
I’m not copying our great French novels and putting them up on Amazon for people to read. I’m awful at the language and I’m content to spend the time being bad.
Many new developers have seemingly lost that and again, I understand that many people need jobs so I’m not criticizing them. But I am criticizing an industry that has come up with absolutely insane entrance requirements based on a badly flawed theory of a 20x developer. Instead, we should onramp people into the industry with our blessing to be incredibly bad at it because software development is really really hard.
But it gets even worse because a lot of these new developers have paid for the privilege of pushing really bad habits to Github. Bootcamps are easy to search for and if you spend anytime, you’ll see a lot of bootcampers pushing really bad code taught to them by people with absolutely zero experience in the industry. Based on what I’ve seen, I would rather be waterboarded than attend a software bootcamp. It’s the blind leading the trusting and pushing them to push the exact same 6 projects with the exact same 24 problems, instead of taking the time to be bad.
I’ll compare this to music. Do you want to know what Jimi Hendrix, Eric Clapton and Keith Richards have in common? At one point in their lives, they were all bad at the guitar. But they learned (just like we all can) and became gods of the instrument.
We are good at ‘do this’ but very bad at ‘why’
This is another one that I understand. It is really hard to teach and sometimes it’s hard to explain why without explaining twenty other things that your students aren’t ready for. But I am absolutely amazed by how many popular tutorials don’t even try to explain the why.
It’s problematic because while it’s good to know best practices, it is better to understand why they are best practices. It’s better to understand why because sometimes developers have to violate ’the best practices’ and come up with their own best practices to solve that particular problem. It’s very hard to know if you can safely break a rule unless you understand why it was a rule.
We need to accomodate all learning styles
Through my research, I noticed that while there are still high quality written tutorials, the vast majority have moved into video. And while video tutorials are excellent for some people, they’re not excellent for all. I’ve also noticed that outside of a few open source projects, there is a real dearth of places where people can go to work with a group of people while they are learning. It’s relatively easy for new developers to find groups once they know what they’re doing, but it’s very hard for them to find groups while they are learning.
Between written tutorials and groups of learners at different levels, we could start finding and working against some less helpful patterns.
Final words
We’ll be releasing this repo and a bunch of content in the coming weeks so keep an eye out for updates. But this whole experience has both rekindled my love of the industry and my love of teaching people how to solve tough problems. Life is good, code is fun and the people in software are absolutely fascinating.
Have an excellent weekend!