7 ms·
Devex: What actually drives productivity
- endtime 3y agoI ran a couple developer experience teams at Google over a period of a few years. The motto was "easy, fast, and fun". Too much software development isn't.
- analog31 3y agoI love Python, and Arduino too. ;-)
- freddref 3y agoHow do you maintain that as things grow?
- jvanderbot 3y agoexcellent modularity, ownership, fast tooling, and effortless communication?
- galaxyLogic 3y agoOwnership yes. But then what happened to Agile "shared code-ownership"?
- jvanderbot 3y agoI have no idea what part of this comment chain contradicted shared ownership, so I'm afraid I can't conjure a good response.
- bluquark 3y agoOne problem of scale here is that unless a tooling investment has made literally 100% of the work easy, most of a developer's workweek almost by definition winds up spent on the remaining slow and hard problems. So investing in tooling certainly improves productivity, but whether it can make things "fun" depends on which categories of hard/slow problems a given developer enjoys.
- endtime 3y agoWell, they weren't Google-wide teams, they were teams for specific platforms/areas within Google. So I don't have any experience scaling it to 100k SWEs. But in many cases it's a question of prioritization and polish. Just as an example, it's very easy to cut corners on API design for internal customers - unless the TL of the devex team is in the room. Or sometimes there are cross-cutting technical issues that no one really owns and no one will prioritize addressing, in part because of the relatively high organizational overhead of doing so and ambiguous ROI...unless the org has specifically staffed a devex team to search out and fix such issues.
- Bellend 3y agoGive me a life altering kickback as a fat cheque each April or get the minimum possible work I can do to keep my job whilst management tries to figure out what that is and if I am viable. I do maybe 20% a week of my total. To be clear, I have been through the stress. ESPECIALLY in the games industry where a specific corner/corner collision had me crying and wished I was dead coz it was on me. I solved it, I got nothing.
- rektide 3y ago> I solved it, I got nothing. Alas one of the most defining aspects of business seems to be an entire lack of rewards for being the Johnny On The Spot, for tackling shit. It's absurd how little benefit there is to being good or caring or taking on the hard shit.
- esafak 3y agoMove to greener pastures and let the competition eat their lunch. Voting with your feet is how we have nice things.
- 93po 3y agoYep. I just quit my last job because I bust my ass with zero recognition or credit. Annual pay raise was less than inflation. I'm out.
- esafak 3y agoI used that very line about the inflation when I left too! And my last manager was nice, but the company was rudderless and mismanaged. I believed I could do better.
- 93po 3y agoMy employer interestingly didn't ask anything about compensation during my exit interview, and I wasn't about to say anything that was negative or not prompted. Benefits me not at all to be honest. I don't think it's "wrong" for employers to not at least match inflation. Ultimately I accepted the job for a set salary. If I want to negotiate higher, that's on me. If they want to do a better job retaining me, they need to offer it without me prompting it. After a promotion I got while there, I was getting paid $110k for a job that averages $190k in my city. Didn't make any sense and the raise was 4%, so I left.
- rektide 3y ago> The Three Dimensions of DevEx Our framework distills developer experience to its three core dimensions: feedback loops, cognitive load, and flow state . These dimensions emerged from real-world application of our prior research, which identified 25 sociotechnical factors affecting DevEx. IMO, solid groundwork for analyzing development. These feel like good core principal components.
- fnordpiglet 3y agoIt’s missing “soul crushing corporate culture” IMO that’s the single most important factor in developer experience. The rest is an effect of that.
- andrewjl 3y agoWhat's odd is that focusing on feedback loops and cognitive load usually lets one out-execute the competition, mapping pretty cleanly to beating them in the market. Yet both of these are hilariously lacking in bigco type environments. Flow state is in the same boat to be clear. But its value is less obvious from the vantage point of someone in a communication-heavy role (as many business focused roles tend to be).
- karmakaze 3y agoSeems like a fine description/analysis. What it amounts to seems to simply be to listen to what developers complain about, in addition to other metrics. A problem is of course that sometimes developers complain that they can't build their grand vision, regardless of how unproductive it is to customers. Also managers don't first-hand understand the importance of developers gripes. A pragmatic approach where an aspect/complaint is worked on to reduce friction etc and measure/survey improvements should inform them what's worked and what hasn't. > To improve DevEx, teams and organizations should focus on creating the optimal conditions for flow state. Disruptions should be minimized by clustering meetings, avoiding unplanned work, and batching help requests. Leaders should also recognize that flow state depends on creating positive team cultures that give developers autonomy and opportunities to work on fulfilling challenges. Some things that address this: no meeting Wednesdays, large meeting block Thursdays, rotating ATC (air traffic controller) for one person to handle interruptions to save the team. One thing that still happens is swiss-cheese meeting schedules starting on the hour (or half hour) and rounding up to same, which waste arbitrary-sized small gaps.
- bostik 3y agoOr to put it simply: allow the people who can actually create the value, to produce the value.
- pyrolistical 3y agoWhat if the value is self serving? Oops, I accidentally defined politicians
- fatneckbeard 3y agosounds kind of like Toyota Production System
- FridgeSeal 3y ago> shows that human factors such as having clear goals for projects and feeling psychologically safe on a team have a substantial impact on developers' performance I for one am _shocked_ at this profound revelation. Sarcasm aside, I sure hope this isn’t a shock to anyone in any sort of position to enact these changes.
- Animats 3y ago"Today, many organizations aiming to improve developer productivity are finding that a new developer-centric approach focused on developer experience (also known as DevEx) unlocks valuable insights and opportunities." That reads like the beginning of a pitch on r/Metaverse_Blockchain. One of the references, "What Happens When Software Developers are (un)Happy"[1] is more useful. [1] https://www.sciencedirect.com/science/article/pii/S0164121218300323?via%3Dihub https://www.sciencedirect.com/science/article/pii/S016412121...
- hliyan 3y agoAlso note that the prior work they repeatedly cite (no less than 5 times in as many paragraphs, and indirectly referenced several times in relation to the 20+ "sociotechnical factors"), i.e. reference number (9), is based on "semi-structured interviews with 21 developers". While a lot of the observations and recommendations are correct (and are obvious to any seasoned engineering manager), this seems like an academic exercise in picking three somewhat disparate aspects of development and trying to fit them into a geometric shape (an equilateral triangle) and then calling it a framework.
- ororroro 3y agoPersonally I am shocked that a company (DX) that sells developer survey tools would recommend surveying developers.
- dimitarbak 3y agoThey present a framework. Measuring the three dimensions of Feedback Loops, Cognitive Load, and Flow State can be done without surveys. Example here: https://docs.kedehub.io/kede-manage/kede-devex.html https://docs.kedehub.io/kede-manage/kede-devex.html
- spartanatreyu 3y agoTo their credit, they mention that customers should be running fewer survey's with more thought put into making it a higher quality survey then actually following through with the results rather than spitting out more lower quality surveys.
- galaxyLogic 3y agoCognitive load, that is an interesting concept. How to measure it? One way you could measure it is count how many questions/decisions you must ask and answer when trying to complete a task. The more questions there are the more cognitive load. I have found in my own work that writing down the questions I need answered helps me make progress in the right dimension. Being explicit about them.
- ElFitz 3y agoOr how many extra hoops not directly to what you have to get done you have to jump through to get "it" done, whatever "it" is. ie, rebasing a branch and fixing 10 tests because your 5 days old PR hasn’t been reviewed and there are now conflicts. Or remembering, each and every time you add a reducer, data source, type, or whatever, to update 5 different lists and enums across to codebase so what you added is properly referenced and used everywhere. Or deploying by hand by zipping everything and drag and dropping the right files in the right place, put not overwriting the wrong ones by mistake, on a mounted remote server in Windows Files Explorer. Or, when new bugs suddenly arise out of nowhere, having to test if it actually does come from your codebase, or if it’s actually from _that_ microservice, the one maintained by _that_ team, the one headed by the CTO, that somehow can’t be bothered to have any automated tests in place and yet likes changing and removing "unused" endpoints. I could go on, and on, and on… Basically, all the things you have to keep in mind and organise or plan for, even though they are only loosely related to your current focus. Having a good engineering culture and relentlessly streamlining and simplifying (but not _necessarily_ automating) both codebases and processes helps _tremendously_. Case in point: CI / CD, automated rollbacks, green / blue deployment, etc.
- dimitarbak 3y agoYes, counting how many questions you must ask to complete a task is a sound way to measure cognitive load. One example is here: https://docs.kedehub.io/kede-manage/kede-devex.html#kede-devex-load https://docs.kedehub.io/kede-manage/kede-devex.html#kede-dev...
- junglistguy 3y ago[dead]
- joeyguerra 3y agoknowing what to do drives productivity.
- naruhodo 3y agoUncertainty drives procrastination. And more generally, procrastination is an attempt at emotional regulation.
- edrxty 3y agoOr at least being empowered to do what you think is right. If I don't know what to do and I'm gonna get yelled at for doing what I see as the biggest risk buy-down/most responsible task then I'm not doing shit.
- villgax 3y agoI swear to god I'll not go ahead with future job prospects until I get confirmation that they do not use ARCON PAM or Oracle/SAP/SAS in their stacks at any point....
- musicale 3y ago> feeling psychologically safe on a team [has] a substantial impact on developers' performance Make sure that developers feel psychologically safe, right up to the moment you lock them out of the building and send them a layoff email. Reassure the remaining developers that they, too, are "safe."
- musicale 3y agoWhat did they mean by productivity, and how did they evaluate it?