> I agree that extremism in order to learn is a great strategy.
I think it is key to consciously decide when you're learning and when you're doing, and to keep that in mind as you act.
If your goal is to learn, feel free to try bold stuff that might not work. But when your goal is to build, stick to boring stuff that you're confident will work.
This applies at all scales. When you're inventing a programming language, is it a scientific instrument or an engineering tool? When you're adding a feature, it is to understand the users or to deliver value to them? When you're changing the signature of a function, is it an experiment or an improvement?
Agreed. I've been shipping software for over 30 years.
Shipping can be quite "boring."
For example, I am about halfway through a social media app (90% of the way, if we include the backend).
The backend was written in PHP. I decided to do that, because it was an "all-purpose" open-source system, designed for low-budget orgs.
Also, I was already an experienced PHP programmer, and PHP is just fine as a server stack. It's not crazy good, but it works great.
The frontend is being written in Swift, which some companies might consider "edgy," but I'm using traditional UIKit, and storyboarding, which many folks would consider "clunky" (I'm supposed to use SwiftUI).
The thing is, is that SwiftUI is still trying on outfits, and the app is going to be very complex. I am not yet convinced that SwiftUI is "ripe" enough to do an app with the complexity I need.
That said, I want to learn SwiftUI this year, and explore its edges.
IMO we can and should take measured risks when shipping too. You can only learn so much in fake environments.
You just have to take measured risks, controlling the blast radius as appropriate in your context. But we have to be able to make progress as an industry, and that means taking risks when building real stuff.
> I agree that extremism in order to learn is a great strategy.
I think it is key to consciously decide when you're learning and when you're doing, and to keep that in mind as you act.
If your goal is to learn, feel free to try bold stuff that might not work. But when your goal is to build, stick to boring stuff that you're confident will work.
This applies at all scales. When you're inventing a programming language, is it a scientific instrument or an engineering tool? When you're adding a feature, it is to understand the users or to deliver value to them? When you're changing the signature of a function, is it an experiment or an improvement?