└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # The Way of Code 2 | 3 | To me, programming is not a science but a practice. The 4 | more I write code the less I believe that there are unified **correct** ways of doing 5 | and that the end result is limited not by methods of engineering but by the skill 6 | of a programmer to express their desired form. 7 | 8 | Programming happens in the mind. There is a disparity between what can be *proven*, what 9 | can be *imagined* and what can be *expressed*, and that distance is the experience and 10 | art of the programmer. 11 | 12 | As I try to be a better programmer I've turned toward debugging my mind. Considering the 13 | different states I'm in as I program and being mindful to do each as well as I can. This 14 | has required a lot of experimentation with different tools and techniques from editors 15 | to various forms of meditation. 16 | 17 | I've been programming for about 20 years but have only settled in to this method of iteration 18 | recently. After doing this for about a year I've become a little more confident in my assessments and 19 | am going to start writing them up in this repo. These begin with what I belive are 3 20 | distinct states of mind you must shift between while programming. 21 | 22 | # States of Mind 23 | 24 | I find that I have 3 distinctly separate states of mind that must be engaged when programming. 25 | 26 | * **Vision** - in which I assemble the code in my mind until it is clear enough to express. 27 | * **Expression** - in which I commit what’s in my mind to text as well as I can. 28 | * **Reflection** - in which I look back on the expression in order to understand it in the context of 29 | what now exists in text rather than what had been in my mind. 30 | 31 | Each state naturally flows into the next and these states are cyclical as reflection often uncovers a 32 | new problem, then I think of a solution, then I express it and reflect upon the newly “fixed” state. 33 | 34 | Sometimes these states are long running and sometimes they are incredibly short. During some furious debugging 35 | I might cycle through them all a few times a minute. While other problems I may think about for years before 36 | I have enough in my mind to express. 37 | 38 | ## Vision 39 | 40 | Since this state is entirely mental many of the best tools are away from the keyboard. 41 | 42 | If I have a specific problem I need to work on today it’s best to clear the mind first, meditation 43 | works quite well. Clearing away all the thoughts and anxieties you might be carrying with you means 44 | you have more room to envision the code you’re about to write. 45 | 46 | For longer projects that I think about for months or years, having conversations with friends and 47 | colleagues, reading other people’s code and libraries on GitHub, researching and learning all play a 48 | role in building the vision I want to eventually express. 49 | 50 | While I do not believe programming to *be* a science, science has a strong role to play. Learning through 51 | books and academic papers shape what can be envisioned. For instance, without understanding how certain 52 | cryptographic techniques work you wouldn't know how to apply them to solving a particular problem. Part of 53 | my practice is continually learning about these things but I might also dive in to specific areas of research 54 | in order to build the vision for a specific problem, or I might have a problem in mind for years and only 55 | recognize the missing piece when reading something new in white paper. 56 | 57 | One thing I’ve learned not to do is try to write before I have a clear vision for what I want to express. 58 | The process is frustrating and ends in very poor code if I’m thinking of the expression as I write it. The 59 | best way to write code is often to stop typing and fully consider what needs to be typed before moving on. 60 | 61 | Coding is not an "act" it is a process and the most important part of that process does not include typing 62 | and might be happening while walking or making tea. 63 | 64 | ## Expression 65 | 66 | As I've gotten better at acknowledging and separating these states of mind the tools I use during expression 67 | have changed the most. Since I'm not learning as I type, since I'm not imagining what I want to type as I type, 68 | since I'm not correcting errors as type, the tools that help in those tasks have had to be thrown away. 69 | 70 | An editor I can write fast in is a must. Anything I see visually as I type other than the code will draw my 71 | attention away from the expression and interrupt my flow. 72 | 73 | All the features people add to editors in order to reduce errors need to be turned off. I want errors to go un-noticed 74 | while I'm expressing what is in my mind. I’m often writing code for variables and functions that do not exist yet. 75 | I even turned off syntax highlighting, as I can’t help but look to the highlighter as a sort of error check. Anything 76 | that draws my attention interrupts the flow of expression. Most programmers have had sessions or at least moments of 77 | intense flow and we often are trying to re-produce those flow states, but it's not until I started removing all the 78 | tools we use to "help" us program that I realized how much they interrupt that flow. 79 | 80 | It is not necessary in this state of mind to build confidence in the accuracy or runability of the expression. 81 | The primary purpose is to move code from your mind to text. Build confidence in the expression 82 | once it’s out of your mind. 83 | 84 | ## Reflection 85 | 86 | It starts with just reading what you’ve written. Correct all the tiny and obvious mistakes first. 87 | 88 | Now lint the code, run the code, run any tests, build confidence in the expression. 89 | 90 | If there’s a big problem, shift to envision the solution. If it works, envision the tests or documentation. 91 | 92 | # Tooling Theories 93 | 94 | Different states of mind lend themselves to very different tools. 95 | 96 | While I've turned off syntax highlighting in my editor in order to improve my ability to express it makes the editor 97 | a poor place to center learning and debugging. I mostly read code on GitHub where there is excellent highlighting and 98 | other tools. For debugging I now rely on a variety of command line tools to point out where the issues are rather 99 | than integrating them into my editor. 100 | 101 | Now that the editor/IDE isn't the central dumping ground for all tooling I'm much less dependent on a specific 102 | device or environment. I do all of my development in a remote docker container. As I take on different tasks 103 | I can spin up different machines or tmux sessions suited to the task. 104 | --------------------------------------------------------------------------------