↓Skip to main content

Ditch old tools and habits for the golden tools of your new company

·9 mins
Table of Contents

Q: A company I interview with said they only support one IDE for the entire company. I don’t feel like working for orgs that force a specific IDE on engineers. Plus, who knows what else they are enforcing. Should I bow out?

When engineers join a new organization, they bring their expertise and experience. That’s why companies hire them in the first place. But they also carry baggage: convictions, expectations, and customs that do not always fit the new organization. The list goes on to accompany the baggage with tooling preferences, such as IDEs, editors, terminal emulators, operating systems, and workflow ergonomics.

It’s frowned upon when an organization we’re to join asks us to learn a new tool or break our ergonomics mold. Why is that? In fact, why is it acceptable, and even encouraged, to learn a new language or framework at work, but learning a new IDE makes our blood boil? Or a new command-line tool with different ergonomics to what we are used to?

Most of us fail to realize that growing a business to a non-trivial scale is not achievable without standardization and opinionated approaches. And yes, sometimes said standards can be at odds with the preferences of some engineers. But, in continuation, I will share a perspective on why standardization should not be a deal-breaker. I will also give you an angle to see how a company applies standardization at scale will help you grow as an engineer.

In continuation, we’ll discuss:

  • Why shipping is the company’s heartbeat
  • What is a “golden path”
  • What are “golden tools” and some examples
  • Why (wrong) golden tools shouldn’t be a dealbreaker
  • Why embracing the golden tools is helpful for your career

Shipping is your company’s heartbeat #

As Intercom’s CTO Darragh Curran wrote back in 2017, software only becomes valuable when you ship it to customers. Shipping brings the software, and by extension the company, to life. If users don’t have the product in their hands, it’s useless regardless of how useful or pretty it is.

Putting the software in front of customers can provide value, and in return, the same customers reward the company by paying for the software. A continued improvement of the product by adding features or eliminating defects is how the company retains the old and acquires new customers. Its ability to ship continuously is paramount for the product improvements to continue.

While shipping is (usually) trivial for startups, many shipping “guardrails” start to spring off as the companies scale. With a great variety of half-baked tooling, it’s common to see engineers reinventing wheels to facilitate shipping or other cross-cutting concerns. Unfortunately, engineers end up expending energy that they should spend on shipping actual valuable software to the end-users. Reinventing wheels slow down the heartbeat, and scale-ups must fight this phenomenon.

So, the natural question is, how can companies keep scaling while keeping their heartbeat intact?

The golden path #

When a company reaches a non-trivial scale to continue shipping, they commonly create a “golden path”. In the wild, folks use “golden” or “blessed” or “paved” path, but the idea is the same: the golden path is the organization’s path with the least resistance to a technical goal. In my mind, the golden path is the opinionated and supported path to frictionless shipping helped by the company’s guardrails.

Spotify defines its golden path as the ‘opinionated and supported’ path to ‘build something’. Charity Majors, in her article on the topic, explains the golden path as:

The recommended list of default components for developers to use when building new services. The path of convergence and the path of least resistance.

A golden path unlocks a few things:

  • Prevents tech stack sprawl – the organization standardizes on a palette of technologies and tools, making them the obvious choice for the problem. Conversely, skewing away from the palette is challenging and adds friction.
  • Innovation and shipping velocity - product engineers, don’t have to think about choosing technologies, only about using the golden stack to deliver value to customers.
  • Nurtures guardrails - the golden tools, technologies, and frameworks create a set of guardrails for the product’s ecosystem. The guardrails allow engineering teams to focus on what matters while obeying the domain’s rules.

So, where does developer tooling fit in the picture?

Golden developer tooling #

Spotify centers its Golden Path on step-by-step tutorials about building, but my interpretation extends to the developer tooling. As an extension to the golden path, the tooling that the company has chosen to support, so-called ‘golden’ tools, are the supported tools that integrate without friction in the company’s ecosystem.

Companies that take developer productivity earnestly strive to provide best-in-class tooling. But supporting all popular tools in each category is prohibitively expensive. Therefore when defining the golden tooling, organizations must make an informed bet and invest in a narrow subset of tools they will standardize on. That’s why one’s favorite IDE might not be supported or allowed – but it’s not something that should alert you.

The goal behind the golden tools is not to stifle engineers or to set standards for the sake of putting them. Instead, by using the golden tools, engineers won’t have to reinvent the wheel, have fewer decisions to make, and can focus on shipping.

Examples of golden tooling #

Below I’ve added a non-exhaustive list of examples of golden tooling that I have seen in the wild.

Launching microservices

Folks think that just because a company uses a microservices architecture, they can launch a service in any language they desire. Of course, that’s an option, but the most productive organizations that use microservices support only a few core languages.

Creating a new microservice is commonly a (semi-)automated process that creates a skeleton service with all batteries included in a given language that is immediately deployable. Having all batteries included allows the product teams to focus on delivering value without thinking of any cross-cutting concerns such as logging, observability, CI/CD, etc.

Standardized IDEs

Some companies center the development experience around a single IDE. That allows them to customize the in-editor experience - internal plugins and integrations with the remote development environment that customize the experience beyond what is possible with publicly-available plugins.

For example, through proprietary/internal plugins, the IDE can communicate with internal metrics servers. The IDE can then send telemetry directly to the metrics servers, which can measure the experience of the whole development team. For example, think of boot time, source code indexing time, RAM and CPU consumption, test run resource consumption, etc. The developer experience team can then build off of these insights.

It’s worth pointing out that companies do not prohibit the use of other IDEs, but they support them at best-effort. Such a level of support allows said companies to invest in the experience of the primary IDE beyond what the community accepts as possible. But if some developers want to stray from the paved path and use other tooling - they’re welcome to as long as they are at peace with not having the best development experience compared to the rest.

SDKs for cross-cutting concerns

One example of a cross-cutting concern is observability. While I love the concept and the abilities in unlocks, supporting observability through an in-house tool or integrating with a 3rd party solution such as Honeycomb, is no small feat. In companies with many teams, you can expect some entropy – engineers can reimplement language-specific wrappers of tooling and make it work organically within their domain. Unfortunately, this is an anti-pattern: more code and different solutions to the same problem lead to more bugs and maintenance costs.

A standardized approach that works great is to provide a single SDK-to-language pair – and sunset all other application-specific wrappers or variants of the SDK. While this might appear prohibitive, having a single SDK to instrument components is ideal, as it allows one team (usually the platform team) to maintain and improve said SDK.

Supporting a primary SDK prevents library sprawl and allows for controlled and focussed library development. When a new feature gets added, it is available to all applications using the SDK. All they have to do is bump the library’s version number. And there’s one obvious way to get observability in your service – through the ‘official’ SDK.

Not a deal-breaker #

You don’t like Visual Studio Code but if you accept the new offer you’ll be forced to use it. You are even surprised you are considering it. What is even going on? Is the offer that good? Or is there more to it?

I get it, breaking habits is painful. We invest time and energy to customize our editors/IDEs, or the command line environment. And then we are asked to abandon it because our employer decided to standardize on another tool. It sucks.

But, as with most things, there’s a silver lining: we get to learn and expand our horizons. Software engineers continuously learn (and Google!) to do their job well, so getting exposure to more tooling and ergonomics, while in the short term is painful, this exposure in the long term makes us better engineers. But, on the other hand, some of us consider our habits a step too close to our identity as engineers, which might be a more significant leap for some than others.

Why embracing golden tooling is good for your career #

At the beginning of this essay I brought up “non-trivial scale”. If you are in an organization that has standardized some tooling, it means that they have achieved said scale. And honestly, for engineers that are early in their career, this is a great place to be.

With enough investment on the company’s part, any tooling can be built with sufficient guardrails. But not every company has the budget to do that. If you are landing in an organization that has invested resources into it, you are setting yourself up for exciting learning.

By seeing the golden path in practice, you can expand your horizons and see what is possible. For example, maybe in your previous company, the internal tooling was non-existent, and you were hazardously running data migration scripts on the production data on the production web servers. But in a mature company, you will see how they guard production data (e.g., via access-control lists), how they do data migrations using internal frameworks, and how they run said migrations on separate non-load-bearing machines.

Also, you will see patterns, such as how they manage PII at scale, how they spin off new services and deploy them, or how hundreds of pull requests are reviewed and merged every day. And not just see, but you will also be able to read and improve all the code running behind this tooling and automation.

These are invaluable lessons and experiences that will help you down your career — all for the price of learning a new IDE.

Additional reading #

↑