In the past, I've asked friends in the field I trust, but I'm wondering if there's a better option out there.
1. Your problem
2. The solution you chose
3. Your strong belief your solution is the best, and that no one can possibly find any fault in it.
Then post it to HN and wait for people to school you :)
Peoples compulsion to point out other peoples flaws is far greater than their drive to help.
Otherwise post to any forum with a female-sounding name. Works as well.
As a solo dev, not getting feedback is the "best" part for me; I work on projects on my own just because of this. I'm the god of my tiny worlds, no one gets to judge them (positively or negatively). I write code as I see and the outcome always pleases me. I don't need feedback when I code for pleasure.
As an employee, sure I get feedback of my code via code reviews. This is fine as well.
- 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 do have some developer friends to talk to when i need to get it out and once in a while i team up with one of them to create something. That way I learn new things and get some feedback but nothing close to what i had back then when i was working in a company.
"If five people tell you there's a problem, they're almost certainly right. If they tell you how to fix it they're almost certainly wrong."
Getting feedback from the compiler is like this in spades.
While the act of trying to change, or even understand code which you wrote a while ago, will very likely to reveal it to be overly-engineered, incomplete, confusing, or some combination of all of these, it's very unlikely to come with a message saying, "And if you change it like this, all of these problems will go away."
You only get that by reading design advice and trying to apply it to your own work, and by looking at code which turns out to be better than yours and working out where the differences lie.
What is harder is dealing with architectural issues but I'm not convinced they are that easy to avoid in a team environment either.
Reporting a bug takes work. Doing it clearly takes more work. Some percentage of people will do work for free. Relying on it is a choice with tradeoffs.
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
I'm actually working on spinning up a service around this (specific to WordPress developers for now). Designed to help freelancers and other developers who are feeling stuck and just want some coaching/advice, specific help on projects or specific problems, or confidence having someone behind them as they take on bigger/more complicated projects.
We've been piloting it with a few people so far and have caught some things early that, if they were built, would have caused some headaches down the road that we were able to help avoid.
I don't know how well that scales or if it applies to other spaces, but I feel like there are people who specialize in different stacks that could offer a service like this as well.
Personally I only use a debugger when there are bugs, but I know some people who debug the code when they are developing to check that it is doing what they want.
If it’s just to improve your craft, I’d say there are lots of ways to learn without peer review. Studying other code based, open source, etc.
But if you’re a founder building your first project, the quality of your code is like concern #999 in the list. As long as it works and the clients are happy, you have better problems to focus on (like how to grow users). Much of HN doesn’t want to hear that, but many (most?) $100m startups were stitched together with duct tape for the first n years. And you know what? It works out fine. You deal with the technical debt later as you need to.
1. Good feedback is hard to get outside of a trustful relationship.
2. Good feedback is important.
Consequently, I think it would be worth $300-400/month of your employer’s time to have an ongoing relationship with a contractor with whom you could do code review and technical coaching sessions with.
I read the code of of my project's dependencies and learn from it. I receive the RSS feed of the GitHub repositories in my email client, read the change log, and very often I'll see a commit fixing a bug or implementing a feature and go check how it was done.
This makes coming up with good solutions a lot easier, as sometimes instead of implementing the solution in your code, you either submit a pull request or extend the dependency, especially if it has a plugin architecture and solve the problem upstream so that the downstream part (i.e: your client code) isn't too crazy. i.e: instead of the solution being maritime and going around a continent, you fix the geography and dig a canal so that the downstream solution is elegant.
You can have the IRC channels in your email client, such as Thunderbird. The Python IRC channel and mailing lists are great: top notch people will go above and beyond to help you. Case in point, here's a question I posted to the mailing list https://mail.python.org/pipermail/tutor/2015-April/thread.ht... (Good Taste Question: Using SQLite3 in Python).
The people who replied were nice, informative, and patient.
Look at that yours truly douche trying to learn PCB design: https://www.electro-tech-online.com/threads/my-begginnings-w...
Refine with every remark these generous members made about the board, assimilate the concept, and practice. My second board for a project was way better, but submitted nonetheless for critique again: https://www.electro-tech-online.com/threads/first-pcb-steppe...
For quick, real-time conversations, IRC and Slack channels. For longer, deeper, conversations: mailing lists or forums.
The point is: put something out into the world, and let the world poke holes in it.
If you don't want to do that, you most likely need to pay consultants to review the code.
