Three behaviors that resonated with me were #6, "Understand that code is cheap," #15,"Don’t count the number of hours," and #29 "Move Fast and Break Things."
#6
"But the experience gained from writing the (bad) code was actually the “output” vs. producing shippable code. It was simply part of the process that ultimately led to the result." This perspective really resonated with me because it highlights how much of coding (and essentially life) is about learning through the process. A lot of times you have to try what doesn't work in order to find what does, and this wayfinding isn't a waste of time at all because it leads you to the right answer.
#15
This one actually got me excited because of a lot of the work I was doing in my previous work was "shallow work." I'm exctied to have a career where I can get away from that (answering emails, meetings, mostly administrative tasks" to where I can do "deep work" everyday and really challenge my mind by learning and getting better at a skill everyday. I also feel like when you are doing administrative work it's VERY easy to get distracted by things like browsing the internet, texting, or responding to every ping from your phone because your brain is already is such a shallow mindset it's so east to switch. But deep work involves concentration that is so much more intense it takes lots of energy to get out and get back in, so I would think that shallow distractions would be less tempting to indulge in. I'm looking forward to having less of these distractions and a more stimulating career.
#29
I like this one because it basically says don't be a perfectionist, which is something I'm constantly working on in work and life. Don't feel bad for using a "horrible hack" because there are literally not even close to enough hours in the day to do everything you want to accomplish.
-
The big takeaway the author makes about checklists is that even experts with years of experience mess up routinely, and having checklists can greatly reduce these errors. Keeping checklists applies to beginners too because they can help establish a good routine and way of thinking. I think a checklist will be useful as a beginner developer because it can be used to set steps in how to think through a problem. When creating a game in the techical prework, it was hard to read the problem and then start coding. But having a checklist of things to do, like using pseudocode to logically verbalize the problem, then break up the problem into smaller steps and go mini-problem by min-problem. This helped make the larger problem more achievable and when I needed help from others I had specific questions to ask about a mini-problem I was working through.
I was initially a little skeptical of a strengths-based development, but I hope that my skepticism can be answered because it sounds like a really positive way of thinking. My questions are: How do you forms team solely from strengths of you don't take into account team member's weaknesses? What if everyone has similar strengths at a company, how do you assess who gets to work on the best project? What would a performance review look like? And how do you distinguish weaknesses from something you can work on and change? I'm not sure what my strengths will be within software development yet, but I know my strength from my last job was communication and directness. I know this because of feedback on performance reviews from my managers. I hope to develop my strengths at Turing by really learning how to work on a team and being assertive on it.