Software Engineering activities are split between ones that provide direct value to customers in the short-term and ones that indirectly benefit customers in the long-term. It is important to have a good balance of both in order to ensure the long-term viability of Software Engineering work and continuously offer maximal value to customers. The best Software Engineers out there are those who have mastered the skill of balancing short-term direct-value activities with long-term indirect-value activities.
Examples of short-term direct-value activities are gathering user requirements from customers, breaking requirements down into use-cases, writing implementation code, doing QA testing, and deploying software into the cloud.
Examples of long-term indirect-value activities are reading tech books and blogs, learning new technologies with vastly different approaches to what is commonly followed, building toy projects that explore new ideas, and attending local tech meetups and software conferences.
Developers who engage in short-term direct-value activities without engaging in long-term indirect-value activities end up stagnating in technical skills and getting stuck in what is known as Single-Loop Learning (read about Single-Loop Learning and Double-Loop Learning here: https://en.wikipedia.org/wiki/Double-loop_learning). In other words, they get stuck inside the box without intelligent questioning of the technology approaches and libraries being used. So, they passively accept what some library creators decided (including what they decide in future library versions) without thinking for themselves, thus losing the ability to think outside the box and make exponential jumps in productivity. Instead, they might make contributions to libraries inside the box of what they already use instead of exploring much different simpler and more elegant solutions outside the box.
Often, such developers practice an anti-pattern known as Hero Worship as they position some library creators as Heroes on top of everyone else, making themselves believe that the Heroes are way above anybody else's ability to think, and thus they shut down their mind and default to relying on the thoughts, ideas, and works of the "Heroes" without ever questioning them. That's instead of actually thinking for themselves and living by the truth that everyone makes mistakes and everyone could be wrong from time to time, including library creators. As a result, they end up adopting highly over-engineered solutions that waste a lot of productivity due the solutions being originally created for the large organizations of the "Heroes" and their specific project situations.
The single loop referred to in Single-Loop Learning is the short-term feedback loop that is relied on to improve things within the box of previously selected technologies without periodically questioning the entire box in an outer long-term feedback loop to explore brand new novel approaches that might provide exponential jumps in improvement (Double-Loop Learning). For example, developers that use Java Enterprise Edition + Spring could continuously discover weaknesses in an inner feedback loop that leads them to upgrade their Java Spring libraries repeatedly. They won't have exponential jumps in productivity unless they employ an outer feedback loop that enables them to re-evaluate all their technology choices and discover that the dynamically typed Ruby language and the Rails web framework could offer exponential improvements in productivity for many business domains that would cut 12 months of work down into 6 months or less.
Unfortunately, developers who stick to the safe box of technologies they are accustomed to instead of practicing Double-Loop Learning end up in a rot due to the Dunner-Kruger Effect (https://nesslabs.com/dunning-kruger-effect), meaning they end up not knowing what they don't know as time goes on. So, when others discover new ways to improve Software Engineering productivity and quality in an exponential jump that renders 12 months of work doable in 6 months or less, the developers stuck inside the box end up missing out on those benefits completely. It's like Java developers that have never experienced the huge productivity benefits of Ruby on Rails. They don't know what they don't know. Eventually, their competitors end up swooping in and taking their business, which is what sometimes causes layoffs at companies. In other circumstances, such developers are fired due to not delivering work at maximum capacity when others are able to do their work in half the time or less.
One metaphor to explain this is how shipping services advanced over time. More than a couple of centuries ago, shipping companies relied on horse carriage. Later, they relied on the train. After that, cars were invented, so shipping could be done on trucks. Finally, airplanes were invented and sped up the ability to ship packages even further. If horse carriage shipping companies kept themselves too busy with horse carriages pulling the weights of their shipments to actually learn how to utilize newer technologies of shipping, they would have allowed their competitors to beat them to learning how to use newer methods of transportation and finish work in less than half the time needed for shipping on horse carriage, thus winning their business over.
Some developers like to tell themselves excuses, like they are too busy with customer value adding work to spend any time reading tech books or exploring new novel technologies. Unfortunately, this attitude neglects the big picture and the fact that long-term indirect-value activities do bring more value to customers even if it is not apparent as they ensure the delivery of maximum value to customers in the long-term. So, not spending time on such activities results in worse quality work for customers in the long-term. Meaning, such developers resign themselves to doing bare-minimum quality work for customers by avoiding long-term indirect-value activities instead of boldly spending out of the box time that would enable them to do maximum quality work for customers over the long haul. In turn, they end up opening the door for their competitors to eat their lunch, whether by taking their company business or taking their employment positions.
Making excuses to avoid something is always a red flag that signals mediocrity and a mediocre work ethic. Good Software Engineers always take responsibility instead of making excuses, and they have a healthy engineering curiosity about better technology approaches. No one can be thought of as a good engineer without having curiosity and passion for learning alternative methods of engineering that could offer better benefits to customers than whatever technologies are being used. Developers who make excuses usually do so because they have gotten too attached to and too comfortable within the confines of whatever technologies they know and have gotten too lazy to learn new technology approaches that shatter the comfortable box they have been operating inside of. Additionally, some of those developers are simply selfish as they care more about earning a paycheck with familiar work than doing their absolute best work possible for customers everyday. As such, those developers cannot actually be trusted to do the best work for customers. This matter goes further than keeping one's business and job. Those who do not do the best work possible for the amount of money paid to them by customers while claiming to belong to one of the "best businesses" out there are literally lying to their customers and engaging in unethical behaviour.
In summary, Software Engineers must engage in a good balance between short-term direct-value activities and long-term indirect-value activities to ethically ensure the long-term viability of Software Engineering work and continuously offer maximal value to customers, which helps in guarding their business and job from the competition.
No comments:
Post a Comment