3 ms·

Creating code is the lowest level of programming. Deleting code is much more refined. Preventing code is sublime.

by none_to_remain 3y ago

Jensson 3y ago
This leads to analysis paralysis. Building things helps you think clearer.
- otterley 3y ago
  I’ve learned at Amazon that writing about what you want to build, and why, and why not do something else - in a way that others can clearly comprehend, and before ever touching a line of code - helps you think even more clearly.
  - ffsm8 3y ago
    It really doesn't, unless you've already implemented a variation of the thing before. There is a time for reflection and planning/thinking about a given software problem, but you're mostly wasting time doing so in-depth before you've done/looked through a rudimentary implementation. Your planned architecture will be worse then the one from the person that interated several times while introspecting the resulting code, discovering misconceptions on the way. Do note that this initial implementation is only there to learn the domain of the software, basically. The phase can be skipped if you're not really changing anything and mostly just reimplement something you've done before. At that point, you're not doing something new however.
    - lioeters 3y ago
      > initial implementation is only there to learn the domain I've been trying to do a kind of documentation-driven development, where I write a fairly detailed README file before I write a single line of code. It hasn't gone as smoothly as I imagined, I think it takes practice to get more effective - similar to test-driven dev. And it made me realize my usual approach is "to think by coding", and to explore the problem space with a rough draft of a program. It must be a common approach, as I've heard people say "Throw away the first draft." Not only in programming but about writing in general. Ah, there's even a term for it: Throwaway prototyping - https://en.wikipedia.org/wiki/Software_prototyping#Throwaway_prototyping https://en.wikipedia.org/wiki/Software_prototyping#Throwaway...
  - exceptione 3y ago
    I am interested, is there some public material about this method?
    - marklar423 3y ago
      It's basically just writing a design document; Google has a similar culture. I suppose if you're not actually showing it to anybody it becomes rubber ducking via design document.
    - office_drone 3y ago
      Commoncog has some blog posts about the process: https://commoncog.com/putting-amazons-pr-faq-to-practice/ https://commoncog.com/putting-amazons-pr-faq-to-practice/ https://commoncog.com/product-development-iterated-taste/ https://commoncog.com/product-development-iterated-taste/
  - CuriouslyC 3y ago
    While I disagree with this approach in general - manually executing a task and following the data flow is the best way to understand a new system - I will say that with the rise of LLMs, writing documentation, stubs and comments first may be the fastest way to bootstrap a new project.
  - taneq 3y ago
    Maybe it does for some people but based on all of the functional specifications I've implemented over the years, they are by far the exception. Maybe designing and documenting first is OK if it's done by people who've already learned how systems work by building and maintaining a lot of them, though.
    - nradov 3y ago
      The documents used in Amazon at that lifecycle stage aren't functional specifications. The point is to justify launching a few project to management. You should be able to clearly explain why it's worth expending resources.
- Buttons840 3y ago
  You don't have to save everything you build. Many times I've implemented a feature and felt unsatisfied with it, reverted, and built the same thing again.
- high_5 3y ago
  Not necessarily. You might end up just building things on top of things spiral which reduces the ability to think clearly.
- ambicapter 3y ago
  You can build a ton of things and not put them in production (to then pay the price of what you built). Practice makes perfect then.
- adql 3y ago
  Designing does. Building and using it is for confirming or revoking any prior assumptions you had about the initial design to improve it. Most of the thinking should be put into designing and then revising the design, the "building" should be the simplest part.
appplication 3y ago
Love this, I’m going to steal it
bee_rider 3y ago
Is this true? I find creating, then deleting to be more grounding. Explore a couple paths and pick the good one, don’t just stay home.
- lazyasciiart 3y ago
  Some ideas don’t have a good path - they are just going to suck time and energy until cancelled. Like, the last one I’m thinking of: way out of our core product, there are others out there that are pretty good already, it got proposed as a “quick win” which was absolutely delusional, and the winning argument for why we went ahead and built it was that version 2 would do all the extra work that did tie it back to our product and made it worth doing. Sadly, I failed at preventing it, so the team spent more than twice as long as (they) predicted to build something half as functional and surprise, no v2 will happen.

Creating code is the lowest level of programming. Deleting code is much more refined. Preventing code is sublime.

Jensson 3y ago

This leads to analysis paralysis. Building things helps you think clearer.

otterley 3y ago
I’ve learned at Amazon that writing about what you want to build, and why, and why not do something else - in a way that others can clearly comprehend, and before ever touching a line of code - helps you think even more clearly.
- ffsm8 3y ago
  It really doesn't, unless you've already implemented a variation of the thing before. There is a time for reflection and planning/thinking about a given software problem, but you're mostly wasting time doing so in-depth before you've done/looked through a rudimentary implementation. Your planned architecture will be worse then the one from the person that interated several times while introspecting the resulting code, discovering misconceptions on the way. Do note that this initial implementation is only there to learn the domain of the software, basically. The phase can be skipped if you're not really changing anything and mostly just reimplement something you've done before. At that point, you're not doing something new however.
  - lioeters 3y ago
    > initial implementation is only there to learn the domain I've been trying to do a kind of documentation-driven development, where I write a fairly detailed README file before I write a single line of code. It hasn't gone as smoothly as I imagined, I think it takes practice to get more effective - similar to test-driven dev. And it made me realize my usual approach is "to think by coding", and to explore the problem space with a rough draft of a program. It must be a common approach, as I've heard people say "Throw away the first draft." Not only in programming but about writing in general. Ah, there's even a term for it: Throwaway prototyping - https://en.wikipedia.org/wiki/Software_prototyping#Throwaway_prototyping https://en.wikipedia.org/wiki/Software_prototyping#Throwaway...
- exceptione 3y ago
  I am interested, is there some public material about this method?
  - marklar423 3y ago
    It's basically just writing a design document; Google has a similar culture. I suppose if you're not actually showing it to anybody it becomes rubber ducking via design document.
  - office_drone 3y ago
    Commoncog has some blog posts about the process: https://commoncog.com/putting-amazons-pr-faq-to-practice/ https://commoncog.com/putting-amazons-pr-faq-to-practice/ https://commoncog.com/product-development-iterated-taste/ https://commoncog.com/product-development-iterated-taste/
- CuriouslyC 3y ago
  While I disagree with this approach in general - manually executing a task and following the data flow is the best way to understand a new system - I will say that with the rise of LLMs, writing documentation, stubs and comments first may be the fastest way to bootstrap a new project.
- taneq 3y ago
  Maybe it does for some people but based on all of the functional specifications I've implemented over the years, they are by far the exception. Maybe designing and documenting first is OK if it's done by people who've already learned how systems work by building and maintaining a lot of them, though.
  - nradov 3y ago
    The documents used in Amazon at that lifecycle stage aren't functional specifications. The point is to justify launching a few project to management. You should be able to clearly explain why it's worth expending resources.
Buttons840 3y ago
You don't have to save everything you build. Many times I've implemented a feature and felt unsatisfied with it, reverted, and built the same thing again.
high_5 3y ago
Not necessarily. You might end up just building things on top of things spiral which reduces the ability to think clearly.
ambicapter 3y ago
You can build a ton of things and not put them in production (to then pay the price of what you built). Practice makes perfect then.
adql 3y ago
Designing does. Building and using it is for confirming or revoking any prior assumptions you had about the initial design to improve it. Most of the thinking should be put into designing and then revising the design, the "building" should be the simplest part.

appplication 3y ago

Love this, I’m going to steal it

bee_rider 3y ago

Is this true? I find creating, then deleting to be more grounding. Explore a couple paths and pick the good one, don’t just stay home.

lazyasciiart 3y ago
Some ideas don’t have a good path - they are just going to suck time and energy until cancelled. Like, the last one I’m thinking of: way out of our core product, there are others out there that are pretty good already, it got proposed as a “quick win” which was absolutely delusional, and the winning argument for why we went ahead and built it was that version 2 would do all the extra work that did tie it back to our product and made it worth doing. Sadly, I failed at preventing it, so the team spent more than twice as long as (they) predicted to build something half as functional and surprise, no v2 will happen.