The most carefully-constructed, architecturally-pure piece of code will still break in the face of future requirements. And in a surprising number of cases, it will break on the <i>very first</i> new requirement. Keep it straightforward and get it done.<p>You will almost never be working on something so performance-critical that it truly needs cleverness and super-optimization. And you will rarely have time to properly <i>measure</i> a particular thing anyway. You <i>will</i> be expected to frequently change things and super-optimal code is a pain to modify.<p>You will work with programmers with a variety of skills and it will often be impossible for them to maintain things of moderate complexity. Or, your team will be using ancient tool versions that <i>can’t</i> reliably do the spiffy new thing in the language. Again, straightforward code wins.<p>When you write a test, first set up a case that fails to make sure your test can actually catch a failure. Too much time is spent debugging things because tests “pass” when the tests themselves just weren’t doing what they meant to do.<p>The code is king: put everything you possibly can in there (comments, etc.). Don’t let people set up external documentation that no one reads, because it becomes wrong/misleading within a day. If you <i>must</i> have things outside the code, they <i>need</i> to be revision-controlled alongside the code, in the same repository.
To stop being obsessed with pointless BS and actually finish something. Even if it's terrible.<p>Also, that I would <i>deeply</i> regret going to school to learn progamming once Udemy became a thing.
Here are some<p>>Yes I am a programmer, stop questioning it<p>>Stop avoiding learning to make macros and job automation, it will pay dividends<p>>Javascript is fine, not great.<p>>Embedded systems should be my full-time hobby<p>>Stop avoiding capitalism and start charging money for my otherwise free products.