69
The looming demise of the 10x developer
(blog.testdouble.com)
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
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).