From 69f2145960c2bf8f71a06298fc5bca1ed99a0c56 Mon Sep 17 00:00:00 2001 From: Craig Maloney Date: Sat, 1 Sep 2018 12:51:17 -0400 Subject: [PATCH] First pass on journaling --- chapter03.md | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/chapter03.md b/chapter03.md index 547fc7e..465109e 100644 --- a/chapter03.md +++ b/chapter03.md @@ -22,8 +22,6 @@ The best (and perhaps only) way we learn is by making mistakes. Learning by maki We need environments where programmers can safely learn from their mistakes. We need spaces where programmers can feel good and confident about trying new things. We need places where developers can try out their ideas and not have those changes ripple out to other unrelated systems. This is the best way that developers can learn and be brave in their learning process. -#### FIXME - These environments must model the target systems, and they must be as close as is practical to those target systems. That doesn't mean you need to make exact copies of expensive production environments but you do need to create models of production environments that test most of the pieces your code will come in contact. Having models that mirror production systems means that when you move your code to production you'll introduce fewer changes with unintended consequences. Your changes will have already existed in a production-like environment. You can take comfort in knowing that the changes you enact in these models will be the same changes that will appear on the target system. Ideally you'll need to have an environment like this on a machine that you control. This means that you're not competing with other programmers in your organization who are also being brave with their changes. But you'll also want to ensure that you keep your environment up-to-date with their changes (and any production changes) so your development model matches what's on the target system and what will be on the target system. A good model is one that is kept current with what it is modeling. It's the same as a map of a city: it's best when it matches the area its modeling and is kept current with changes that occur in that city. A good map of the city might tell you about the recent construction happening on your route. A useless map doesn't even show your route because it wasn't built when the map was created. If our model of production is constantly falling behind what's in production we will spend more time rectifying the changes that we're making with the changes between our model and production. @@ -42,26 +40,25 @@ Revision control can also play a role in seeing the development of the code of o ## Learning from failure -Sometimes we fail. Sometimes the code that we wrote isn't up to the realities of the system it's implemented on. Sometimes we push code that does something that we didn't expect and does any number of things. In all of these cases it causes discomfort, whether to us, the folks we support, or the folks we work with. +Sometimes we fail. Sometimes the code that we wrote isn't up to the realities of the system it's implemented on. We push code that does something unexpected and systems break as a result. We can lose track of where we are in our code and make changes that conflict with other changes and cause us to spend the rest of the afternoon undoing those changes. In all of these cases it causes discomfort, whether to us, the folks we support, or the folks we work with. -I'm not going to lie: failure sucks. It makes us feel like we're less of a person because we failed. We feel inadequate and wonder how others think of us. Do they think less of us? Have we damaged our relationship with those who use whatever we've programmed? Have we let our team down? All of these questions come at the forefront and they all stem from two desire: a desire to do our best and desire to do no harm to others. We want others to think well of our skills and of us. Failure runs counter to those desires and amplifies whatever feelings of inadequacy we might have. We wonder if we should be programming at all or if our talents should be used elsewhere. We feel like giving up. +I'm not going to lie: failure sucks. It makes us feel like we're less of a person because we failed. We feel inadequate and wonder how others think of us. Do they think less of us? Have we damaged our relationship with those who use whatever we've programmed? Have we let our team down? All of these questions stem from two desires: a desire to do our best and desire to do no harm to others. We want others to think well of us and our skills. Failure runs counter to those desires and amplifies whatever feelings of inadequacy we might have. Those feelings can include wondering if we should be programming at all or wondering if our talents should be used elsewhere. We wonder if we should just give up. -We don't think of failure as part of the learning process. Failure is often seen as the end-point of the journey. In school a failing grade is seen as a condemnation. We don't see it as "I need to practice this some more"; instead we see that we have caused shame and discomfort to ourselves and our loved ones. We do ourselves a grave disservice if we don't realize that failure is a natural part of a process and that it's OK to fail. Not everything we do will be perfect. Mistakes will creep into the best code we write. We will slip up and deploy to the wrong system. Our mistakes will cause discomfort to others. Accepting this gives us the freedom to realize that despite our best efforts we will not be perfect. But rather than seeing that as a limitation we can use this as part of our growth process. +We don't usually think of failure as part of the learning process. Failure is often seen as the end-point of the journey. In school a failing grade is seen as a condemnation. We don't see it as "I need to practice this some more"; instead we see that we have caused shame and discomfort to ourselves and our loved ones. We do ourselves a grave disservice if we don't realize that failure is a natural part of a process and that it's OK to fail. Not everything we do will be perfect. Mistakes will creep into the best code we write. We will slip up and deploy to the wrong system. Our mistakes will cause discomfort to others. Accepting this gives us the freedom to realize that despite our best efforts we will not be perfect. But rather than seeing that as a limitation we can use this as part of our growth process. When we realize we are going to make mistakes we can change our approach in how we make them. I mentioned before about creating models of our environments. What better way to allow us to make mistakes than in an environment where those mistakes can be contained and rolled back? Creating models allows us to practice and test our assumptions in environments that nobody else has to see. It's akin to a practice space for musicians where they can run through their material without the need to perform it right the first time. They can work out the troublesome parts and make mistakes until they are confident in their performance. Mistakes are how we learn what works and what doesn't work. They are an integral part of our learning process. We tend to remember the lessons of what didn't work better than the ones that did work. Mistakes help us shore up where we lack knowledge and help us see the gaps that we have. - -#### FIXME - -Mistakes also act as a reminder to pause for a moment and not get too wound up in the urgency of things. My own mistakes tend to happen more frequently when I'm rushing to meet a deadline (whether real or self-imposed). My worst mistakes happen when I'm tired and rushed, where I'm practically flailing at the keyboard trying to get something, anything, working. Allowing myself to pause for a moment, reflect on what it is that I'm trying to do, and see the uncertainty in the moment allows me the moment I need to recalibrate and refocus in the moment. +Mistakes also act as a reminder to pause for a moment and not get too wound up in the urgency of things. My own mistakes tend to crop up when I'm rushing to meet a deadline (whether real or self-imposed). My worst mistakes happen when I'm tired and rushed, where I'm practically flailing at the keyboard trying to get something (anything!) working. When I allow myself to pause for a moment, reflect on what I'm trying to do, and see the uncertainty in the moment I can take steps to recalibrate and refocus in the moment. I give myself the freedom to course-correct and understand that I'm not doing my best and I need to do something different. It might be something small like giving my brain a bit of rest or something large like revisiting the assumptions I made about what I'm doing. Taking the pause lets me see if I want to continue doing what I'm doing and understand if that's OK. ## Journaling our mistakes -There's value in not making the same mistakes twice. But it also brings some self-recrimination when we realize that we've made the same mistake again. +### FIXME + +There's value in not making the same mistakes twice. Understanding that we've repeated the same failure is useful because it gives us a pattern to understand. We can see that doing the same thing again gives us a failing result. This can be part of the learning process as long as we don't fall into a spiral of self-recrimination when we realize that we've made the same mistake again. -One trick that I use more infrequently than I would like is journaling. Journaling about what happened and how we fixed it is one way to explain to someone else (ourselves) what happened. Explaining what happened allows us to become a teacher to ourselves and reinforces the learning process. By explaining what happened in words that someone else will need to understand we give ourselves the ability to articulate our own thoughts about what happened and codify them. +One trick that I use more infrequently than I would like is journaling. Keeping a journal of what happened and how we fixed it is one way to explain to someone else (often ourselves) about what happened. Explaining what happened allows us to become a teacher to others and ourselves and reinforces the learning process. Writing down what happened in a way that others fan understand allows us to become more clear to ourselves on what we understand. When we articulate our own thoughts about what happened and codify them we gain an understanding into our own thoughts and can shake loose other ideas we might have that might not normally be available. We become our own sounding-board for ideas on how best to proceed. This isn't about keeping a record for posterity so we can go back and find opportunities to beat ourselves up about the past. It's a way to teach ourselves and maximize the learning process. It's about giving ourselves the freedom to be the instructor to our future self so we can be more aware when a mistake is about to happen and understand how to correct it. It allows us to focus on the moment just long enough to understand what happened, what we did to correct it, and how we can best proceed from here. It also helps us to locate where our gaps are and the next actions that we'll need to take in order to shore up those gaps. -- 2.31.1