tips.md

• plan for code that is easy to delete/replace rather than code that is easy to extend or reuse. As needs change, you're more likely to change the assumptions about what the system should do than in how many ways it should do it. If the code needs extending, it's then easy to replace it with a bit that's easy to extend
• planning for code that is easy to throw away is the best way I've found to properly bake in abstraction and isolation. The question is always "if I take this shit out or change its implementation entirely, do I need to replace anything else?". If the answer is "yes", then you may be leaking into other components. Fix it. turns out when you have that, it's also suddenly easier to reuse code.
• write a prototype of whatever significant task you have to do, and consider it a draft. Use it to figure out requirements or to make your first mistakes in. Throw it away. Try again. As I gain more experience I find my prototypes smaller and individually more solid, but anything where I lack experience tends to get thrown away because of very serious assumptions I had made without realizing it.
• it's better to fail early and loudly on a few records than slowly corrupting data over thousands or millions of them. It's easier to replay an action or reimburse a customer than realizing the books were wrong for years.
• don't optimize for programming speed, optimize for understanding speed. You end up putting a fuckton more time in trying to understand code than writing it the first time around
• you should spend time maintaining code, both yours and the code of others. It's less fun than writing new code, but it's way easier to learn what not to do if you do maintain code bases. Senior devs that can just spend their time shitting new code for others to pick up may not improve their maintainability a lot
• technical debt is something I prefer worded in the Quebec slang equivalent of 'pelleter par en avant', or 'shoveling forward' (with reference to shoveling snow in your yard, and just pushing more and more in front of you). The cost is not an aside you eventually have to sit down and repay, but a progressive accumulation that keeps making any progress harder.
• Global variables are one kind of thing that can break your programs by spookily changing things at a distance. More insidious are entrenched implicit design decisions. Sometimes, an accidental (or at least non-explicit) technical decision has been made and relied on by other components, and there is no way to find about it in code. Documentation or peer experience is the only way to get these aside from diving in the code system-wide to get a good global view of things (and this is costly, may take months to do)
• the easiest way to change a component into a legacy system is to have one person in charge of it with no code reviews. Diluting ownership a bit makes it easier over time for knowledge of it not to die. If people know how the system works, it's not yet legacy and it's a good time to clean it up.
• if a system runs forever without crashing, the day it is restarted or needs to be is going to be terrible
• in a MVC architecture, an ORM is not a model, it's a middleware to make models easier to write. keep your ORM out of my controller
• you can't fix a bug or refactor a system you don't understand. Understanding the problem and the code base is step #1 every time.
• if you're in a codebase without tests, write tests before refactoring or patching things so you catch some of the unexpected side-effects you'll have. This does tend to lead to huge hulks of terrible tests because codebases not intended for testing just have that effect. Eventually you can rewrite the code to be testable, and then rewrite the tests again.
• blaming a library or a compiler for bugs almost invariably leads to useless energy spent trying to blame someone else. the bug is almost always in my own code.
• testing shit on a crappy computer shows load issues a lot earlier than on a powerful machine. Testing or developing on underpowered hardware can actually be pretty helpful.
• when you think of running a cronjob, ask yourself why couldn't you run it every day, hour, minute, second. Is there a way to just do things live? The fewer cronjobs you have, the easier capacity planning and operations become. There's no fun trying to debug scheduling of cronjobs for long running tasks when they start creating contention issues against each other and bleed through your day
• have back ups. Have a playbook telling you how to restore them. Have playbook practices so operational knowledge isn't siloed to one or two people exclusively.
• simplicity, brevity, and understandability are not the same thing.
• writing tests first is the only way I don't half-ass tests
• I still use a pen and paper to draw diagram and solve my problem by hand before touching code
• ask someone to review your stuff; they don't have the same context you do and will find questions or alternative ways better than yours
• predictability is fucking great to have. I don't care for the fastest system if I can have an okay one that is reliable on these figures. There's nothing better for operations than well known operational boundaries.
• take a break. When you're tired and you can't see clear anymore, you'll spend 10x the amount of time you'd spent if you take a break and come back later. Knowing when to pause and recuperate can really help a whole damn lot for overall productivity.
• Know when you're out of your element, and go read books, papers, blog posts. Gain experience indirectly by people who solved these problems (or similar ones) before you did. It's invariably easier than rediscovering it all by yourself.
• also http://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html