TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Case for ‘Developer Experience’

186 点作者 PretzelFisch超过 3 年前

16 条评论

stevebmark超过 3 年前
One downside I&#x27;ve observed from focusing on DX: We have too many single page apps &#x2F; 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&#x27;s why the Jamstack mascot is the loading spinner.<p>The much better solution, SSR first with optional client hydration, takes more developer work and more cognitive overhead. It&#x27;s much easier to write a React application and not worry about server side specific data fetching to do universal rendering, even though that&#x27;s the strongest option for performance. Next.js is bringing us closer to the DX of enabling SSR first by default, but it&#x27;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&#x2F;SSR.<p>My main takeaway is that DX is important when it introduces the <i>right</i> abstractions that are <i>also</i> end user focused.
评论 #28656514 未加载
评论 #28655727 未加载
评论 #28659010 未加载
评论 #28675081 未加载
评论 #28657523 未加载
评论 #28657017 未加载
评论 #28655859 未加载
评论 #28655767 未加载
mooreds超过 3 年前
I&#x27;m a big fan of TID: Trust in Developers.<p>That means building out an application and experience that has the following:<p><pre><code> * 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.) </code></pre> I don&#x27;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&#x27;ve written on that before: <a href="https:&#x2F;&#x2F;www.mooreds.com&#x2F;wordpress&#x2F;archives&#x2F;3438" rel="nofollow">https:&#x2F;&#x2F;www.mooreds.com&#x2F;wordpress&#x2F;archives&#x2F;3438</a><p>For another smart, if different take, read this: <a href="https:&#x2F;&#x2F;redmonk.com&#x2F;jgovernor&#x2F;2020&#x2F;11&#x2F;26&#x2F;addressing-the-developer-experience-gap-newcode-or-gluecode&#x2F;" rel="nofollow">https:&#x2F;&#x2F;redmonk.com&#x2F;jgovernor&#x2F;2020&#x2F;11&#x2F;26&#x2F;addressing-the-deve...</a><p>The post talks about tooling and a cohesive structure as the next great opportunity.
madrox超过 3 年前
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.<p>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.
评论 #28656875 未加载
kaycebasques超过 3 年前
Tangential idea: I worked on Google&#x27;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.
评论 #28655616 未加载
评论 #28655556 未加载
rememberlenny超过 3 年前
While only slightly relevant to the content of the article, the author has an incredible tweet thread.<p>&quot;Taylor Swift as classic programming textbooks, a thread.&quot;<p><a href="https:&#x2F;&#x2F;twitter.com&#x2F;jeanqasaur&#x2F;status&#x2F;1290883041418649600?s=20" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;jeanqasaur&#x2F;status&#x2F;1290883041418649600?s=...</a>
bmeski超过 3 年前
I’ve had “engineers” at my company push leadership enough to force me to create a build&#x2F;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.<p>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?<p>Edit: so don’t just trust “engineers”.
macando超过 3 年前
Great analysis. My only remark is that the focus is fully on the backend&#x2F;infra.<p>On the frontend, observability and transparency are the main reasons why I still use Redux and its dev tool. It&#x27;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].<p>And DX in general? Well, this is how it&#x27;s stacked in today&#x27;s startups<p><a href="https:&#x2F;&#x2F;pbs.twimg.com&#x2F;media&#x2F;FAIZRuaVQAEGwGU?format=jpg&amp;name=small" rel="nofollow">https:&#x2F;&#x2F;pbs.twimg.com&#x2F;media&#x2F;FAIZRuaVQAEGwGU?format=jpg&amp;name=...</a><p>[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28539247" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28539247</a>
lanstin超过 3 年前
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.
评论 #28655525 未加载
macando超过 3 年前
Since the article is talking about the great expansion I&#x27;m offering a counterpoint - the great collapse.<p><a href="https:&#x2F;&#x2F;www.swyx.io&#x2F;js-third-age&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.swyx.io&#x2F;js-third-age&#x2F;</a><p>&gt; <i>Collapsed Layers (One thing doing many things well instead of many things doing one thing well)</i>
rytcio超过 3 年前
I think the author misses the mark about what the problem is with developer experience, although they get the analogy of a &quot;rainforest&quot; correct.<p>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.<p>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 <i>where</i> 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, &quot;we&#x27;ll worry about that later&quot;. 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.<p>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&#x27;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&#x27;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.<p>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.<p>[0] <a href="https:&#x2F;&#x2F;qz.com&#x2F;646467&#x2F;how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code&#x2F;" rel="nofollow">https:&#x2F;&#x2F;qz.com&#x2F;646467&#x2F;how-one-programmer-broke-the-internet-...</a>
评论 #28657024 未加载
oblib超过 3 年前
I got to &quot;With developers spending less than a third of their time actually writing code,&quot; and thought &quot;what?&quot; then read the rest of it: &quot;developer experience includes all the other stuff: maintaining code, testing, security issues, addressing incidents, and more.&quot; and then though &quot;oh yeah... that&#x27;s about right on a good day&quot; lol!
Derbasti超过 3 年前
&gt; 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.<p>I think that&#x27;s not the right way to look at it. It&#x27;s just that a task that&#x27;s automated no longer needs a dev. Thus we only work on things not (yet) automated.<p>As a corollary, easy-to-replace parts inevitably become replaced with hard-to-replace parts, because those are the ones that stay.
mercurialsolo超过 3 年前
DX today exists at lots of different levels, from competitive code games, to hackathons, to well formatted docs &amp; code samples - all IMO form a larger umbrella of DX.<p>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.
LurkingPenguin超过 3 年前
&gt; As every company continues to become a technology company inside — regardless of product or service — developers are getting more of a say.<p>I know this is Silicon Valley gospel but just because technology is a critical part of many if not most companies&#x27; operations today doesn&#x27;t mean that those companies are &quot;technology companies.&quot;
cryptica超过 3 年前
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 &#x27;natural selection&#x27; to take place and to ensure that the ecosystem&#x2F;platform can evolve over time.
评论 #28657107 未加载
bluedino超过 3 年前
&gt;&gt; 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.<p>Does this count the 6 people I interviewed this year that couldn&#x27;t fizzbuz?
评论 #28656103 未加载
评论 #28655601 未加载
评论 #28655908 未加载
评论 #28659293 未加载
评论 #28655750 未加载
评论 #28655640 未加载