Breaking the 'Software is Magic' Mindset in Development
The Magic of External Dependencies
There's a certain kind of magic that comes with understanding external dependencies in software development. For some developers, this magic seems unattainable, leading to a sense of disbelief and surprise when their peers accomplish tasks they deemed impossible. This disbelief extends to various aspects of development, from coding in C++ or Rust to implementing novel algorithms for unique applications.
The existence of packages that "just work" seems to be the work of a different breed of developers, a breed they believe they can't coexist with.
The Responsibility of Code Incorporation
The responsibility that comes with incorporating any code into a project is often overlooked. Whether it's a library, framework, or a simple copy-paste, the code you incorporate is your responsibility. It's crucial to understand the code you're incorporating, as you're responsible for its behavior as much as the code you've written. This understanding is so crucial that some developers refuse to include code they don't have the source code to.
The Pitfall of "Out of Sight, Out of Mind"
The "out of sight, out of mind" approach doesn't work when it comes to code you're responsible for. This mindset can lead to a lack of understanding and an inability to fix issues when they arise. It's not enough to simply string together various incantations of code and hope they work as expected.
The Magic Mindset in Software Development
Some developers view software building as a form of magic rather than a discipline that can be learned from basic principles of computer science. They rely heavily on third-party libraries and tutorials, and when something breaks, they resort to randomly moving things around or copying and pasting code from forums until it works. This "software is magic" mindset can lead to a lot of brute force cobbling, but it's not a sustainable or efficient way to develop software.
The Underestimation Issue
The issue with this mindset is the assumption that everyone else operates the same way. It's one thing to lack experience or knowledge, but it's another to constantly underestimate your peers. This underestimation can lead to a shaky self-esteem and a reliance on fragile and changing third-party libraries to solve specific problems that could be better solved with custom code.
The Ego Defense Mechanism
This underestimation can also be a defense mechanism for the ego. It can be difficult to accept that a peer or employee might be more capable, leading to a dismissal of their accomplishments and ideas. This dismissal can even extend to ignoring or scoffing at initiatives that could improve the development process, such as creating a transparent API or refactoring common client customizations. The irony is that these "brilliant ideas" are often later presented as new discoveries when found in a third-party library.
Conclusion
Understanding code is indeed a superpower. It's a skill that requires time, effort, and a willingness to learn. It's not magic, and it's not exclusive to a certain breed of developers. It's a skill that can be learned, and it's a skill that makes a significant difference in the development process.