| Not the GP but I've been in a similar position: - Be good (and fast) at Googling things. - Know your foundations, deeply. Don't memorize design patterns and algorithms: instead, learn how to arrive at them organically and how to analyse and understand them. - Avoid overengineering like the plague and stop seeking perfection. I've seen lots of teams of "1x" engineers fail because they're too worried about peer approval, so they end up trying too hard to arrive at the "perfect" solution. And then business changes its mind and they have to rearchitect everything. - Accept that business people will change their minds and design your software around it. The world doesn't revolve around your precious codebase. If the higher ups want to change something, you have to do it. Your codebase should have been malleable enough for a 180 degree pivot. - Stop chasing unicorns. Yeah, maybe Vim will give you that extra 10% edge you need, but if you're comfortable with Atom, why change? - Keep it simple, don't be clever. Only use the subset of the programming language that is free of "gotchas". What's the output of `[].push(1)` in ES6? Who gives a shit? Keep that stuff out of your code. - Learn to evaluate if using an external dependency is actually faster than writing something from scratch or just copying some code. Sometimes it isn't, and people miss out on having simpler code, simpler interfaces AND learning new stuff because of that. Of course, you're not going to do that with a crypto - Avoid things that might slow you down. The CI taking 30 minutes to run or the compilation taking 10 minutes are a sign that you're doing something very wrong and too complicated. -- As for practical recommendations: - A single integration test is better than multiple disconnected unit tests that have the same coverage. It allows you to change your code without changing the tests. - Avoid transitive dependencies in your classes/functions by using simple Dependency Injection. Just pass those dependencies as a parameter or whatever. This will help you have units of code that are more testable, more flexible and don't require maintenance. Also you don't need those mock-in - Make code simpler to read and to debug. Avoid reflection, metaprogramming and stuff like that. Don't do things that require magic. |