Again, it doesn't have to be perfect - it's only a model. But it does need to be close enough where your code will behave in a similar fashion between the model and the target environment.
-### FIXME
-
## Time machines
-There are plenty of other folks who will tell you the benefits of revision control (and many folks who will show you the exact steps for how to set up revision control). Having a good revision control system will allow you to create areas where you can test code without having to merge these tests into production. Good revision control will allow you to create a space (or "branch" in git parlance) based off of existing code that you can use to experiment and develop on. It also allows you to commit to that space and diverge as much as you need to in order to fully explore the changes you're making. What's most important though is that good revision control will allow you to abandon that space if you need to - you're not forced to commit those changes back to a production machine. This allows you to see if something might work and abandon those changes if they don't pan out. Good revision control affords the programmers the ability to branch off from any point in time and explore what happened in the code base. In a sense they're time machines, allowing you to play "what if?" scenarios with your code. This is vital for your learning because you can feel secure in testing and trying things and have the ability to rewind those changes (or delete them entirely) without affecting the work of others.
+There are plenty of other folks who will tell you the benefits of revision control (and many folks who will show you the exact steps for how to set up a revision control system). Revision control systems such as git, svn, cvs, and the like have helped programmers coordinate releases and keep a log of what work was added to their project. Having a good revision control system allows you to create areas where you can test code without having to merge these tests into production code. Good revision control lets you to create a space (or "branch" in git parlance) based on existing code that you can use to experiment and develop. It also allows you to commit in that space and diverge as much as you want or need to in order to fully explore the changes you're making. What's most important though is that good revision control will also allow you to abandon that space if you need to - you're not forced to add those changes back to your production code. This allows you to see if something might work and abandon those changes if they don't pan out. Good revision control affords the programmers the ability to branch off from any point in time and explore what happened in the code base. In a sense they're time machines and infinite universes, allowing you to play "what if?" scenarios with your code and move back and forward through time in your code. This is vital for your learning because you can feel secure in testing and trying things and have the ability to rewind those changes (or delete them entirely) without affecting the work of others.
Learning how your revision control system works will give you freedom in making mistakes. Many of these systems can seem complex at first but with continued practice and patience you'll understand what the revision control is doing and what its capabilities are. You'll be able to judge how many risks you can take with your code and be more confident with the risks you take.
+Revision control can also play a role in seeing the development of the code of other folks. You can get a window into their development process and see what certain features look like as they are added. This can help you learn about an unfamiliar code base, and can show you the direction they took in order to make the code the way that it is. It can give you a window into the history of a project and what all went into making it happen. It can be a time machine into the history of a project and can help you understand that programming is a process. Not all projects come fully-formed from programmer minds.
+
## 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.
-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 I damaged my relationship with my co-workers? All of these questions come at the forefront and they all stem from a desire to do our best and make sure that we don't cause harm to others. We want others to think well of us and our skills and failure amplifies whatever feelings of inadequacy we might have. We wonder if we should eve be doing this at all, or if our talents lie 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 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.
+
+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 let failure be part of the learning process. Failing feels a lot like and end-point of the journey. In school a failing grade doesn't usually mean "I need to practice this some more"; it usually means that we're going to cause shame and discomfort to ourselves and our loved ones. I think there's a huge disservice we give ourselves if we don't acknowledge that failure is 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'll slip up and deploy to the wrong system. We'll cause discomfort to others.
+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.
-A better approach is the one I mentioned above: allowing ourselves the freedom to have places where it's OK to make mistakes. Mistakes are how we learn what works and what doesn't work. We tend to remember the lessons of what doesn't work better than the ones that do work.
+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 help us shore up where we lack knowledge and help us see the gaps that we have. They also are a reminder to pause a bit and not get too wound up in the urgency of things. I know that my own mistakes tend to happen 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 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.
## Journaling our mistakes
projects / themediocreprogrammer.git / commitdiff