Give 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.
In other words, you're extrinsically motivated. Possibly an excess of rewards and punishments in the past has burned you out and destroyed your intrinsic motivation, as extrinsic motivators are known to do. Your final paragraph makes it sound that way.
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.
> you might be happier if you chased work you loved rather than a fat cheque.
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.
I rarely read people talk about intrisic vs extrinsic. But I've seen this on the field in various jobs. Intrinsic motivation is rarely rewarded (and most of the time ground down). That's why a lot of people just want their own WFH gig so they can keep reaching higher levels as they see fit.
This sounds highly entitled on your part. Employment is a transactional business relationship. I care a lot about my work and my profession in general, but at the end of the day I'm being paid to care about whatever it is that I'm being paid to care about.
I want to be paid for my work, but you can't buy my care. Or maybe it would be possible but no job has offered enough to buy my care yet. It's just that I do care about my job regardless of the pay.
I care about my job and the industry I work in, otherwise I wouldn't have the job in the first place. But if I wasn't being paid, I wouldn't do the work. You can't buy my basic personal interest, but you can absolutely buy my ongoing care and attention.
> 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.
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?)"
They could, but then they'd lose out on strong deals.
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.
If you don't need to pay your employees more than what's "fair" because they aren't motivated by money, what becomes of the excess profit in your company that you save on bloated salaries? Do you donate it to charity? And on a related note, what motivates you?
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 ?
Honestly, no. I just get tired of hearing the same boring "I only hire go getters who enjoy hard work for its own sake" mantra in response to people asserting their own worth.
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.
You're so eager to take offense, you're imagining I'm someone different than who I am, and that I'm saying something different than what I'm saying.
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.
The OP has a point. You can be intrinsically motivated and still wind up bitter and disillusioned by spending years in a terrible job where all the “devex” things in this article are deep in the negative. High cognitive load, constant interruptions kicking you out of flow and miserably slow feedback loops can make anyone hate their work. Your description of doing work you’re proud of with a good team is a far off fantasy for a lot of people. You being a consultant should know this more than anyone.
Oh, I know. Best thing people can do in that situation is to move on. Life’s too short to spend 1/3 your waking hours in an environment you hate.
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.
Now these are all statements I agree with. And if I missed any of this in your earlier comments, I apologize. Although I would add that I think everyone has the instinct to be intrinsically motivated.
I don't think he's advocating for bleeding to death. If I understand your message, you'd rather optimize playing the corporate game "negotiate higher, while doing just enough" ? is that right ?
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.
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.
I don't know if this is even solvable in principle. There's just little to no correlation between the tough parts of this job, and the outcomes visible to stakeholders (even technical managers).
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 manager should never see only "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.
I'd personally solve it asap but I would never declare it until it was absolutely critical and then look like a superstar at day0 to offset all of the time I spent doing nothing for weeks.
> Me having promised the feature today, and now saying it'll be next week.
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.
Congrats on taking that step, I've often debated on doing the same but can't seem to make the leap. I checked out your company and am very impressed. While the site says "Sorry, we don't currently have any open positions." I'll take this opportunity to ask: Could there be a need for someone with two decades of diverse technology expertise, or a role that specifically requires skills in C#, SQL, or AWS, which hasn't yet been filled within your company?
I 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.
My 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.
They look at you as a process. Paying you more is like disturbing the process. Better keep the process running without touching it. They can always offer you more if you decide to look for a job elsewhere.
It's sadly very true. Yes-men, doing their best to handle everything without asking .. get nothing[0]. I think it should be taught that any favor in a professional context should start with a negotiation until you trust these people to respect your engagement and involvement into caring for the project.
[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
There is a lot of middle ground between game industry 80 hour crunch mode and doing “maybe 20% a week of my total”
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)
Something to keep in mind… people change. Capacities of an individual worker may suddenly shift for better or worse through what is essentially happenstance (family emergency, burnout, unlocking motivation, etc)
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“
That's probably hard for a company to manage appropriately, and determine if they're getting 20% or 100% effort. Do you negotiate with them, "I'll deliver x by February and you pay me $Y,000,000 but if I'm not on target, I'm happy with $Z,000 per month"? After all, how can they read your mind? Honestly curious.
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.
Maybe there's a Laffer Curve of programming. The 100% programmers are doing 0% per week due to lack of life altering kickback or equivalent, and the 0% programmers are doing 100% per week but deliver no value. Somewhere in between, the 50% programmers are the ones who are actually delivering the most value.
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.
I remember a former manager, telling me that being the only software engineer they had ever worked with, I had been my own benchmark.
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.
There might very well be! But your last sentence for me only makes sense if the mediocre person is rewarded which is honestly not a thing. Since if the mediocre developer was rewarded they wouldn't end up being like me.
"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.
Also 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.
To 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.
The ACM Queue article didn't clearly explain what they meant by productivity or how they evaluated it.
[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.
> 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.
What'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).
I 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.
One 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.
Well, 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.
Seems 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.
Cognitive 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.
Or 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.
> 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.
I 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....
Or 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.
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.