On being a good programmer.

on being a good programmer.md

1. Your code will fail, no really, with 100% reliability. Only those who plan for failure don't become subjected to it when it occurs. Why? It's a so-called-mental-modal, when you're programming, believing your code will fail, and it will, often causes you to place better error handling, assertions or write unit tests to help diagnose a failure, not prevent it. Some of the nastiest bugs in the world are those which are not reliabily reproducable, or hard to track down the CAUSE of the bug. You'll find yourself spinning your wheels for weeks if you don't plan for how you will debug problems.
2. Use assertions on all inputs to a function/method to check the semantics and validity (or, type, if javascript). Doesn't really matter how trivial the assertion is. And it doesn't matter how small the code base, it could grow. Why? When errors occur, they don't propogate the error, this makes it infinitely easier to find the source of the problem, rather than backtracing from some side effect bad input caused.
3. The best way to find examples of a library of code is in the unit tests. Also, if the code does not have tests, its not the worst idea to consider a different library. Why? Unit tests must succeed with some sort of meaningful result, examples in unit tests tend to be the best practice or correct way of handling it. They're very useful as they give you an idea of what the author expects people to do with it, and not how you're using it.
4. Everyone sucks at management. Management is much more difficult than you'd think. When developing software manage the projects with your own Discovery, Planning, Design and Develop mentality to force your mode of thinking to be broad enough to find obvious defects in an approach before you start implementing it. But also, put a time cap on each of the activities so you don't begin to do too much planning/design before you jump into the code.
5. Divorce your ego from your code Why? Your code will fail, if you place pride in it, when someone brings up a valid bug, you WILL become defensive, no matter how hard you try not to be.
6. Divorce your capabilities from your estimates. Be sure when on a team not to quote the amount of time you think it would take you but the amount of time it would take your team.
7. Always state at the beginning of a class what it does not do. Why? It helps focus what DOES NOT belong in this code. This is a much clearer way of communicating to others how they should use the class then saying what it DOES do.
8. Always be kind and respectful to people. The biggest failure in your career will not be a faulty deploy, a defect or a data loss but ruining the relationships with the people you work with. This is the ONLY thing i can GUARANTEE will get you fired at any job (outside of complete neglect or malace).
9. 90% of performance problems come down to a cache miss. Why the cache is missing (or if it even intended to ever try and hit!) is a different story. Cache's are beautiful, but execution time tends to rise very quickly after L1.
10. Be aware of the cost of new technologies, regardless of the hype, you should always know WHY you're using a build tool or framework, and know WHAT you'll loose because of it. Think critically about these things, they'll save you so much time. Why? When a build tool or framework immediately solves a problem for people there's always a strange mental disconnect that happens after where they become almost blind to the costs it has. Critically argue with yourself over the potential downsides of any tool/framework/library before you adopt it, or write your own.
11. Your feedback loop matters, alot. Having a quick feedback loop where a change can nearly instantly be seen is one of the most valuable productivity tools developers have. Even if your jade templates only cost you 2 seconds on a refresh with live reload, consider you'll be doing 190 of those refreshes a day (i've counted), and you've lost 380 seconds (or 6.3 minutes). This may not seem like a lot, but add in other build steps or transpilers and that number (on one project i've worked on) suddenly jumps to a 12 second delay. Inadvertantly, by adding seemingly banal build steps, i've lost 38 minutes of my day. Or almost 4~5 hours a week. Now consider a team of 20 working on a project, that's a lost 80 ~ 100 hours a week for the team.
12. Always process or wait for data on a seperate thread Why? See the origins of nginx or node.
13. Ship as soon as you possibly can, even if its only good for one person But, realize, i mean ship to that one person, don't force a non-mature product on everyone else. Why? This is so useful as a good feedback loop early in development helps remove features that were useless or focus your attention on problems that you didn't know were there.
14. If a class or function can be broken up and each new part can be tested independently, break them up. With the caveat that it should be kept private to the other function, if you cannot don't break it up. Reason why is people will break stuff by taking short cuts in code and using a helper function that seems to only do one thing when it infact does a lot more, and maybe they dont' know it.
15. If a portion of a class or function could be swapped out with something else that adds functionality, do it.
16. If a library requires a library to function, its not a library. Libraries should have no dependencies. Frameworks, build tools, components, and applications might, but not libraries.
17. Any software library can have too little functionality to be useful, but can also have too much functionality to be useful.
18. Avoid coupling your software: Look at your using/import/require for guidance
19. Laziness is your best friend when developing, make your programs work for you. Do not work for them. Software should serve humans, not the other way around. Make your software (regardless if its a command line utility, library, or otherwise) be forgiving and do what ever it without needing to ask for information or interrupt the user. (e.g., assume values and prompt for agreement). See Microsoft Outlook vs. Apple Mail setup screens.
20. Learn how to learn; define your expectations, when they're wrong, readjust them but also consider why you had those expectations in the first place.
21. Ask yourself every morning in the mirror if this was the last day on earth, would you want to be doing what you're doing? If the answer is no for more than a week, change jobs.
22. Like english, if you can write shorter code, without being confusingly clever, do it.
23. Whenever you initialize a class, all members of that class should not be bound by time or convention. Or, your code needs a better relationship with its data.
24. If you cannot describe what a function or class does, VERY SIMPLY, and not in a FactoryFactoryBeanOfCupOfCoffeeDelegate then you're probably doing it wrong.
25. If your function calls a function, you're might be doing it wrong.
26. Deep call stacks are generally a good indicator to how complex a system is.
27. Code that generates code is insanely powerful, but really dangerous. Don't use it without unit tests.
28. Debugging without stack traces When you have no idea where a problem is, comment out half the code, if the problem is in that area, keep going.**
29. Common problems with inheritence You might need to inherit from more than one thing. A class may sometimes need to morph into two different classes, that are mutually exclusive... If a base class changes, the entire chain of subclasses may break.. What if i only need 1/3 of the class methods?
30. HTML/CSS: Seperate your css/classes into paint, layout and composite classes
31. Organize your code by features, not by language Because anyone stepping into the project will always think about it as features, not as what language it was programmed in. Filetypes can handle the language part just fine.
32. Use a central logging system. It really does help when debugging distributed systems.
33. Do not do inserts or updates, do upserts. Don't have separate code paths for insert vs. update on SQL only!, use upserts.

Prune and delete data. Someday it'll get too big (NTP)

Don't use database links, implicit hidden behaviors are bad mmk.

Motivation is key to being a good programmer

Don't ever try and build the best system; start with something extremely small and try and make it great, then try again with something else. Before you know it you'll have something amazing.

https://biarity.gitlab.io/2018/02/23/passwordless/ good example of one solution creating more than its fair share of problems.

Advanced beginners tend to get stuck in the habit of over abstracting in pursuit of "Great Design", Senior programmers can sniff out when there's a reason for abstraction and when you shouldn't to save time. https://hacksoflife.blogspot.com/2018/08/solve-less-general-problems.html . Abstraction is a maintenance tax.

you'll write more code in tests than you will in the actual functionality

State your assumptions, and find MORE than one way to assert and test them. If somehow there's a disagreement in what you assumed vs what you receive, bail out, and quickly.

• Use connection pools for databases
• Always reuse your http agent if you're making out-going API calls on an API.