This article resonated with me on so many levels. The concepts of becoming obsessed, re-framing, not eating junk and the ten
tab rule are all ones that I have actually utilized in the past and in my current profession. The idea of creating a
checklist to cut down on error correction time, though suprisingly simple, was a bit of a revelation to me! I know I'll be
discussing that more in the next reflection so I will pause on that for now. Similarly revelatory was "always be listening".
I recently had my own epiphany that I could utilize more of my time reading by incorporating audio books while
walking/working-out/cooking and thereby increase my input capacity. The idea of doing the same thing with coding podcasts is
something I'd like to immediately incoprporate into my pre-work process. Overall these 8 methods feel very natural for me
while also giving me ideas for further implementation.
As I had mentioned in the previous reflection the checklist concept has hit me like a freight train. This reading only further inclines me toward the possibilities and practicle applications of checklists. One of the aspect that really stuck with me was the concept of creating the checklist out of your 10 most common mistakes. I cannot fathom how many times this would have been useful to me in previous professional situations without having to rely on inperfect memeory and limited experience to suss out issues. Simply the idea that, as the tasks we are asking ourselves to complete are multiplying in both number and complexity, we have to embrace the idea that we are falible humans and implement strategies that take some of the onus off our already overtaxed memories. This has clear cut implications for me with regard to my upcoming time as a student. Not only in keeping priorities and deadlines straight but in sorting through the variety of concepts and languages we're going to be exposed to in a relatively short period of time. In a similar vein, upon entering the field of development I imagine checklists will be vital to not only stay organized and on track but to avoid wasting the time of fellow developers or clients. It is a tactic I am thankful to be exposed to at this early stage.
Overall, as an individual just starting out on this path, these behavior all seem like advice worth heeding. Items such as "use google aggressively", "say, I don't know" and "take responsibility for your mistakes" are ones that I have always tried to employ in previous professional situations. Those are the skills I'm hoping to translate into success in the field of web development. Others were unfamiliar and resonated deeply. "Understanding that code is cheap" is one that is going to be extremely important for me to internalize. Scraping hours of work to start on a fresh and ultimately better approach is something I know will be difficult but absolutely necessary and highly effective. To me this is effectively linked with "don't count the number of hours" as well. Spending the majority of my time in 'deep work' seems like the best way to get better and work at a quality level. However, rectifing all that deep work with remember that the product of that work is 'cheap' and can and should be utimately replaed if there is better code is a concept I will be committed to working toward. Lastly, "move fast and break things" resonated with me on several levels. Utlizing failure as a learning experience but being able to optimize moving forward to not repeat mistakes is something I aspire to. Becoming comfortable with failure in general will be a large part of my journey at Turing and in the world of coding. I like the spirit of this behavior and hope I can live up to its ideal. Regardless I'm sure I will be breaking a lot of things and at a certain point learning is inevitable.