Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My approach to building large technical projects (2023)

mitchellh.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: My approach to building large technical projects (2023)

#41

Post by chrisweekly »

amenghra wrote: post #5
davidkunz wrote: post #3

I have huge respect for Mitchell, it's impressive what he achieved. I agree with all the points of this article and would like to add one: Have a quick feedback loop. For me, it's really motivating to be able to make a change and quickly see the results. Many problems just vanish or become tangible to solve when you playfully modify your source code and observe the effect.

If you have the time, what Bret Victor’s talk Inventing on Principal. The talk covers feedback loops. https://www.youtube.com/watch?v=PUv66718DII

YES that is one of the all-time most inspiring talks I've ever seen. DX is so important. I got a taste for this kind of thing when I first encountered LiveReload (circa 2012?) and radically upgraded my and my team's webdev workflows.

Re: My approach to building large technical projects (2023)

#42

Post by ericmcer »

davidkunz wrote: post #3

I have huge respect for Mitchell, it's impressive what he achieved. I agree with all the points of this article and would like to add one: Have a quick feedback loop. For me, it's really motivating to be able to make a change and quickly see the results. Many problems just vanish or become tangible to solve when you playfully modify your source code and observe the effect.

seriously, especially for personal projects.

The second you lose motivation the whole thing poofs into non-existence, so making it enjoyable is almost the most important facet.

Re: My approach to building large technical projects (2023)

#43

Post by dasil003 »

skeeter2020 wrote: post #32
theryan wrote: post #29

Earlier quoted context omitted.

The Mythical Man-Month by Fred Brooks is still a good read today and goes into depth about this topic. He called it the second system effect and considered it to be the most dangerous system an experienced developer will create. His 'No Silver Bullet' theory may or may not stand up to what AI is doing today as well.

From what I've seen it's standing up. His original statement/hypothesis is often misrepresented. "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity." If he had also included "volume" then AI would have disproved him! More anecdotally, the hands-on experi…

I agree with the quote as stated, but I would refactor it for a more powerful insight.

I do believe order of magnitude improvements in productivity and reliability are possible, but they don't come from technology or management technique, they come from simplicity. The simplest possible thing that gets the job done can be infinitely more reliable than whatever baroque contraption comes out of typical fog-of-war enterprise environments. The trick is having the judgement to understand what complexity is essential and how to distill things down to the most valuable essence. This is something AI will never be able to do, because the definition of value is in the eye of the human beholder.

Re: My approach to building large technical projects (2023)

#44

Post by kkukshtel »

Building demos as a key part of development is really key imo. Demos act as a half-step between working on the software (programming) and writing about the software (writing). Demos act more as a way to continually validate your own theses about what a project SHOULD do, and act as nice feedback mechanism as you continue to work. They are also long-living, so when you break something you can see you broke it and continue the feedback system again.

I do this as part of the work on my own game engine:

https://github.com/zinc-framework/Zinc.Demos/tree/main/Zinc....

Re: My approach to building large technical projects (2023)

#45

Post by HeyLaughingBoy »

hk__2 wrote: post #17
iamflimflam1 wrote: post #9

For me just starting is the best way. So many people see a big project and get trapped in analysis paralysis.

Oh, starting is easy. It’s finishing that’s hard.

This is where a Definition of Done statement becomes important

Re: My approach to building large technical projects (2023)

#46

Post by [deleted] »

kkukshtel wrote: post #44

Building demos as a key part of development is really key imo. Demos act as a half-step between working on the software (programming) and writing about the software (writing). Demos act more as a way to continually validate your own theses about what a project SHOULD do, and act as nice feedback mechanism as you continue to work. They are also long-living, so when you break something you can see you broke it and cont…

[deleted]

Re: My approach to building large technical projects (2023)

#48

Post by westurner »

sjdjsin wrote: post #34
MoreQARespect wrote: post #33

Earlier quoted context omitted.

Hermetic e2e tests (i.e. ones that can run offline and fake apis/databases) dont have that problem so much. They also have the advantage that you can A) refactor pretty much everything underneath them without breaking the test, B) test realistically (an underrated quality) and C) write tests which more closely match requirements rather than implementation.

> i.e. ones that can run offline and fake apis/databases I can see a place for this, but these are no longer e2e tests. I guess that’s what “hermetic” means? If so it’s almost sinister to still call these e2e tests. They’re just frontend tests. > A) refactor pretty much everything underneath them without breaking the test This should always be true of any type of tests unless it’s behavior you want to keep from break…

> try to isolate the bugs to smaller units of code (or interactions between small pieces of code).

This is why unit tests before e2e tests.

It's higher risk to build on components without unit tests test coverage, even if the paltry smoke/e2e tests say it's fine per the customer's input examples.

Is it better to fuzz low-level components or high-level user-facing interfaces first?

IIUC in relation to Formal Methods, tests and test coverage are not sufficient but are advisable.

Competency Story: The customer and product owner can write BDD tests in order to validate the app against the requirements

Prompt: Write playwright tests for #token_reference, that run a named factored-out login sequence, and then test as human user would that: when you click on Home that it navigates to / (given browser MCP and recently the Gemini 2.5 Computer Operator model)

Re: My approach to building large technical projects (2023)

#49

Post by jebarker »

mhaberl wrote: post #11
davidkunz wrote: post #3

I have huge respect for Mitchell, it's impressive what he achieved. I agree with all the points of this article and would like to add one: Have a quick feedback loop. For me, it's really motivating to be able to make a change and quickly see the results. Many problems just vanish or become tangible to solve when you playfully modify your source code and observe the effect.

This perfectly aligns with my experience. Every large project I have worked on showed a clear correlation between the ease of setup and running and the number of problems on the project, like bugs and missed deadlines.

Totally agree. I work in LLM training software and I believe progress in the field is actually much slower than it should be because of the excruciatingly long feedback loops involved in development. The software stacks are deep and abstract and much of the testing involves full integration tests that take a long time to spin up.

Re: My approach to building large technical projects (2023)

#50

Post by nemetroid »

skeeter2020 wrote: post #32
theryan wrote: post #29

Earlier quoted context omitted.

The Mythical Man-Month by Fred Brooks is still a good read today and goes into depth about this topic. He called it the second system effect and considered it to be the most dangerous system an experienced developer will create. His 'No Silver Bullet' theory may or may not stand up to what AI is doing today as well.

From what I've seen it's standing up. His original statement/hypothesis is often misrepresented. "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity." If he had also included "volume" then AI would have disproved him! More anecdotally, the hands-on experi…

It is interesting though that when he mentions AI as one of the non-silver bullets, one of the arguments is that the AI models of the time were problem-specific and not easily transferable.
Post reply on HN