Mentoring
Webinar: How I became an engineering leader
Developers turned engineering managers discuss the skills you need to level up your career.
Investing in a great build system is the lowest hanging fruit for developer productivity.
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.
When I first arrived at Microsoft, I was immediately suspicious of dedicated release teams and their value-add to my work. Having come from a background of only writing with a group of roughly 3-4 people, I was dismissive of this team — partly because these teams gave me the impression of a bloated process.
Over time, I understood the value of this team, and I realized that there’s a nuanced balance to prevent dedicated teams from becoming more akin to a meaningless and lengthy process. It’s about finding the right mixture of the best developer tools to create a delightful shipping and building lifecycle for the developer.
Speaking of a delightful build-and-ship lifecycle: most developers spend a lot of their time in the developer environment. Today, I’ll focus on the basics of the IDE you choose for your developer team, but more importantly, the holistic view of IDEs from the vantage point of an engineering leader. Here’s what we’ll cover today:
- The minimum requirements
- Thinking like an engineering leader
- What Business Problems Do Developer Environments Need to Address?
- Next Steps: Improving your developer tools
The minimum requirements
We all know the basics of every developer environment should include opening indexed files, autocomplete support, and basic searchable functions for any new team member to get an idea of how the code is structured. Ultimately, the function of any developer environment should provide developers with a performant coding environment that can run on their machines.
For companies with a broader range of hardware for remote teams, Docker and other cloud-based containers can provide a hardware-agnostic solution for distributed developers.
In my opinion, IDE is a set of tools that makes development delightful and debugging relatively easy.
How an engineering leader should think about IDEs
If you think of IDEs as a desktop application, you’re thinking too small. Think of IDEs as not just one tool with plug-ins and integrations but as multiple IDEs created to work with various team members, multiple repos, and different stages of shipping — all while providing snapshots in staging, testing, and shipping. It’s in your hands to think about the consequences of multiple developers making changes simultaneously to the codebase and the downstream impacts.
The IDE should integrate everything from deploying on your machine to running in a one-box, making changes on the codebase, and observing outputs without tedious deployment steps. In other words, leaders must view the desktop applications we call IDEs as part of a whole system of development.
With all this in mind, it’s even more critical to ensure you’re refreshing your IDE every 3-4 years to tackle technical debt early. In different words, you’re investing in your company’s future and streamlining the process your developers go through to create a seamless build and deployment experience.
What Business Problems Do Developer Environments Need to Address?
Here are five questions, especially for smaller companies, that every engineering leader needs to answer in order to prevent technical debt and assure non-technical business stakeholders.
-
What’s the time from test to deployment in your staging environment?
This is a fundamental step every developer goes through multiple times a day. By finding the time, there’s a more accessible lift in translation to directly impact costs. -
How much time is taken to build the code?
If the time taken to build code is longer than expected, it might be a good indication to clean up your library, such as starting with correct caching.
-
How much time is taken to deploy the code?
Sometimes deploying takes you a while. You can configure one-box development environments so your developers can test at a basic level without deploying it elsewhere.
-
How much time does it take to successfully close a pull request or merge into the master branch?
The first step is to invest in automated testing. When you have few engineers, your testing system scales well, but you hit problems faster than you think with 10s of engineers queueing up multiple requests.
If it takes 3 hours of testing and your developers are stuck waiting, you’ll need to improve your BVT (Build Verification Testing) process so that your developers can run tests in minutes, with exceptions for more extended tests that run all the changes. Investing in parallel automatic testing gives your team a more scalable and delightful development experience.
-
When debugging an issue, how many steps does it take to access the data and logs required to debug an issue?
Logs from testing issues should be easy to access and stream to the developer’s machine. While there’s a higher bar at larger companies because of security concerns, you should have a system that ships logs to a central server for developers to access quickly.
Eventually, you would build a distributed logging system or cloud watch. Here are two helpful resources for your reference:
Next Steps: Improving your developer tools
As your company builds a designated engineering enablement team, they can continue to evolve these IDEs so that developers don’t have to take hours of configuration and setup. Instead of taking 100 steps to deploy code to production, the steps can be streamlined to take ten steps from building to deploying code.
Optimizing IDEs is not just about an application; it’s about improving the entire development cycle from writing to shipping code. From deploying on your machine, running on a one-box, making changes in the codebase, and observing performance without tedious deployment steps. From there on, a release team and DevOps can take it to staging and deployment.
Ultimately, your team will build, compile, and deploy to production faster and eventually have a dedicated DevOps release team.
A famous XKCD comic shows a developer wasting a ton of time waiting for the compiler. It’s comically relatable for any engineering leader but also an improvement area. With a slow build system, your developer is wasting a lot of time; if they run into a compiler error, your developer has to restart the whole process.
Investing in a great build system is the lowest hanging fruit for developer productivity. With different build systems (Bazel, CMake), you must choose based on your team’s needs. Developers will be demoralized if they wait hours to test a couple of lines of code change. It’ll feel like building software with punch cards. With a quicker build system, you’ll have a substantial competitive advantage for the health and productivity of your engineering organization. Most importantly, it’ll make your developer’s development process delightful.