11–20 of 209 posts
1. Make lots of mistakes. 2. Experience pain in the form of late, buggy software and angry clients. 3. Read books and work on side projects. (Martin Fowler’s were my favorite). 4. Repeat for 5-10 years with hopefully ever-decreasing amounts of 1 and 2. You probably think I'm kidding...
5. Ideally, make _unique_ mistakes.
If you made the same mistake twice, then you were in trouble.
Emphasis on GitHub repos: you can learn a lot of good practices and efficient solutions in open source projects somewhat related to your problem domain.
There are a lot of famous books on the subject of best practices: "Code Complete" and "Clean Code" are the first to come to mind, but I'm sure the folks here can recommend others.
Pragmatic Programmer: http://amzn.com/020161622X
Code Complete 2: http://amzn.com/0735619670
Blog posts other developers make detailing the way they've built a particular project have helped me gain some perspective when looking to understand how people are working in a particular stack. Learning from other projects is good for understanding how people are using contemporary tools. Github is also a great source for this, you can search with those tags to find relevant projects. As for software engineering in…
The hard part is finding the right blog. There are a ton of blogs out there from developers with little experience who are convinced that their way of doing things is the best/only/right way. The blogs are often nothing more than SEO for their resumes.
For that reason, I'd lean heavier on books. At least with books there is some filter. Yes, it can be incomplete and sporadic, but it's often better than the wild west of bad information out there, especially in web dev blogs.
Take Mongo for example: is the issue that your database keeps going down? If you frame it that way, it doesn't take long to discover clustering, replicasets, and monitoring. Is the issue that your queries are hammering the server? If so, googling that leads you down a months-long rabbit hole that ends in indexing, caching, and denormalizing strategies. Are you frustrated with the amount of boilerplate needed to get mongo data to the frontend? That's a good hint that you're in the market for a library/framework that might help with that.
Much in the same way that one of the hardest parts of solving a bug is knowing what to Google, specifically defining what "better" looks like is the first step towards getting there.