As a software engineer turned founder, I am passionate about ensuring that developers are technically equipped. Here are the critical areas of focus to help developers reach their full potential.
Fahim ul Haq is the co-founder and CEO of Educative, the world's leading upskilling platform for and by developers. He is a former software engineer at Microsoft and Facebook with a deep passion for creating better, more efficient ways for developers to master in-demand skills.
Hey, I’m Fahim. Previously a software engineer at Microsoft and Facebook and now founder of a startup educative.io.
Do you remember your first job as a developer? I remember the first time I stepped through the doors of Microsoft's Redmond campus and the feeling of exhilaration for what lay ahead. That was a long time ago. Since then, I've had many more exciting career firsts, from finding a compiler bug (more on this in a future newsletter), joining Facebook (now Meta) during a peak growth phase, and perhaps my favorite first, becoming a founder of Educative. And while the logos and titles may have changed, the challenges of being a developer have not.
Engineering Enablement is a driving topic I’ve wrestled with since my earlier career days as a software engineer. It may not have been called by this name back then, but it’s a nuanced and complex topic that knowledgeable people and influential organizations worldwide are working to better understand. Articles such as “What is Engineering Enablement” helped shape my thoughts around this topic, and it’s encouraging to see more traction on a topic that needs more engagement.
I started the Engineering Enablement Newsletter to share learnings and conversations with others in the tech industry to build a community of individuals passionate about enabling developers to be more productive and successful. At its core, I believe Engineering Enablement covers three core tenets —
Ensuring developers are:
Technically equipped
Aligned to the company objectives
Happy
Engineering Enablement priorities can look different from various perspectives across the organization. Developers are concerned about their work and careers, engineering and technical leaders are concerned with retention and team growth, and business stakeholders need to meet their goals. But no matter which of these groups you’re speaking to, they all align on those three core tenets.
For now, let’s start with the core tenet that I think about every day — technically equipping developers. Taking my background as a software engineer and now leading a product-driven tech startup, I’ve picked up on some critical areas of focus to help developers reach their full potential.
Here are ten pillars for technically equipping developers:
Over several weeks, I would like to use this space to reflect on the industry and start to answer two important questions for each pillar:
Does this practice of engineering enablement have a significant impact on developer productivity and well-being? And if so, how and why?
What tools, practices, and management styles are available today that address this focus area of engineering enablement? And how are they successful?
For now, let’s have a quick overview on ensuring developers are technically equipped.
Tied to a developer’s lifecycle, developer onboarding is more than just the first couple of months at a job; but has three distinct phases or stages of ramping up:
Minimal workable knowledge
T-shaped developer
Long-term mindset for the team
Throughout a developer’s lifecycle at an organization, their onboarding stage helps define potential impact and defines the necessary components to navigate to their next career stage.
Ephemeral
Long-term
Ephemeral collaboration usually happens in messaging apps like Slack or Teams. Conversations typically include asking if people are in the office or not or checking in on a teammate.
Long-term collaboration consists of one-pagers and documents that are important for the learning process of anyone who might join a project. Documenting collaboration around earlier discussions is necessary for quick decision-making.
With globalized companies and distributed teams, asynchronous collaboration tools should prioritize defining remote work as a norm than an exception. Ideally, people on the tool seamlessly collaborate on each other’s work and make sure people aren’t blocked. We’ll cover this and other important collaboration priorities in more detail with upcoming newsletters.
Ultimately, developer environments should provide developers with a performant coding environment that can run on their machine. Docker technology helps create an agnostic solution for companies with a wider range of hardware for remote teams.
I’ll later cover why internal teams should invest in writing custom plug-ins that enhance the experience for your organization, while also covering the importance of internal documentation, internal libraries, networks, and VPNs.
GitHub and Gitlab are the main repositories used by developers, but there’s also a greater conversation around mono or multiple repos. Let’s discuss this in future articles.
Great tools facilitate code reviews and enables teams to ship better products. But code reviews is as much about culture as it is about great tooling.
If you’re not deliberate about creating a good code review culture, they can become toxic. I’m fairly passionate about this topic, so I look forward to discussing how to create a good culture around code reviews that is productive and helps everyone learn to grow.
Alongside personal accountability comes transparency between the developers and their managers. Growth is important to both engineers and their managers. Great engineering leaders intentionally create a culture of feedback, and timely feedback provides opportunities for consistent growth within engineers and their teams.
With faster feedback loops, developers can work on other items, and receive early indications of how their code will perform in production.
I’m eager to share how testing frameworks should tie into the CI/CD infrastructure. I’ll later cover the importance of creating a culture of writing testable code and why developers should write code they can test to find bugs and regressions.
Ultimately, every software engineer should have easy access to quickly upskill themselves. For future newsletters, we’ll discuss how developer learning funnels into conversation topics such as developer retention, shipping code faster, APIs, developer satisfaction, and frameworks.
It’s a big space, and I’m curious to hear others’ approaches and perspectives as my following newsletters dive deeper into each focus area.
Until then, feel free to subscribe, and let’s talk soon.
A focus on standard developer collaboration practices and how they should be modified to better enable developer productivity.
Instead of thinking about Developer Onboarding as one gigantic task, splitting it into three distinct stages enables developers to grow faster in...
It can be daunting for new developers transitioning into a new engineering role as they deal with unfamiliar codebases and high expectations. It is...