We worry too often about what will happen when it breaks. What if it’s not perfect? What if it’s not seamless? Make it break. When it’s broken, you have to fix it, you have no choice. A car with a punctured tire is very different from one with a slow leak – the slow leak keeps you going to the gas station to get it refilled, a puncture forces you to fix the root cause.
The best thing about writing code is the immediate feedback. It works or it doesn’t. Your code pumps out oodles of value or it returns bugs. Bugs are great, they never go out of style and you get the same level of response to what you are doing – immediate feedback as to whether you’re on the right path or the wrong one. Never fear the bug, fear the program that has no bugs.
If there was a definition for being overqualified for an opportunity and still getting the job done, it is this video. Don’t forget to have fun. https://youtu.be/RvatDKpc0SU
The simplicity of this statement is that you are trying to do something and figure out what went wrong. try { // Try to do something } catch { // What went wrong? } The part not listed is the finally clause, which sometimes I think should be called “Again” as in – try again, don’t give up – don’t stop. It’s like the teacher saying “Again. Again. Again” – until you have it right.
Checklists are great, I use them infinitely all over the place. But where they fail (and fail me) is the reorganization of said lists based on priority changes, based on workload changes, based on what I’m doing changes. This is where AI could do something useful to help out – reorganize a checklist against what I already have going on in my life. Adjust, refine, redistribute – until then, I’ll keep doing it myself.