## The Gap
-I've chosen the word "gap" to describe the difference between where you are now and where you think you should be for good reason. A gap is something imposed by others, whether by force or by neglect. If a gap appears in your garden fence it means the fence is weaker at protecting the garden. A gap can also be something that requires our attention. "Mind the gap" is a phrase coined in the late 1960s by the London Underground to warn folks of the space between the platform and the train cars. If someone weren't careful around that gap it could lead to an unsafe situation.
+I've chosen the word "gap" to describe the difference between where you are now and where you think you should be for good reason. A gap is something imposed by others, whether by force or by neglect. If a gap appears in your garden fence it means the fence is weaker at protecting the garden. A gap can also be something that requires our attention. "Mind the gap" is a phrase coined in the late 1960s by the London Underground to warn folks of the space between the platform and the train cars. If people aren't careful around that gap it could lead to an unsafe situation.
The gap in this case is the distance between our current abilities and where we think we should be. Sometimes the gaps are self-imposed because of our desires to improve ourselves, but more often the gap is externally imposed.
One of the biggest creators of gaps in our programming career is change. As programmers we are fully aware of the cycle of change in programming culture. We're constantly having changes thrown at us: changing technology, changing priorities at work, or even changing our strategies to try to keep up with the demands made of us.
-Change can also come from within our community. Our community of developers and users could move on to a new technology; whether for personal or professional reasons. We may no longer get the support we need to do our jobs and be faced with the prospect that we too need to update our skills or be left behind in an abandoned community.
+Change can also come from within our community. Our community of programmers and users could move on to new positions and new technologies. We may no longer get the support we need to do our jobs and be faced with the prospect that we too need to update our skills or be left behind in an abandoned community.
-Change can lead to stress. Stress is prevalent in programmer circles because things are often changing. What worked on Friday afternoon can be broken on Monday morning because of a change to a library that we were using. Our development environment could break because of an upgrade that didn't apply properly. Production might need security fixes and those fixes mean we have to redo a major piece of our software because it no longer works. There are plenty of ways in which we are kept in a cycle of change.
+Change can lead to stress. Stress is prevalent in programmer circles because things are often changing. What worked on Friday afternoon can be broken on Monday morning because of a change to a library that we were using. Our development environment could break because of an upgrade that didn't apply properly. Production might need security fixes, and those fixes mean we have to redo a major piece of our software because it no longer works. There are plenty of ways in which we are kept in a cycle of change.
-Not all change is because of bad events happening. The software that we use could have very good reasons for changing. New features can be introduced that require new ways of thinking about your code. Security fixes may mean that our systems are more resilient to outside attacks, but require different ways of using that system. New and better optimizations may lead to our code running faster but need a few tweaks to take advantage of those speed benefits. A refactor of an API can lead to cleaner and more concise ways of interacting with another system, but those changes are not backward-compatible with current code. Change can be positive.
+Not all change is bad. The software that we use could have very good reasons for changing. New features might be introduced that require new ways of thinking about your code. Security fixes may mean that our systems are more resilient to outside attacks, but require different ways of using that system. New and better optimizations may lead to our code running faster but needing a few tweaks to take advantage of those speed benefits. A refactor of an API can lead to cleaner and more concise ways of interacting with another system, but introduce changes that are not backward-compatible with current code.
-But change requires time and effort in order to adapt to it. The gap can only be closed if we have the resources and time to work on it. If we're struggling with our current workload and someone changes how something works we now have to budget our time to adapt to that change. If our mental-muscle-memory knows how something works and that has significant change it requires us to re-train our mental model of how that thing works. And if you're already feeling like you don't understand the systems and environment that you're working on then adding additional change can leave you feeling stranded among the newly-formed gaps in your knowledge.
+Change can be positive, but change requires time and effort in order to adapt to it. The gap can only be closed if we have the resources and time to work on it. If we're struggling with our current workload and someone changes how something works we now have to budget our time to adapt to that change. If our mental-muscle-memory knew how something worked and is now faced with a significant change it requires us to re-train our mental model of how that thing works. And if you're already feeling like you don't understand the systems and environments that you're working on then adding additional change can leave you feeling stranded among the newly-formed gaps in your knowledge.
## Closing The Gap
projects / themediocreprogrammer.git / commitdiff