Ask HN: How do solo devs get feedback on their code?

For solo devs working on a closed source codebase, how do you get feedback on design and implementation decisions?

In the past, I've asked friends in the field I trust, but I'm wondering if there's a better option out there.

- pay someone

- open source it

- reframe the arch in another example you can share (pull out the important parts and showcase them)

- describe the arch (in some detail) and ask about potential issues

There are different levels to consider design feedback, from overall arch to detailed (appropriate) use of language constructs. Is it maintainable, easy to change, easy to understand?

I'd love a good answer to this. A couple months ago I struck out on my own with a non-technical partner, and I definitely miss peer code review.

By running the code. Let's say the code is bad. The software will let you know if there's a logical error. The software will be hard to maintain when you want to update it, The software will be hard to use when users try it. There's no feedback like the one the software gives. The proof is in the pudding. If you're new to software and a junior developer, then outside feedback is much needed, but once you're experienced. The most useful feedback is going to be the one the software gives you.

Reading other people's code is perhaps the second most important skill after programming.

There's a great analogy in the essay Babble [1]. In the essay the author explains the process with which humans construct sentences. They say that we learn to babble, we perform a search in the space of all possible sounds, we weigh those possible continuations, select the most probable and filter them using some function. As we grow and through multiple interactions with others and in particular our parents, we improve our filter function. In tandem, we also need to improve our babbling function, that is, we need to improve the search space and the weighting that we give to the noises so that we chain them in interesting ways.

By analogy, we learn to code-babble by working on projects, and by reading other people's code, we learn to filter.

The author notes that it is of equal importance to train both filters in the case of speech, as deficiens in one can leave you either mute or appear as uninteresting, or incoherent. By analogy, deficiency in code babble leaves you unable to construct interesting patterns, and deficiency in code filtering leaves you with a create but otherwise garbage of hot spaghetti.

[1] https://www.lesswrong.com/posts/i42Dfoh4HtsCAfXxL/babble