Effective Developer Advocacy: Prototyping, Open Source, Community Building

Having worked specifically in Developer Advocacy in the past, I have well-formed opinions about how it should work and some data-driven insights into what makes Developer Advocacy effective. My experiences and observations have led me to a clear vision of what I’d like to see in DevRel teams and, more specifically, from developer advocates as a sometimes fellow developer advocate and an all the time software solutions developer/engineer/etc.

Prototyping and Problem-Solving

One of the primary areas where Developer Advocates (DAs) can shine is by creating prototype applications that tackle specific problems. Regardless of their experience level, DAs should be hands-on with the technology they are advocating for. For instance, a Developer Advocate focused on logging should dive deep into tweaking logging mechanisms. This could involve demonstrating advanced configurations, optimizing log formats for better readability, or integrating logging frameworks with monitoring tools.

For security-focused DAs, I’d make the case that attention to detail should be even more pronounced. They should not only explain the fundamentals of OAuth implementations or JWT tokens but also delve into the details that often trip up developers and be familiar – in general – with the infosec area of the industry. For example, demonstrating best practices for token storage, handling token expiration, and ensuring secure communication channels and why you should do these things would be immensely valuable.

Contributions to Open Source

Another critical aspect of an effective DevRel team is active participation in Open Source Software (OSS) projects. Developer Advocates should regularly contribute to OSS, not just through code but also by writing articles and creating content that highlights their experiences. Sharing what works, what doesn’t, and the lessons learned during these contributions can provide invaluable insights to the broader community.

Imagine a DA working on integrating two popular tools. Documenting the journey—right from initial setup, through the challenges faced, to the final implementation—can serve as a roadmap for others attempting the same. Articles that cover these real-world integrations, the hurdles encountered, and the solutions devised would be a treasure trove of knowledge for developers worldwide. They’re something, that often, is simply not available. When they are, they’re often short, rudimentary, and rarely offer insight beyond the simple happy path.

The Right Amount of Travel

I am generally supportive of the operational situation, backed by data, that Developer Advocates should keep travel engagements to around 10-25% of their work. Excessive travel—anything more than 25%—is a red flag for several reasons. These aren’t reasons I’m just making up either, because I have seen some advocates manage excessive travel pretty well, but the vast majority of people just simply don’t have the bandwidth and ability to mitigate the risks:

Disruption to Focused Work: Traveling takes most Developer Advocates away from focused work on building prototypes, learning a technology, or exploring tangential aspects of what they’re advocating for.
Loss of Technical Expertise: It starts the process of pulling an advocate away from their technical expertise and focus time, causing a lapse in hands-on technical work.
Perception of Detachment: This can perpetuate the idea that many Developer Advocates don’t really work with the tech or have a solid understanding of what they’re advocating.
Erosion of Credibility: Building on the previous points, this tends to render an advocate’s reputation useless in working as an engineer/developer/programmer, as people become highly doubtful of their technical acumen.

Building Community Through Collaboration

Effective DevRel is not a solo endeavor; it thrives on collaboration. Developer Advocates should foster a sense of community by working together on projects, sharing knowledge, and supporting each other’s efforts. They should write articles and create content that speaks to their experiences of working together. Highlighting what tools and techniques that mix well and identifying common problem points can pave the way for more streamlined development processes, spearheaded by developer advocates showing exactly how to do this at a tactical level.

For example, a series of blog posts or videos where DAs from different specialties come together to build a cohesive application can be incredibly insightful. For example at Amazon, seeing a security DA work alongside a logging DA and a front-end DA (do those exist at Amazon?) to tackle a comprehensive project would not only showcase their individual expertise but also their ability to collaborate and create a unified solution.

Improving DevRel

In my humble opinion, there are several ways DevRel can improve and amplify its impact:

Hands-on Demonstrations: More live coding sessions, webinars, and workshops where DAs build and troubleshoot applications in real-time. This hands-on approach makes the learning process more tangible and relatable.
Transparency in Learning: Sharing not just successes but also failures and lessons learned. This transparency can demystify the development process and make it more accessible to developers at all levels.
Inclusive Contributions: Encouraging contributions from developers of all backgrounds and experience levels. This inclusivity can lead to a richer, more diverse set of solutions and ideas.
Focused Content: Creating content that addresses specific, granular aspects of development. Whether it’s a deep dive into a niche feature of a logging tool or an in-depth guide on securing OAuth implementations, focused content can provide deep insights that broad overviews often miss.
Collaborative Projects: Promoting and participating in cross-functional projects that bring together DAs from different domains. This collaboration can lead to more holistic and robust applications and tools.

In conclusion, Developer Advocates play a pivotal role in bridging the gap between technology and the developer community. By focusing on hands-on prototyping, active OSS contributions, and fostering collaboration, DevRel teams can significantly enhance their effectiveness. Transparency, inclusivity, and a commitment to continuous learning will ensure that DevRel not only keeps pace with the rapidly evolving tech landscape but also helps shape its future.

Note! All of these points, I’m absolutely open to debate about. This is my findings, there are a limited number of studies around this topic, and I’m more than happy to change my mind based on new data! If you’ve got any data or a different take on any of these points, I want to hear them! Let’s get a conversation going over at @Adron on Mastadon or Threads or LinkedIn!

The New Version “F1 Help” of the 00s – Code Challenges – A 2nd Rant on Modern Interviews

Hey folks, let’s take a trip down memory lane. Some of y’all remember the good ol’ days of the early 2000s when we’d hit F1 and magically summon the help documentation to save us from our coding woes? Ok, maybe it was Stackoverflow then, but regardless we had a whole set of companies that thought it a good idea to base interviews off of the documentation, and that became dubbed the
F1 Interview” or “Documentation Interview”. Fast forward to 2024, and here we are, stuck with the modern equivalent of that dreaded F1 interview: the infamous “code challenge” in technical interviews. It’s time we talk about why these challenges are the new bane of existence for building effective software development teams.

The Rise of the Code Challenge

Oh the magnificent code challenge /s. It’s like a rite of passage now. You’ve got your resume polished, your GitHub repo gleaming, and your LinkedIn profile looking sharp. But before you can even think about landing that dream job, you’re hit with a coding challenge that makes you question your very existence.

These challenges usually involve solving some obscure problem that you’ll never encounter in the real world. You know the ones: reverse a binary tree, find the longest palindromic substring, or implement a LRU cache. It’s like being asked to juggle flaming swords while riding a unicycle for a bicycle messenger gig. Pointless. Sure, it’s impressive and cool being able to juggle flaming swords on a unicycle, but how often are you going to need that skill on the job?

Continue reading →

The Great Advantage of Meritocracy: How Algorithm Interviews Keep Your Hiring Pipeline Narrow

Ah, the joys of algorithm and data structure interviews. Or as I like to call them, the “let’s weed out anyone who isn’t a robot” interviews. You see, these code challenge interviews are touted as the pinnacle of assessing a developer’s true potential. Because nothing says “I can build scalable, maintainable software” like solving a problem about reversing a linked list on a whiteboard, right?

Let me break down the astounding advantages of these interviews for you.

Narrowing Your Candidate Pool

First and foremost, if you want to reduce the number of applicants faster than a bad odor clears a room, code challenge interviews are the way to go. These challenges are a fantastic method for eliminating a huge percentage of your candidate pool. Who cares about that candidate with 10 years of solid, hands-on experience in system design and architecture? If they can’t recall the exact time complexity of bubble sort, they’re clearly not worth your time. Because everyone knows that bubble sort is essential knowledge in the real-world scenarios you’ll encounter daily. Sure, buddy.

Continue reading →

Embracing the Principal Engineer Role: Leadership Beyond Code

Stepping into the principal engineer role is a significant milestone in any technical career. It’s a role that extends far beyond the realms of coding and technical prowess, demanding a blend of strategic thinking, mentorship, and alignment with business goals. As someone who has traversed this path, I find the principal engineer position to be both challenging and immensely rewarding.

The Ambiguity of the Principal Engineer Title

One of the unique aspects of the principal engineer role is its inherent ambiguity. Depending on the company and team, the responsibilities and expectations of a principal engineer can vary significantly. This ambiguity can be both a challenge and an opportunity, as it requires a keen understanding of the specific context in which you operate.

In some organizations, a principal engineer is primarily a technical leader, deeply involved in coding, architecture, and solving complex technical problems. In other settings, the role may lean more towards strategic oversight, focusing on aligning technical efforts with business objectives and driving innovation across multiple teams.

Understanding this variability is crucial. When stepping into a principal engineer role, it’s essential to clarify expectations with your leadership and team. This clarity ensures that you can effectively meet the demands of the role and contribute meaningfully to your organization’s success. As I like to describe, start from day 1 with recon, find the gaps, fill the gaps!

Technical Excellence and Innovation

At the heart of the principal engineer role lies an unwavering commitment to technical excellence. This isn’t just about mastering the latest technologies or frameworks—it’s about a deep, intrinsic understanding of foundational principles and the ability to innovate. A principal engineer must be able to architect solutions that are not only effective today but also scalable and adaptable for tomorrow.

Strategic Vision and Business Impact

One of the most significant shifts in transitioning to a principal engineer role is the need to adopt a strategic mindset. It’s essential to think beyond immediate technical issues and consider the broader business implications. This involves staying updated on industry trends, understanding the company’s strategic objectives, and aligning technical decisions to support these goals.

Mentorship and Team Development

A principal engineer is a mentor and leader within the engineering team. This role goes beyond providing technical guidance; it involves nurturing talent, fostering a culture of continuous learning, and inspiring innovation. Effective mentorship means investing time in developing the skills and careers of less experienced engineers.

In my discussions about the toxicity of coding challenges during interviews and setting up effective processes for junior developers, I’ve emphasized the importance of a supportive wholistic environment. As principal engineers, we play a crucial role in shaping this environment. This means offering constructive feedback, encouraging professional growth, and creating an inclusive culture where every team member feels valued and empowered.

Driving Business Alignment

Understanding the business context and aligning technical efforts with business goals is a key aspect of the principal engineer role. This requires regular communication with stakeholders, a thorough understanding of the business model, and the ability to articulate how technical decisions impact the company’s objectives.

Continuous Learning and Adaptability

The tech landscape is constantly evolving, and as principal engineers, we must be committed to continuous learning. This means staying updated with the latest advancements, continuously refining our skills, and being open to new ideas and methodologies.

Learning from Others: Interviewing Principal Engineers

In my quest to deepen my understanding of the principal engineer role beyond my own, I’ve embarked on a journey of interviewing principal engineers from various companies and industries. These conversations have provided invaluable insights into the diverse ways this role is interpreted and executed. Through these interviews, I aim to uncover common challenges, effective strategies, and the unique experiences that shape the principal engineer’s journey. Subscribe and stay tuned for future posts of the interviews I’ve undertaken!

Each interview sheds light on different facets of the role, from technical leadership and strategic vision to mentorship and business alignment. By sharing these insights, I hope to create a resource that helps aspiring principal engineers navigate their paths and understand the broad spectrum of responsibilities and opportunities this role entails.

Embraced Conclusions

The principal engineer role is a blend of technical mastery, strategic thinking, mentorship, and business alignment. It’s a role that challenges us to grow continuously and to think beyond the code. For those who embrace these challenges, it offers a unique opportunity to make a significant impact on their organizations and the tech community at large.

As we navigate this journey, let’s remember that our goal is not just to build great software but to build great teams, drive business success, and create a culture of innovation and excellence.

Stay curious, keep learning, and keep pushing the boundaries of what’s possible.

The Fallacy of “Years of Experience” in Software Development

In the ever-evolving landscape of software development, the metric of “years of experience” has long been considered a gold standard for assessing a developer’s expertise. However, as the industry matures and the complexity of technology deepens, it’s becoming increasingly clear that this measure is not only outdated but often misleading. Let’s dive into why “years of experience” should no longer be the primary gauge of a developer’s prowess and explore what truly reflects a developer’s skill and impact.

The Irrelevance of “Years of Experience”

Experience Doesn’t Equate to Expertise: Merely clocking in years at a job does not guarantee a deep understanding or mastery of software development. A developer with ten years of repetitive, unchallenging tasks may know far less than a developer with three years of intense, varied projects. Quality and diversity of experience eclipse the sheer passage of time.
Rapidly Changing Technologies: The tech world is in a constant state of flux. Programming languages, frameworks, and best practices evolve at a breakneck pace. A developer who hasn’t kept up with these changes may find their once-relevant skills becoming obsolete. It’s not about how long you’ve been coding but how well you’ve adapted to and adopted new technologies.
Innovation and Problem-Solving Over Time Served: Software development is fundamentally about solving problems and innovating. A developer who consistently finds creative, effective solutions and can bring them to fruition is far more valuable than one who simply logs hours. Innovation is not a function of time; it’s a function of mindset and approach.

Better Measures of a Developer’s Skill

Successful Solutions Deployed: A more meaningful measure of a developer’s capability is the number and impact of successful solutions they’ve deployed. This includes applications, systems, and features that solve real-world problems, meet user needs, and provide business value. A track record of successful deployments speaks volumes about a developer’s practical skills and effectiveness.
Longevity and Iteration of Solutions: For developers with 5+ years in the field, an excellent metric is the longevity and continuous improvement of their solutions. How many of their deployed solutions are still in production and actively used? More importantly, are these solutions being iterated on and enhanced, either by the original developer or by others? This indicates not only the robustness and relevance of their work but also their ability to build maintainable, scalable systems.
Breadth and Depth of Projects: Evaluating the variety and complexity of projects a developer has tackled provides insights into their adaptability and breadth of knowledge. Developers who have worked across different domains, tackled diverse challenges, and delivered under varying constraints are likely to have a richer, more versatile skill set.
Community and Contribution: Active participation in the developer community through open-source contributions, technical blogging, mentoring, and speaking engagements can also be a strong indicator of a developer’s passion and expertise. These activities demonstrate a commitment to continuous learning and sharing knowledge, which are crucial traits for staying relevant in the tech industry.

The Path Forward

As we rethink how we assess software developers, it’s crucial for hiring managers and team leads to shift their focus from years of experience to more meaningful metrics. By valuing successful solutions, the longevity and iteration of these solutions, and the breadth and depth of project experience, we can better identify truly skilled and impactful developers.

In practice, this means asking different questions during interviews, emphasizing problem-solving and project-based assessments over resumes and tenures. It’s about fostering an environment where continuous learning, adaptability, and innovation are prioritized and rewarded.

In conclusion, while “years of experience” has been a convenient shorthand, it’s time we move beyond it. Let’s embrace a more nuanced, accurate understanding of what makes a developer truly great. Because at the end of the day, it’s not about how long you’ve been in the game; it’s about how well you implement and play it.

Month: July 2024