12 ms·

Good DevEx increases productivity. Here is the data

243 points by saeedesmaili 3y ago

lopkeny12ko 3y ago
This required an entire commissioned research study and published article...?
- leosanchez 3y ago
  You can think of it as an Ad for GitHub Copilot
  - HankB99 3y 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
- geekjock 3y 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 3y 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 3y ago
  I recommend scaling that to no meetings on most days.
- Aurornis 3y 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.
- rqtwteye 3y 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 3y 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.
- maccard 3y 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 3y 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 3y 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 3y 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?
  - geekjock 3y ago
    +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 https://queue.acm.org/detail.cfm?id=3639443
- shermantanktop 3y 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 3y 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.
GiorgioG 3y ago
Then why do you guys completely ignore https://github.com/orgs/community/discussions/10369 https://github.com/orgs/community/discussions/10369 ?
- rokkamokka 3y 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.
  - GiorgioG 3y 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 3y 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 3y 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 3y 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.
j45 3y 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 3y 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.
  - j45 3y 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.
bloopernova 3y 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/ 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 3y 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.
  - bloopernova 3y 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?
  - hinkley 3y ago
    Part of this work used to be called toolsmith, but it doesn't quite cover the job description.
yjftsjthsd-h 3y 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 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 3y 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-h 3y 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 3y 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...
datadrivenangel 3y 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.
- geekjock 3y 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!
  - Lienetic 3y 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 :).
  - vlovich123 3y 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.
deleted 3y ago
[deleted]
froggygirlxoxo 3y ago
Good DevEx is incredibly important. Nice to see actual data supporting what is already known anecdotally.
jgerrish 3y 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 3y ago
What's DevEx?
- geekjock 3y 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 https://queue.acm.org/detail.cfm?id=3595878
- robertakarobin 3y 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 3y ago
  A shipping company, like VPS or DHT. Or, "Developer Experience", if you prefer.
- swah 3y ago
  "Keep your feedback loops short" is the main one :)
wnolens 3y 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 3y 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 3y 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.
  - rgblambda 3y 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.
- marwis 3y 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 3y 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.
    - marwis 3y ago
      That's surprising. GA workflows are basically yaml lists of docker container names to run. I thought it would've been trivial to emulate. At least much easier than any other system.
- 3y ago
rqtwteye 3y ago
We definitely need daily meetings to discuss this and find collaborative solutions :-) But seriously, is this a surprise to anybody?
jaxr 3y 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 3y ago
Private offices for focus without distractions will become a thing again. Compare salary vs office rent
james2doyle 3y 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.
- deleted 3y ago
  [deleted]
- Kranar 3y 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.
baq 3y 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 3y 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 3y 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 3y 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 3y 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 :(
ontouchstart 3y ago
The other day I was looking up Unix find command on Wikipedia (https://en.wikipedia.org/wiki/Find_(Unix) 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 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 3y 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
flurie 3y 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-determinants-health https://health.gov/healthypeople/priority-areas/social-deter...
- geekjock 3y 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.
  - flurie 3y 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 3y 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 3y ago
I wonder how much having an office where you can close the door would improve DevEx
zoomzoom 3y 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-efficiency-with-our-new-scorecard https://www.withcoherence.com/post/measure-your-pr-efficienc...
lizard 3y 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 3y 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.
- geekjock 3y ago
  See this previous paper: https://queue.acm.org/detail.cfm?id=3595878 https://queue.acm.org/detail.cfm?id=3595878
adamzochowski 3y 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 3y 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 3y 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 3y 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 3y ago
Of course good DevEx increases productivity. Also see Joel on Software: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
gymbeaux 3y 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.

243 points by saeedesmaili 3y ago

lopkeny12ko 3y ago

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

leosanchez 3y ago
You can think of it as an Ad for GitHub Copilot
- HankB99 3y 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
geekjock 3y 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 3y 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 3y ago
I recommend scaling that to no meetings on most days.
Aurornis 3y 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.
rqtwteye 3y 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 3y 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.
maccard 3y 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 3y 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 3y 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 3y 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?
- geekjock 3y ago
  +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 https://queue.acm.org/detail.cfm?id=3639443
shermantanktop 3y 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 3y 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.

GiorgioG 3y ago

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

rokkamokka 3y 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.
- GiorgioG 3y 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 3y 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 3y 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 3y 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.

j45 3y 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 3y 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.
- j45 3y 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.

bloopernova 3y 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/ 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 3y 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.
- bloopernova 3y 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?
- hinkley 3y ago
  Part of this work used to be called toolsmith, but it doesn't quite cover the job description.

yjftsjthsd-h 3y 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 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 3y 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-h 3y 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 3y 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...

datadrivenangel 3y 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.

geekjock 3y 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!
- Lienetic 3y 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 :).
- vlovich123 3y 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.

deleted 3y ago

[deleted]

froggygirlxoxo 3y ago

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

jgerrish 3y 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 3y ago

What's DevEx?

geekjock 3y 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 https://queue.acm.org/detail.cfm?id=3595878
robertakarobin 3y 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 3y ago
A shipping company, like VPS or DHT. Or, "Developer Experience", if you prefer.
swah 3y ago
"Keep your feedback loops short" is the main one :)

wnolens 3y 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 3y 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 3y 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.
- rgblambda 3y 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.
marwis 3y 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 3y 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.
  - marwis 3y ago
    That's surprising. GA workflows are basically yaml lists of docker container names to run. I thought it would've been trivial to emulate. At least much easier than any other system.
3y ago

rqtwteye 3y ago

We definitely need daily meetings to discuss this and find collaborative solutions :-) But seriously, is this a surprise to anybody?

jaxr 3y 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 3y ago

Private offices for focus without distractions will become a thing again. Compare salary vs office rent

james2doyle 3y 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.

deleted 3y ago
[deleted]
Kranar 3y 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.

baq 3y 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 3y 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 3y 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 3y 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 3y 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 :(

ontouchstart 3y ago

The other day I was looking up Unix find command on Wikipedia (https://en.wikipedia.org/wiki/Find_(Unix) 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 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 3y 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

flurie 3y 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-determinants-health https://health.gov/healthypeople/priority-areas/social-deter...

geekjock 3y 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.
- flurie 3y 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 3y 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 3y ago

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

zoomzoom 3y 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-efficiency-with-our-new-scorecard https://www.withcoherence.com/post/measure-your-pr-efficienc...

lizard 3y 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 3y 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.

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

adamzochowski 3y 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 3y 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 3y 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 3y 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 3y ago

Of course good DevEx increases productivity. Also see Joel on Software: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

gymbeaux 3y 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.