Devex: What actually drives productivity
queue.acm.org
queue.acm.org
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.
For knowledge work, though, the best work is done by people who are intrinsically motivated. Rewards (like a life-altering kickback) don't actually elevate performance that much. Instead, they become the new baseline, and performance falls once again. Alfie Kohn talks about a study in his book, "Punished by Rewards," where kindergartners who received a reward for coloring—something they normally intrinsically enjoyed!—spent less time coloring than those who didn't.
I guess what I'm saying is that you sound burned out, and you might be happier if you chased work you loved rather than a fat cheque.
As for me, I'd rather hire people who are intrinsically motivated and pay them fairly. People can tell when their coworkers aren't engaged. It spoils the culture of the whole team.
That has always been the case for me: as long as I can comfortably pay my bills, I don't really care about extra money, has zero effect on my performance.
But even when doing what I love (programming), I still feel the need for some form of external recognition. I've noticed even a simple "thank you for the extra work" or "great job" can do wonders for my motivation within the company.
> People can tell when their coworkers aren't engaged. It spoils the culture of the whole team.
I wonder if that's the case for remote workers. I have been fully remote for the past 10 or so years and it almost always seems to me most people are slacking and I'm the one putting in most of the work.
Should angel investors decline to fund founding teams that aren't this instrinsically motivated?
"70%?! That sounds extrinsically motivated... We believe that the best work is done for intrinsic satisfaction! We'll throw in a subsistence salary and 1% equity, just because. (And let's make it options, not founders' shares, since you're intrinsically motivated, right?)"
Perhaps performance and capability to negotiate is sometimes downstream of, but not always not 1:1 correlated to, intrinsic vs extrinsic motivation.
In my experience, the top performers I've hired and worked with who have had the highest performance and highest compensation have all been intrinsically motivated. YMMV.
How can we reliablt study a work done one children coloring books and getting small rewards , as a relevancy for grown people, serious people. with families to feed that are getting big bonuses that have high impact on them ?
The thing that I think you (and many others in this weak crop of leaders) don't understand about your own success story is that you were one of the lucky ones. The reality is that a lot of others out there burned their midnight oil, and even probably enjoyed the thrill of it, but then got nothing for it. Indeed, they probably even got laid off as a reward. And then they rationally decided that they didn't want to die a sucker.
I'm a programmer who advises software leaders on how to create effective software development organizations. I didn't get here by burning the midnight oil; I got here by understanding software development—and getting lucky. I adopted Extreme Programming back in 1999, had notable successes, and people wanted to learn from my experience.
I'm saying that people work most effectively when they are intrinsically motivated. This is well supported by books such as Alfie Kohn's _Punished By Rewards,_ and more recently popularized by Daniel Pink.
The job of the manager is to support that motivation: to provide context and resources (I don't mean people); to trust people to do a good job; to put decisions about work processes in the hands of the people doing the work. And yes, to hire people who are worthy of that trust, and who work well in that sort of environment, and to remove people who are not.
This is not about working long hours, or taking advantage of people. It's about doing work that you can be proud of, in an environment that supports doing your best work, with a team that's jelled, creating things that are better than you can create alone.
If you've never been in that kind of environment, it might seem like an impossible dream, or even a cynical ploy to pay less.
It's not.
I think the thing a lot of people in this thread are missing is that intrinsic motivation isn’t just about the person. It’s mostly about the workplace. It isn’t possible to create intrinsic motivation, but it is possible to destroy it. Micromanagement, useless interruptions, excessive meetings, unreasonable deadlines, all that devex stuff, and yes, unfair compensation… it’s all going to lead to an environment where people hate their job. If you’re in that kind of environment, get out. It’s bad for your soul.
If so I'm trying this and so far I'm deeply unhappy, even with a "high" salary, I struggle to wake up. Meanwhile 2 years ago I was doing part time manual labour and self driven fullstack app on my own time and own term. I was 10x happier.
Software work teams are messy.
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.
Spent two days dealing with memory corruption caused by a badly-written third-party library (proprietary, binary-only distributed)? I may have felt like I own the universe when I finally found the problem, but what does my manager see? Me having promised the feature today, and now saying it'll be next week.
A bad manager may ignore everything but that, but if a manager isn't even aware there was much more to the story than just that, both the manager and the individual have failed.
"Oh THAT is why we keep Bellend"
That's a different problem altogether. This isn't a factory and robots. There's no way anyone can estimate if and when an unknown can be solved. The game of estimates for these things is silly at best.
> There's just little to no correlation between the tough parts of this job, and the outcomes visible to stakeholders
There is if you make it so. If the stakeholder only cares about new features that's how we end up with products releasing new features non-stop but never fixing bugs that users care about.
The problem is the attitude and treatment towards software engineering being like a factory worker. It's not predictable the way they want it. They don't understand what's tough.
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.
[0] it can go even worse, I was thrown under the bus while doing everything.. i have no proof but i assume the other people were too happy to see me burn so they can go back to pretend working without someone showing what's the normal output is
Rewarding this behavior incentivizes the creation of unnecessary problems only Johnny knows how to solve.
Honestly, working on a team where people refuse to do anything more than the bare minimum to fool management each week kind of sucks for everyone else. Everyone else eventually leaves for teams that have a healthier work balance. Extremes are bad in both directions.
> 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.
I get it. You went through an abusive work relationship. That doesn’t mean you now need to become bitter about every job. (Same applies to relationships, FWIW, some people to though an abusive personal relationship and then proceed to sabotage all of their future relationships so they can avoid the feeling of being taken advantage of. It’s not healthy)
Corporations and management simply don’t have any tools to predict or control those things so they simply reward work and replace people who can’t work at a given base level. Adding a bit/lot of political machination and basic stimulus response for economic conditions and you explain most of “performance management“
Personally I'm not very extrinsically motivated. But I can be extrinsically demotivated by things like a colleague making much more than me while doing much less. These stressors are what keep me out of the job market and in my own company.
Your 20% puts you somewhere on the curve, perhaps to the right of the optimum, which might also explain the lack of life altering kickback. It's a feedback loop. Management wants workers at the top of the curve, not at the interchangeable edges.
It may very well be that the mediocre programmers, who feel lucky to be employed at all, are carrying the industry on their shoulders. Oddly enough this gibes with the widespread management attitude that they'd rather reward a mediocre person who works hard, than a brilliant worker who appears to be taking it easy.
And that it was only when I was gone, and they started working with other software engineers, that they realised how effective I was, even when I wasn’t as productive as usual, and how they had failed to appreciate it.
It truly was an enlightening moment for me. But years later I still don’t have a clue as to what I should take away from it.
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/S016412121...
[1] appears to do better by classifying self-reported outcomes into positive and negative categories. Classifying comments into the high or low productivity category seems challenging, but at least they provided a few examples. More importantly they identified a range of other positive and negative outcome categories.
IMO, solid groundwork for analyzing development. These feel like good core principal components.
IMO that’s the single most important factor in developer experience. The rest is an effect of that.
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).
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.
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.
> 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.
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.
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.
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.
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."