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

11–20 of 56 posts

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

#11

Post by mhaberl »

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.

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

#12

Post by mrheosuper »

>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 source code is in single file. No respect to modularity. But it was fun, and it worked. Now just try to finish a toy project seem much harder than ever.

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

#13

Post by Bukhmanizer »

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 this is why often new languages get so hyped early on. A bunch of inexperienced people get to leave all the boring “best practices” back in their old languages

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

#14

Post by lordnacho »

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…

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

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

#15

Post by zingar »

ramon156 wrote: post #10
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.

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).

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

#16

Post by mrheosuper »

lordnacho wrote: post #14
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…

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.

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

#18

Post by meander_water »

Great read, but I was expecting something different based on the title.

This sounds like his approach working on personal projects. I'm really curious about large technical team projects though. What's the best approach to getting stuff done and making sure everyone is working towards the same goal etc.

After 15 years I have yet to see a technical project that hasn't run over budget, over time, under delivered or burnt people out.

I'm sure there are people out there with counter examples who know exactly how to deliver projects at a massive scale. Any links/suggested reading would be appreciated!

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

#19

Post by cloudexpat »

I remember reading this when it was published, and the milestone breakdown Mitchell describes was exactly what got us from a theoretical solution to a production platform.

That combined with launching an MVP first rather than the "complete" vision. Shipping early meant we avoided the trap of spending months perfecting features no one actually used.

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

#20

Post by makeitdouble »

meander_water wrote: post #18

Great read, but I was expecting something different based on the title. This sounds like his approach working on personal projects. I'm really curious about large technical team projects though. What's the best approach to getting stuff done and making sure everyone is working towards the same goal etc. After 15 years I have yet to see a technical project that hasn't run over budget, over time, under delivered or bur…

> over budget, over time, under delivered

TBH these are fine in my book.

"over budget" is only an issue if there's really no more money, and I think it's pretty rare for IT projects. Most of the time it's just someone complaining the estimate was off.

"Over time" is the same, it's an issue if there was a real deadline, but the best practice is not plan unflexible events (e.g. do a huge PR campaign with the date on it) before it's basically done.

"under delivered" is a matter of expectations, the real pointis that it was delivered at all.

> or burnt people out.

This one is not like the others. People shouldn't burn out over bullshit deadlines.

Post reply on HN