Category: Growth

To be good at what you do, you have to have unquantifiable criteria you hold yourself to – which is undeniably susceptible to the weathering effects of prolonged and repeated, exposure to minor rationalizations.

Good Engineers Hold Themselves to A Standard

We want to believe ourselves to be good at the things we do and to believe that, we have to compare ourselves to a standard of measure. The standards I have developed, refined, and believe in always revolved around maintainability, consistency, portability, scalability, flexibility, testability, and reliability – you cannot provide a true, accurate, and meaningful measure and are thus, by definition, qualitative in nature. All of my work, personal or professional, needed to implement testing frameworks, allow for easy reconfiguration, facilitate obvious future feature work and avoid stale documentation through self-documenting code.

These metrics were very clear and concrete in my mind, but perception is not always reality. I readily pick up new concepts and technologies – some due to personal interest, many due to professional necessity – but how can you measure that which you haven’t fully adopted? “I’ll learn how to test my Ansible after I get the hang of it”: there goes reliability, “AoC would greatly improve this project that doesn’t natively support it”: now maintainability means Teagan fixes it, “I’ll just use the Redfish API to get system health checks”: bye, bye scalability. These seemed like justified rationale, but the standards I cherish, damaged through rationalities, were no match for the complete lack of feedback that permeates silo’d work.

Better Engineers Hold Others to A Standard

As a self-proclaimed “PR Tyrant” (pull request for the uninitiated), working with a team of talented engineers gave me a lot of satisfaction. It was understood that when you submitted a pull request that you were requesting it be held to the level of quality of all who reviewed it, that you address those concerns before your work is accepted into the project, and what happens in a pull request does not reflect on you the person – and if you can provide a logical and well-formed argument that contradicted my concern, I was open to listen and discuss with an open mind.

I approached every review with my “Definition of “Done” – every comment and concern related directly to one of the items in my checks list:

• Is the documentation updated and understandable? – Maintainability
• Does it run in my environment? – Portability
• Are there meaningful, effective tests that capture positive, negative, and edge cases? – Reliability
• Can I discern the author from the code? – Consistency
• Does every component have a purpose and perform that purpose efficiently? – Testability
• Are dependencies provided or created on-demand? – Flexibility
• Can the work react to changes in the environment appropriately? – Scalability

Each and every comment and concern received a tagged “severity level” (blocking, non-blocking, suggestion, opinion) and an explanation for the PR comment. Having their own set of criteria and priorities, the other members of my team pushed me to improve. We always tried to have an open mind if the author or reviewer could back up their stance with logic and reason, that was enough to remove or reduce the “severity level”. This process helped everyone learn new architectures, patterns, consider edge cases, and work as a team. We were all held to a level of quality that, usually, reinforced our personal standards; I like to believe these people and this project thrived because of everyone’s willingness to listen, explain and understand each other.

That is until an opportunity I believed to be the “perfect” fit was floated to me. Working with a Home Automation and Applied AI team seemed to fit in with my personal interests and hobbies so well, I just could not pass it up. After about 18 months of working essentially alone, having to beg for code reviews, and never seem to be on the same page with my manager, I couldn’t take it. I had lost sight of my own level of quality due to working with technologies and frameworks I had not used before, utilizing cloud infrastructure that seemed to be intentionally convoluted and hard to understand – but hey, the projects I built worked and were immediately assigned another. I lost that feedback loop, someone holding me accountable to my or their standards, and I barely noticed. The job they promised me never manifested, and a ridiculous pattern of misunderstandings on the scope of work, requirements, tasks – I left, and while I still believed I held myself to my standards – to find out they were mere shadows of the former selves.

The Best Are Always Improving Their Standards

I have known Alan for 5 years, and the whole time knew I wanted to work for World Wide Technology – It was blatantly obvious they truly trusted and invested in the people in their employ, every person I met who worked with World Wide Technology spoke highly of the company, loved their jobs, crazy smart and great people. After a 3 month-long interview process – yes, this seems extreme, but this just shows that they truly want to make sure it’s a good fit both ways and the investment is mutual between the prospective employee and company. The interview process was, without a doubt, the best interview experience I have ever had. They provided a person I’d be working with upon hire to be there throughout the process and each interview was followed up with positive feedback and constructive feedback – which I took to heart, and they noticed the work I put in to address the areas I could improve. My first week was not your normal orientation, it was your indoctrination into working in a truly Agile environment. The terms Agile and DevOps are thrown around a lot in the technology industry but they are not just buzzwords, just ideas, not just practice – they are a cult-like life philosophy, driven by often and fast feedback to improve and I willingly drank that Kool-Aid.

For example: when you’re assigned a project, your team has full autonomy – you decide work schedule, communication methods, distribution of work, and how internal issues are resolved. Every team is different, so how one team works doesn’t mean that process would be successful in another team, by providing trust and autonomy you feel empowered, valued, and respected; in the end, your team is more efficient and happy.

After 2 years of letting myself chip away at my standards, I almost felt ashamed to submit code for review – a feeling I hadn’t felt since the inception of my career. Each comment and concern I received was perfectly in line with my original level of quality – logical, reasonable, and well-articulated – I couldn’t wait to implement the fixes, test, discuss and repeat. That feeling of raising the bar, that you let drop over the years, raises your perception of your work equally high.

However, this doesn’t make us the best engineers we can be. To be the best version of ourselves, we have to live the philosophy that is Agile/DevOps – that is, how do we bring our standards to a higher, more improved state? Feedback! We set up weekly sessions to talk about our work, how we can improve, when is it ok let slide, when is it not. These sessions aren’t just talking, we take them and implement them – and sometimes they don’t work, and try new ideas until it works – and we repeat. It’s not always about the quality of our work, but how to communicate better, how to mentor better, how to Life better.

Drink the Kool-Aide, find your feedback loop, and get that feedback fast and often, listen to the feedback. Change is hard, but growing spiritually, professionally, personally is far more rewarding than your fear of failure. Failure is nothing more than an indicator to try different, not harder. You can be a better you – and you are the only one who can define a better you, raise your quality standards, and see where it takes you!