5 ms·

> Personal projects remain unfinished or abandoned because I’ve wanted to do things the “right” way. So I start building it the “right” way with complicated too

> Personal projects remain unfinished or abandoned because I’ve wanted to do things the “right” way. So I start building it the “right” way with complicated tools and processes, then raise my hands and think it’s all too much for what I want to do. It puts all sorts of things out of reach. So true it hurts.

rgrieselhuber 4y ago
This brings to mind some of Paul Virilio’s writings, who discussed this idea of speed (to include not only velocity but also the sensory assault that comes with complexity and speed combined. This has been paraphrased as “speed is a continuation of fear by other means.” How many framework decisions are made in this mindset?
- riesenheim 4y ago
  Thanks for this fascinating connection. "History progresses at the speed of its weapons systems." https://en.wikipedia.org/wiki/Paul_Virilio#War_of_movement https://en.wikipedia.org/wiki/Paul_Virilio#War_of_movement
  - rgrieselhuber 4y ago
    Virilio was a very interesting writer.
ZephyrBlu 4y ago
Yeah, the primary goal of any side project should be doing whatever maximizes the chance you continue working on it. The lesson from survivorship bias is to optimize for survival :).
- marginalia_nu 4y ago
  Yeah, I like the analogy of a march, as a contrast to the sprints typically employed in commercial development. Like my search engine project is 2 years in now, and still not anywhere near "done". Yet it keeps getting better and more capable at a slow but steady pace.
- deleted 4y ago
  [deleted]
brightball 4y ago
I feel this. The other day I decided to just use Rails for one of these personal projects that I’ve been over-engineering for a while and it’s making progress. Completely forgot how fast Rails makes everything. Based on the experience I’m probably going to force myself to just use Rails for any personal stuff now and figure if any of them actually take off I’ll rebuild if I need to.
- Ziggy_Zaggy 4y ago
  This. Find a tech (NOT the fotm shenanigans) that will help you get a product up and running. Then you can always go back and swap out parts as needed. Try not to be influenced by the "omg, that tech is SOOO old!!!" crowd.
- deleted 4y ago
  [deleted]
- svnpenn 4y ago
  this is the exact opposite of the point the comment you replied to is making. Rails is not simple. we are talking about SIMPLE, like CGI. Rails is a classic example of a slow bloated framework.
  - brightball 4y ago
    Rails makes a lot of very complicated things, very simple. Doing what I'm trying to do with CGI would be a huge headache by comparison. When I said "how fast rails makes things" I meant from a standpoint of productivity.
  - qbasic_forever 4y ago
    Rails will be significantly faster than a CGI script that spawns a whole new process, starts up your script interpreter, etc. with every single web request.
hit8run 4y ago
100%. I finish projects with Rails... Can't say this about things I start in Go with Clean Architecture and a distributed frontend written in SvelteKit etc. pp. I need to print this out: "JUST USE RAILS FOR NOW."
- ehnto 4y ago
  Some of the "right" tools are right only in context of a professional team anyway. Especially true when deciding how to organise a project. If it is just me, for me, I will write it simply and from scratch or use a familiar general purpose framework like rails or laravel. One I have lots of experience with so the project actually gets done, instead of spending all my energy learning another new tool.
- nickjj 4y ago
  > "JUST USE RAILS FOR NOW." That could also be reduced down to "JUST USE RAILS". Why not get the best of both worlds where you finish projects AND be happy about it? The "for now" makes you think it's a bad decision and you hacked something together to get it done. But you can finish, stick with Rails and be insanely successful based on what's important to you (start, finish, maintain, profit, IPO, etc.).
  - hit8run 4y ago
    You convinced me: JUST USE RAILS. It's printed out.
- sgt 4y ago
  Or for us Pythonistas, just use Django. Heck, even if it's just a simple REST API (using DRF), I often do it as the project tends to grow.
  - satvikpendem 4y ago
    If only there were something similar for Node, or Rust.
abc3354 4y ago
> Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project. A quote from Linus Torvalds someone posted on HN and I saved almost a year ago
- chrisweekly 4y ago
  "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system." - John Gall
  - satvikpendem 4y ago
    This describes biological evolution well too. However, I wonder how this works for physical things, how does one create a simple version of a train or bridge? Some things have a complexity floor.
    - still_grokking 4y ago
      How did the "simpler" physical laws looked before nature arrived at the current ones? (That's a half serous question, of course.)
notjustanymike 4y ago
What's funny is this is how Agile works in a functioning organization. You validate the idea first and quick, and only then iterate with new layers of complexity. Building something the "right" way before ever having seen the product live is called waterfall.
derefr 4y ago
The thing that nobody tells junior programmers, but which you really have to pick up from experience, is this: "The right final architecture" is never achieved by just immediately going out and building that architecture, i.e. by hooking up all the tools required to support that architecture. That's cargo-culting the architecture. Facebook's use of Cassandra and CI lint-checks and blue-green deployments is just like military cargo planes' use of radio towers — they didn't build those first; they scaled the thing they were doing to the point that these things became necessary support structures, and then they built them. The "right way" — the right process for engineering a solution — has very little to do with up-front architectural design. The "right way" — the way that'll be most likely to get you to that "right final architecture" eventually — is really the tenable way: the iterative approach that allows you to build up your solution while keeping only one change or consideration in your head at a time. Which means that engineering "the right way" involves not doing all those cargo-cult practices unless/until they become necessary, and even then, only adopting them one at a time. Just like you wouldn't try to make ten different refactorings in a codebase in one patch-set. Or, to put that another way: YAGNI applies to processes and tools just as much as it does to code. Some projects never exceed 1000 lines. Do those projects need CI cyclomatic-complexity checkers? No. Only introduce support structures to a project, as the pain of not having them starts to outweigh the pain of adding them.
- CM30 4y ago
  > Facebook's use of Cassandra and CI lint-checks and blue-green deployments is just like military cargo planes' use of radio towers — they didn't build those first; they scaled the thing they were doing to the point that these things became necessary support structures, and then they built them. This is so true. In fact, a lot of the technology choices companies at the scale of Facebook use are only necessary because they're so large/popular, and were added later to stop everything falling over. Because it's so unlikely your project will ever need to contend with a billion users or whatever, you really shouldn't be designing under the assumption that's likely to happen.
satvikpendem 4y ago
I was feeling the same way recently, and I made an HN post about trying to solve this problem of perfectionism. "Tell HN: I was tired of being a perfectionist so I built an app within 24 hours" https://news.ycombinator.com/item?id=33303269 https://news.ycombinator.com/item?id=33303269
deleted 4y ago
[deleted]

rgrieselhuber 4y ago

This brings to mind some of Paul Virilio’s writings, who discussed this idea of speed (to include not only velocity but also the sensory assault that comes with complexity and speed combined. This has been paraphrased as “speed is a continuation of fear by other means.” How many framework decisions are made in this mindset?

riesenheim 4y ago
Thanks for this fascinating connection. "History progresses at the speed of its weapons systems." https://en.wikipedia.org/wiki/Paul_Virilio#War_of_movement https://en.wikipedia.org/wiki/Paul_Virilio#War_of_movement
- rgrieselhuber 4y ago
  Virilio was a very interesting writer.

ZephyrBlu 4y ago

Yeah, the primary goal of any side project should be doing whatever maximizes the chance you continue working on it. The lesson from survivorship bias is to optimize for survival :).

marginalia_nu 4y ago
Yeah, I like the analogy of a march, as a contrast to the sprints typically employed in commercial development. Like my search engine project is 2 years in now, and still not anywhere near "done". Yet it keeps getting better and more capable at a slow but steady pace.
deleted 4y ago
[deleted]

brightball 4y ago

I feel this. The other day I decided to just use Rails for one of these personal projects that I’ve been over-engineering for a while and it’s making progress. Completely forgot how fast Rails makes everything. Based on the experience I’m probably going to force myself to just use Rails for any personal stuff now and figure if any of them actually take off I’ll rebuild if I need to.

Ziggy_Zaggy 4y ago
This. Find a tech (NOT the fotm shenanigans) that will help you get a product up and running. Then you can always go back and swap out parts as needed. Try not to be influenced by the "omg, that tech is SOOO old!!!" crowd.
deleted 4y ago
[deleted]
svnpenn 4y ago
this is the exact opposite of the point the comment you replied to is making. Rails is not simple. we are talking about SIMPLE, like CGI. Rails is a classic example of a slow bloated framework.
- brightball 4y ago
  Rails makes a lot of very complicated things, very simple. Doing what I'm trying to do with CGI would be a huge headache by comparison. When I said "how fast rails makes things" I meant from a standpoint of productivity.
- qbasic_forever 4y ago
  Rails will be significantly faster than a CGI script that spawns a whole new process, starts up your script interpreter, etc. with every single web request.

hit8run 4y ago

100%. I finish projects with Rails... Can't say this about things I start in Go with Clean Architecture and a distributed frontend written in SvelteKit etc. pp. I need to print this out: "JUST USE RAILS FOR NOW."

ehnto 4y ago
Some of the "right" tools are right only in context of a professional team anyway. Especially true when deciding how to organise a project. If it is just me, for me, I will write it simply and from scratch or use a familiar general purpose framework like rails or laravel. One I have lots of experience with so the project actually gets done, instead of spending all my energy learning another new tool.
nickjj 4y ago
> "JUST USE RAILS FOR NOW." That could also be reduced down to "JUST USE RAILS". Why not get the best of both worlds where you finish projects AND be happy about it? The "for now" makes you think it's a bad decision and you hacked something together to get it done. But you can finish, stick with Rails and be insanely successful based on what's important to you (start, finish, maintain, profit, IPO, etc.).
- hit8run 4y ago
  You convinced me: JUST USE RAILS. It's printed out.
sgt 4y ago
Or for us Pythonistas, just use Django. Heck, even if it's just a simple REST API (using DRF), I often do it as the project tends to grow.
- satvikpendem 4y ago
  If only there were something similar for Node, or Rust.

abc3354 4y ago

> Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project. A quote from Linus Torvalds someone posted on HN and I saved almost a year ago

chrisweekly 4y ago
"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system." - John Gall
- satvikpendem 4y ago
  This describes biological evolution well too. However, I wonder how this works for physical things, how does one create a simple version of a train or bridge? Some things have a complexity floor.
  - still_grokking 4y ago
    How did the "simpler" physical laws looked before nature arrived at the current ones? (That's a half serous question, of course.)

notjustanymike 4y ago

What's funny is this is how Agile works in a functioning organization. You validate the idea first and quick, and only then iterate with new layers of complexity. Building something the "right" way before ever having seen the product live is called waterfall.

derefr 4y ago

The thing that nobody tells junior programmers, but which you really have to pick up from experience, is this: "The right final architecture" is never achieved by just immediately going out and building that architecture, i.e. by hooking up all the tools required to support that architecture. That's cargo-culting the architecture. Facebook's use of Cassandra and CI lint-checks and blue-green deployments is just like military cargo planes' use of radio towers — they didn't build those first; they scaled the thing they were doing to the point that these things became necessary support structures, and then they built them. The "right way" — the right process for engineering a solution — has very little to do with up-front architectural design. The "right way" — the way that'll be most likely to get you to that "right final architecture" eventually — is really the tenable way: the iterative approach that allows you to build up your solution while keeping only one change or consideration in your head at a time. Which means that engineering "the right way" involves not doing all those cargo-cult practices unless/until they become necessary, and even then, only adopting them one at a time. Just like you wouldn't try to make ten different refactorings in a codebase in one patch-set. Or, to put that another way: YAGNI applies to processes and tools just as much as it does to code. Some projects never exceed 1000 lines. Do those projects need CI cyclomatic-complexity checkers? No. Only introduce support structures to a project, as the pain of not having them starts to outweigh the pain of adding them.

CM30 4y ago
> Facebook's use of Cassandra and CI lint-checks and blue-green deployments is just like military cargo planes' use of radio towers — they didn't build those first; they scaled the thing they were doing to the point that these things became necessary support structures, and then they built them. This is so true. In fact, a lot of the technology choices companies at the scale of Facebook use are only necessary because they're so large/popular, and were added later to stop everything falling over. Because it's so unlikely your project will ever need to contend with a billion users or whatever, you really shouldn't be designing under the assumption that's likely to happen.

satvikpendem 4y ago

I was feeling the same way recently, and I made an HN post about trying to solve this problem of perfectionism. "Tell HN: I was tired of being a perfectionist so I built an app within 24 hours" https://news.ycombinator.com/item?id=33303269 https://news.ycombinator.com/item?id=33303269

deleted 4y ago

[deleted]