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

21–30 of 56 posts

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

#21

Post by SteveLauC »

Really enjoy the post, thanks for sharing.

> My goal with the early sub-projects isn't to build a *finished* sub-component, it is to build a good enough sub-component so I can move on to the next thing on the path to a demo.

This is so enlightening. And I realized that to do this, one has to "skip" something. Other folks mention they ignore code modularity when doing this, I don't think I will do that, keeping code clean and reading/working in such a codebase actually make me satisfied and motivated. For me, I am going to "skip" algorithms, data strucuture and performance.

So the point here is probably, we should skip things, but if a thing motivates you, it should not skipped?

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

#22

Post by Vipsy »

An interesting consideration is how the chosen modularization approach can impact onboarding time for new contributors. A well structured breakdown might not just aid initial development speed, but also reduce ramp up friction for future team members or external collaborators. This is an impartant factor often under-estimated in solo-driven projects.

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

#23

Post by piltdownman »

//Decompose a large problem into smaller problems. Only solve the smaller problem enough to progress on a demo... ...then continue to iterate on more functionality. Make demos as frequently as you can. Prioritize functionality that enables you to adopt your own software Go back and iterate on each component as needed for future improvements//

So in essence we have: Empirical Process Control, Self-Organization, Collaboration, Value-Based Prioritization, Time-Boxing, and Iterative Development.

Is this just solo-SCRUM or am I missing something here?

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

#24

Post by Cthulhu_ »

mrheosuper wrote: post #12

>This is an area where I think experience actually hurts. I've seen senior engineers get bogged down building the perfect thing and by the time they get a demo, they realize it sucks. The implementation doesn't suck, but the product or feature itself actually sucks. This resonates with me. Sometime i want to "turn off" my brain and write shitty code. Back in the day, i made a lot of toy project. Sometime all the sour…

I think you can practice it; do some coding excercises, e.g. Advent of Code is coming up again, usually it's only the later ones that require some optimization or clever algorithms (...I never got that far). Or a constrained environment, you can't write long code in pico-8. Or time limited, like a hackathon or game jam.

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

#25

Post by CaptainOfCoit »

Cthulhu_ wrote: post #24
mrheosuper wrote: post #12

>This is an area where I think experience actually hurts. I've seen senior engineers get bogged down building the perfect thing and by the time they get a demo, they realize it sucks. The implementation doesn't suck, but the product or feature itself actually sucks. This resonates with me. Sometime i want to "turn off" my brain and write shitty code. Back in the day, i made a lot of toy project. Sometime all the sour…

I think you can practice it; do some coding excercises, e.g. Advent of Code is coming up again, usually it's only the later ones that require some optimization or clever algorithms (...I never got that far). Or a constrained environment, you can't write long code in pico-8. Or time limited, like a hackathon or game jam.

Game jams and hackathons are a fun and easy way to get a lot better at scoping and saying no, and being able to predict what works or not once everything is in place.

It's a playful environment with low stakes too, compared to working in a startup, so really advice new programmers to participate in order to learn faster.

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

#27

Post by saaspirant »

mrheosuper wrote: post #12

>This is an area where I think experience actually hurts. I've seen senior engineers get bogged down building the perfect thing and by the time they get a demo, they realize it sucks. The implementation doesn't suck, but the product or feature itself actually sucks. This resonates with me. Sometime i want to "turn off" my brain and write shitty code. Back in the day, i made a lot of toy project. Sometime all the sour…

LLMs (Cursor) have pretty much solved this problem for me. I design the DB tables manually and let it run somewhat wild with implementation.

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

#28

Post by poszlem »

This isn't an "everyone who struggles to finish projects or is a perfectionist has it" kind of post, but if this has been a long-term pattern for you, one that's caused real suffering, lost jobs or contracts, or kept you from finishing important work - please consider getting checked for ADHD. It took me 42 years to get diagnosed, and starting on stimulants genuinely changed my life and pretty much solved those issues for me.

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

#29

Post by theryan »

mrheosuper wrote: post #16
lordnacho wrote: post #14

Earlier quoted context omitted.

Isn't this called the second system problem? When you've done it before, you feel like you need all the bells and whistles?

You are right, this is the first time i've heard about "second system problem". Never know it has its own term.

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.

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

#30

Post by skydhash »

zingar wrote: post #15
ramon156 wrote: post #10

Earlier quoted context omitted.

Would you say that testcases help here? I've been thinking about applying e2e tests on any bugs I find so I know they're fixed

E2E tests in a high ratio to other tests will cause problems. They’re slow and brittle and become a job all on their own. It’s possible that they might help at the start of debugging, but try to isolate the bugs to smaller units of code (or interactions between small pieces of code).

And I would add that e2e tests should be more about the businesses rules. Making sure everything is there for a specific flow and not caring that much about the intricacy of things. And such, it should really be part of Ops, not Dev.

Quick feedback with unit tests can help. It can be a pain to decouple stuff so you can test them better, but it’s worth it IMO.

Post reply on HN