[HN Gopher] Good DevEx increases productivity. Here is the data
___________________________________________________________________
Good DevEx increases productivity. Here is the data
Author : saeedesmaili
Score : 169 points
Date : 2024-01-24 16:18 UTC (6 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| lopkeny12ko wrote:
| This required an entire commissioned research study and published
| article...?
| leosanchez wrote:
| You can think of it as an Ad for GitHub Copilot
| HankB99 wrote:
| Yes.
|
| > "Certain technologies like GitHub Copilot can help
| developers better understand their code and future-proof
| their productivity."
|
| I would have never thought that. /s
| geekjock wrote:
| Ever seen developers that are frustrated by technical debt and
| whose business leaders don't seem to care? This study is aimed
| to help with that.
| willio58 wrote:
| > developers who carve out significant time for deep work enjoy a
| 50% productivity boost.
|
| Makes sense from personal experience. At my company we have 1 no-
| meeting day a week (Thursday). Especially since I've gotten into
| management I've found Thursday to be my favorite day and I
| probably get ~70% of the actual code work I do in a given week
| done on that day. If you don't have something like this, I really
| recommend it!
| theonething wrote:
| I recommend scaling that to no meetings on most days.
| Aurornis wrote:
| Matches my experience, too.
|
| Unfortunately, some companies approach culture and DevEx as an
| additive system where they keep piling more meetings, more
| engagement, more activities, and more process on top of
| everyone's responsibilities.
|
| When a company approaches DevEx and culture by subtracting
| things that aren't working it's like a breath of fresh air.
| rqtwteye wrote:
| I often think the once-a-week-no-meeting-days should be
| reversed to once-a-week-meeting-days. Put all status,
| retrospective, planning and other recurring meetings into this
| one day so people can actually work the rest of the week.
|
| During Covid my company had a 32 hour week for a year and we
| lost zero productivity because the first thing that was
| eliminated were the meetings that just fill time but achieve
| nothing.
| phreack wrote:
| Regular meetings and calls can't go over twice a week period.
| For me, it's one of the biggest reasons for unproductivity.
| I've worked on a lot of projects and the amount of meetings
| was directly correlated to how much everything was delayed.
|
| In all cases, the people who pushed the most for meetings
| were the ones who contributed the least, and in fact had a
| negative impact. Nowadays it's a nonnegotiable rule from the
| start in our agency when taking on new clients.
| tiborsaas wrote:
| Shocking discovery, instead of fighting the tools we can do the
| actual stuff.
|
| edit: to be a bit positive, at least this is neatly presentable
| to managers who might want to axe DX improvement projects.
| rcbdev wrote:
| > We finally have data to back up the benefits of developer
| experience
|
| Any manager who was waiting on the "data" (read: sponsored study)
| that you need to invest in proper tooling for your devs isn't
| going to do anything significantly different because of it.
| helicalmix wrote:
| This feels like an uncreative statement though, as there are
| many different ways to use this data.
|
| For example, what if an engineering manager needs to convince
| finance for headcount to hire a devex employee?
| geekjock wrote:
| +1
|
| If you read the introduction of the paper, you'll see that
| the aim of this paper is to give managers and developers
| concrete data to use to help get buy-in on investing in
| developer experience from business leaders.
|
| https://queue.acm.org/detail.cfm?id=3639443
| shermantanktop wrote:
| You need to think like a desperate manager. Yes, I know, I
| know.
|
| The job of a manager is to make good choices and decisions. In
| the absence of an obvious best choice, they have work backward
| from both success and failure scenarios, including the
| political and social impacts.
|
| In the absence of external studies and data, if they make an
| investment in this area and it turns out not to help, they will
| be left telling their boss things like "everyone says this is
| right, not sure why my project didn't work."
|
| But a flimsy fig leaf that comes from outside and smells
| objective is a perfect CYA tool that allows the manager to take
| a risk while anticipating the need to manage and contain
| failure.
|
| Does that describe a healthy dynamic and a smart organization?
| No, but it's reality at many places.
| elzbardico wrote:
| Sometimes the manager knows it, but the manager have managers
| who need to have some external justification to cover their
| assess. It is basically the same principle that drives hiring
| consultants to say exactly the same thing the team have been
| saying for years.
| baq wrote:
| This is just the whitepaper to cover the manager's manager ass.
| GiorgioG wrote:
| Then why do you guys completely ignore
| https://github.com/orgs/community/discussions/10369 ?
| rokkamokka wrote:
| I feel like the people in that issue are doing something wrong.
| I've never unintentionally started a review instead of
| submitting a comment. I feel the buttons are pretty clear about
| which does what.
| GiorgioG wrote:
| As someone bitten in the ass by this, it's a UX issue. If it
| were just me, fine - I'm an idiot. But it's enough people
| that come looking for this exact same problem.
| kayodelycaon wrote:
| This happens to me semi-regularly. There's a mode difference
| where if you're reviewing, the comments don't get sent, when
| normally those comments are sent immediately.
|
| It's rare that I complete reviews in a single session, so I
| often don't realize I'm in the middle of a review when I go
| back to the PR.
| Bjartr wrote:
| > I feel like the people in that issue are doing something
| wrong.
|
| And there are UX choices that could result in fewer people
| doing something wrong.
| powersnail wrote:
| They are doing something wrong, and having enough people
| doing the same thing wrong is exactly why the design of a
| product might need to be re-considered.
| j45 wrote:
| Good DevEx is incredibly important.
|
| I'm not so sure it should be obsessed on more than the Customer
| and User experience, though.
|
| If DevEx doesn't create Devs who understand users better and help
| put them in the users shoes, I would think there is room for Good
| DevEx to improve.
| myaccountonhn wrote:
| Getting feedback rapidly is part of good DX, so IMO getting
| feedback from customers should be accounted for in the cycle.
| They help each other.
| j45 wrote:
| I agree, but many developers are promised to not have to deal
| with customers.
|
| Then again, I lean towards the idea that separating product
| management and product ownership results in a disconnected
| product from users.
| bloopernova wrote:
| My role is DevOps but I find myself gravitating towards improving
| the developer experience, which I think is a worthy subcategory
| in the DevOps practice.
|
| The team I'm on previously didn't have any automated way to set
| up developer workstations, now we've got an Ansible script that
| does most of everything they need in less than an hour. (Our VPN
| is slow as cold molasses) Previously, setup was ad-hoc, leading
| to troubleshooting questions like "did you follow instructions in
| this forwarded email, this one section from a wiki page, and a
| copy/paste comment in chat?". Now it's "did you run the script?".
|
| Similarly, the concept of the "Internal Developer Platform" might
| be interesting to some:
| https://internaldeveloperplatform.org/core-components/
|
| It's kind of amazing to me that there are whole teams out there
| that struggle with awful environments that actively put up
| barriers to efficient coding.
| hotpotamus wrote:
| I suppose I could be called DevOps, and I've always seen that
| as part of the job - making the infrastructure as easy for the
| devs to work with as possible. They've got their own
| specialities to worry about; infrastructure shouldn't be one of
| them. I've heard the role called somewhat derogatorily
| "helpdesk for devs", but that is part of the job, and I embrace
| it. I also embrace "yaml wrangler" - it's not my favorite thing
| to do, but it does sometimes need wrangling. I suppose I've
| always seen the role as a generalist one who has some
| understanding of the overall system, and how to glue (or duct
| tape) it all together.
| bloopernova wrote:
| I've been called a Systems Wrangler before. It was pointed
| out to me that I love to wrestle with a new unfamiliar
| system, "taming" it to work with our stuff.
|
| I think I prefer that to some other choice descriptors that
| have been applied to me! ;) "Git Whisperer" is another one
| that is amusing to me, considering the difference in meaning
| between "Wrangler" and "Whisperer". Does that mean Git
| requires a subtle approach?
| hinkley wrote:
| Part of this work used to be called toolsmith, but it doesn't
| quite cover the job description.
| agumonkey wrote:
| devops and dx share the same spirit of reducing friction
|
| at my job i can't stop leaning toward them because I can count
| in blood the amount of energy, time and money wasted on the
| thousands papercuts stacked over time
|
| one needs to find a balance of fluidifying the daily logistics
| involved, it amps up joy and reduce stress.. leaves more time
| for problem solving and creativity.
|
| sadly most devs / managers couldn't care less about that
| jswank wrote:
| I've a similar background, and have worked recently w/ a
| handful of teams with atrocious, self-imposed developer
| experience. I think that applying concepts like SLOs and error
| budgets to relevant developer-centric activities can really
| help focus the team and other stakeholders well before the
| experience passes some threshold of terrible.
| hinkley wrote:
| This is practically a tenet for me now:
|
| If you tolerate painful problems you are capable of fixing,
| you're a masochist. If you expect others to tolerate them,
| you're a sadist.
|
| I often work with people who are more than happy to have
| someone fix problems. But I also work with people who don't
| just denigrate such work, but are obstructionist. You're
| expending energy to stop other people from making the system
| better. There's something deeply wrong with such people.
| notpachet wrote:
| > You're expending energy to stop other people from making
| the system better. There's something deeply wrong with such
| people.
|
| Lurking somewhere inside everyone is a sublimated death
| wish.
| darkwater wrote:
| > You're expending energy to stop other people from making
| the system better. There's something deeply wrong with such
| people.
|
| One explanation is emotional attachment to a
| system/technology/solution/process they helped put in
| place. If someone wants to improve it by heavily modifying
| or God forbid getting rid of it, they will fight back
| because they feel personally attacked for it. It is wrong,
| but it happens a lot.
| rgblambda wrote:
| I don't know if it would help or not to mention that the
| existing system helped to get the company to where it is
| today, when delivering the "now is the time to get rid of
| this" pitch.
|
| Acknowledging how long the existing system has been live
| would hopefully be a reminder that you're not trying to
| erase their achievement.
| yjftsjthsd-h wrote:
| > Using work design theory, we created a set of research
| hypotheses, developed questions, and surveyed more than 20
| industry-diverse companies.
|
| So it's a bunch of surveys, not experimental data; AFAICT nothing
| here distinguishes ex. "devs who understand their code are
| productive" from "devs who are productive develop an
| understanding of the code". But forget correlation/causation,
| because it turns out their claims - even in the linked "research"
| is about how people _feel_ , not their actual effectiveness -
| choice quotes are
|
| > developers who report a high degree of understanding of their
| code feel 42% more productive
|
| or
|
| > Developers who have a significant amount of time carved out for
| deep work feel 50 percent more productive compared with those
| lacking in dedicated time
|
| Notice that there's no attempt to objectively see if those
| feelings are true! SLoC might be poor, but you could look at
| _literally any objective measure_ to proxy actual productivity
| and be better off than this!
|
| So for all that I'd like to believe them, and all that the claims
| _could actually be true_ , this is just a bunch of meaningless
| nonsense that barely qualifies as "data" and certainly shouldn't
| be taken seriously as "research".
| geekjock wrote:
| "You could look at literally any objective measure to proxy
| actual productivity and be better off than this"
|
| It's fairly well-established in research (and in practice) that
| there is no objective measure of developer productivity.
| Metrics like lines of code, number of pull requests, velocity
| points are incredibly poor proxies.
| yjftsjthsd-h wrote:
| Alright, I'm willing to consider that their claims are not
| merely unsupported but impossible to support, but that's not
| a better look exactly.
| zer00eyz wrote:
| >>>> It's fairly well-established in research (and in
| practice) that there is no objective measure of developer
| productivity.
|
| Oh, there is.
|
| Money.
|
| How much do you spend on eng to earn a buck (eng value,
| infrastructure). Impact of your next project on the bottom
| line. How much can you save by making a change.
|
| So many bullshit features from engineers, and product people
| that have FUCK ALL impact on the bottom line. But hey they
| made you happy, or looked good on your resume to get you the
| next job...
| marcosdumay wrote:
| Lines of code is a much better proxy than reported
| productivity.
|
| It stops being a good proxy if you use it to reward or punish
| developers, compare different languages, or different types
| of software. But if you don't do those, it's quite good.
|
| Velocity points is worse, because the current culture implies
| it will be used to reward or punish developers. But it's
| probably still better than reported productivity.
|
| In fact, reported productivity is probably one of the worst
| metrics around. People can't even keep track of how long they
| spend programing, much less of how much they accomplish.
| datadrivenangel wrote:
| I am 100% sold on developer experience being key for fast
| iteration and high quality software operations, but the actual
| research cited here seems fairly flimsy. It was based on a web
| survey by DX (love them by the way), that had 219 completed
| responses and asked likert scale (1-5) questions about how they
| felt.
|
| Good developer experience increases self-reported productivity. I
| do suspect that it correlates with actual productivity and
| business outcomes, especially around reducing the productivity
| loss that comes from error remediation.
| geekjock wrote:
| I'm one of the co-authors of the study. Your critique is valid
| though by research standards, for this type of study, our
| sample is sufficient. We are planning to replicate this study
| on a larger scale in the future, though!
| vlovich123 wrote:
| Are there any plans to figure out objective ways to measure
| productivity and what distinguishes "good devex" from "bad
| devex"?
|
| I've worked at a lot of big tech companies that do surveys
| about internal tooling and every year it's rated as a weak
| spot, across years and companies this seemed like a
| consistent trend.
|
| And yet everyone had teams dedicated to improving various
| aspects of devex so it's unclear if these teams are just
| improving the wrong things or if productivity really is
| improving and it's something else (eg the amount of code debt
| grows faster than devex improvements or people are asked to
| go faster than the devex improvements can keep up or the
| devex is being improved but the size of the survey means not
| enough people feel it because you optimize smaller subsets of
| engineering orgs).
|
| That's another thing to be mindful about large scale and
| small scale surveys - the latter might be sampling specific
| teams adopting the tool whereas the former might find there's
| no way to make everyone happy and it all turns into a wash.
| geekjock wrote:
| "Are there any plans to figure out objective ways to
| measure productivity"
|
| You can't measure developer productivity objectively,
| assuming you're referring to metrics like lines of code,
| number of pull requests, or velocity points which are
| infamous. There's broad agreement on this both within the
| research community as well as practitioners at leading tech
| companies.
|
| Here are some examples:
| https://newsletter.pragmaticengineer.com/p/measuring-
| develop...
|
| "... and what distinguishes 'good devex' from 'bad devex'"
|
| Yes to this. This is an ongoing effort - we have two
| previous journal papers that touch on this which may be of
| interest to you:
|
| - https://getdx.com/research/devex-what-actually-drives-
| produc...
|
| - https://getdx.com/research/conceptual-framework-for-
| develope...
| vlovich123 wrote:
| > You can't measure developer productivity objectively,
| assuming you're referring to metrics like lines of code,
| number of pull requests, or velocity points which are
| infamous. There's broad agreement on this both within the
| research community as well as practitioners at leading
| tech companies.
|
| No those are metrics you're suggesting. There are better
| ones as someone else mentioned (time to get code from PR
| to production, some way of measuring the quality of work
| getting to production, etc). Yes, the obvious metrics are
| poor and better metrics are difficult to measure and
| quantify. And obviously no single metric is going to
| capture something as multidimensional as code
| development.
|
| Also, the link you reference doesn't support your
| argument.
|
| > Across the board, all companies shared that they use
| both qualitative and quantitative measures
|
| Throughout it discusses that people do use quantitative
| metrics to help guide their analysis and none of them try
| to do the obviously naive ones as mentioned.
|
| This isn't intended as a critique, but as an engineering
| profession anything that isn't quantifiable means it's
| open to interpretation and argument weakening forward
| progress to be restricted to what becomes adopted as
| industry standard which is in many ways more of a
| popularity contest of fads rather than concrete technical
| improvement.
| geekjock wrote:
| Makes sense - I agree with you. My mistake on assuming
| you were referring to metrics like the ones I listed.
| droopyEyelids wrote:
| For your first question about good devex, there are
| definitely some objective ways to measure it.
|
| * The time it takes for completed code to be deployed to
| production * count of manual interventions it takes to get
| the code deployed * count of other people that have to get
| involved for a given deploy * how long it takes a new
| employee to set up their dev environment, count of manual
| steps involved
|
| Stuff like that
| hibikir wrote:
| Asking people whether the developer experience is good or
| bad is not going to be the most efficient of approaches:
| It's ultimately asking for a mood. When teams are asked
| what they are spending a lot of time on than they wish they
| shouldn't, you can at least see what are the heavier pain
| points. It doesn't help if your developer experience budget
| is zero, but it can at least organize the useful
| alternatives.
|
| In most places I've worked at, the a survey asking for
| specific pain points gets great results, because the worst
| time sinks stick out like a sore thumb, especially if you
| have workers that have worked in high quality
| organizations.
| callalex wrote:
| Having been on the teams that improve developer experience,
| the problem is that one of my hands gives while the other
| takes away. I can address every complaint a developer has
| about the company platform, but at the same time
| requirements change. As a company grows they start caring
| more about security and firewalling between different data
| and services which makes developing harder and more
| annoying.
| datadrivenangel wrote:
| I do love to see more research here, thank you!
|
| Having done internal developer & analyst tooling work (and
| used DX), this type of survey is great for internal
| prioritization when you have dedicated capacity for
| improvements.
|
| I'd be curious to see more about organizational outcomes, as
| this is piece of DevOps/DevEx data that I feel is weakest and
| requires the most faith. DORA did some research here, but
| it's still not always enough to convince leadership.
| geekjock wrote:
| Agreed with this. We're working on it!
| IshKebab wrote:
| I agree. I think this is just one of those things that we know
| is true but can't easily be proven via the scientific method.
|
| I expect some HN readers will balk at the idea that we can know
| things but can't prove them scientifically but only because
| they haven't really thought about it. E.g. does giving
| variables sensible names reduce bug counts? Obviously. But it's
| very difficult to prove even something as obvious as that.
| herval wrote:
| > Good developer experience increases self-reported
| productivity.
|
| So do ineffective DX, most times. There's "proper" way to
| assess productivity gains that don't rely on subjective self-
| reporting (eg the DORA metrics). The "improving feedback loops"
| item on this report makes sense on that light - the other two
| are questionable as a direct proxy
| Paul-Craft wrote:
| > So do ineffective DX, most times.
|
| I don't find this hard to believe, but do you know of any
| research showing this?
| froggygirlxoxo wrote:
| Good DevEx is incredibly important. Nice to see actual data
| supporting what is already known anecdotally.
| jgerrish wrote:
| Sometimes just taking a break, sitting and contemplating life
| over a shared meal is best.
|
| But sometimes bringing forward data like this is the right
| choice. It's what we need as we look to the future.
|
| Very cool.
| wesselbindt wrote:
| What's DevEx?
| geekjock wrote:
| > Developer experience encompasses how developers feel about,
| think about, and value their work.9 In prior research, we
| identified more than 25 sociotechnical factors that affect
| DevEx. For example, interruptions, unrealistic deadlines, and
| friction in development tools negatively affect DevEx, while
| having clear tasks, well-organized code, and pain-free releases
| improve it.
|
| https://queue.acm.org/detail.cfm?id=3595878
| robertakarobin wrote:
| Developer Experience, i.e. the developer's "quality of life"
| while developing. Things like good tooling, good documentation,
| and lack of distractions contribute to DevEx.
| quesera wrote:
| A shipping company, like VPS or DHT.
|
| Or, "Developer Experience", if you prefer.
| swah wrote:
| "Keep your feedback loops short" is the main one :)
| wnolens wrote:
| Even if good devex didn't increase productivity, it increases
| developer happiness and as a developer, I will try to tithe my
| budgeted time to improve it and hide it among ambiguous tasks.
| When I feel I can't, I sense I am at a toxic workplace.
|
| And while I've never left a job primarily due to developer
| experience alone, it's always the second reason in mind which
| makes me want to never go back.
| turtlebits wrote:
| That's a shame, because Github actions is IME the worst
| productivity killer since you can't test locally- which makes
| iterating painfully long.
| ch4s3 wrote:
| It's really amazing. Github Actions has been an absolute curse
| on my team, it's bundled with other Github and Azure charges so
| finance convinced us to abandon CircleCI and I have nothing but
| regrets.
| rgblambda wrote:
| Now imagine having to work with AWS CodePipeline+CodeBuild
| (because it's always one more service with AWS). The worst CI
| tool I've ever worked with, but it goes into the AWS bill and
| no one ever questions that so that's what we're using.
| marwis wrote:
| What's wrong with local runners like nektos/act?
|
| I haven't used personally but curious if it has some
| shortcomings they don't mention.
| wesleyyue wrote:
| They are not 1:1 parity with the hosted version, they are
| hard to run, and they are slow. When I tried GA I often had
| to just test on the hosted service, and debugging on the
| hosted service is so slow and painful. I honestly am very
| surprised that GA is so popular, it's probably the worst CI
| I've used and I thought I was missing something.
| teeray wrote:
| What's the crowd favorite self-hosted alternative these days?
| conor- wrote:
| GitHub Actions is predicated on push n' pray SDLC. Actions is
| also showing some of the warts that exist from being forked
| from the old Azure DevOps TFS pipelines.
|
| I haven't used GitLab CI runner too often, but the carrot of
| being able to use a runner on my local machine is extremely
| appealing.
| SkyPuncher wrote:
| That has nothing to do with GitHub Actions. That's just poor
| setup
| rqtwteye wrote:
| We definitely need daily meetings to discuss this and find
| collaborative solutions :-)
|
| But seriously, is this a surprise to anybody?
| jaxr wrote:
| Disclaimer: didn't read the paper yet. But the assertions are
| "Feel X% more Y", which is hardly hard data. Seems like the
| methodology was just interviews?
| acd wrote:
| Private offices for focus without distractions will become a
| thing again.
|
| Compare salary vs office rent
| james2doyle wrote:
| Incoming semi-related rant.
|
| This doesn't apply to LLMs writing code, and it is quite an
| aside, but I think we have destroyed a lot of ways the web works
| by chasing a "good" dev experience.
|
| It is "nicer" to write JSX and Typescript in a Next.js project
| than it was to write jQuery in inline script tags on WordPress.
| No doubt. But I never had issues maintaining, scaling, updating,
| or improving those old sites. And I definitely wasn't nickel and
| dimed for every feature/service I needed to add.
|
| I didn't have to wait for builds, or compiling, or worry about
| the deployment Node.js being a different version than the local
| Node.js. Or "open source" framework features being locked to
| certain hosts (looking at you RSC and Next.13) and their
| platforms. And the worst thing, coming back to a project after a
| couple years and it being impossible to get working because all
| the tooling has changed and/or been abandoned.
|
| I recently had a client from 8 years ago want to move their
| hosting. They had been sitting on a PHP/Laravel-based CMS, hosted
| on DigitalOcean, paying $10 a month for ~7 years.
|
| I haven't deployed any websites in the last 3 years that I think
| could even survive that long. Let alone even run locally after
| that time. The site could be running fine, but the tooling to
| work on it, or the platforms supporting it, will break. But my
| dev experience writing them has been, _Chefs kiss_!
|
| React will be updated, and perfectly workable things will be
| deprecated, the tools to build/bundle code will be deprecated or
| abandoned for ones with a "better experience", and the hosting
| providers will drop support for older Node.js versions.
|
| Maybe this speaks more to the disposable nature of the web these
| days, but I feel like websites specifically started getting more
| brittle and complicated when we started chasing dev experience
| over user experience.
| Kranar wrote:
| I think this is mostly your own personal experience and likely
| a bit rose tinted.
|
| It is perfectly possible to deploy a webapp in React that will
| last for 10 years more or less how a website from 10 years ago
| could still function today. Also jQuery's very existence was
| due to how much of a disaster writing webapps was in the past
| with the host of compatibility issues between not only browsers
| but just within versions of the same browser. Also there's no
| issue scaling WordPress? WordPress is notoriously slow and hard
| to scale. It's a great option for getting a basic website up
| and running quickly but by God is it a slow and bloated mess
| and while you can performance tune it, it's not at all a simple
| or straight forward process and it certainly wasn't easier 10
| years ago.
|
| I've been a web developer since 1998 and it's definitely much
| easier to deploy, maintain and scale websites today than it
| ever was not to mention that websites today play a much larger
| role with the rise of mobile computing than they did back then.
|
| To the extent that it was easier to do anything in the past, it
| was because the concerns of the past were much smaller than
| they are today. Security was a much lesser concern 10-15 years
| ago than now. Writing webapps that work across multiple devices
| also was a much lower priority. Compatibility was a complete
| mess, many sites were developed to just work on a specific
| version of Internet Explorer. The idea that 10 years ago there
| were minimal problems deploying websites or maintaining them is
| likely you remembering the good parts and forgetting the bad or
| that your websites didn't need much scale or didn't address
| many of the modern concerns that exist today. Things were
| pretty bad back then to be frank and it's much easier today
| than it ever was.
| james2doyle wrote:
| Don't get me wrong, I agree with you that things are easier
| for developers.
|
| I followed a lot of the (let's face it) hype and marketing
| around going headless and using hosted services. And the
| experience is pretty great for a developer.
|
| But I've had clients who aren't happy with waiting for
| builds, paying per seat for a CMS, the turnaround of bug
| fixes and features, having to buy new services that used to
| be included, and also keep on top of the 100s of dependencies
| or changes among those services. All while being constantly
| charged for these "pleasures".
| briffle wrote:
| surely they upgraded their OS, and the packages to patch
| security vulnerabilities, right?
|
| Long uptimes aren't always great, when it comes at the expense
| of security.
| wk_end wrote:
| I think you're getting some causality twisted - websites
| started getting more brittle (if they did?) when they started
| getting more complex, and they started getting more complex
| precisely _because_ better dev tooling enabled it.
| james2doyle wrote:
| Oh true. That is a good point. I didn't think of it that way
| baq wrote:
| Great data.
|
| Now please fix github actions so it isn't such a PITA to develop
| workflows in. (I'd start with deprecating yaml actions,
| personally. Step 2 would be a local dev runner.)
| Austizzle wrote:
| Agree, there is an open source runner called act, but when I
| tried it (briefly) it seemed to give different results from
| actual actions which is unfortunate
|
| An official local runner would be fantastic
| Xeamek wrote:
| >Adobe is an example of a company that recognizes the value of
| providing an effective working environment for developers. CJ
| Dotson, senior PM of developer productivity at Adobe, notes that
| "when technology is what you sell, investments in DevEx are not
| optional. Adobe's investment in DevEx leads to higher developer
| satisfaction and better business outcomes."
|
| Ok, a bit of a fluff, but sure, it's just a first paragraph of a
| chapter, _surely_ they will expand on it in the next one and
| actually give some examples. After all, they wouldn 't make this
| a one-of statement just to mention Adibe by name and get that
| sponsorship money, right? Right?!
| bearjaws wrote:
| 'Member when DevOps was about improving DX? I member.
|
| Since every organization lost sight of the fact that DevOps
| should be serving the Developers as a customer - DevEx was a low
| priority and DevOps became about infrastructure purism.
| ontouchstart wrote:
| The other day I was looking up Unix find command on Wikipedia
| (https://en.wikipedia.org/wiki/Find_(Unix)). It lead me down a
| rabbit hole to a project called Programmer's Workbench
| (https://en.wikipedia.org/wiki/PWB/UNIX).
|
| Notable firsts in PWB include:
|
| The Source Code Control System, the first UNIX revision control
| system, written by Marc J. Rochkind
|
| The remote job entry batch-submission system
|
| The PWB shell, written by John R. Mashey, which preceded Steve
| Bourne's Bourne shell
|
| The restricted shell (rsh), an option of the PWB shell, used to
| create widely-available logins for status-checking, trouble-
| reporting, but made safe by restricting commands
|
| The troff -mm (memorandum) macro package, written by John R.
| Mashey and Dale W. Smith
|
| Utilities like find, cpio, expr, all three written by Dick
| Haight, xargs, egrep and fgrep
|
| yacc and lex, which, though not written specifically for PWB,
| were available outside of Bell Labs for the first time in the PWB
| distribution
|
| Amazing.
| ontouchstart wrote:
| The PWB might well be called a "human-end" computer; like
| "front-end" and "back-end" computers, it improves productivity
| by efficient specialization.
|
| - An Introduction to the Programmer's Workbench, T. A. Dolotta
| and J. R. Mashey
| flurie wrote:
| The authors tacked on a mini-survey to DX's regular survey
| offering, limiting participants to people who work at orgs
| willing to pay for DX's survey offering. It was not
| extraordinarily expensive, but the fact that they as recently as
| a month ago had public pricing and no longer do suggests it's
| probably more than it was at something like $15 PUPM.
|
| I'm a bit pessimistic that much of this research is being driven
| by large orgs in collaboration with researchers who aren't
| sufficiently independent. That's not to say that this sort of
| work isn't valuable, or that the research is fraudulent, but many
| people who work on software don't work for these sorts of orgs,
| and it's not clear to me how those people will be able to
| participate in research going forward.
|
| Much of this work also feels like it's becoming the industry
| equivalent of something like the Social Determinants of
| Health[1]. People with greater job satisfaction and more
| uninterrupted time are more productive? Is that the best we can
| do?
|
| [1] https://health.gov/healthypeople/priority-areas/social-
| deter...
| geekjock wrote:
| "I'm a bit pessimistic that much of this research is being
| driven by large orgs in collaboration with researchers who
| aren't sufficiently independent."
|
| I'm one of the co-authors of the study. I think your sentiment
| is valid but what you describe is true for most fields of
| research: conflicts of interest can be a problem.
|
| I can attest to the fact that the researchers behind this study
| have extensive backgrounds in academic research and hold
| themselves to high standards. If nothing else, not doing so
| risks putting individual reputations on the line.
| anoojb wrote:
| I work in DevEx...it's pretty clear the market does not value
| DevEx as an investment area right now for companies of all kinds.
| There are higher priorities, but I'm eager to see areas where the
| counter-factual might exist.
|
| Instead of using metrics like "productivity" I would like to see
| a more detailed analysis describing ways in which DevEx oriented
| productivity contributes to impact/outcomes on an idiosyncratic
| basis and how it might generalize.
| tomcam wrote:
| I wonder how much having an office where you can close the door
| would improve DevEx
| zoomzoom wrote:
| Developer experience is hard to quantify, and is not a simple as
| correlating with subjective input of "how devs feel." SPACE and
| DORA are attempts to get objective about engineering
| productivity. Some teams prefer to use a more subjective approach
| here as well. There aren't any great answers for equivalents in
| developer experience, yet.
|
| There are some obvious "tooling" considerations that impact
| developer experience. For the most part, these are related to how
| much devs can "self-service" the various parts of the SDLC, and
| how good the user experience of that service flow is. For teams
| that want to get a great experience without reinventing the
| wheel, internal developer platforms like what we're building at
| Coherence (withcoherence.com) are a great answer.
|
| We've also got a free 1-minute PR velocity scorecard that you can
| try: https://www.withcoherence.com/post/measure-your-pr-
| efficienc...
| lizard wrote:
| Having worked as a software developer in several different areas
| of enterprise IT, the vast majority of the work is about
| "Improving {process} to increase {team}'s productivity."
| Businesses already know, or at least hope, that "Good {worker}Ex
| increases productivity" and push endlessly towards that
| objective. It's quite possibly the only reason non-software
| companies hire software developers.
|
| It's just that IT departments routinely fail to be included in
| that. So the IT workers get burnt out working on projects they
| don't understand to make someone else's job easier, while their
| job gets continually worse because everything is an IT problem
| now. (And in many cases, nothing actually improves for the
| business either, because the project only considered the "happy
| path" so they are still spending most their time dealing with the
| special cases, but now have to go through IT who are too busy
| doing the same thing for everyone else.)
| nzach wrote:
| Do we have a precise definition for what "DevEx" means?
|
| Talking about productivity by itself is already pretty hard,
| trowing "DevEx" into the mix seems to me like the perfect recipe
| to sell snake oil.
| adamzochowski wrote:
| I worked for a large corporation. The corporation had a program
| to hire coop students, both from high school (limited to 4 hrs a
| day for 5 months), and from university (different universities
| had different programs, some had 4 month engagements, others than
| 16 month long ones).
|
| This had positive effect of forcing our internal documentation
| for developers to be top notch, so that students / new hires were
| up to speed as fast as possible.
|
| If your corporation has resources to hire co-op students, use
| this as opportunity to look into what DevEx pieces are missing,
| what you can improve. This will improve your teams docs/devex and
| will help your team better interface with other teams within the
| corporation.
| olliej wrote:
| One big issue in developer productivity that seems less
| overlooked now is testing and test turnover time. I guess you
| could argue this falls under the responsiveness banner in the
| article, but that doesn't really discuss the extensiveness of
| testing and focuses mostly on things like review feedback.
|
| Testing in general is great because as your corpus gets ever
| larger you can be more confident that just running the testsuite
| is sufficient to catch regressions. That's why large projects
| these days often require every behavioral change or bug fix to
| have new tests to cover the intended behavior and additional
| negative tests as well (eg don't just test the new behaviour/fix
| works, you have to add tests for neighboring behavior as well).
| For many simple fixes the time to make tests is actually greater
| than the time to make the fix itself because you reduce the
| overall development time for the entire project in doing so.
|
| Over time that makes new development substantially easier and
| less worry inducing, but if you're constantly adding new tests
| you get a new problem: eventually running all the tests just
| takes an absurd amount of time, even spread over all the cores
| (and depending on what your tests do it can make your computer
| unusable at the same time).
|
| I recall at some point the webkit bugzilla added bots so you
| could queue automatic test and commit flags, so you could locally
| test just the subset of tests you expected to be impacted and
| then rely on the automated infrastructure doing the full tests
| prior to merging which helped there.
|
| I vastly prefer that to "merge and rely on CI bots catching
| regressions" because it trivially leads to you having local
| checkouts that have failures and then you have to go back and
| forth verifying the local failures are existing in the tree, etc.
| In my experience that model seems much more prone to having
| regularly broken bots, and that breakage leads to normalization
| of broken bots and general distrust of local failures ("my change
| couldn't have caused this breakage, so it must already be broken
| in the tree and CI hasn't caught up")
|
| You get similar issues with build times and there isn't really a
| solution for that in the C/C++ model of compilation - if the
| wrong header is touched you end up in a miserable near world
| build misery pit, and it doesn't seem like there's any real
| solution for that yet. This feeds into the last point as well: if
| you get local failures but you don't have confidence that the
| build isn't already broken there's much less incentive to rebuild
| the entire tree without your changes to confirm the "impossible
| by your change" regression is not in fact caused by your changes.
| ChrisMarshallNY wrote:
| I tend to spend as much -or more- time on the backend of my apps,
| as I do, on the frontend (frequently more time).
|
| Not only is it important to make developer experience smoother,
| it is also important to make it _safer_. When a dev makes a
| mistake, it can cause big problems, so it 's important to make
| their tools easy to use and understand.
___________________________________________________________________
(page generated 2024-01-24 23:01 UTC)