Ask HN: How do solo devs get feedback on their code?
28 comments
Write a blog post about:
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 :)
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 :)
This is the correct answer.
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.
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.
> For solo devs working on a closed source codebase, how do you get feedback on design and implementation decisions?
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.
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.
- 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?
- 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 just raise a PR with myself as the reviewer. It works most of the time but it can get pretty heated when I have arguments with myself over code styles and test coverage.
We don't. Unfortunately this is one of my problems for been solo developer. I also don't have anyone to discuss the features and the architect decisions i need to take.
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.
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.
Spitballing here. Read other codebases, read books about patterns and practices and architecture, read language and library documentation, and then go back and re-read your code?
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.
Not by a long shot! How is this going to teach you new patterns and practices, better ways of coding and structuring your code? At best this will find you easy to detect bugs.
There's a much quoted aphorism with regard to getting feed back on fiction:
"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.
"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.
The most useful feedback will come from customers. If you have a bug or are missing a feature they will tell you.
What is harder is dealing with architectural issues but I'm not convinced they are that easy to avoid in a team environment either.
What is harder is dealing with architectural issues but I'm not convinced they are that easy to avoid in a team environment either.
> If you have a bug or are missing a feature they will tell you
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.
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.
People don't report it for free, they are hoping for a fix in return.
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
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 used https://www.pullrequest.com just to pay someone else to look at my code and make suggestions. Aside from just the normal nitpick styling stuff, they usually have decent architecture suggestions and help you avoid making costly mistakes. It's not cheap, but my project is a full time effort that makes money and I found it worthwhile.
The answer is literally don’t work alone. You’re code is your baby. How do you get someone else to raise your baby? Make it their baby, too.
Anecdotally, for myself I've just been able to talk about my code with some trusted friends in more general terms, to get around not being able to share proprietary code and have gotten some good ideas that way.
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.
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.
I have been in this position a few times and I recommend using static analysis and linters e.g FindBugs for Java, CppCheck for C++.
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.
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.
I’d say it really depends on WHY you want feedback. And perhaps who you are / what the code is doing for you (fun side project to build your skills vs MVP of your new funded startup).
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.
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.
I have found that the best way to get feedback on anything code related is to draw it with a diagraming tool with as much detail is possible. Label each part of the diagram in some logical order and then include a brief description of each step. Posting a labeled diagram with a repo gets 10x engagement and feedback compared to just posting a link in my experience. My favorite diagramming tool is diagrams.net
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.
I think:
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.
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.
Your future self.
Mailing lists, IRC channels, Slack channels, and various channels of the stack you're using. i.e: language and other components and dependencies of your project. StackExchange network works, too. (i.e: StackOverflow, ServerFault, etc.)
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.
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 it's working on a closed source code base, I think you're not going to find many other options beyond looking at similar open source projects online, or finding and evaluating the merits of different design patterns.
I have mostly received feedback when I post parts of my code on stackoverflow with queries. (Sometimes, all I get are downvotes and an autocomment that my post is locked for not being good enough. Even that helps.)
you can create prs for your own work and review it yourself on a different day. or possibly get a mentor and ask them? i don’t have a mentor so idk
Open-source projects allow you to get feedback and hopefully contributions to a code base. You need to like open-source and have other people want to contribute to your project.
If you don't want to do that, you most likely need to pay consultants to review the code.
If you don't want to do that, you most likely need to pay consultants to review the code.
In the past, I've asked friends in the field I trust, but I'm wondering if there's a better option out there.