Let's be honest, most IT engineers are autodidacts out of necessity. Our industry isn't mature compared to most of the professions that exist today. Computer Science was first offered as a degree in 1962 in the US, and Network Science is flatly ancient, but generalized IT infrastructure support only became a schooled profession much more recently than that.
Early IT engineers were typically self-reliant trade professionals that entered the field with a pioneer mindset, bringing their prior professional experiences. Technology was in its infancy, and there was no shortage of mountains to climb. Resiliency is a given for these folks, because there was no "Googling" before Google, and everything was new.
We saw another wave of IT engineers enter the field (myself included) in the mid-'00s/'10s. Industry education like Cisco Networking Academy became widely available in this time period, resulting in more well-rounded individuals without sacrificing a sense of self-reliance. It's our culture to teach ourselves, but we're OK with learning in a classroom too.
Now, we see new entrants on the field. IT degrees are available in many universities, and the quality of education is good. Will we all be replaced by the "smartphone generation"?
Why does this matter?
The values of stoicism and self-education are embedded deeply in the IT professions, but it's important to understand its weaknesses. Autodidacts don't receive the benefits of "periodic curriculum review" because there's no curriculum; focus is experiential.
Stoicism can be harmful, too. IT engineers specialize in finding flaws in technology systems, anything created by an engineer will be evaluated ruthlessly for problems.
When we introduce IT automation, we invite a toxic level of self-criticism with any code or solutions we create. The IT industry grew in parallel with computer science, but we need to learn a few lessons the easy way.
Plato's Cave
Let's talk about Plato's Allegory of the Cave. Plato attempts to produce an example of synthesizing Form by isolating a real object from its projection.
Plato created a hypothetical scenario where some individuals are imprisoned from childhood in a cave, unable to see the outside world. The details on execution don't matter much in this case, because it's not a guidebook on how to implement a real experiment - that would be inhumane. They can't see the outside world for whatever reason, but light sources are external, and have their own natural phenomena. Plato goes further and states that puppeteers can create shadows and create new stimuli for the prisoners.
Humans are amazing and adaptable, but this works to our disadvantage here. The prisoners optimize to their surroundings, developing complex narratives about the lights and shadows they perceive - but they cannot observe the true phenomena. These complex narratives become ingrained in our sociocultural foundation, and for all purposes, it becomes reality.
What do you think happens when the prisoners are released? Would they be overjoyed to experience sunlight, astronomy, other Greek wonders?
Socrates doesn't think so. Excessive stimuli introduced too quickly will force an individual back to the comfort of their own beliefs, resulting in an immediate rerouting back to that cave. A prisoner in this hypothetical scenario is forced to leave and cannot return until they've explored the world at least a little.
When this individual returns to the cave to tell others about their experience, they notice that he's blind (simply unaccustomed to cave darkness) and overwhelmed with new information. Long story short, they all agree to kill anyone who forces them out of their cave of psychological comfort.
Caves at Work
We're self-critical autodidacts, isolated by the limits of our own experiences. This doesn't reflect on capability at all, and the resilience that comes with the profession has a great deal of value.
How do we see our own value and capability, then? Most IT infrastructure work doesn't have a direct result, it enables others to create opportunity and value. It's not directly observable in day-to-day work, but we will see shadows of it in our cave of comfort.
We need to get out of that cave. IT Automation is just the most current example because it merges the CS and IT professions - which we thought were incompatible.
Don't kill the messenger
The first step to improvement is to remove that pact to wipe out any individual who is introducing new ideas. New stimuli are good, and capable IT engineers should have no problem interfacing with new ideas or technologies - it's what we live for. There's no reason to fear new ideas and technology in a field borne of pioneering and exploration. Don't be the firefighter in Fahrenheit 451.
Don't hold ideas too tightly either - we live in an industry where the technology cycles at a dizzying rate. What was right yesterday may not be right tomorrow, or it might be right forever. Learn to feel comfortable evaluating ideas for validity and usefulness. Be about as attached to them as the ol' company laptop - if it's a good one, keep it, if it doesn't, turn it in after a few years.
Remember that everyone's uncomfortable
Instead of wiping out threats to your team, I'd suggest being supportive of others instead. Avoid personal attacks, and use language to shift focus towards refining a technical solution when you peer review code.
Embrace new Qualia
Here are two completely different forms of qualia:
We as humans bring a unique combination of skills and knowledge with us everywhere we go.
Learn to enjoy experiencing new things, it's the entire point of our industry, and nobody can truly predict what an individual can create when new things are added to a collective experience.
This isn't exclusive to IT, and shouldn't be - while further suggestions are IT-specific, I'm also specifically saying to seek qualia outside the IT field as well.
Peer Review / pull request
Fortunately for us, git already exists and is used heavily both by IT engineers and software developers alike due to the "DevOps" movements.
This post is already too long to cover creation of a branching strategy for a software project, which is its own subject.
Instead, I'd like to suggest something. If you think your code is bad, start peer reviewing others. Enterprise Source Control Management (SCM) platforms include the concept of a Pull Request (Examples) as a method to invite others to take a look at their code.
Use peer reviewing opportunities as a way to pick up new qualia and improve your coding style! I'd recommend opening up a distribution list (or posting somewhere, anything works really) with a list of individuals interesting in participating in peer review. Ask questions! Encourage those who opened their ego to punishment by sharing what's essentially their own thought processes for everyone to see - they probably aren't comfortable with it either.
Your mission, as an enthusiastic peer reviewer, should be twofold:
First, strive to create an environment where individuals want to present their code for peer review. This doesn't have to be prescriptive, if it takes donuts to make it fun, then use donuts. Avoid any language or patterns that might make it painful or difficult to receive feedback. Remind others that their contribution is valuable as are they.
Second, try to learn from others. Branching strategies, coding styles, all that you participate in with a pull request is valuable. It doesn't need to be rushed, because you're not studying for a certification - you're participating in collective, experiential learning.
Remember that we as humans bring a unique combination of skills and knowledge with us everywhere we go.
Top comments (0)