Ask HN: How to learn best practices when you have no one to teach you?

By the time things have been reduced to "best practices" the intellectual rush of discovery has been cooked out. If you a still fishing for best practices: experiment, make mistakes, fix, learn how things work, run tests, try things that make sense first, talk through problems with smart friends, and enjoy the fruits of discovery. It is often helpful to find a mentor, someone who can help structure the search for "best practices" and who will give advice.

>>Don't worry about good code at a startup.

Totally depends on the startup. Building a new blog engine? Sure, go wild. Making financial software? You need to be very careful, and write good, secure code.

My advice would be not to worry about this too much at this phase. A lot of "best practice" is institutional and has to do with how the stack/org/community is structured. There's not a lot that's "best practice" in a vacuum. In terms of stuff that would be considered best practice in a vacuum, you can maybe look at some of the classic stuff like Code Complete, or any of the TDD or pattern books.

Other people have mentioned that "best practices" can be a double edged sword. Software engineering is very varied and it's hard to abstract out "best practices" that apply in all situations. Don't get blinded by "principles" and evaluate each technical situation on its own merits and weigh the tradeoffs of the solutions you can think of before proceeding. There are way too many variables for you to have a playbook that reads "in x situation do y" most of the time.

With regard to best practice being institutional, you'll formulate a lot of it on your own as the org grows (if it does.) For example, having code reviews would widely be considered a best practice across the industry, but in your situation it is obviously not reasonable. Who would review your code? You? Lots of institutions have style guides for software engineers (I would consider this a best practice) to keep software easily readable to as many team members as possible. In your situation, what engineers are you trying to keep on the same page? None? In your case, this is then not a useful best practice.

There are community best practices that sometimes spring up around quirks of the language and its tooling. I would say the best way to deal with the first is to use a lint. That will teach you a lot. The second is something you usually have to get bitten by to find out.

Finally, read a lot of code in your language/framework of choice (critically of course.) You'll learn a lot of tricks, and will also see a lot of traps to avoid by doing this. If you're in Node, reading the source to Express is probably a good place to start and is obviously applicable to your work (and can only pay dividends in that respect.)

Problem solving doesn't work like that. Many comparable issues have been found and solved by different people at different times, in parallel, unknown to each other.

With as many people as we have on Earth it is unlikely that one special unique problem can only be solved by one special unique person. While it might happen, it's unlikely to happen to a software developer at a small company. The problems and solutions you find there are often relatively comparable or even generic, and are found and solved by many people in parallel at the same time. While working together might be faster, it has nothing to do with the feasibility of detecting and repairing issues.