Maximizing Impact: Travel as a Developer Advocate

I almost titled this post “Wasting Company Time & Burning Yourself Out” considering some of the interactions and involvement I’ve seen in the DevRel Community of late. But I’ll get to that drama and angry frustrations later in the post, but immediately let’s get down to brass tacks.

As I dive into the nuances of traveling as a Developer Advocate, it’s crucial to clarify that this post isn’t just about logistics or coping mechanisms, but about the larger strategic picture beyond just the tactical underpinnings of day to day travel, airports, train stations, and the like. Instead, I aim to delve into what underpins the demand for travel as a developer advocate. Travel is far more than just getting from point A to point B to partake in an action. It’s about positioning myself—and by extension, the organizations and efforts I represent—to make meaningful connections, drive impact in decisions, and stay ahead in a rapidly evolving industry.

Strategic Travel: Guiding the Future of Major Projects

When it comes to strategic trips, the stakes are high. These aren’t just any industry conferences or casual meetups; they’re focused events where the future of a project might hang in the balance. Take, for example, a situation where a software fork of a major open-source project is on the horizon. The decision to fork isn’t taken lightly—it’s a move that could redefine the project’s trajectory, influence developer adoption, and ultimately shape the software landscape for years to come. Being on the ground and having built connections with the people involved face to face is irreplaceable. Having just had few meetings or video conf calls doesn’t cut it, one can’t replace the built trust of time spent face to face builds. This is where traveling to where people are, as an advocate, become priceless.

In these scenarios, my travel is centered around influencing and guiding these pivotal moments. I’m there to represent the interests of my company, to ensure that our vision and goals align with where the project is heading. This might involve meeting with the core contributors, understanding their motivations, and providing insights that can help steer the project in a direction that benefits both the community and the enterprise. It’s about being at the table when decisions are made, rather than reacting to them after the fact.

Continue reading “Maximizing Impact: Travel as a Developer Advocate” →

The Missing Pieces: What Online Tutorials and Docs Always Seem to Forget

Yo, fellow coders and tech enthusiasts! Adron here, and today we’re diving into a topic that’s been grinding my gears for ages – the stuff that’s always missing from online tutorials and docs. Buckle up, ’cause we’re about to get grumpy!

0. The Invisible Prerequisites

Before we even get to the main course, let’s talk about the appetizer that so many tutorials forget to serve – the damn prerequisites! I can’t tell you how many times I’ve started a tutorial only to find out halfway through that I needed some obscure tool or specific version of something that wasn’t mentioned upfront.

Here’s the deal, tutorial writers: lay out ALL the prerequisites clearly at the beginning. And I mean ALL of them. Don’t assume I have jq installed for your GraphQL tutorial. Don’t assume I’m running the latest version of Python (and for the love of code, specify WHICH Python – 2.x or 3.x?).

And here’s a novel idea: how about actually telling me where to find and install these prerequisites? Give me links, give me version numbers, give me command line instructions. Assume I’m starting from scratch on a fresh machine. Because guess what? Sometimes I am!

Even though this isn’t a tutorial, but just because I mentioned them here, check out jq here and Python here.

Continue reading “The Missing Pieces: What Online Tutorials and Docs Always Seem to Forget” →

Elaborating on Multilevel Engineering Teams

Just wrote up the previous post and wanted to elaborate further on the different levels, examples for leadership to follow, and related ideas from my own learning. Thus, the point of this post, enjoy.

Junior Engineers

Example: Onboarding and Mentorship Programs for Junior Engineers

In one of my past roles, I spearheaded the onboarding process for junior engineers by introducing a structured mentorship program. Each new junior hire was paired with a senior engineer or a mid-level engineer who served as their mentor for the first three months. During this period, the junior engineers were assigned shadowing tasks during dev cycles. This included sitting in on design meetings, assisting in code reviews, and collaborating on smaller feature developments.

The shadowing model had a two-fold benefit: it accelerated the learning curve for the juniors, giving them real-world exposure to engineering best practices and the development process, while also offering senior engineers the opportunity to practice leadership skills by teaching and guiding these new team members.

In this mentorship framework, juniors were tasked with bug fixes or smaller features. For instance, a junior engineer might be responsible for writing the unit tests for a feature developed by their mentor. By working on tangible parts of the codebase and receiving feedback directly from senior engineers, junior engineers quickly gained confidence in their abilities, which also led to early wins for the team.

Why It Works:
This approach enhances team cohesion and knowledge-sharing while ensuring junior engineers are not thrown into the deep end without support. It also fosters growth in senior engineers by reinforcing the mentor’s knowledge and leadership through teaching.

Continue reading “Elaborating on Multilevel Engineering Teams” →

Building a High-Performing Engineering Team: Strategies for Recruiting, Retaining, and Growing Talent Across Junior, Mid-Level, Senior, and Principal Roles

Building a diverse and inclusive engineering team at multiple levels—junior, mid-level, senior, and principal—requires thoughtful leadership, precise recruiting, and a clear vision for growth and success. As demonstrated through my extensive experience in recruiting, making hiring decisions, and fostering an environment that retains talent, the importance of addressing the needs of engineers at all levels becomes paramount.

The Core Needs for Building a Multilevel Engineering Team

  1. Junior Engineers

Junior engineers are often eager to learn, adapt quickly, and bring fresh perspectives to the team. When hiring junior engineers, it is crucial to focus on their potential and learning acumen. Junior engineers benefit from structured mentorship programs, frequent feedback, and opportunities to work alongside mid-level and senior engineers on real-world projects. Their presence adds energy and creativity to the team, while providing senior team members a chance to mentor and teach, enhancing their leadership abilities.

Example:

I’ve often structured onboarding processes to include hands-on mentorship, assigning junior engineers to shadow senior engineers in early sprints. This approach not only accelerates their learning curve but also allows the senior team members to refine their teaching and leadership skills, ensuring a seamless transfer of knowledge.

  1. Mid-Level Engineers

Mid-level engineers form the backbone of the team, possessing enough experience to handle core tasks independently while also being able to guide junior developers. They often play a critical role in driving features from conception to delivery, balancing technical execution with business needs. In hiring mid-level engineers, the focus should be on their adaptability, ability to take ownership of projects, and technical versatility.

Example:

In several of my roles, I’ve emphasized the importance of giving mid-level engineers the autonomy to lead small projects. This has empowered them to make decisions, troubleshoot issues, and see how their contributions directly affect the success of the team and product delivery.

  1. Senior Engineers

Senior engineers bring deep technical expertise and are key to setting the technical direction of the team. They are often tasked with solving complex problems, making architectural decisions, and mentoring both mid-level and junior engineers. Senior engineers also play a role in recruitment, helping to attract and assess potential candidates for both technical and cultural fit.

Example:

In one of my previous roles, I created a mentorship loop where senior engineers were responsible for running technical interviews and mentoring junior and mid-level developers through code reviews and collaborative pair programming. This not only fostered a culture of growth but also helped build a stronger connection between different levels of the team.

  1. Principal Engineers

Principal engineers lead by example, focusing on long-term technical strategy and influencing the engineering culture at an organizational level. They often bridge the gap between leadership and the technical team, providing mentorship to senior engineers while aligning the technical vision with business goals. Principal engineers are vital to creating a sustainable development ecosystem, ensuring that the team grows while maintaining high standards of quality.

Example:

One key aspect of principal engineers’ growth is their ability to learn from other levels, especially junior and mid-level engineers. In my experience, I have encouraged principal engineers to spend time in code reviews with junior developers, which often leads to new insights about simplifying architectures or improving communication. This symbiotic relationship benefits both the junior developers, who get to learn from experienced engineers, and the principal engineers, who stay grounded in the day-to-day technical challenges.

The Synergy Between Levels and Why It Matters

A truly successful engineering team thrives when engineers across all levels contribute to each other’s growth. Junior engineers push more experienced team members to stay adaptable and up-to-date with emerging technologies. Mid-level engineers build strong ownership and leadership qualities through their guidance of juniors, while also learning from the technical depth and decision-making frameworks of senior and principal engineers. Senior and principal engineers, meanwhile, grow as leaders by mentoring and learning from the fresh perspectives of those earlier in their careers.

Leadership plays a critical role in maintaining this ecosystem, ensuring there are platforms for collaboration and knowledge sharing. A culture of mentorship and continuous improvement not only helps with the retention of talent but also ensures that the team remains innovative and adaptable.

Why Recruiting and Retaining Across Levels is Crucial

A well-rounded team with a balanced distribution of junior, mid-level, senior, and principal engineers is not only essential for delivering quality software but also for the overall success and sustainability of an organization. Engineering managers and leadership must be able to demonstrate their ability to attract, hire, and retain talent at every level. This involves creating an environment where engineers feel challenged, supported, and valued.

When each level is respected and invested in, retention rates improve, the onboarding process becomes smoother, and the team can scale more effectively. Additionally, diversity across experience levels allows for a more holistic approach to problem-solving, where insights from all stages of a career path are valued and contribute to innovative solutions.

My history has taught me time and again that building teams with a wide range of experience and skill level is the best way to go. Ensuring a culture of continuous learning and collaboration each level of an engineering team has unique contributions to make, and by fostering these relationships, the team as a whole becomes stronger, more innovative, and more successful in delivering top-notch software and services. The end product is a team, that is retained well past the average tenure, that can build, maintain, innovate around, and keep a product and service going for years and years.

Understanding Event-Driven Architecture in Golang with CQRS

Understanding Event-Driven Architecture in Golang with CQRS

When diving into modern architecture patterns, especially in microservices and distributed systems, event-driven architecture (EDA) emerges as a highly effective strategy. The ability to decouple systems, process events asynchronously, and handle large amounts of data without a monolithic design makes EDA an appealing approach. For example, think about an online shopping platform where a customer places an order. Each event, like inventory updates, payment processing, and order confirmation, is triggered as separate actions. With EDA, each of these services can handle their responsibilities independently, ensuring scalability and fault tolerance.

In this article, I’ll break down the essentials of event-driven architecture, introduce the Command Query Responsibility Segregation (CQRS) pattern, and explore how to implement both in Golang with a practical reference to the CQRS implementation by Jet Basrawi.

What is Event-Driven Architecture?

Event-driven architecture is an approach where components of a system communicate by producing and consuming events. These events are typically simple statements of fact that something has happened in the system. This allows systems to be reactive, decoupling producers and consumers, and promoting loose coupling, scalability, and flexibility.

Continue reading “Understanding Event-Driven Architecture in Golang with CQRS” →