this post was submitted on 23 Nov 2023
121 points (96.9% liked)

Programming

17444 readers
187 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

Many of us write opensource code in a void: nobody ever looks at it, uses it nor reviews it. We are the only users and authors.

In order to improve, where can we get our code reviewed? I don't mean professionally, just from like-minded individuals.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] stifle867@programming.dev 72 points 1 year ago (13 children)

This is not an answer to your question but it's tangentially related.

Someone I greatly respected ran an open-source project with the policy of merge everything. Completely flip this idea of carefully review, debate and revise every PR. His theory was that it helps to build an open community, and if something breaks someone else will revert that commit. He says that the main branch was almost always stable, a massive improvement to how it was run previously. He passed several years ago and for some reason this reminded me of him.

I guess what I'm trying to say is if you get something out there that people find useful, the code will be looked at. It doesn't help you if you're looking for someone to collaborate sorry.

[โ€“] varsock@programming.dev 17 points 1 year ago* (last edited 1 year ago)

There is a very effective approach (34:00), that big companies like cloudflare use, to ship a product in a fast and quality way. It bears parallels to what you are describing. In essence engineers should not get hung up in the details to trying to solve everything.

  1. Just build a proof of concept
  2. Discard the prototype no matter what and start from scratch keeping the initial feedback in mind
  3. Build something internally that you yourself will use
  4. Only once something is good enough and is used internally, then release it to beta.

So that tedious process in trying to flush out all the details before seeing a product (or open source effort) working end to end, might be premature before having the full picture.

load more comments (12 replies)