Good DevEx increases productivity. Here is the data

https://github.blog/2024-01-23-good-devex-increases-productivity/

by saeedesmaili • 2 years ago

243 128 2 years ago

github.blog

lopkeny12ko• 2 years ago

This required an entire commissioned research study and published article...?

leosanchez• 2 years ago

You can think of it as an Ad for GitHub Copilot

HankB99• 2 years ago

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

geekjock11• 2 years ago

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• 2 years ago

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• 2 years ago

I recommend scaling that to no meetings on most days.

Aurornis• 2 years ago

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.

rqtwteye2• 2 years ago

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• 2 years ago

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.

maccard2• 2 years ago

One of the things to be aware of is that two meeting free days won't double that output. You still do a lot of valuable "stuff" in that meeting time. But, a reliable period of uninterrupted focus time is rocket fuel for an IC. I get mornings for free (I live in the UK and work mostly with the US), and it's insane how efficient I am for it.

tiborsaas• 2 years ago

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• 2 years ago

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• 2 years ago

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?

geekjock11• 2 years ago

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• 2 years ago

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• 2 years ago

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.

baq2• 2 years ago

This is just the whitepaper to cover the manager's manager ass.

GiorgioG2• 2 years ago

Then why do you guys completely ignore https://github.com/orgs/community/discussions/10369 ?

rokkamokka• 2 years ago

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.

GiorgioG2• 2 years ago

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• 2 years ago

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• 2 years ago

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• 2 years ago

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.

j452• 2 years ago

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• 2 years ago

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.

j452• 2 years ago

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.

bloopernova2• 2 years ago

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• 2 years ago

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.

bloopernova2• 2 years ago

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?

hinkley3• 2 years ago

Part of this work used to be called toolsmith, but it doesn't quite cover the job description.

agumonkey• 2 years ago

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• 2 years ago

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.

hinkley3• 2 years ago

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.

Rapzid2• 2 years ago

In my experience workstation setup scripts can be a waste of time to implement and maintain in certain contexts; like everything it depends.

maccard2• 2 years ago

I completely agree. In my experience what, what works is:

1) Development containers. They're not for every situation, but if they suit your situation (prebuilt base images, private repo, long build times that can be split out into common layers, probably remote dev with a good IDE that natively supports them, i.e. a Jetbrains IDE), they're amazing. They completely remove the need for "works on my machine" as you deploy a multi stage built app from the same base container image.

2) Single "5 step" setup page. The setup guide should be: Install git/p4, install toolchain with versions, log in, clone, `make build`/`cmake --build` / `npm run dev`. Depending on what you work on, "run dependencies in a container" (database, grafana/prometheus, log agent) might be there too. Everyone who is onboarded follows these steps, and their first two tasks, in your teams issue tracker are "fix anything that didn't work in setup guide", and "make a PR", both of which should happen on day 1/2.

yjftsjthsd-h3• 2 years ago

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

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".

geekjock11• 2 years ago

"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-h3• 2 years ago

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• 2 years ago

>>> 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...

marcosdumay2• 2 years ago

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.

datadrivenangel2• 2 years ago

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.

geekjock11• 2 years ago

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!

vlovich1233• 2 years ago

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.

datadrivenangel2• 2 years ago

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.

Lienetic• 2 years ago

For the uninitiated among us - can you share more context on the research standards and the reasoning behind it? I'm interested and would like this to influence some decisions I have but would like to understand the confidence here :).

IshKebab4• 2 years ago

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.

thaumaturgy4• 2 years ago

It's peculiar that "developer productivity" is even a term. It doesn't have a generally-agreed-upon definition. I don't think a definition is even possible.

So, we keep trying to come up with objective measures of a term that is impossible to objectively measure. Isn't that weird?

Why not "developer happiness", or, if that's too hippy-dippy for the suits, "developer satisfaction"? Surely we can reason that, all other things being equal, happier developers are more productive.

Then, surveys like this one make perfect sense. "Hey, how satisfied are you with the tools / processes / whathaveyou at your employer?" That's a valid question, and collecting a pile of answers does start to yield some useful insights into what works and what doesn't.

But no, we're trying to use "developer productivity" instead, as though we're all simple machines that provide value by converting coffee into code, and the winning business is the one that is able to extract the most SLOC out of the cheapest and most miniscule quantity of coffee.

herval3• 2 years ago

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• 2 years ago

So do ineffective DX, most times.

I don't find this hard to believe, but do you know of any research showing this?

makeitdouble• 2 years ago

DORA metrics

I generally agree with your point, with the caveat that metrics like DORA are the first to be gamed when applied to an organization.

It's the usual cycle of applying the metrics first in an informal way, then using it for team/process evaluations as it seems to be somewhat reliable, then teams start to reajust how they make the tickets and the deploy cycle in ways that dramatically increase the metrics while reality hasn't changed much.

Analyzing productivity with completely objective metrics will I think always bear these flaws (I'd assume even measuring things at the highest level as "wages vs revenue" would be gamed on how wages and revenue are calculated ?)

froggygirlxoxo• 2 years ago

Good DevEx is incredibly important. Nice to see actual data supporting what is already known anecdotally.

jgerrish• 2 years ago

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• 2 years ago

What's DevEx?

geekjock11• 2 years ago

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• 2 years ago

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• 2 years ago

A shipping company, like VPS or DHT.

Or, "Developer Experience", if you prefer.

swah• 2 years ago

"Keep your feedback loops short" is the main one :)

wnolens• 2 years ago

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• 2 years ago

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• 2 years ago

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.

rgblambda2• 2 years ago

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.

marwis2• 2 years ago

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• 2 years ago

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• 2 years ago

What’s the crowd favorite self-hosted alternative these days?

conor-• 2 years ago

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• 2 years ago

That has nothing to do with GitHub Actions. That’s just poor setup

Rapzid2• 2 years ago

That's most automation and you almost need an obsessive personality for it.

Lots of room for innovation for sure. But if you think actions is bad try iterating on Windows slip streaming.

akvadrako• 2 years ago

It's not hard to put all the meat in containers run via a Makefile.

Then to test locally you just do "make check".

The problem comes if you start using pre-made actions instead of simple commands.

rqtwteye2• 2 years ago

We definitely need daily meetings to discuss this and find collaborative solutions :-)

But seriously, is this a surprise to anybody?

jaxr• 2 years ago

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• 2 years ago

Private offices for focus without distractions will become a thing again.

Compare salary vs office rent

james2doyle3• 2 years ago

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• 2 years ago

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.

james2doyle3• 2 years ago

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• 2 years ago

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• 2 years ago

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.

james2doyle3• 2 years ago

Oh true. That is a good point. I didn't think of it that way

baq2• 2 years ago

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• 2 years ago

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• 2 years ago

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• 2 years ago

'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.

ilc• 2 years ago

IMHO: DevOps was about a simple thing.

"One throat to choke." If there is a problem, you have operations, and development mixed together to produce one nexus of responsibility.

The moment someone says "I can't.... because I'm not a..." in those situation you've lost the point.

The whole point is... It IS your problem as a team. FIX IT. You have everything. Make it happen.

Now a days... the thread has been totally lost. I've gone back to development. I prefer tossing the dead cats over the fence over receiving them.

Either way... the poor cat is dead... we didn't work together to save it :(

ontouchstart2• 2 years ago

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.

ontouchstart2• 2 years ago

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

flurie2• 2 years ago

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...

geekjock11• 2 years ago

"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.

flurie2• 2 years ago

Thank you for the response! Though I think in taking the rest of the context of my criticism away you've avoided the main point of it, which isn't conflict of interest, but whom your research serves to benefit. For example, it would be a shame if cancer research were carried out only on rich or educated participants. That doesn't mean that you shouldn't work with the population you have access to, but perhaps you should give some thought to how you can broaden participation.

anoojb• 2 years ago

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• 2 years ago

I wonder how much having an office where you can close the door would improve DevEx

zoomzoom• 2 years ago

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• 2 years ago

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• 2 years ago

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.

geekjock11• 2 years ago

See this previous paper: https://queue.acm.org/detail.cfm?id=3595878

adamzochowski• 2 years ago

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• 2 years ago

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• 2 years ago

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.

brown9-2• 2 years ago

This seems like a tautology because what we think of as a good “experience” is something that lets us get our work done quickly. No one ever said a tool had great devex but was hard to get stuff done with.

zubairq• 2 years ago

Of course good DevEx increases productivity. Also see Joel on Software:

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

gymbeaux• 2 years ago

A few years ago I worked for a startup that was recently acquired. We were absolutely minting money, but all the devs got these little Dell ultrabooks with dual-core 15W i7 CPUs. It took around 20 minutes to build the frontend of our web app. People generally tolerated it, but I rocked the boat and rallied coworkers until we all got 6-core 45W i7 laptops. I was lobbying for my sanity, but obviously reducing build times by 10x adds up really quickly and the “managing out” from higher ups that I received subsequently was kind of insane considering the man-hour savings.

Good DevEx increases productivity. Here is the data

Related Stories