Here is some insight that has helped me, some my own advice, some paraphrased from other sources, and I credit the source when I have it in my notes: - There i

Here is some insight that has helped me, some my own advice, some paraphrased from other sources, and I credit the source when I have it in my notes: - There is no "silver bullet" for managing the complexity of user needs. Instead, (good) software is characterized by not a static state of "solving the problem", but a continuous refinement-- an existential struggle against incidental complexity. - Have a very positive mindset, and inspire the same in your team. - highly reliable websites for small companies: http://www.kalzumeus.com/2010/04/20/building-highly-reliable-websites-for-small-companies/ http://www.kalzumeus.com/2010/04/20/building-highly-reliable... - Learn your debugging tools well: Get good at Chrome Debugging tools, pdb, visual studios debugger, or whatever the debugging environment is for your project. - “… never consider your education complete or your opinion above questioning regardless of your title, your years of experience, your awards and accomplishments, or anything else that isn’t rational argumentation or evidence. Retaining a healthy degree of humility, constantly striving for improvement, and valuing objective metrics above subjective considerations will go a long way ..." (http://www.daedtech.com/how-software-groups-rot-legacy-of-the-expert-beginner http://www.daedtech.com/how-software-groups-rot-legacy-of-th...) - This is a marathon, not a sprint. - Practical engineering advice: https://www.quora.com/What-are-the-best-kept-secrets-of-great-programmers/answer/Jens-Rantil?srid=V3G&share=1 https://www.quora.com/What-are-the-best-kept-secrets-of-grea... - Read books. I can especially recommend Refactoring by Martin Fowler and The Pragmatic Programmer as a more introductory text (affiliate links: http://amzn.to/2ekPnTL http://amzn.to/2ekPnTL and http://amzn.to/2ekJQMK http://amzn.to/2ekJQMK). Understanding why and how to do scrum effectively is really important too -- I waited too long to read a book that laid that out for me (http://amzn.to/2ekPxul http://amzn.to/2ekPxul) - Good programming advice from Kent Beck: https://www.facebook.com/notes/kent-beck/mastering-programming/1184427814923414/ https://www.facebook.com/notes/kent-beck/mastering-programmi... - Eventually, you will have to choose between engineering management and continuing to be close to technology. Trying to do both is a recipe for burnout. Some people might be able to do both simultaneously without trouble, but you're probably not one of them. - Always be looking for ways to remove yourself as a bottleneck. This needs to be done both on a technical level and on an organizational level. - Push back as necessary against demands of your time and energy that are not in harmony with your needs as a technologist. - Good programming comes from good habits. (in that vein: copy-and-paste is the devil.) - Seriously, read books. It's incredible how much good advice is out there.