20 ms·

The Case for ‘Developer Experience’

184 points by PretzelFisch 5y ago

lanstin 5y ago
Nothing new here on the complexity. AOL had a similar service dependency graph around 2004 or earlier. Paypal had a considerably denser graph I made post-D3 in I don’t 2012? 1000 services by name (some segregation by QoS so maybe less code than that implies). The core graph or central service dependencies (removing all the services that just called other services and weren’t themselves called, repeatedly till nothing could be removed) was like a hundred, with many loops.
- lanstin 5y ago
  Having read the whole article, not sure what the point is. Focusing on the problem before the capabilities is good, but so much energy is spent working around missing capabilities, “this service won’t propagate the debug header and the team won’t fix it” that it is natural. I will say design is useful - the AOL graph was mostly hub and spoke. App Routers -> domain specific orchestrators -> single coarse grained functional API. Paypal was more poi;t to point to point. AOL encouraged devs to take some time just mulling over a new problem or new servers until a sensible approach seemed feasible. Few weeks for a 3 month project, few months for a year long project. and in the 90s good software had observability. Metrics and logs and tracing, all on the fly to enable or disable prospective msgs (you had to turn off a certain log msg on the fly when a dev accidentally left would should be a tracing level msg at like an always log level).
bluedino 5y ago
>> The number of developers is currently larger than the population of Australia, growing faster than the population of Brazil, and set to exceed the population of Canada. Does this count the 6 people I interviewed this year that couldn't fizzbuz?
- willcipriano 5y ago
  "Started in 2006, and published twice a year, it provides the most comprehensive, current, detailed data on the state of the developer population. It includes information on the total number of developers in the world, as well as on the total number of developers involved in specific technology areas. This report combines EDC’s proprietary global developer population model with selected findings from EDC’s semi-annual Global Development Survey."[0] Looks like it depends on how "EDC’s proprietary global developer population model" works. [0]https://evansdata.com/reports/viewRelease.php?reportID=9 https://evansdata.com/reports/viewRelease.php?reportID=9
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- vkou 5y ago
  And more importantly, how does that number compare to the number of golf balls that can be fit into a 747?
  - nicbou 5y ago
    You can fit far fewer than a million developers in a 747
- phkahler 5y ago
  >> Does this count the 6 people I interviewed this year that couldn't fizzbuz? Yes. The bell curve for software developers is very wide. The 10x developers are real, they're way out there - maybe 2 standard deviations from average. The "can't fizzbuzz" crowd is large, probably only 1 standard deviation (or less) below average.
  - danbmil99 5y ago
    1 out of 6 programmers can't solve fizzbuzz? That seems way too harsh. 2 standard deviations would mean 2.5%, or 1 in 40 -- that seems more likely, at least in my DX
    - vikingerik 5y ago
      This is a well-known sampling bias. The number of interview candidates who can't solve fizzbuzz is very high, because those are the people who aren't in jobs and are therefore interviewing. Interview candidates are a skewed sample of the entire population.
- LurkingPenguin 5y ago
  > Does this count the 6 people I interviewed this year that couldn't fizzbuz? No, but it does count the 1 guy who started a Shopify store and has made 6 figures selling "Do u even fizzbuzz bro?" t-shirts.
deleted 5y ago
[deleted]
kaycebasques 5y ago
Tangential idea: I worked on Google's Web DevRel team for about 6 years. Another core conflict I saw a lot is the tension between developer experience and user experience. An improvement in developer experience sometimes resulted in a degraded user experience.
- orf 5y ago
  Can you give some examples?
  - noahtallen 5y ago
    One example is dropping support for older browsers. Dropping IE support is better DevX because debugging esoteric IE bugs is very time consuming. But if you have a lot of people using IE, dropping it is worse UX for them, especially if they are using IE6 from a very old OS and can’t get the latest browser. So at that point, the balance becomes “ok, if less than 1% of requests come from this browser, we don’t explicitly support it.”
    - no_butterscotch 5y ago
      This is similar for Android developers. How soon can we drop support for Android OS #? Because # doesn't have the easier to use animation API, or because we'll need to display an extra modal, or some such.
    - msh 5y ago
      That can just as well be a business decision. We have X budget for this website, we currently have > X expenses so what can we cut. Then cutting the difficult browser is not a hard decision.
      - judge2020 5y ago
        This is how it works and HN complains about it a lot, ie. when some service or program doesn't support Linux or Firefox.
stevebmark 5y ago
One downside I've observed from focusing on DX: We have too many single page apps / Jamstack sites, where the default is to send the entire application in Javascript bundles, and do little to no HTML over the wire. This is inherently bad for performance and especially bad for mobile. It's why the Jamstack mascot is the loading spinner. The much better solution, SSR first with optional client hydration, takes more developer work and more cognitive overhead. It's much easier to write a React application and not worry about server side specific data fetching to do universal rendering, even though that's the strongest option for performance. Next.js is bringing us closer to the DX of enabling SSR first by default, but it's not there yet and many people use Next.js only for SPAs or static rendering, and miss the point that its main power is universal/SSR. My main takeaway is that DX is important when it introduces the right abstractions that are also end user focused.
- Zababa 5y ago
  > The much better solution, SSR first with optional client hydration, takes more developer work and more cognitive overhead. I would argue it takes less developer work and cognitive overhead if you're doing traditional SSR.
  - H12 5y ago
    And the newer HTML-over-WebSockets pattern takes this even further, IMO. In my (admittedly limited) experience, it's hard to beat the DX provided by Phoenix LiveView.
    - aabbcc1241 5y ago
      That DX can be futher improved with static type check (e.g. with typescript)
      - Zababa 5y ago
        I agree with static typing, but disagree with TypeScript itself. It's a great tool to type existing JS code, but for greenfield projets I find it lacking. Structural typing means that you can't make the difference between an address and a name without resorting to branding, which sucks. Strict null checks are opt in. ADTs are a pain to use.
rememberlenny 5y ago
While only slightly relevant to the content of the article, the author has an incredible tweet thread. "Taylor Swift as classic programming textbooks, a thread." https://twitter.com/jeanqasaur/status/1290883041418649600?s=20 https://twitter.com/jeanqasaur/status/1290883041418649600?s=...
madrox 5y ago
I’ve advocated DX across my leadership career. However, I believe current development methodologies are at odds with significant DX improvement. Engineers didn’t start out making micro service architecture. It emerged as a consequence of large organizations running agile teams (Conway’s Law). Agile teams are solving their problems, which are a subset of the org’s problems at best or ironically opposed to them at worst. Anyone who’s had to fight another team to get something done knows what I’m talking about. That means DX will always cater to the lowest common denominator among them, much like third party tools will try to solve for breadth of user needs over depth. If we really want a better DX paradigm, we need to figure out another way of working that isn’t agile, either with a big A or a little a. I don’t know what that is yet, but doing anything less will just be the equivalent of making a better Jira.
- mooreds 5y ago
  > we need to figure out another way of working that isn’t agile, Isn't devops the next generation? (I mean devops as promulgated by Accelerate: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 https://www.amazon.com/Accelerate-Software-Performing-Techno... , not 'smoosh the devs and ops teams together, add Jenkins and hope for the best'.)
  - madrox 5y ago
    I'm not convinced it's materially different. At scale it looks similar to large agile organizations of today.
macando 5y ago
Great analysis. My only remark is that the focus is fully on the backend/infra. On the frontend, observability and transparency are the main reasons why I still use Redux and its dev tool. It's like live logs on steroids. Not only do you see the chain of actions that led to a certain outcome, you see the state at each step. This makes the reasoning about the bugs much easier. There was a tool on Show HN a few days ago that does exactly this but on the browser level[0]. And DX in general? Well, this is how it's stacked in today's startups https://pbs.twimg.com/media/FAIZRuaVQAEGwGU?format=jpg&name=small https://pbs.twimg.com/media/FAIZRuaVQAEGwGU?format=jpg&name=... [0] https://news.ycombinator.com/item?id=28539247 https://news.ycombinator.com/item?id=28539247
cryptica 5y ago
Nice article. Excellent point about software heterogeneity. Ecosystems and platforms should support potentially a wide range of different tools, engines, languages, hardware... Heterogeneity is necessary for 'natural selection' to take place and to ensure that the ecosystem/platform can evolve over time.
- chubot 5y ago
  This is one of the main motivation for Oil: we have more and more languages and tools and they will never be consolidated. Software is being used in more and more areas so this is natural / inevitable. Slogan: Shell is the Language of Heterogeneity and Diversity https://www.oilshell.org/blog/2021/07/blog-backlog-1.html https://www.oilshell.org/blog/2021/07/blog-backlog-1.html To be concrete, a "monoglot" lives in a world where the language's package manager is responsible for integrating different pieces of software. In contrast, a polyglot uses multiple languages, and the package managerS (plural) are just tools, not the world, and they're called from shell scripts! (Or something morally equivalent, like a Makefile or Dockerfile) The future is more polyglot, e.g. your Rust or Zig code will coexist with a lot of C and C++ code. Sometimes they will be linked into the same process, but often they'll live in different processes and you'll use various forms of IPC.
macando 5y ago
Since the article is talking about the great expansion I'm offering a counterpoint - the great collapse. https://www.swyx.io/js-third-age/ https://www.swyx.io/js-third-age/ > Collapsed Layers (One thing doing many things well instead of many things doing one thing well)
rytcio 5y ago
I think the author misses the mark about what the problem is with developer experience, although they get the analogy of a "rainforest" correct. Developers are in a run-away-train kind of situation, where they think that more libraries, more frameworks, more tools, more languages, more abstractions, etc. is the key to a better developer experience. In reality, this is the exact thing that is making development and developers miserable. The whole `is_even` fiasco [0] should have been a wake up call. The plain fact of software development is that there is going to be complexity, and there is going to be some point where adding features or fixing things is going to become a slog. The choice where do you want that to happen? With the never-ending reliance on libraries, frameworks, tools, etc. the difficulties has been shifted towards the latter half of development, "we'll worry about that later". Sure, the share holders and the angel investors are stoked when a team can get an app running in a few months. But guess what, down the road when it comes time to add more features, make it fast, to flesh out the app into its full potential...it will end up in a nightmare of trying to wrestle the code and the barely comprehensible infrastructure to get it to do what they want. Good luck trying to figure out what is making the app slow in that rainforest. The best thing I ever did for my mental health when working on hobby projects was to keep it simple stupid. In the case of C++ and games, I do everything in my own code maybe using Sean Barret's header files or GLFW for Window and input. Use a .bat file to build the code, rather than some overly complicated build tool so that it can build in 2 seconds rather than 5 minutes giving me very fast iteration speed. The Vulkan rendering code, the math, system level stuff like memory and file IO is all my own. For web stuff, I wrote a production web app for an internal team in a single PHP file with only a templating library. Going this route has undoubtedly doubled my productivity. Static site generator? I'd rather write one in Python than try to figure out some complex dependency ridden mess of an open source tool that never does what I want it to do. The pain of developer experience is self inflicted. In an effort to reduce friction in development, a system of increasingly worse friction has been introduced. Programmers need to stop being afraid of writing code, and, dare I say stop being lazy. Developers could be just as productive, if not more productive, if they would just write the code. [0] https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ https://qz.com/646467/how-one-programmer-broke-the-internet-...
- lifeisstillgood 5y ago
mooreds 5y ago
I'm a big fan of TID: Trust in Developers. That means building out an application and experience that has the following: * a substantial education component. You are an expert in X, so educate developers so they can get better at X * meets developers where they are (in terms of languages and tooling) * allows both high and low levels of abstraction (including a well documented and consistent API) * free to start (even though we all have to eat, developers want to kick tires with minimal effort) * encapsulated functionality that does a few things and a few things well. The RDBMS is a model here. * an open feedback loop, typically on GitHub or in public. (Slack is a bit of an anti-pattern here.) I don't know how devs are going to use tools built for them, but the last thing I want is for them to be disempowered. The farthest end of the empowerment spectrum, of course, is open source, but there are business model problems with that. I've written on that before: https://www.mooreds.com/wordpress/archives/3438 https://www.mooreds.com/wordpress/archives/3438 For another smart, if different take, read this: https://redmonk.com/jgovernor/2020/11/26/addressing-the-developer-experience-gap-newcode-or-gluecode/ https://redmonk.com/jgovernor/2020/11/26/addressing-the-deve... The post talks about tooling and a cohesive structure as the next great opportunity.
oblib 5y ago
I got to "With developers spending less than a third of their time actually writing code," and thought "what?" then read the rest of it: "developer experience includes all the other stuff: maintaining code, testing, security issues, addressing incidents, and more." and then though "oh yeah... that's about right on a good day" lol!
bmeski 5y ago
I’ve had “engineers” at my company push leadership enough to force me to create a build/plug-in system for react components to render a map of the US. I made the same map in D3 at home over the weekend in vanilla JS. The excuse was DX. How can we test it and use storybook if we don’t use react and generate a giant dingus of a bundle? Edit: so don’t just trust “engineers”.
mercurialsolo 5y ago
DX today exists at lots of different levels, from competitive code games, to hackathons, to well formatted docs & code samples - all IMO form a larger umbrella of DX. I still see it as an emerging field with more work done to synthesize under a single umbrella of being able to communicate abstraction levels, concept understanding, adding explainability to decision models and of course tailored for the skill tree at where the target developer today is at.
Derbasti 5y ago
> It’s certainly possible, for some problems, to automate the problem away. But other problems (for instance, finding and fixing bugs) cannot be fully abstracted, often requiring user input. I think that's not the right way to look at it. It's just that a task that's automated no longer needs a dev. Thus we only work on things not (yet) automated. As a corollary, easy-to-replace parts inevitably become replaced with hard-to-replace parts, because those are the ones that stay.
LurkingPenguin 5y ago
> As every company continues to become a technology company inside — regardless of product or service — developers are getting more of a say. I know this is Silicon Valley gospel but just because technology is a critical part of many if not most companies' operations today doesn't mean that those companies are "technology companies."

184 points by PretzelFisch 5y ago

Nothing new here on the complexity. AOL had a similar service dependency graph around 2004 or earlier. Paypal had a considerably denser graph I made post-D3 in I don’t 2012? 1000 services by name (some segregation by QoS so maybe less code than that implies). The core graph or central service dependencies (removing all the services that just called other services and weren’t themselves called, repeatedly till nothing could be removed) was like a hundred, with many loops.

lanstin 5y ago
Having read the whole article, not sure what the point is. Focusing on the problem before the capabilities is good, but so much energy is spent working around missing capabilities, “this service won’t propagate the debug header and the team won’t fix it” that it is natural. I will say design is useful - the AOL graph was mostly hub and spoke. App Routers -> domain specific orchestrators -> single coarse grained functional API. Paypal was more poi;t to point to point. AOL encouraged devs to take some time just mulling over a new problem or new servers until a sensible approach seemed feasible. Few weeks for a 3 month project, few months for a year long project. and in the 90s good software had observability. Metrics and logs and tracing, all on the fly to enable or disable prospective msgs (you had to turn off a certain log msg on the fly when a dev accidentally left would should be a tracing level msg at like an always log level).

bluedino 5y ago

>> The number of developers is currently larger than the population of Australia, growing faster than the population of Brazil, and set to exceed the population of Canada. Does this count the 6 people I interviewed this year that couldn't fizzbuz?

willcipriano 5y ago
"Started in 2006, and published twice a year, it provides the most comprehensive, current, detailed data on the state of the developer population. It includes information on the total number of developers in the world, as well as on the total number of developers involved in specific technology areas. This report combines EDC’s proprietary global developer population model with selected findings from EDC’s semi-annual Global Development Survey."[0] Looks like it depends on how "EDC’s proprietary global developer population model" works. [0]https://evansdata.com/reports/viewRelease.php?reportID=9 https://evansdata.com/reports/viewRelease.php?reportID=9
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
vkou 5y ago
And more importantly, how does that number compare to the number of golf balls that can be fit into a 747?
- nicbou 5y ago
  You can fit far fewer than a million developers in a 747
phkahler 5y ago
>> Does this count the 6 people I interviewed this year that couldn't fizzbuz? Yes. The bell curve for software developers is very wide. The 10x developers are real, they're way out there - maybe 2 standard deviations from average. The "can't fizzbuzz" crowd is large, probably only 1 standard deviation (or less) below average.
- danbmil99 5y ago
  1 out of 6 programmers can't solve fizzbuzz? That seems way too harsh. 2 standard deviations would mean 2.5%, or 1 in 40 -- that seems more likely, at least in my DX
  - vikingerik 5y ago
    This is a well-known sampling bias. The number of interview candidates who can't solve fizzbuzz is very high, because those are the people who aren't in jobs and are therefore interviewing. Interview candidates are a skewed sample of the entire population.
LurkingPenguin 5y ago
> Does this count the 6 people I interviewed this year that couldn't fizzbuz? No, but it does count the 1 guy who started a Shopify store and has made 6 figures selling "Do u even fizzbuzz bro?" t-shirts.

deleted 5y ago

[deleted]

kaycebasques 5y ago

Tangential idea: I worked on Google's Web DevRel team for about 6 years. Another core conflict I saw a lot is the tension between developer experience and user experience. An improvement in developer experience sometimes resulted in a degraded user experience.

orf 5y ago
Can you give some examples?
- noahtallen 5y ago
  One example is dropping support for older browsers. Dropping IE support is better DevX because debugging esoteric IE bugs is very time consuming. But if you have a lot of people using IE, dropping it is worse UX for them, especially if they are using IE6 from a very old OS and can’t get the latest browser. So at that point, the balance becomes “ok, if less than 1% of requests come from this browser, we don’t explicitly support it.”
  - no_butterscotch 5y ago
    This is similar for Android developers. How soon can we drop support for Android OS #? Because # doesn't have the easier to use animation API, or because we'll need to display an extra modal, or some such.
  - msh 5y ago
    That can just as well be a business decision. We have X budget for this website, we currently have > X expenses so what can we cut. Then cutting the difficult browser is not a hard decision.
    - judge2020 5y ago
      This is how it works and HN complains about it a lot, ie. when some service or program doesn't support Linux or Firefox.

stevebmark 5y ago

One downside I've observed from focusing on DX: We have too many single page apps / Jamstack sites, where the default is to send the entire application in Javascript bundles, and do little to no HTML over the wire. This is inherently bad for performance and especially bad for mobile. It's why the Jamstack mascot is the loading spinner. The much better solution, SSR first with optional client hydration, takes more developer work and more cognitive overhead. It's much easier to write a React application and not worry about server side specific data fetching to do universal rendering, even though that's the strongest option for performance. Next.js is bringing us closer to the DX of enabling SSR first by default, but it's not there yet and many people use Next.js only for SPAs or static rendering, and miss the point that its main power is universal/SSR. My main takeaway is that DX is important when it introduces the right abstractions that are also end user focused.

Zababa 5y ago
> The much better solution, SSR first with optional client hydration, takes more developer work and more cognitive overhead. I would argue it takes less developer work and cognitive overhead if you're doing traditional SSR.
- H12 5y ago
  And the newer HTML-over-WebSockets pattern takes this even further, IMO. In my (admittedly limited) experience, it's hard to beat the DX provided by Phoenix LiveView.
  - aabbcc1241 5y ago
    That DX can be futher improved with static type check (e.g. with typescript)
    - Zababa 5y ago
      I agree with static typing, but disagree with TypeScript itself. It's a great tool to type existing JS code, but for greenfield projets I find it lacking. Structural typing means that you can't make the difference between an address and a name without resorting to branding, which sucks. Strict null checks are opt in. ADTs are a pain to use.

rememberlenny 5y ago

While only slightly relevant to the content of the article, the author has an incredible tweet thread. "Taylor Swift as classic programming textbooks, a thread." https://twitter.com/jeanqasaur/status/1290883041418649600?s=20 https://twitter.com/jeanqasaur/status/1290883041418649600?s=...

madrox 5y ago

I’ve advocated DX across my leadership career. However, I believe current development methodologies are at odds with significant DX improvement. Engineers didn’t start out making micro service architecture. It emerged as a consequence of large organizations running agile teams (Conway’s Law). Agile teams are solving their problems, which are a subset of the org’s problems at best or ironically opposed to them at worst. Anyone who’s had to fight another team to get something done knows what I’m talking about. That means DX will always cater to the lowest common denominator among them, much like third party tools will try to solve for breadth of user needs over depth. If we really want a better DX paradigm, we need to figure out another way of working that isn’t agile, either with a big A or a little a. I don’t know what that is yet, but doing anything less will just be the equivalent of making a better Jira.

mooreds 5y ago
> we need to figure out another way of working that isn’t agile, Isn't devops the next generation? (I mean devops as promulgated by Accelerate: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 https://www.amazon.com/Accelerate-Software-Performing-Techno... , not 'smoosh the devs and ops teams together, add Jenkins and hope for the best'.)
- madrox 5y ago
  I'm not convinced it's materially different. At scale it looks similar to large agile organizations of today.

macando 5y ago

Great analysis. My only remark is that the focus is fully on the backend/infra. On the frontend, observability and transparency are the main reasons why I still use Redux and its dev tool. It's like live logs on steroids. Not only do you see the chain of actions that led to a certain outcome, you see the state at each step. This makes the reasoning about the bugs much easier. There was a tool on Show HN a few days ago that does exactly this but on the browser level[0]. And DX in general? Well, this is how it's stacked in today's startups https://pbs.twimg.com/media/FAIZRuaVQAEGwGU?format=jpg&name=small https://pbs.twimg.com/media/FAIZRuaVQAEGwGU?format=jpg&name=... [0] https://news.ycombinator.com/item?id=28539247 https://news.ycombinator.com/item?id=28539247

cryptica 5y ago

Nice article. Excellent point about software heterogeneity. Ecosystems and platforms should support potentially a wide range of different tools, engines, languages, hardware... Heterogeneity is necessary for 'natural selection' to take place and to ensure that the ecosystem/platform can evolve over time.

chubot 5y ago
This is one of the main motivation for Oil: we have more and more languages and tools and they will never be consolidated. Software is being used in more and more areas so this is natural / inevitable. Slogan: Shell is the Language of Heterogeneity and Diversity https://www.oilshell.org/blog/2021/07/blog-backlog-1.html https://www.oilshell.org/blog/2021/07/blog-backlog-1.html To be concrete, a "monoglot" lives in a world where the language's package manager is responsible for integrating different pieces of software. In contrast, a polyglot uses multiple languages, and the package managerS (plural) are just tools, not the world, and they're called from shell scripts! (Or something morally equivalent, like a Makefile or Dockerfile) The future is more polyglot, e.g. your Rust or Zig code will coexist with a lot of C and C++ code. Sometimes they will be linked into the same process, but often they'll live in different processes and you'll use various forms of IPC.

macando 5y ago

Since the article is talking about the great expansion I'm offering a counterpoint - the great collapse. https://www.swyx.io/js-third-age/ https://www.swyx.io/js-third-age/ > Collapsed Layers (One thing doing many things well instead of many things doing one thing well)

rytcio 5y ago

I think the author misses the mark about what the problem is with developer experience, although they get the analogy of a "rainforest" correct. Developers are in a run-away-train kind of situation, where they think that more libraries, more frameworks, more tools, more languages, more abstractions, etc. is the key to a better developer experience. In reality, this is the exact thing that is making development and developers miserable. The whole `is_even` fiasco [0] should have been a wake up call. The plain fact of software development is that there is going to be complexity, and there is going to be some point where adding features or fixing things is going to become a slog. The choice where do you want that to happen? With the never-ending reliance on libraries, frameworks, tools, etc. the difficulties has been shifted towards the latter half of development, "we'll worry about that later". Sure, the share holders and the angel investors are stoked when a team can get an app running in a few months. But guess what, down the road when it comes time to add more features, make it fast, to flesh out the app into its full potential...it will end up in a nightmare of trying to wrestle the code and the barely comprehensible infrastructure to get it to do what they want. Good luck trying to figure out what is making the app slow in that rainforest. The best thing I ever did for my mental health when working on hobby projects was to keep it simple stupid. In the case of C++ and games, I do everything in my own code maybe using Sean Barret's header files or GLFW for Window and input. Use a .bat file to build the code, rather than some overly complicated build tool so that it can build in 2 seconds rather than 5 minutes giving me very fast iteration speed. The Vulkan rendering code, the math, system level stuff like memory and file IO is all my own. For web stuff, I wrote a production web app for an internal team in a single PHP file with only a templating library. Going this route has undoubtedly doubled my productivity. Static site generator? I'd rather write one in Python than try to figure out some complex dependency ridden mess of an open source tool that never does what I want it to do. The pain of developer experience is self inflicted. In an effort to reduce friction in development, a system of increasingly worse friction has been introduced. Programmers need to stop being afraid of writing code, and, dare I say stop being lazy. Developers could be just as productive, if not more productive, if they would just write the code. [0] https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/ https://qz.com/646467/how-one-programmer-broke-the-internet-...

lifeisstillgood 5y ago

mooreds 5y ago

I'm a big fan of TID: Trust in Developers. That means building out an application and experience that has the following: * a substantial education component. You are an expert in X, so educate developers so they can get better at X * meets developers where they are (in terms of languages and tooling) * allows both high and low levels of abstraction (including a well documented and consistent API) * free to start (even though we all have to eat, developers want to kick tires with minimal effort) * encapsulated functionality that does a few things and a few things well. The RDBMS is a model here. * an open feedback loop, typically on GitHub or in public. (Slack is a bit of an anti-pattern here.) I don't know how devs are going to use tools built for them, but the last thing I want is for them to be disempowered. The farthest end of the empowerment spectrum, of course, is open source, but there are business model problems with that. I've written on that before: https://www.mooreds.com/wordpress/archives/3438 https://www.mooreds.com/wordpress/archives/3438 For another smart, if different take, read this: https://redmonk.com/jgovernor/2020/11/26/addressing-the-developer-experience-gap-newcode-or-gluecode/ https://redmonk.com/jgovernor/2020/11/26/addressing-the-deve... The post talks about tooling and a cohesive structure as the next great opportunity.

oblib 5y ago

I got to "With developers spending less than a third of their time actually writing code," and thought "what?" then read the rest of it: "developer experience includes all the other stuff: maintaining code, testing, security issues, addressing incidents, and more." and then though "oh yeah... that's about right on a good day" lol!

bmeski 5y ago

I’ve had “engineers” at my company push leadership enough to force me to create a build/plug-in system for react components to render a map of the US. I made the same map in D3 at home over the weekend in vanilla JS. The excuse was DX. How can we test it and use storybook if we don’t use react and generate a giant dingus of a bundle? Edit: so don’t just trust “engineers”.

mercurialsolo 5y ago

DX today exists at lots of different levels, from competitive code games, to hackathons, to well formatted docs & code samples - all IMO form a larger umbrella of DX. I still see it as an emerging field with more work done to synthesize under a single umbrella of being able to communicate abstraction levels, concept understanding, adding explainability to decision models and of course tailored for the skill tree at where the target developer today is at.

Derbasti 5y ago

> It’s certainly possible, for some problems, to automate the problem away. But other problems (for instance, finding and fixing bugs) cannot be fully abstracted, often requiring user input. I think that's not the right way to look at it. It's just that a task that's automated no longer needs a dev. Thus we only work on things not (yet) automated. As a corollary, easy-to-replace parts inevitably become replaced with hard-to-replace parts, because those are the ones that stay.

LurkingPenguin 5y ago

> As every company continues to become a technology company inside — regardless of product or service — developers are getting more of a say. I know this is Silicon Valley gospel but just because technology is a critical part of many if not most companies' operations today doesn't mean that those companies are "technology companies."