121–130 of 147 posts
I think it’s often called the “tracer bullet principle” as well. Get a full version of your system working quickly from end to end, then improve each part incrementally. Powerful stuff indeed, also for your motivation and sense of accomplishment. Nothing sucks the joy out of work more than building and building and not getting any feedback.
This is incredibly simple yet incredibly powerful, and something that everyone who becomes proficient at delivering things of value learns eventually, but is rarely taught so succinctly. By the way, for the programming case, this is a big part of the reason functional programming is so powerful. Avoiding shared state allows you to write your outline of smaller and smaller pieces, then write each piece as a stateless…
Earlier quoted context omitted.
This looks very cool, especially for hobby projects. I follow approximately the same flow with infinitely nested TODOs in logseq. The cli tree flow is very likely better, but those destructive pops -- it would be hard for me to let go of the ability to look back at the end of the day retrospectively and see the path that was explored.
> The cli tree flow is very likely better, but those destructive pops -- it would be hard for me to let go of the ability to look back at the end of the day retrospectively and see the path that was explored. It's a trade-off: aggressively pruning the noise leaves a lot of signal. I have also found that, when writing down goals/objectives/tasks/whatever, knowing in advance that they are going to be discarded once don…
It's probably the former
(came up with the concept when struggling to write my PhD thesis)
Hope it helps!
This is incredibly simple yet incredibly powerful, and something that everyone who becomes proficient at delivering things of value learns eventually, but is rarely taught so succinctly. By the way, for the programming case, this is a big part of the reason functional programming is so powerful. Avoiding shared state allows you to write your outline of smaller and smaller pieces, then write each piece as a stateless…
I’m not so convinced that this is a property of functional programming as much as simply good programming. I’ve seen functional programs that pass around huge data structures that couple functionality. I’ve never seen the benefit of performing elaborate monadic dances to avoid state that would have been simpler to represent in a non-functional language.
Isolating state is the key principle. Philosophically you could say a program following this principle written in an object oriented or procedural language is more "functional" than a program that passes around a big tangle of state in a single data structure written in a functional language.
This is incredibly simple yet incredibly powerful, and something that everyone who becomes proficient at delivering things of value learns eventually, but is rarely taught so succinctly. By the way, for the programming case, this is a big part of the reason functional programming is so powerful. Avoiding shared state allows you to write your outline of smaller and smaller pieces, then write each piece as a stateless…
Yes. Ideally a codebase is just a monorepo of pure functions and apps are simply the control flow that weaves them. Write reusable libraries not microservices (silos). Sadly incentives are not aligned for this at scale - easier to buy cloud SaaS n+1 whose sales team insist "this $badware solves a Hard Problem" while your devs sit in ceremonies all day.
This is incredibly simple yet incredibly powerful, and something that everyone who becomes proficient at delivering things of value learns eventually, but is rarely taught so succinctly. By the way, for the programming case, this is a big part of the reason functional programming is so powerful. Avoiding shared state allows you to write your outline of smaller and smaller pieces, then write each piece as a stateless…
To be fair to other styles, we generally learned already that shared state is bad. It's avoided in basically every language/service these days. It may be enforced more strictly with functional programming. But "With other programming paradigms, you can't just knock out all the little pieces without thinking about the other pieces" is taking it too far. For example, you want to add email sending to your app? The libra…
Can't "sendEmail" be a function near the edge of the network that does the IO of actually pushing the bytes across the network, decoupled from the "pure" functions at the heart of your application?
This is incredibly simple yet incredibly powerful, and something that everyone who becomes proficient at delivering things of value learns eventually, but is rarely taught so succinctly. By the way, for the programming case, this is a big part of the reason functional programming is so powerful. Avoiding shared state allows you to write your outline of smaller and smaller pieces, then write each piece as a stateless…
> With other programming paradigms, you can't just knock out all the little pieces without thinking about the other pieces because the state is all tangled up. Which slows you down. I don't think so. I use the style of programming described in the post, and my code is mostly OOP, but almost entirely without mutable state. You may claim "but that's not OOP", but I would reply that FP is not about having no shared stat…
Interestingly, Erlang is very much a functional language. But Erlang procedures are a lot like Smalltalk objects, as explained by Joe Armstrong. You send messages to a pid (process id) which then update some state held by the process and possibly sends back a value in response. But the new state is always computed by a pure function.
Maybe this is similar to your design philosophy?
I’m constantly amazed at how differently I learned to do things from my father than from school. My father had all sorts of approaches similar to this, and it’s how I learned to write essays (outside-in) and research (inside-out), and which I later applied to programming. It made school trivial and fun, and it’s what I’m teaching my kids.
Sounds interesting. Can you provide some more examples?
Earlier quoted context omitted.
I think it's the opposite. I think quality often comes from evolution and iteration. There've been so many projects where I get stuck because I want to maximize quality, so I get writer's block. The worse, is that sometimes you'll try to perfect something on your project that ultimately isn't of great value. Building something quickly, and then iterating to perfect it seems to work for many people.
And what many people of either side forget: both are not a one size fits all. There are some things that need planning up front (a car or a rocket) and some things can be done agile and iteratively. Likewise, some things can't be made via solopreneurship/indiehacking and some things can't be achieved with classic VC-backed entrepreneurship. There's a time for both.
There’s the stories of college professors who split their class into two groups, one group that is graded on quality of a single photo/pottery submission, and the other group graded solely on quantity of work produced, and the group tasked with producing quantity always produces higher quality.
I guess I don’t see why building a car or rocket would be different, other than we now know how to do it well.
When people were first building rockets, it was just a blooper real of failures.
Is there some distinction along figuring out the theory/physics, versus figuring out the application, real world, material science angle? Like I could see spending a long time on the theory side, but once that’s understood, it seems like figuring out which materials can produce the required physics is quick iteration’s bread-and-butter.