Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
DevOps / Software Development

Developer Experience: Devs Shouldn’t Have to “Figure It Out”

Developer Experience (DX) is the overall interactions and feeling that the developer feels when working towards a goal.
Aug 16th, 2021 10:00am by
Featued image for: Developer Experience: Devs Shouldn’t Have to “Figure It Out”
Feature image via Pixabay.

Looking at where major DevOps trends are headed, a common theme across many tools and practices is improving the developer experience. One paradigm of thinking is that if you improve your internal customer experience, then your external customers will benefit too. However, up till now the developer experience has been quite siloed and segregated — for a multitude of reasons, such as scaling or having best-of-breed technologies to support individual concerns.

What Is Developer Experience (DX)

Ravi Lachhman
Ravi is an evangelist at Harness. Prior to Harness, Ravi was an evangelist at AppDynamics. Ravi has held various sales and engineering roles at Mesosphere, Red Hat and IBM, helping commercial and federal clients build the next generation of distributed systems.

Developer Experience (DX) is the overall interactions and feeling that the developer feels when working towards a goal. It is similar to the definition of User Experience (UX), except in this case the primary user is a software engineer. The core definition of UX is how a user interacts and experiences a product, system, or service — focusing on perceptions of utility, ease of use and efficiency. User experience focuses on improving customer satisfaction and loyalty. Developers, however, are internal customers, rather than the external customers that traditional UX targets.

With the consumerization of enterprise IT, the expectation for users of enterprise systems continues to rise, because of their experiences outside of the enterprise. Seen as highly technical when compared to an average business system user, the developer experience can sometimes take a back seat because of a stigma that “developers can just figure it out.” Having poor DX is a detriment to overall engineering efficiency and the ability to innovate and iterate while not adding to technical debt.

How Do You Measure Developer Experience?

Similar to user experience, there can be multiple objective and subjective measures of developer experience. Focusing on the three pillars of user experience — usability, findability and credibility — are also excellent markers of measuring developer experience.


Usability is how easy your software or service is to use. It answers the question, “Would a first-time user of your platform be able to achieve their goal?” Also, usability is about removing barriers. For example, unnecessary steps. Measuring usability for internal customers might be a little more challenging if the frameworks that are in place for UX for external customers are not there. Surveys are a good way of gathering feedback and also, if possible, using remote usability tests such as heat-mapping and tracking tools to measure interaction and drop-off.


Findability is how easy or quickly a user of your software or service can find the functionality they are looking for. Having logical, contextual and concise search and navigation features are important. Supporting the user journey across their changing tasks alludes to good findability. Similar to measuring usability, asking users what they think or having the ability to record times and use heatmaps of what is being clicked on, or where frustration starts, are all good steps.


Credibility is that your users trust your software or service to solve their problems. Credibility is a long-term pillar, not only for today’s needs but for tomorrow’s needs also. The changing landscape of developer technology does make this hard to keep up. For developer experience, having a service that is reliable and performant is key to credibility. Meeting the scaling needs of the wide swath of technologies that internal customers use can be challenging. Continued adoption of your software or service is a key measure of credibility.

One pitfall to avoid is just focusing on the output first. For example, observability in the manufacturing world infers that if the output is good, the internal states are good too. If your team or organization is producing a lot, then the DX must be good. The truth is, that’s not necessarily the case — high production might be one indicator, but there might also be high toil or high burn. The expertise, staff and overhead costs are high to produce large amounts of artifacts.

Good developer experience will lead to more efficient, and thus more highly productive, teams. Looking at the four key metrics from Accelerate (deployment frequency, lead time for changes, MTTR, and change failure rate), can all improve with improvements in developer experience.

What Does Good Developer Experience Look Like?

Good developer experience supports innovation, iteration, safety and velocity. Great developer experience allows developers to focus on and experiment with what is important — and not pick up technical debt with non-functional or application operational concerns (such as scaling and robustness) along the way. Software is a team sport. Allowing for quick integration and deployment of changes, to get them into the hands of the end users, is the goal of software engineering.

Two of the biggest detriments of developer experience are context switching and decision fatigue. Imagine a customer service representative at an airline having a high volume of complex issues, switching between multiple systems, and reaching out to different departments for answers or expertise — that can drive up resolution time (an example of context switching). The need to constantly make decisions and negotiate can also lead to decision fatigue. Ironically, software engineers face similar dilemmas navigating the end of their workstreams — e.g. heading to production and supporting production.

Because of competing priorities and deadlines, software engineers are great at finding the path of least resistance — so technical debt can accrue if they’re not careful. Reducing context switching and decision fatigue for developers, by having highly usable and credible software and platforms, makes for a great DX.

Comparing StackOverflow Developer Survey results over the last few years, an interesting trend appears. In today’s market, it is not normal for someone to work their entire career on one project or at one firm. The amount of time that developers are on projects is decreasing, and the amount of time that it takes developers to be productive members of the team (ramping uptime) is increasing. Developer experience is key to building and maintaining the next generation of software and platforms. Good DX will help reduce ramp-up time and assist in the ultimate goal: getting ideas to production.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.