Tech's most contentious debates end with people talking over each other, but they make way more sense viewed through the lens of inter-generational conflict.
When I saw the title, I thought “just another blog on 10x developer”. I don’t really know why I decided to read on, but I’m happy I did. Searls touches on many more while investigating the topic. The writer approaches the topic from a inter-generational point of view and also goes in to things like “passion” and “craftsmanship”. I would even say, this is not about the 10x developer at all. This is about how as a young engineering discipline we are still trying to find better ways of doing things.
It’s an open secret that the industry has no idea how to teach people to program. Computer Science degrees famously don’t prepare programmers for the job of programming, which has always been left as an exercise to the student to figure out on their own time. If the industry is going to outlive us enthusiast programmers, will it adopt a sustainable approach to educating the next generation that doesn’t require people to teach themselves everything?
With regards to education, one of the things I’ve come to understand goes entirely counter to the way I was taught at University - for me, programming is a creative activity. It’s an iterative process, and the less constraints I have on how I achieve something, not what I achieve, the better I enjoy it, the more productive I am, and the better by many measures the end solution will be.
I think that is a key part of what’s missing from CS education, to understand that and lean into it to both increase engagement but also to get people thinking outside the box for solutions to their problems. Students seem to be taught so much, but very little about “Here’s a high-level problem, provide a solution” which is the “core loop” of software development (outside of being a code monkey implementing other people’s designs). You go over requirements and specifications, but you don’t actually DO it… you don’t speak to people, ask the questions, realise they’d don’t know much about software, then later go “Oh shit, I made this assumption and made the wrong thing!”
One of the things that I used to like more than anything was achieving things even though there were constraints. For example, back in the 90’s even before even AJAX was a thing, I created a site for a betting company that was a SPA and pulled in data and live betting odds. I did this by having a message queue in JavaScript, a hidden frame from which to send messages from the queue to the server using a form, and then the server returned JavaScript code which executed and put the data where needed and updated the page. I absolutely loved that project, and most people on the team just couldn’t believe it was even possible.
But I didn’t solve it through engineering, I solved it through playing - trying things, seeing what would work/what didn’t, adapting the idea, etc. until I found something that worked - and it was based on some of the things I’d been messing about with in my own time (somewhat bizarrely, creating a sort of online aquarium of Dr. Seuss fish where each one was a person viewing the site!)
I think if we can inject more of the creativity, tinkering, iterative, playful side into our education it’ll make a huge difference.
What you did with the message queu in Javascript is impressive. And I’m sure there are other efforts that solved “impossible” problems in creative ways. Creativity is important in a lot of professions and I can admit that it is probably more important in programming than, say, accounting (I hear “creative accounting” is not a good thing). However, I don’t think creativity is vital in what we do. It’s useful, sure. But, for example, it’s not as important as critical thinking. I think the real problem is that we are a relatively new engineering discipline that is still under rapid change. The paradox is, if we look at the programming paradigms, we don’t actually see many new things. We reheat the stuff from 60s/70s all the time (functional programming is a good example). But the socio-technical aspects of what we do (and how we do it) is under constant change (waterfall, agile, autonomy, etc.). And, this is probably what makes software unique. We have a very short feedback loop (as opposed to building a bridge). And I would say, that should also have its place in education.
When I saw the title, I thought “just another blog on 10x developer”. I don’t really know why I decided to read on, but I’m happy I did. Searls touches on many more while investigating the topic. The writer approaches the topic from a inter-generational point of view and also goes in to things like “passion” and “craftsmanship”. I would even say, this is not about the 10x developer at all. This is about how as a young engineering discipline we are still trying to find better ways of doing things.
With regards to education, one of the things I’ve come to understand goes entirely counter to the way I was taught at University - for me, programming is a creative activity. It’s an iterative process, and the less constraints I have on how I achieve something, not what I achieve, the better I enjoy it, the more productive I am, and the better by many measures the end solution will be.
I think that is a key part of what’s missing from CS education, to understand that and lean into it to both increase engagement but also to get people thinking outside the box for solutions to their problems. Students seem to be taught so much, but very little about “Here’s a high-level problem, provide a solution” which is the “core loop” of software development (outside of being a code monkey implementing other people’s designs). You go over requirements and specifications, but you don’t actually DO it… you don’t speak to people, ask the questions, realise they’d don’t know much about software, then later go “Oh shit, I made this assumption and made the wrong thing!”
One of the things that I used to like more than anything was achieving things even though there were constraints. For example, back in the 90’s even before even AJAX was a thing, I created a site for a betting company that was a SPA and pulled in data and live betting odds. I did this by having a message queue in JavaScript, a hidden frame from which to send messages from the queue to the server using a form, and then the server returned JavaScript code which executed and put the data where needed and updated the page. I absolutely loved that project, and most people on the team just couldn’t believe it was even possible.
But I didn’t solve it through engineering, I solved it through playing - trying things, seeing what would work/what didn’t, adapting the idea, etc. until I found something that worked - and it was based on some of the things I’d been messing about with in my own time (somewhat bizarrely, creating a sort of online aquarium of Dr. Seuss fish where each one was a person viewing the site!)
I think if we can inject more of the creativity, tinkering, iterative, playful side into our education it’ll make a huge difference.
What you did with the message queu in Javascript is impressive. And I’m sure there are other efforts that solved “impossible” problems in creative ways. Creativity is important in a lot of professions and I can admit that it is probably more important in programming than, say, accounting (I hear “creative accounting” is not a good thing). However, I don’t think creativity is vital in what we do. It’s useful, sure. But, for example, it’s not as important as critical thinking. I think the real problem is that we are a relatively new engineering discipline that is still under rapid change. The paradox is, if we look at the programming paradigms, we don’t actually see many new things. We reheat the stuff from 60s/70s all the time (functional programming is a good example). But the socio-technical aspects of what we do (and how we do it) is under constant change (waterfall, agile, autonomy, etc.). And, this is probably what makes software unique. We have a very short feedback loop (as opposed to building a bridge). And I would say, that should also have its place in education.
This talk by Dave Farley sums up my thoughts about “software engineering” quite well: Taking Back “Software Engineering” – Craftsmanship is Insufficient (Piped link).
I’m glad I saw this comment because I was also about to skip it, but found the article to be a worthwhile read as well. Thanks for sharing it.