[HN Gopher] The Case for 'Developer Experience'
___________________________________________________________________
The Case for 'Developer Experience'
Author : PretzelFisch
Score : 72 points
Date : 2021-09-25 17:30 UTC (5 hours ago)
(HTM) web link (future.a16z.com)
(TXT) w3m dump (future.a16z.com)
| macando wrote:
| Since the article is talking about the great expansion I'm
| offering a counterpoint - the great collapse.
|
| https://www.swyx.io/js-third-age/
|
| > _Collapsed Layers (One thing doing many things well instead of
| many things doing one thing well)_
| lanstin wrote:
| 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 wrote:
| 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 wrote:
| >> 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?
| [deleted]
| vkou wrote:
| And more importantly, how does that number compare to the
| number of golf balls that can be fit into a 747?
| [deleted]
| phkahler wrote:
| >> 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 wrote:
| 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
| willcipriano wrote:
| "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
| stevebmark wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| Chyzwar wrote:
| With webpack you can use module federation to share code and
| reduce bundle size for micro-frontend applications. There are
| other ways to make your application bundle smaller.
|
| I spend a lot of time optimizing performance at work, both for
| UX and DX. It is common on HN to bash on large bundle sizes of
| SPAs, but in reality this not a problem unless users are on IE.
| At work, I often work tirelessly to reduce the amount of
| dependencies and bundle size, but I know that this would not
| make things faster, just more maintainable.
|
| For UX perf killers are IMO: - rendering large
| number of deeply nested dom nodes and doing repaints and
| reflows. - large data fetches and storing huge number of
| objects in memory. - slow/flaky APIs, in many cases slow
| backend is main bottleneck, JS is plenty fast - silly
| animations, bad design that force clicking and multi stage
| workflows.
|
| For DX perf killers - micro-something. Micro
| services/frontend in organistions without deep pockets.
| - special snowflakes internal abandoned framework that only two
| people in company know - lack of dedicated people for
| tooling and dev infrastructure - lava layer design
| pattern, multiple competing technologies used within same
| codebase/product.
| dfabulich wrote:
| > It is common on HN to bash on large bundle sizes of SPAs,
| but in reality this not a problem unless users are on IE.
|
| This is dangerously wrong. Large bundle sizes are a huge
| problem on slow Android phones (and almost all Android phones
| in real-world use are slow).
|
| Even in the US, if you walk into a cellular store and ask for
| an affordable phone, they're going to give you a device that
| will take 7-10s to download, parse, and execute a 3MB JS
| bundle, even over wifi. (The parsing _alone_ will kill you!)
|
| (And if you're in a developing economy? That "affordable"
| phone is the best phone you can reasonably buy with a month's
| wages. The median phone is even slower!)
| Chyzwar wrote:
| In US 55% of people carry iphone. Depending on app, people
| with affordable phones are not your users (b2b).
|
| Browsers would cache parsed javascript. More likly loading
| images will be slower.
|
| There are use cases that general perfomance matter a lot
| but people are obsesing on js bundle size too much.
| WesolyKubeczek wrote:
| > - special snowflakes internal abandoned framework that only
| two people in company know
|
| And remember that today's darling framework all the internets
| are raving about is a special snowflake abandoned framework
| tomorrow that no one gives a damn about anymore.
|
| The corollary to this is that the spice must flow, and the
| wheels must keep spinning, thus the hamsters^Wdevelopers must
| keep rewriting everything using the current darling
| languages, frameworks, and paradigms, restlessly contributing
| to the ever growing carbon footprint as CI/CD pipelines keep
| chugging away at each oneliner commit!
| candiddevmike wrote:
| I don't think SSR is that big of a deal these days with faster
| phones and data plans. You get more returns focusing on bundle
| size, code splitting, and time to first paint.
| bmeski wrote:
| There are websites and web apps. Two very different things.
| tobr wrote:
| They're not 'very different', they exist along a continuum.
| Most somewhat complex projects will include parts that live
| at various points in that continuum.
| jelling wrote:
| Blitz.js is worth a look as it supports both out of the box
| vosper wrote:
| I like Blitz, but it's built on Next JS - isn't that where it
| gets it's SSR and static capabilities?
| rytcio wrote:
| 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-...
| madrox wrote:
| 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 wrote:
| > 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-Techno... , not 'smoosh the devs and ops teams
| together, add Jenkins and hope for the best'.)
| macando wrote:
| 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=...
|
| [0] https://news.ycombinator.com/item?id=28539247
| [deleted]
| rememberlenny wrote:
| 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=...
| kaycebasques wrote:
| 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.
| beckingz wrote:
| I guess it is a better developer experience to not need the
| software to work...
| orf wrote:
| Can you give some examples?
| lstamour wrote:
| Not the OP, but one came to mind quickly: developers like
| quick build times and easy to edit files, but end users need
| efficiently-packed, minimal builds - the more you do at build
| time to improve performance, the more time a developer has to
| wait for builds. This is especially true if E2E tests improve
| UX by reducing bugs but again devs have to wait. Finally,
| it's convenient for devs if no API surfaces change but it's
| convenient for users to have the newest features that will
| save them time. It takes work to make sure both UX and DevRel
| goals can align in the same solution... they're different
| audiences, even if there is overlap.
| lupire wrote:
| That's why we have fast debug builds with logging, and
| slow, optimized, prod builds.
| paulryanrogers wrote:
| Electron?
| noahtallen wrote:
| 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 wrote:
| 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.
| rjsw wrote:
| A sports organization that I know seems to have bought a
| website that won't work with any browser, every User Agent
| that I have tried causes an error.
|
| It still seems to download a fair bit of Javascript so I
| guess a developer had to write it at some point.
| msh wrote:
| 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 wrote:
| This is how it works and HN complains about it a lot, ie.
| when some service or program doesn't support Linux or
| Firefox.
| cryptica wrote:
| 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.
| mooreds wrote:
| 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
|
| For another smart, if different take, read this:
| https://redmonk.com/jgovernor/2020/11/26/addressing-the-deve...
|
| The post talks about tooling and a cohesive structure as the next
| great opportunity.
___________________________________________________________________
(page generated 2021-09-25 23:00 UTC)