How Psychology Impacts Training Tech Professionals Series

6 min read11 hours ago

–

It is a central part of the engineering journey to have needs that can only be addressed with outside support. As mentors and leaders, we always seek to identify what each software engineer needs and provide that support so that each can ship code, master complex architectures, find professional fulfillment, and share their technical innovations with the world. We must consider the human behind the keyboard as much as the outputs in the terminal.

I am often asked by younger developers, “What does a CTO or VP of Engineering actually do?” Or I encounter engineers who think such leaders are only there when a deployment fails or a “Post-Mortem” meeting is scheduled. Whether a brilliant backend developer needs support in navigating team dynamics and agile ceremonies, or the socially savvy product manager needs support with understanding the nuances of technical debt, it is incumbent upon us to support the needs of all our people. Perhaps especially in an global, remote industry where personality, traits, and (cultural) background impact *how *a team member operates as an individual and on a team.

I wouldn’t have left the academia I loved so much for such a drab critical-first existence. Rather, as I often explain in response, our role is to ensure all developers and teams feel psychologically safe and personally supported so that mentors can mentor and engineers can build.

Each day, we look to ensure these integral Maslowian needs — starting with the baseline of security in one’s environment and moving toward the self-actualization of “The Element” in one’s craft. The actionables in this important endeavor take many forms, from refactoring a messy sprint process to implementing better CI/CD pipelines. The consistent piece is the mindset that what we are doing is what is ultimately best for our engineers’ growth, and the team’s success.

Sometimes, the pursuit of this daily objective requires difficult conversations with stakeholders, architects, and staff. We may have to discuss a performance gap or pivot a project away from a developer’s preferred stack. But we rest assured that as passionate and committed technical leaders, the end goal — a high-performing, healthy engineering culture — is worth tackling the challenging moments with optimism.

In doing so, we likewise model for our engineers the importance of technical conviction. We show them the courage to acknowledge that a “breaking change” faces us, yet we proceed with the energy and confidence that fearlessly refactoring our systems offers opportunities for meaningful results for everyone involved.

Does every deployment work out? Not remotely. Servers go down, and logic fails. Yet the growth-minded, positive, engineer-centered approach always yields feelings of purpose and accomplishment regardless of the outcome of a single “Merge Request.”

An example of this mindset is how we use Code Review as a Catalyst for Growth

The Code Review (CR) is a central part of the engineering journey — a moment where we acknowledge that our work requires outside support to reach its full potential. As technical leaders and mentors, our goal in a CR is not to “gatekeep,” but to identify what each software engineer needs to ship code, master complex architectures, and share their gifts with the OSS world. Often, this is not a top down process at 0xide Professional Services. It’s a peer to peer, adult social learning process. We do this together in the virtual rooms. A safe climate where we are purposeful in nurturing an environ where everyone can freely be themselves and grow together. Where feedback is not criticism, rather a Vygotsgy-ian support through the Zone of Proximal Development.

Social learning is the key point here. “Research on social learning for adults is grounded in a blend of classic psychological theories and modern educational frameworks. These sources emphasize that adults learn most effectively through modeling, collaboration, and social interaction, often as a bridge between behaviorist and cognitive learning styles” (Mukhalalati, 2019; Hill et al., 2009).

Whether a brilliant backend developer needs support in writing more readable logic, or the socially savvy junior dev needs support understanding a race condition, it is incumbent upon us to support the needs of all our engineers through this adult-focused, research supported process.

For Example: Our Core Principles of Review

1. Psychological Safety Over Syntax

We are often asked by junior developers why we spend so much time in “the comments”, or why do we need User Stories and Architectures- and the impending group review thereof. They sometimes think the CR process is only there when someone makes a mistake. However, the true role of a reviewer (a role everyone in the group assumes and practices) is to make sure every engineer feels safe and comfortable. By no means do we coddle anyone. Quite the contrary- the greatest growth comes in moments of discomfort, through dealing with struggle, and overcoming challenges. Dr. Twerski conveys this here. Our process is to create an environment where everyone knows they can go to that uncomfortable place, hear that hard feedback, and have the resilient, growth-mindset to filter emotion and get to the crux of the message- and to respond with actionables.

In fact, we are known for the high expectations of our people to exceed their expectations of themselves, give each other feedback with fierce candor, be open to being pushed very hard, and to ship their proof of work with rigorous accountability.

We ensure Maslowian needs — security in one’s work and the ability to fail safely — are met so that developers can learn. Fail in the rooms, make mistakes together, support one another- Everyone is leader and pupil. Socratic and Kipling inspired practices. This practice not only includes everyone in a working group in various roles (developing skills that span across an organization), but also provides diverse opinions on best approaches. Often, the Gestaltian outcomes are far more effective, even innovative, than would be that from an individual problem-solving process, or even a senior review.

• Actionable: Avoid “Why did you do this?” and instead use “Can you help me understand the trade-offs of this approach?”
• Actionable: Use “I” statements to reduce defensiveness (e.g., “I find this logic a bit difficult to follow” rather than “Your code is confusing”).
• Ultimately, it’s about asking GOOD QUESTIONS. HARD QUESTIONS. The answers to which are often either validation of the peer’s decisions and work, or the responses to which manifest new understandings and better outputs.

2. Differentiated Feedback

We recognize that every engineer is in a different “Zone of Proximal Development.”

• For the Junior Engineer, we focus on foundational patterns, strong process (and the muscle memory from executing them) and “Clean Code” principles.
• For the Senior Engineer, we focus on architectural impact, scalability, and long-term technical debt.

3. Modeling Conviction and Courage

The CR process sometimes requires difficult conversations about performance or refactoring. We tackle these challenging moments with optimism, with aDweckian mindset. By providing honest, growth-oriented feedback, we model for our engineers the importance of having the courage to know a challenge faces us (like a fundamental logic flaw) and proceeding with the confidence that fixing it now offers meaningful results for the whole team.

The Actionables of Growth-Minded Reviewing

The Old Way (Neurotic/Gatekeeping)

• Focus on finding every “typo” or style nitpick.
• Making the developer feel “in trouble” for bugs.
• Demanding a change without explanation.

The New Way (Growth-Oriented)

• Focus on high-level logic and architectural integrity.
• Celebrating the “bug” as a learning opportunity for the team.
• Open discourse about the Kipling approach to discuss changes, revisions to empower the developer’s future choices.

Conclusion

Does every “Merge Request” work out perfectly on the first try? Not remotely. Logic fails and edge cases are missed. Yet, if we maintain a learner-centered, engineer-focused mindset, the review process will always yield feelings of purpose and accomplishment — regardless of how many “changes requested” comments are on the PR.

This Blog is Part of a Series on the Psychology of Engineering, and training Tech Professionals from the 0xide Professional Services Team.

For inquiry please reach out on LinkedIn here

***0xide Professional Services ***is a Rust Language and Networking focused Education, Talent, and Open-Source Community. We offer training, advisory, and leadership development for teams, organizations, and individuals. Founded in 2021, 0xide has been successfully doing this work in now our 5th year across niche Rust environs with 1000s of builders, leaders, strategist, and researchers.