[HN Gopher] Ask HN: How do solo devs get feedback on their code?
       ___________________________________________________________________
        
       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.
        
       Author : guinness74
       Score  : 15 points
       Date   : 2021-03-28 17:48 UTC (5 hours ago)
        
       | devoutsalsa wrote:
       | 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.
        
       | segmondy wrote:
       | 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.
        
         | quickthrower2 wrote:
         | 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.
        
         | tonyedgecombe wrote:
         | 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.
        
           | afarrell wrote:
           | > 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.
        
       | verdverm wrote:
       | - 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?
        
       | melenaos wrote:
       | 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.
        
       | corry wrote:
       | 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.
        
       | lewishogan wrote:
       | 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.
        
       | papaf wrote:
       | 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.
        
       | foreigner wrote:
       | 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.
        
       | PartiallyTyped wrote:
       | 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
        
       | itwy wrote:
       | Your future self.
        
       ___________________________________________________________________
       (page generated 2021-03-28 23:02 UTC)