Cool but the only way I can stick to self-imposed deadlines is with medication. No amount of self-help and work philosophy can fix what's broken on a hardware level.
That’s an unspoken truth that some therapists don’t want to admit. Some will push you to the limit, while detracting from medication, even when it’s necessary, because as you said, no amount of software will modify (enough) the hardware
I like this idea in theory. It seems to be empirically a good observation. I do take issue with the solution though.
Maybe it comes down to how you model the minds of those around you, but I notice a pattern in articles like this, that the solution seems to be presented as universal. In my experience, deadlines, especially self-imposed ones, are very effective for some (say 40%) of people, but they're not a panacea.
Wouldn't it be nice if there was some more general theory that explained Parkinson's law, and suggested various solutions that will work for various people?
> I love deadlines. I love the whooshing noise they make as they go by. - Douglas Adams
One of the things I learnt about ADHD from my recent diagnosis is how it disrupts your perception of time compared to people without it. To me it doesn’t matter if there’s a deadline, my brain just does not perceive time in a way that makes it matter.
Of course I have strategies to manage this, and medication helps somewhat. But if I set a deadline for myself I’m never going to keep it.
My girlfriend has ADHD and she mostly only can get things done when there are deadlines outside of her control (e.g. cleaning up when we have visitors).
When she wants to do something just for her it can take ages, if it gets done at all.
I would like to help her with this but I don't really know where to start.
For 'time blindness' my personal solution is that I have a miband that vibrates periodically. I think most smartwatches have such a function.
I am an inattentive type who skated thru behavioral checks by being the quiet kid who never causes problems. What this really means is I am doing ranked competitive daydreaming and sometimes need to be reminded to exist.
In some cases, time pressure can focus me and get me to a solution faster, but I then need downtime to recharge. I don't think I've worked in that sort of environment since working in food service or at a movie theater.
Deadlines often just stress me because I can't effectively reason about the intervening time.
Partly because in practice, there's one group of people _setting_ deadlines and a completely different set of people responsible for them. I don't know how one moves into the deadline-setting ruling class, but it definitely isn't diligent work, careful attention to detail and achieving demonstrable results.
And even if you’re the one setting deadlines, if the powers that be are punishing people over any missed deadlines you’ll quickly learn to set deadlines to at least 3x the amount of time you think something will take.
I'm cofounder of https://talkjs.com, and I strongly disagree. We do not believe that Parkinson's Law universally holds, and in fact we do not use deadlines at all. If I'm not mistaken, the standard lore goes as follows:
1. Work is awful and people hate doing the work they get assigned
2. Therefore, people will try their best to do as little of it as possible
3. Thus, if there's no deadline, or the deadline is very lenient, then people will mess around to fill the time -> Parkinson's Law!
Turns out that if you stop the military carrot & stick model of work, and instead try to actually be a place where people want to do great work, then this dynamic changes completely. We do it like this:
1. Make sure every employee does some amount of customer support. This makes everybody feel that real people are facing real problems that need real solutions, fast.
2. Give people a lot of freedom in what they work on, in what order, so long as it fits broad company objectives. If a customer reports a bug and it "nerd snipes" you completely, go for it!
3. Teach people scoping and iterative delivery. Stuff like "ship it when it's better than what's live now" (vs "ship it when it's perfect"). Many engineers like to polish things forever until it's perfect (this is the less cynical interpretation of Parkinson's law) but you can just coach people in this, takes a few months max.
I can honestly say that our dev team is the most productive team I've ever been a part of, and we do this without deadlines, without yelling managers who turn your estimations into promises, without overtime, and anything else like that. Parkinson's Law doesn't need to hold. It's a consequence of a shitty low-trust working culture.
Admittedly I've no idea whether our approach scales to larger companies - we're 15 people. Also we hire explicitly for people who are able to handle this kind of freedom. But it works excellently for us.
>>> "ship it when it's better than what's live now"
Is a fantastic rule - as it is almost always measurable (even things like engineering quality can be measured (a little)) and so justifiable.
Also your last line (Deadlines are poverty) suggests that it’s a term you use a lot in your company - want to expand?
> Also your last line (Deadlines are poverty) suggests that it’s a term you use a lot in your company - want to expand?
Nah, I just invented it to make the comment feel more edgy. Your question made me realize that that's the only reason it was in there, so I edited it out. I mean I do believe that deadlines are poverty but the comment is sufficiently controversial without it.
Basically, I think the idea of hiring highly intelligent and creative people, and then forcing them to work on assigned tasks on sticky notes given to them by "product managers", is an extremely brutal destruction of capital. Sucking the joy out of creative engineers seems like a very costly idea to me, and I'm not convinced that the project management benefits of doing so exceed that cost. Just see how fast and well and enthusiastic people can code when doing eg open source projects, or hackathons, or entire browsers (Ladybird), and so on. I think as a leader you should want to channel that joy and enthusiasm for your company's (and your people's) benefit. If you give people a lot of trust and freedom, and build a culture of eagerness to ship, you can get that. Deadlines then are an extreme buzzkill and I firmly believe it makes people less productive in the long term, particularly because they'll just do worse work and that compounds quickly.
This chimes with my own experience and attempts to build sane work environments wherever I can.
I think software has a very unusual relationship to the “explore exploit” concept - in that most manual / labour intensive businesses probably work ok with 20% explore - but with software once the explore is done the exploit is a marginal cost - so one should tune software business to be very high explore ratios (lean processes etc).
In other words hire great people and let them experiment.
My general schtick is that software is a form of literacy - and if you hire an illiterate person to for example write your autobiography, the process they would have to come up with would look not dissimilar to most Agile projects.
Or perhaps another way of looking at it - Linus Torvalds accepts patches that have made their way through several layers of “lieutenants” - why shouldn’t the CEO of corporate X be the owner of the codebase that runs the corporation ?
In the end all the discussion should be about the code - if it is not about the code you are discussing the wrong thing.
Anyway - completely agree with your points and your … passion? It’s in the right direction and good luck to your business :-)
Fwiw I agree with most of what you said, but as a business owner I can't let this one slide:
> In the end all the discussion should be about the code - if it is not about the code you are discussing the wrong thing.
The code is important, but in the end it's all about the customer. For us, if it's not about the customer (in the end), you're discussing the wrong thing. This is a key part of our "ship fast and incrementally" ethos - how can you tell whether something is better than what's in production now? By explaining how it impacts the customer.
Yes - of course. I think as a peon in a vast multi national there is too much “other” - PowerPoints, project plans not connected at either end to real customers or real code. I want to at least connect one end :-)
The time in my career where I worked hardest, and with little stress, was on a team that was kind of forgotten and so we were just doing our own thing without deadlines. We decided what we thought was best and started working towards it with a lot of energy and enthusiasm. The team went about a year without any deadlines and very little management of any form, and yet the team was happy and working. Then we lost some political battles and all got fired--but my point is, I've seen that people will work with enthusiasm on things they care about even without pressure.
I think the problem in my situation (above) was that we were disconnected from what was important. You solve this by ensuring everyone is directly connected with the customers. It sounds nice and I hope it continues to work for you and your company.
(It's a shame that this post has net-downvotes currently.)
In a larger organization, you inevitably have a more hierarchical management structure, as well as multiple projects going in parallel. Prioritization and scope creep become significantly more difficult to manage. Only a small and specialized group of people talk directly to customers, which breaks the feedback loop you're talking about. And it's much easier for an individual engineer to go down an unproductive technical rabbit hole.
Many product categories are not well matched to the rapid iterative development style you are describing for your server side chat system, due to the significant costs involved in updating products that are already deployed.
This works in a small organization, and is probably the best way to run one. I've been part of multiple teams like this. Everyone is high agency, genuinely interested, and making decisions that are (at least intended to be) best for the whole.
As another poster said, this just doesn't scale. You eventually hire someone who doesn't care as much, or just sees it as a job, or has worse judgement.
Being able to run this way is almost a paradise, and it's a lot of why startups can out compete big players.
Interesting to put this besides Hofstadter's law, which looks to be also real, which states "It always takes longer than you expect, even when you take into account Hofstadter's Law."
I don't think these need to be reconciled though as they are about different things: one is about imposing psychological threats to induce action and the other is about the inherent incapacity for humans to reason temporally concerning complex tasks.
One problem that arises though is that when tasks can't be sufficiently estimated, how do you reliably impose said psychological threats which don't turn into casual "oops, software's hard and is hard to estimate, hopefully better luck next time."
One very useful outcome of setting relentless deadlines is forcing engineers, who are rather prone to overengineering and analysis paralysis, to just do 'good enough' and unblock themselves.
Its a mental trick to get them to focus on outcomes instead of the journey. Far better to let them mutter darkly about perceived 'technical debt' that is incurred delivering business value than to actually let them try and do things their way :D
This doesn't absolve management of picking the right problems to solve etc, nor absolve engineers of solving those problems in a competent manner.
But what it does is make good engineers work on the right thing, because lots of engineers have a tendency to not see the business wood for the trees and go off solving the wrong problems if self-organising.
Of course it is not nice to be an engineer and see how, as a generalisation, we can all be manipulated like this :)
The reality is mostly against that benefit though. I've seen so many bad decisions to be made in a short timeline to keep up with the deadlines, which leads the project to be dead soon later. There's always a deep balance to be tracked on.
I understand the parent comment like this: "they gave me 30 days so they must be wanting the X solution" vs "I have to finish this today so its ok to do Y instead". The latter works better most of the time because you can do a second, third iteration of the solution with real feedback.
There is also the opposite. It works well for some time, then after a hundred or so sprints with deadlines and no down time, engineers pick up and leave. When there is no time to rework and address some tech debt, suddenly features take longer to develop and UAT becomes a game of whac-a-mole. If at least the management could also focus on delivering real tangible value, mercilessly cull all the nice-to-haves that introduce too much complexity, and prioritize work that will help bring out a stable and polished experience (albeit with less bells and whistles) instead of pushing new half baked features to satisfy the self imposed OKRs and stroking their vanity to move up the ladder.
> about perceived 'technical debt' that is incurred delivering business value than to actually let them try and do things their way :D
Aye.
Some day I will write a detailed account of the worst code I've ever worked with. 1000 lines of spaghetti inside a single if-block; 20,000 blank comments; a whole pantheon of god classes; etc.
And yet, it was a very successful *product*. Much more so than the carefully engineered and architected codebase in an ISO 9001 (or was it 9000?) employer.
"""It was the best of code, it was the worst of code; it was the age of delivery, it was the age of technical debt; it was the epoch of rapid prototyping, it was the epoch of unmaintainable legacy; it was the season of boundless innovation, it was the season of endless refactoring; it was the spring of shipping features, it was the winter of debugging nightmares.""" etc.
You can also just coach engineers to ship iteratively directly, rather than treat them as hopeless basket cases and use deadlines as a workaround. I mean stuff like, teach them to ship when it's better (and not when it's perfect), how to break work down in tiny parts, etc. These are learnable skills. The fact that few people graduate from college with these skills doesn't mean they can't be taught in a straightforward way.
Always doing "just good enough" logically results in a product that's barely good enough. Customers may find a competing product that's better than barely good enough.
Conversely, a very tight deadline might well mean that the project/feature gets shipped - but corners will have inevitably been be cut and the chances of a major rewrite of the feature in the future will have been increased.
This is a failure as a developer. A full rewrite is almost never a good idea. You should be fixing things as you go, and making things better. It’s your job to spread the load and say “I need X days to do some extra work because Y isn’t working properly”, and stand your ground. I worked on a project that had hard deadlines every 2 weeks and shipped an unreliable amount of cruft. Even we had time to say “no, sorry”.
Besides if the project succeeds for years then joy might have made the right choice cutting corners.
If you add daily deadlines to the daily meetings and hang daily motivational posters on the walls you risk blunting any and all responses to the daily managerial background noise.
I worked at a major cloud provider and saw this first hand.
When I started, I was really bothered by the fact that everything took so long. I had joined from a startup where there was time/financial pressure. Everything needed to be done now, and there was incentive to get it done.
The cloud provider was the complete opposite. Everything was slow. Things that should take a day took a week, things that took a week took a month. I rationalized it that there were more checks in place, more i's to dot, more t's to cross.
But in hindsight, it was the domino effect of Parkinson's law in play. The cloud provider had enough money to keep paying everyone in perpetuity; that removes financial constraints. Time constraints could be explained away. So things just got done whenever they got done. The knock on effect of this is that when you depended on other teams, they got around to their external responsibilities whenever, that then slows you if you depended on them.
The larger organization accounts for this by expanding timelines (because what else are directors/vp's/etc to do... they're powerless to actually implement), which are then just filed with more waste.
I believe that this is a problem with western societies at large.
The tempting efficiency of infant capitalism was its decentralized and small scale structure. You can’t govern a country top-down, and letting the people at the bottom do their own work is most efficient.
But now some companies are larger than most countries and we are back to where we started… but without transparency and democratic regulations.
I think we need better ways to deal with large systems and complexity.
True but also the sheer number of people now trying to use it. Other factors include the difficulty of getting an appointment with the first call GP (once known as the family doctor) and the utter madness of many A&E departments. They do a great job but can't cope. 12-hour waits are not unknown. I see no reason to expect a turnaround with the Labour Government.
It would seem building better systems is not enough. We must strive to maintain, continuously improve, and scale them to meet demand.
Sadly culture in the US is diluted into believing that profit motive is a silver bullet that fixes all problems. And many are raised in religions that teach one to deny critical thinking, embrace appeals to authority, and love confirmation bias.
That's not my point. My point is that overhead increases and efficiency decreases the larger your system is. And companies at the size of states are just as inefficient.
Ergo, the idea that the market handles their duties more efficiently is a lie. It has nothing to do with corporate vs state owned enterprise, but a matter of complexity.
There's the Chinese saying "Heaven is high, and the emperor is far away". The idea being that low level bureaucrats are actually the ones running the show. Effectively, that's where China and the CCP sit today.
However, that has similar issues to the ones I described above. Top down mandates, the low level feigns to appease them, but marginal progress is actually made. Instead of expanding the timelines as I spoke about, in the CCP(/Soviet) case, the actual accomplishments are made up to keep "going forward". Think of all the ineffective building done to meet bullshit quotas in the China currently. It harkens back to the Soviet era.
I completely agree. But the intend I wanted to capture was that if you have complete transparency over your own system, can act independently and are not bound by top-down mandates, this is where you have the highest efficiency.
This is identical to the idea of small scale teams working on systems they completely understand and own. This is where you have the most productive teams and it is the same in terms of bureaucracy. And the job of an architect is not to create "a beautiful system", but to lower the complexity of the overall system.
I think the topic of complexity and large systems is one of the defining ones of our time. Similar to entropy, you start with a low-state system where you can generate energy from putting entropy into the system. But with a higher state of entropy, your energy gains decrease.
We act like you can just pure more and more onto the same pile, but eventually, everything stagnates. And only collapse can create a blank slate.
It seems like the real problem is finding a way to address that.
We've seen this play out over and over. Take something like building and zoning codes. They start out doing something worthwhile, like requiring fire exits. But soon you have a bureaucracy micromanaging everything, imposing minimum parking requirements even on a building sitting on top of a subway stop, imposing minimum lot sizes or density restrictions, requiring unnecessarily costly or labor-intensive construction methods at the behest of device makers or trade unions, etc.
What you need is a mechanism, something like checks and balances or a challenge process that allows any rule to be repealed if it doesn't still have enough votes to pass in every branch, to inhibit that process of ossification and corruption and clear out the cruft accumulated by its past operation.
The problem isn't so much that you need to throw sand in the gears. We've eroded some of the checks there used to be (e.g. moving to US Senators having statewide elections instead of being elected by state legislatures) and maybe we should put them back, but in general the system of checks and balances works kind of okay.
The issue is that it's not perfect, and it's never going to be perfect, so you're occasionally going to have things get past the gauntlet and make it into law when they shouldn't. And over time those things accumulate.
So what you need is a functioning process for clearing out the cruft even once it's already there. Something like, make it much easier to repeal rules than enact them.
> What you need is a mechanism, something like checks and balances or a challenge process that allows any rule to be repealed if it doesn't still have enough votes to pass in every branch, to inhibit that process of ossification and corruption and clear out the cruft accumulated by its past operation.
I agree in the sense that some way of "caretaking" is absolutely necessary. Like in a badly maintained IT-system, many managers think you can just keep piling stuff ontop of the old system and you can just happily going forward forever. But of course that is a terrible misunderstanding.
In an IT-system, you either restart from scratch or start a refactor. I think these are the only options here either. This needs talent and money, something the public services have been massively drained of. You can't make a system more lean and efficient by cutting costs, you mot make investments. If you involve Civil Servants, they will tell you exactly what kind of issues they are facing each day processing official documents.
Ideally, you'd start a digital transformation of public services and also streamline the legal cruft at the same time. But the problem is that much of this "cruft" is there on purpose because somebody profits. Such as the impossible Zoning Rules in California to prohibit any additional housing space... because that would make housing more affordable and lower their prices.
In a bigger organization you're further away from the actual mission of the organization, which eliminates the internal motivation to perform well, even in the absence of a measurable reward. For example, I'll always go above and beyond when doing something together with a close friend of mine, but I give zero fucks about my big corporation.
Relatedly, I think many people overestimate how hard it is to compete with the big players. People think that because they earn billions, they are unbeatable. But this is untrue! Scrappy, creative people who just go for it can often beat the big players. As a recent example, look at Cursor AI. Microsoft was in the PERFECT place to come up with Cursor. Microsoft had the most AI knowledge via their own teams and via OpenAI. They have enormous data centers for AI compute. They had the most used code editor (Visual Studio Code). And still Cursor came in and made a better product!
Jeff Bezos said "your margin is my opportunity". I think we can say the same for bureaucracies. Whenever there is a bureaucracy, think "your bureaucracy is my opportunity."
Theory of the firm states that the corporation will get as large as coordination costs allow, but the other way to view that is that large corporations need to compensate for their increased coordination costs in some way.
Empirically, they can often do that successfully, as evidenced by the fact that large cloud providers are, indeed, large.
But you correctly point out that over time this almost guarantees opportunities for firms with lower coordination costs.
> And still Cursor came in and made a better product!
On a long enough timeline Microsoft wins this battle. I don't think you appreciate the inertia of market dominance and a massive existing user base. They can simply copy features and push them to millions of developers overnight. More likely, Cursor either gets acquired or becomes a niche alternative while VSCode maintains its dominance.
Competing with established players when you have zero moat is always tough and I don't think Cursor are even close to winning their category yet. Bureaucracies exist in large companies precisely because they've grown successful enough to need them. While they do create inefficiencies, they also enable consistent execution at massive scale - something startups often underestimate until they try to grow beyond their initial niche. It may be slow, but they win by outlasting, outspending or buying you.
However if you simply mean that Cursor can carve a niche quick enough to become an attractive acquisition target then I might concede that fact.
> On a long enough timeline Microsoft wins this battle. I don't think you appreciate the inertia of market dominance and a massive existing user base.
So Cursor shouldn't even have tried? It is pointless what they have achieved? That's what you're saying?
I disagree. Having people who know about your product and have a positive experience with your product can be very sticky. Coca Cola is a famous example. Also look at AWS. Microsoft has many of the benefits you said. Microsoft has scale, many existing relationships with customers, own much of the related software, and many more benefits. Still, AWS has a 31% market share while Azure has only a 20% market share. The gap becomes more narrow each year, but it's still not closed. There is definitely a huge benefit to grabbing market share by having a superior product. Even while you only temporarily have that.
You also talk about the economies of scale, but that was my point. Even while Microsoft had all the economies of scale, still Cursor came in and took a large part of the market!
This basically describes Slack vs Teams as a case study. Teams launches, Slack says "good luck with that," MS basically gives Teams away for free and gains market share, then SAP acquires Slack.
I don't even use copilot (yet) because the process of reviewing it through all the different obstacles (security, legal, budget) is on it's 24th month or something. I think many people in traditional industry can relate.
It seems like it ought to be reasonably restrictive to install some new AI tool on dev machines.
* they don’t know who’s behind it, what’ll it output?
* they don’t know the business model. Is will it be used to exfiltrate code from the company, aka train on the company’s codebase? Other text files you open?
I’m not at all saying I think Cursor is doing that—training on customer data would be a completely unethical business practice, bordering on malware, usually companies whose names get bounced around here are not so bad. But, the hypothetical host company doesn’t know anything about them, so it is prudent to require some checking.
Is Cursor really better? I tried it briefly but bounced off. I’m convinced that AI-assisted search and replace would be quite nice sometimes, but not enough to switch.
Then again, I don’t use most features in Cody, either. Basic AI code completion seems good enough for me and the fancier shortcuts don’t stick.
I have mixed experiences with the "chat" portion of Cursor AI. The "composer" has been much, much better, albeit on greenfield projects. I haven't explored it too much with existing monoliths, but I suspect it might not fair as well.
I'm currently using it to build an iOS mobile game, using Swift. I've never coded in Swift, or used SpriteKit, but it's going surprising well. When it does produce invalid code, I just copy the error directly out of xCode into Cursor Composer and 9 times out of 10, it fixes the issue first try.
I've used it on different languages, but the rust it produces, even if it runs, is often full of bad decisions. Choosing improper data structures, cloning everything, etc. Curious what the quality is on the scale of "running swift" to "good swift".
I don't think so. The amount of features something like Google cloud has + experience is not cheap to just build.
Plenty of companies try in Germany the schwarz group aka Lidl and the German Telekom too.
Also normal companies are not fast. It takes time for them to learn about something new, understanding it and then implementing it before they finally can us it.
If Ms tells you they will do it in 1-2 years everyone is fine with that. And GitHub announced GitHub spark. Google has this already.
I work in a large law firm and see similar outcomes, coming from a similar fast paced background.
I’ve drawn a different conclusion as to “why” though. Law firms are inherently risk averse. As such things do take time to dot the i’s, and that is more important than the time or financials.
I look at it through the project management lens of the three constraints: Quality, Time and Cost.
The law firm (and potentially your cloud provider) has prioritised Quality. Either Time or Cost take a hit.
High quality + quick = costly.
High quality + low cost = a long time.
I once had my boss at a new job sit me down, a couple of weeks into the job, and tell me "Matt, we have a pace that we work at, and we need you to work at that pace... If leadership gets the idea that we can deliver at a much faster pace, they'll expect it from us all the time." By the time I quit that job, I was able to finish my whole week's work before lunch on Monday. Then I'd just spend the rest of the time working on exploratory projects to stay sharp. So I've seen the utterly pathological version of Parkinson's law. However...
Shipping the wrong thing fast is just shipping the wrong thing, and it's a natural impact of trying to squeeze blood from a stone.
I often give something along the lines of this lecture:
You're trying to solve a $5M problem for $1M, so you're going to push people to make poor choices that don't actually address your problem, and it's going to end up costing $10M after they back up the train and re-lay the tracks. In many cases, the "shortcuts" that teams jump to end up being "longcuts" that drag the program out due to being insufficient to address all of the feature requirements, unplanned due to rushing, etc.
> Matt, we have a pace that we work at, and we need you to work at that pace... If leadership gets the idea that we can deliver at a much faster pace, they'll expect it from us all the time.
Work/life balance is a part of the compensation package. If you suddenly start expecting your employees to work harder, the most talented ones will simply jump ship, because from their perspective, if they're already forced to spend long hours on complex projects, why not at least do it for lots of money. So the only people who stay will be hard-working ones, but less skilled. Meanwhile, in a healthy company, you need a mix of people willing to do demanding, yet simple work, and those who rescue a dumpster fire of a project and then take five coffee breaks.
On the other hand, if you expect your employees to produce every week only what they can do in an afternoon and no more, many of the most talented ones will also jump ship, because they are motivated by accomplishing high-quality work.
It may have less to do with talent than motivation. Motivations people can have at work (and many can and do have a combination in different proportions) can include: making as much money as possible; doing as little work as possible; producing as high-quality work (in their own opinion) as possible; recognition from others for contribution; social relationships and/or being liked; learning new things and developing new skills; being challenged; not being challenged; being part of a collaborative team working well together or being left alone to work independently; etc.
But I think few "most talented" people would last very long at workplace GP described, where doing more than a half-day's worth of work in a week was restrained.
This. Motivation is the key to getting employees to produce over a period of time. Give the good ones the maximum amount of ownership they can handle and they will set an example for everyone else. Grow the talent over time.
Fire the whinny shit-talkers as soon as possible. They drag everyone down.
Intrinsic motivation can be better than extrinsic motivation. Google won a lot of fans and dedicated employees with its original version of 20% time that encouraged people to find stuff they were highly motivated to want to work on and could do so relatively safely in the company's sandbox. It is possible this sort "everything the company needs you to do can be done in one afternoon each week" could be an incredible "80% time" company. There are lots of people that would find "80% of my time at the company is my own" to be quite motivating.
Of course, certainly not in the example scenario above where one layer of management is effectively lying to another layer. That's not a healthy "80% time" when it involves duplicity and covert play acting.
But if you were feeling crazy enough to try to build an overt "80% time" company you likely wouldn't have a hard time finding some of the "most talented" people.
That's certainly how Xerox PARC is described in some of the tales of their classic discoveries/inventions/Demos.
Certain decades of Bell Labs, too, have that glimmer of a bunch of the smartest people allowed to explore stuff they cared about with only the oversight from fellow technical people.
I've even heard Microsoft Research can still sometimes feel a bit like that, though with all the pressures of academia like grant finding and patent applications and other such hustles.
> if you expect your employees to produce every week only what they can do in an afternoon and no more
... then they will have time to fix problems that arrive randomly, rework the parts of their work they got wrong on the first try, and study and train to stay sharp to do the next piece of work. Ironically, all of those will make them produce their next piece of work faster, making this one "problem" worse and worse.
But I left the real benefit to the end... those people will have enough time to think about how they can work into improving something on their workplace. You know, the people that actually do the work, how they can apply the work they know about, because they do it, instead of people that know nothing about it being specialized in thinking how to apply other people's work.
The GP saw a good manager trying to keep his people safe from a dysfunctional organization. The dysfunctional organization is a read flag, for sure, but it doesn't automatically mean the environment is a bad one.
Good software shops leave a good amount of "slack" time for their engineers. It's how you handle shit hitting the fan without burnout.
I currently work on a team that has been basically solving multiple crises per year for years now. In the blips where we've returned to normalcy, we didn't push hard. Because we knew that was time to recover because another crisis was definitely coming.
The crises were external / due to leadership being aggressive without our input..so at that point, all you can do is execute. And part of executing is resting.
Basically stating the fact that people fail to see the value in reinvestment of time and resources for improvement. Being Idle is not a failure but a way to think and be ready if a period of higher intensity comes. And it is healthy to have sometimes more time for a menial task.
People get so crazy about the idea of optimization, but fail to account for severe issues that arise when time is always occupied by something, which seems to happen more and more these days...
No, it’s because Kirk respected Scotty and gave him leeway.
Picard is the meathead, if anyone, and actually watching all the episodes in detail and figuring out their characters you’ll realise that Kirk is twice the scholar and then some Picard pretended to be, especially accounting for the movies and later series. Kelvin timeline doesn’t count, of course.
Sandbagging is a superpower within reason under many circumstances. Most people would much prefer to get a quality promised deliverable on time or a bit early even if it's a bit longer than they would have preferred in an ideal world. (And, if they really do want to pull something in, you sigh and say you'll do your best but no promises.) If something really has a hard aggressive deadline, OK maybe.
But usually it's a case of it will probably take me this long to do a task. But there are some unknowables and someone I might have to lean on could have a sick kid for a couple days. Generally, everyone is happier if you underpromise and overdeliver including you.
An engineering manager I used to work with would drive me crazy because he had this idea of 90% schedules he got from somewhere. Which basically meant there was a 90% chance of meeting the schedule if nothing went wrong. (Which naturally mostly never happened.)
Sandbagging can also lead to nothing ever being worth doing.
Of course, it is shocking how many projects are started without anyone knowing anything other than the end date.
In my view, if the project is of such marginal value that a precise estimate is needed, don't even start the project - instead, find something more valuable to work on.
Maybe that's true of major projects, especially when there are maybe unknown unknowns. (And maybe not.) But there are a ton of deliverables that should be fairly predictable that come with people who have downstream dependencies on them. (Promotion, launch plans, etc.) When something is late it can cause a lot of scrambling and wasted time/money.
[And just to add, I'm mostly speaking to work I'm creating and delivering--for the most part individually. And to the degree that I'm depending on client reviews, etc. that's in the contract.]
The 90% schedule is not a bad idea, but you need to look at it via metrics - what percentage are you actually meeting that schedule? If you are not doing so 9 out of 10 times, you are at a 20% schedule or a 10% schedule.
I would say that it's practically a worse situation. They aren't just ignorant, but willfully so because of a lack of measurable consequences for most. Even worse when there is market capture.
I think people in this thread are imagining two different scenarios: a high-pressure environment with deadlines that are consistently 50% shorter than what’s actually needed throughout the year, leading to burnout... versus setting a desired completion date for your tasks as a personal challenge to keep things moving and avoid analysis paralysis. It’s more like a rally driver setting a target to stay focused and push forward.
No. You can only reduce a timeline to the point where it cant be effectively reached. A timeline that is guaranteed to be missed is no longer a timeline. It's an arbitrary point in time with no real meaning in relation to the work at hand.
I get the point you're trying to make, but in the fictitious scenario you're making, if everything, I mean absolutely everything, is done in 4 days and you're just spending the 5th doing nothing, this isn't Parkinson's law at play, this is just inefficiency.
The idea that something that could be done in 5 could also be done in 4 is less about 'wasting time', but about 'aggressive prioritisation' (which may or may not involve corner cutting).
And even in the case where there is no corner cutting, I think it's a mistake to think that the work going into prioritisation has no cost or overhead, or that this is scalable for months to come.
At a personal level, I find that if I push myself to finish something "more efficiently" because of a deadline (most of which are typically arbitrary rather than organic), this has a backlash effect on my ability to do things efficiently in the projects after. I would imagine a similar risk exists at the organizational level.
> but in the fictitious scenario you're making, if everything, I mean absolutely everything, is done in 4 days and you're just spending the 5th doing nothing, this isn't Parkinson's law at play, this is just inefficiency.
"Absolutely everything" can never be done, because you have things like unknown unknowns. Things that reveal themselves further on in the project and are almost impossible to anticipate.
Alternatively, things like "improving documentation" can also be done nearly in perpetuity. There are always more use cases, caveats and scenarios to describe or examples or onboarding materials to refine for future newcomers.
These are the less-critical things that should be done on a Friday at the pace of the person who is performing them.
I think actually it's not about faster, it's about more efficient. Looking at the rate of improvement here of recent decades, we should've had a 4 day work week long ago. It should even have allowed more people to not work at all and help to make their local community e.g. more human.
Instead the wealth accumulates in places unreachable for 99% of us.
Got to be worth a try. At some point you'd probably find there was a minimum amount of time to actually do the work in (that is, Parkinson's law would break down), but it's certainly past 3 days.
Once I had a paid game project from a third party (who was a friend of my friend) who actually had the client. Either they gave me a 2-month deadline or I gave them one to complete the project, I don't remember it correctly.
I knew I could deliver it in 2 weeks or less, so I got busy doing other projects.
Long story short, client ran away because I didn't communicate with the third party the whole time through my friend (who I kept it in the dark) and delivered the first playable version not according to the exact requirements (how could I because it was not the final version).
I never heard/read about Parkinson's law at that time, I now understand I was just filling my available time with other stuff.
That's why you should probably never expect "perfect" from the finished product but rather a "iteration x" instead.
The articles adresses scope creep. You were asked for a drawing, but ended up with a cartoon "because they process just took me down that road". The deadline is helpful is limiting what the first/second/x'th iteration can be expected to do.
> "A canonical example of this is sending round a survey that can be filled in whenever versus one that needs to be filled in by tomorrow:"
in my experience, setting a short deadline just means a handful of people will reply, the interviewer will extend the deadline and now in the future everybody knows the deadline will be extended anyway, so they don't bother taking your false emergency very seriously.
> Sure, it may take some on the team a half hour to do some work, but for others, it will take two weeks.
That seems like an egregious difference, and I don’t think should be mentioned in such an off hand manner. Why doesn’t your team train people?
FYI, training doesn’t need to be hands-on, I think it’s often better to give employees education/training budgets. Technical team leads should be able to identify someone’s gaps, and make recommendations.
Or maybe it’s better to let someone go instead of wasting their time in a no-growth environment.
It's not a matter of training, it's a matter of lack of rewards and mismatched incentives. The reward for good work is generally more work and a "token" raise at best that is never proportional with the value you added.
The market has converged on a baseline of what is typically expected out of a given role. Now sure, we can argue (and I personally agree) that said baseline has become absolutely terrible, but we shouldn't blame the people for that.
If your objective is to be an employee and engineering is purely a means to an end (to earn a salary as said employee), then delivering the baseline and getting the baseline salary is all you need to do. Any effort beyond that is a waste of time that can rather be spent on hobbies/family/etc because it will not be adequately rewarded.
It only makes sense to go beyond the baseline if you want to learn and have a plausible way to monetize that extra experience (outside of this current job). If you want to build your own product, do consulting, etc.
The solution is to let developers lead the conversation about estimates instead of management pulling deadlines out of thin air.
If the developers can't agree on an estimate it typically means that the requirements are unclear or misunderstood, or some of the developers are better equipped for the work.
I had a somewhat repugnant second-level boss whose philosophy was to give people a little more work than they thought they could do to get the best performance out of them, and I believe he was right since, at least for me, I worked harder to make the earlier deadline and/or did more than I thought I could. He must have known Parkinson's.
That only went so far, since piling yet more work onto someone who made an earlier deadline may get them to the point where they don't perform.
Which is why I appreciated a not-for-profit company where they'd actually ask me if I needed more time, since quality was of utmost importance. At that point at that company I knew the codebase, so I'd consistently over-estimate and deliver early, since there was still a chance of hidden impacts/requirements.
I saw a great one slide corollary to this from a government program manager meeting once - basically, shorter time to first prototype drastically decreases overall program cost.
I think a lot of this has to do with giving the customer less time in which to change their mind.
Tangentially related to op - but, an interesting tangent nonetheless.
Most university students who have to finish assignments know that deadlines are indeed a blessing. Motivating yourself without a deadline is a rare gift that most of us do not possess.
Different people are motivated by different things. Some people are motivated by pressure. Some people are motivated by rewards. Some people are motivated by solving problems. The trouble is, if you blanket apply a strategy that some people find motivating, you risk under-motivating and even demotivating people who are motivated by different things.
Personally I am motivated by solving problems, which strongly implies shipping working solutions. I find artificial deadlines, theatrical recognition ceremonies or financial rewards that amount to a rounding error on my compensation to be demotivating. Everybody is different.
but those are orthogonal. and yes, everyone is different. i am also motivated by solving problems. but i also believe in the premise of the article that deadlines can help push me forward. personally i like deadlines to be set according to the value of the project, which can be its budget or some other externally motivated limitation.
I think this article misses the mark about deadlines.
The main problem with deadlines isn't that they're "poorly applied". It's that typically they reflect other people's priorities, which don't align with yours.
If the deadlines completely match your most efficient prioritisation scheme, then they will work, but you don't need the deadlines in the first place (unless you're lazy, but this is not what we're talking about; when we talk about Parkinson's law and inefficiencies we assume good-will from the outset). As soon as you introduce a deadline, you're basically introducing a change in the distribution of your work, which may lessen one particular item of work, but overall increases the Shannon entropy of your work distribution.
Consider the following. You have guests arriving in 1 hour. You need to clean (45 minutes) and cook (15 minutes preparation time, and 45 minutes roasting in the oven). If left to your own devices, you'll start with food preparation, and then use the baking time to clean. Bang, you've made the deadline.
The problem comes when your wife demands the house be cleaned first. Congrats. You've just made your guests wait 45 minutes for food.
Most externally imposed deadlines have the same effect. They ensure the 'cleaning' is done way faster, and completely disregard the spillover this causes. Typically because they may not even care about the other tasks in the first place; except in the sense that they care about the next deadline they set to you getting missed because you were dealing with previous spillover (which they don't care about).
Paradoxically, this makes people set stricter and stricter deadlines, in order to get people to work "faster". Which of course only causes more spillover and makes things grind to a halt instead.
By definition most people are unable to grasp the true priorities of everyone else sitting around the table after adjusting for all confounding variables such as the correct time order.
Edit: And certainly not within say a half hour meeting once per week.
Because they’re all roughly equivalently intelligent.
i.e. In say a committe of ten, it’s very atypical for there to be 1 literal genius, as the committee chairman, and 9 unsophisticated and easily predictable members around the table.
Such that the chairman can correctly predict this or that, for any of the 9 other members…
176 comments
[ 2.9 ms ] story [ 276 ms ] threadMaybe it comes down to how you model the minds of those around you, but I notice a pattern in articles like this, that the solution seems to be presented as universal. In my experience, deadlines, especially self-imposed ones, are very effective for some (say 40%) of people, but they're not a panacea.
Wouldn't it be nice if there was some more general theory that explained Parkinson's law, and suggested various solutions that will work for various people?
> I love deadlines. I love the whooshing noise they make as they go by. - Douglas Adams
Of course I have strategies to manage this, and medication helps somewhat. But if I set a deadline for myself I’m never going to keep it.
My girlfriend has ADHD and she mostly only can get things done when there are deadlines outside of her control (e.g. cleaning up when we have visitors). When she wants to do something just for her it can take ages, if it gets done at all.
I would like to help her with this but I don't really know where to start.
I am an inattentive type who skated thru behavioral checks by being the quiet kid who never causes problems. What this really means is I am doing ranked competitive daydreaming and sometimes need to be reminded to exist.
I'd also be grateful if you could share some of your strategies.
In some cases, time pressure can focus me and get me to a solution faster, but I then need downtime to recharge. I don't think I've worked in that sort of environment since working in food service or at a movie theater.
Deadlines often just stress me because I can't effectively reason about the intervening time.
The first help me not get bogged down in details and prevent endless polishing, the second are demotivating and unnecessarily stressful.
1. Work is awful and people hate doing the work they get assigned
2. Therefore, people will try their best to do as little of it as possible
3. Thus, if there's no deadline, or the deadline is very lenient, then people will mess around to fill the time -> Parkinson's Law!
Turns out that if you stop the military carrot & stick model of work, and instead try to actually be a place where people want to do great work, then this dynamic changes completely. We do it like this:
1. Make sure every employee does some amount of customer support. This makes everybody feel that real people are facing real problems that need real solutions, fast.
2. Give people a lot of freedom in what they work on, in what order, so long as it fits broad company objectives. If a customer reports a bug and it "nerd snipes" you completely, go for it!
3. Teach people scoping and iterative delivery. Stuff like "ship it when it's better than what's live now" (vs "ship it when it's perfect"). Many engineers like to polish things forever until it's perfect (this is the less cynical interpretation of Parkinson's law) but you can just coach people in this, takes a few months max.
I can honestly say that our dev team is the most productive team I've ever been a part of, and we do this without deadlines, without yelling managers who turn your estimations into promises, without overtime, and anything else like that. Parkinson's Law doesn't need to hold. It's a consequence of a shitty low-trust working culture.
Admittedly I've no idea whether our approach scales to larger companies - we're 15 people. Also we hire explicitly for people who are able to handle this kind of freedom. But it works excellently for us.
>>> "ship it when it's better than what's live now" Is a fantastic rule - as it is almost always measurable (even things like engineering quality can be measured (a little)) and so justifiable.
Also your last line (Deadlines are poverty) suggests that it’s a term you use a lot in your company - want to expand?
Nah, I just invented it to make the comment feel more edgy. Your question made me realize that that's the only reason it was in there, so I edited it out. I mean I do believe that deadlines are poverty but the comment is sufficiently controversial without it.
Basically, I think the idea of hiring highly intelligent and creative people, and then forcing them to work on assigned tasks on sticky notes given to them by "product managers", is an extremely brutal destruction of capital. Sucking the joy out of creative engineers seems like a very costly idea to me, and I'm not convinced that the project management benefits of doing so exceed that cost. Just see how fast and well and enthusiastic people can code when doing eg open source projects, or hackathons, or entire browsers (Ladybird), and so on. I think as a leader you should want to channel that joy and enthusiasm for your company's (and your people's) benefit. If you give people a lot of trust and freedom, and build a culture of eagerness to ship, you can get that. Deadlines then are an extreme buzzkill and I firmly believe it makes people less productive in the long term, particularly because they'll just do worse work and that compounds quickly.
Hell yes.
This chimes with my own experience and attempts to build sane work environments wherever I can.
I think software has a very unusual relationship to the “explore exploit” concept - in that most manual / labour intensive businesses probably work ok with 20% explore - but with software once the explore is done the exploit is a marginal cost - so one should tune software business to be very high explore ratios (lean processes etc).
In other words hire great people and let them experiment.
My general schtick is that software is a form of literacy - and if you hire an illiterate person to for example write your autobiography, the process they would have to come up with would look not dissimilar to most Agile projects.
Or perhaps another way of looking at it - Linus Torvalds accepts patches that have made their way through several layers of “lieutenants” - why shouldn’t the CEO of corporate X be the owner of the codebase that runs the corporation ?
In the end all the discussion should be about the code - if it is not about the code you are discussing the wrong thing.
Anyway - completely agree with your points and your … passion? It’s in the right direction and good luck to your business :-)
> In the end all the discussion should be about the code - if it is not about the code you are discussing the wrong thing.
The code is important, but in the end it's all about the customer. For us, if it's not about the customer (in the end), you're discussing the wrong thing. This is a key part of our "ship fast and incrementally" ethos - how can you tell whether something is better than what's in production now? By explaining how it impacts the customer.
I think the problem in my situation (above) was that we were disconnected from what was important. You solve this by ensuring everyone is directly connected with the customers. It sounds nice and I hope it continues to work for you and your company.
(It's a shame that this post has net-downvotes currently.)
Many product categories are not well matched to the rapid iterative development style you are describing for your server side chat system, due to the significant costs involved in updating products that are already deployed.
As another poster said, this just doesn't scale. You eventually hire someone who doesn't care as much, or just sees it as a job, or has worse judgement.
Being able to run this way is almost a paradise, and it's a lot of why startups can out compete big players.
Sounds good but seems prone to debate over what "better" means.
I don't think these need to be reconciled though as they are about different things: one is about imposing psychological threats to induce action and the other is about the inherent incapacity for humans to reason temporally concerning complex tasks.
One problem that arises though is that when tasks can't be sufficiently estimated, how do you reliably impose said psychological threats which don't turn into casual "oops, software's hard and is hard to estimate, hopefully better luck next time."
Its a mental trick to get them to focus on outcomes instead of the journey. Far better to let them mutter darkly about perceived 'technical debt' that is incurred delivering business value than to actually let them try and do things their way :D
This doesn't absolve management of picking the right problems to solve etc, nor absolve engineers of solving those problems in a competent manner.
But what it does is make good engineers work on the right thing, because lots of engineers have a tendency to not see the business wood for the trees and go off solving the wrong problems if self-organising.
Of course it is not nice to be an engineer and see how, as a generalisation, we can all be manipulated like this :)
Aye.
Some day I will write a detailed account of the worst code I've ever worked with. 1000 lines of spaghetti inside a single if-block; 20,000 blank comments; a whole pantheon of god classes; etc.
And yet, it was a very successful *product*. Much more so than the carefully engineered and architected codebase in an ISO 9001 (or was it 9000?) employer.
"""It was the best of code, it was the worst of code; it was the age of delivery, it was the age of technical debt; it was the epoch of rapid prototyping, it was the epoch of unmaintainable legacy; it was the season of boundless innovation, it was the season of endless refactoring; it was the spring of shipping features, it was the winter of debugging nightmares.""" etc.
So it's important to get the balance right.
Besides if the project succeeds for years then joy might have made the right choice cutting corners.
If you add daily deadlines to the daily meetings and hang daily motivational posters on the walls you risk blunting any and all responses to the daily managerial background noise.
I need to get this stuff done until tomorrow and then it will lie on your desk for 2 weeks?
No thanks.
When I started, I was really bothered by the fact that everything took so long. I had joined from a startup where there was time/financial pressure. Everything needed to be done now, and there was incentive to get it done.
The cloud provider was the complete opposite. Everything was slow. Things that should take a day took a week, things that took a week took a month. I rationalized it that there were more checks in place, more i's to dot, more t's to cross.
But in hindsight, it was the domino effect of Parkinson's law in play. The cloud provider had enough money to keep paying everyone in perpetuity; that removes financial constraints. Time constraints could be explained away. So things just got done whenever they got done. The knock on effect of this is that when you depended on other teams, they got around to their external responsibilities whenever, that then slows you if you depended on them.
The larger organization accounts for this by expanding timelines (because what else are directors/vp's/etc to do... they're powerless to actually implement), which are then just filed with more waste.
The tempting efficiency of infant capitalism was its decentralized and small scale structure. You can’t govern a country top-down, and letting the people at the bottom do their own work is most efficient.
But now some companies are larger than most countries and we are back to where we started… but without transparency and democratic regulations.
I think we need better ways to deal with large systems and complexity.
Sadly culture in the US is diluted into believing that profit motive is a silver bullet that fixes all problems. And many are raised in religions that teach one to deny critical thinking, embrace appeals to authority, and love confirmation bias.
Ergo, the idea that the market handles their duties more efficiently is a lie. It has nothing to do with corporate vs state owned enterprise, but a matter of complexity.
There's the Chinese saying "Heaven is high, and the emperor is far away". The idea being that low level bureaucrats are actually the ones running the show. Effectively, that's where China and the CCP sit today.
However, that has similar issues to the ones I described above. Top down mandates, the low level feigns to appease them, but marginal progress is actually made. Instead of expanding the timelines as I spoke about, in the CCP(/Soviet) case, the actual accomplishments are made up to keep "going forward". Think of all the ineffective building done to meet bullshit quotas in the China currently. It harkens back to the Soviet era.
This is identical to the idea of small scale teams working on systems they completely understand and own. This is where you have the most productive teams and it is the same in terms of bureaucracy. And the job of an architect is not to create "a beautiful system", but to lower the complexity of the overall system.
I think the topic of complexity and large systems is one of the defining ones of our time. Similar to entropy, you start with a low-state system where you can generate energy from putting entropy into the system. But with a higher state of entropy, your energy gains decrease.
We act like you can just pure more and more onto the same pile, but eventually, everything stagnates. And only collapse can create a blank slate.
It seems like the real problem is finding a way to address that.
We've seen this play out over and over. Take something like building and zoning codes. They start out doing something worthwhile, like requiring fire exits. But soon you have a bureaucracy micromanaging everything, imposing minimum parking requirements even on a building sitting on top of a subway stop, imposing minimum lot sizes or density restrictions, requiring unnecessarily costly or labor-intensive construction methods at the behest of device makers or trade unions, etc.
What you need is a mechanism, something like checks and balances or a challenge process that allows any rule to be repealed if it doesn't still have enough votes to pass in every branch, to inhibit that process of ossification and corruption and clear out the cruft accumulated by its past operation.
The issue is that it's not perfect, and it's never going to be perfect, so you're occasionally going to have things get past the gauntlet and make it into law when they shouldn't. And over time those things accumulate.
So what you need is a functioning process for clearing out the cruft even once it's already there. Something like, make it much easier to repeal rules than enact them.
I agree in the sense that some way of "caretaking" is absolutely necessary. Like in a badly maintained IT-system, many managers think you can just keep piling stuff ontop of the old system and you can just happily going forward forever. But of course that is a terrible misunderstanding.
In an IT-system, you either restart from scratch or start a refactor. I think these are the only options here either. This needs talent and money, something the public services have been massively drained of. You can't make a system more lean and efficient by cutting costs, you mot make investments. If you involve Civil Servants, they will tell you exactly what kind of issues they are facing each day processing official documents.
Ideally, you'd start a digital transformation of public services and also streamline the legal cruft at the same time. But the problem is that much of this "cruft" is there on purpose because somebody profits. Such as the impossible Zoning Rules in California to prohibit any additional housing space... because that would make housing more affordable and lower their prices.
Jeff Bezos said "your margin is my opportunity". I think we can say the same for bureaucracies. Whenever there is a bureaucracy, think "your bureaucracy is my opportunity."
Empirically, they can often do that successfully, as evidenced by the fact that large cloud providers are, indeed, large.
But you correctly point out that over time this almost guarantees opportunities for firms with lower coordination costs.
On a long enough timeline Microsoft wins this battle. I don't think you appreciate the inertia of market dominance and a massive existing user base. They can simply copy features and push them to millions of developers overnight. More likely, Cursor either gets acquired or becomes a niche alternative while VSCode maintains its dominance.
Competing with established players when you have zero moat is always tough and I don't think Cursor are even close to winning their category yet. Bureaucracies exist in large companies precisely because they've grown successful enough to need them. While they do create inefficiencies, they also enable consistent execution at massive scale - something startups often underestimate until they try to grow beyond their initial niche. It may be slow, but they win by outlasting, outspending or buying you.
However if you simply mean that Cursor can carve a niche quick enough to become an attractive acquisition target then I might concede that fact.
So Cursor shouldn't even have tried? It is pointless what they have achieved? That's what you're saying?
I disagree. Having people who know about your product and have a positive experience with your product can be very sticky. Coca Cola is a famous example. Also look at AWS. Microsoft has many of the benefits you said. Microsoft has scale, many existing relationships with customers, own much of the related software, and many more benefits. Still, AWS has a 31% market share while Azure has only a 20% market share. The gap becomes more narrow each year, but it's still not closed. There is definitely a huge benefit to grabbing market share by having a superior product. Even while you only temporarily have that.
You also talk about the economies of scale, but that was my point. Even while Microsoft had all the economies of scale, still Cursor came in and took a large part of the market!
Doesn’t change your point, but small correction: Salesforce acquired Slack, not SAP.
Sometimes it causes issues, 99% of the time it's fine.
* they don’t know who’s behind it, what’ll it output?
* they don’t know the business model. Is will it be used to exfiltrate code from the company, aka train on the company’s codebase? Other text files you open?
I’m not at all saying I think Cursor is doing that—training on customer data would be a completely unethical business practice, bordering on malware, usually companies whose names get bounced around here are not so bad. But, the hypothetical host company doesn’t know anything about them, so it is prudent to require some checking.
Then again, I don’t use most features in Cody, either. Basic AI code completion seems good enough for me and the fancier shortcuts don’t stick.
The code somtimes runs, which is a large improvement over recent years, but generally doesn't do what it's supposed to do.
And this is using claude 3.5, which works dramatically better for me in a chat session where i give it exactly what i want it to look at.
I just haven't found a way to be productive with it yet.
I've even tried the usual tricks of forcing it to write comments about what it's attempting to do throughout the code, but even then, fails.
I'm currently using it to build an iOS mobile game, using Swift. I've never coded in Swift, or used SpriteKit, but it's going surprising well. When it does produce invalid code, I just copy the error directly out of xCode into Cursor Composer and 9 times out of 10, it fixes the issue first try.
Plenty of companies try in Germany the schwarz group aka Lidl and the German Telekom too.
Also normal companies are not fast. It takes time for them to learn about something new, understanding it and then implementing it before they finally can us it.
If Ms tells you they will do it in 1-2 years everyone is fine with that. And GitHub announced GitHub spark. Google has this already.
I’ve drawn a different conclusion as to “why” though. Law firms are inherently risk averse. As such things do take time to dot the i’s, and that is more important than the time or financials.
I look at it through the project management lens of the three constraints: Quality, Time and Cost.
The law firm (and potentially your cloud provider) has prioritised Quality. Either Time or Cost take a hit.
High quality + quick = costly. High quality + low cost = a long time.
Shipping the wrong thing fast is just shipping the wrong thing, and it's a natural impact of trying to squeeze blood from a stone.
I often give something along the lines of this lecture:
You're trying to solve a $5M problem for $1M, so you're going to push people to make poor choices that don't actually address your problem, and it's going to end up costing $10M after they back up the train and re-lay the tracks. In many cases, the "shortcuts" that teams jump to end up being "longcuts" that drag the program out due to being insufficient to address all of the feature requirements, unplanned due to rushing, etc.
Work/life balance is a part of the compensation package. If you suddenly start expecting your employees to work harder, the most talented ones will simply jump ship, because from their perspective, if they're already forced to spend long hours on complex projects, why not at least do it for lots of money. So the only people who stay will be hard-working ones, but less skilled. Meanwhile, in a healthy company, you need a mix of people willing to do demanding, yet simple work, and those who rescue a dumpster fire of a project and then take five coffee breaks.
It may have less to do with talent than motivation. Motivations people can have at work (and many can and do have a combination in different proportions) can include: making as much money as possible; doing as little work as possible; producing as high-quality work (in their own opinion) as possible; recognition from others for contribution; social relationships and/or being liked; learning new things and developing new skills; being challenged; not being challenged; being part of a collaborative team working well together or being left alone to work independently; etc.
But I think few "most talented" people would last very long at workplace GP described, where doing more than a half-day's worth of work in a week was restrained.
Fire the whinny shit-talkers as soon as possible. They drag everyone down.
Of course, certainly not in the example scenario above where one layer of management is effectively lying to another layer. That's not a healthy "80% time" when it involves duplicity and covert play acting.
But if you were feeling crazy enough to try to build an overt "80% time" company you likely wouldn't have a hard time finding some of the "most talented" people.
Certain decades of Bell Labs, too, have that glimmer of a bunch of the smartest people allowed to explore stuff they cared about with only the oversight from fellow technical people.
I've even heard Microsoft Research can still sometimes feel a bit like that, though with all the pressures of academia like grant finding and patent applications and other such hustles.
... then they will have time to fix problems that arrive randomly, rework the parts of their work they got wrong on the first try, and study and train to stay sharp to do the next piece of work. Ironically, all of those will make them produce their next piece of work faster, making this one "problem" worse and worse.
But I left the real benefit to the end... those people will have enough time to think about how they can work into improving something on their workplace. You know, the people that actually do the work, how they can apply the work they know about, because they do it, instead of people that know nothing about it being specialized in thinking how to apply other people's work.
The GP saw a good manager trying to keep his people safe from a dysfunctional organization. The dysfunctional organization is a read flag, for sure, but it doesn't automatically mean the environment is a bad one.
I currently work on a team that has been basically solving multiple crises per year for years now. In the blips where we've returned to normalcy, we didn't push hard. Because we knew that was time to recover because another crisis was definitely coming.
The crises were external / due to leadership being aggressive without our input..so at that point, all you can do is execute. And part of executing is resting.
A corollary of this is the following paper
https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_....
Basically stating the fact that people fail to see the value in reinvestment of time and resources for improvement. Being Idle is not a failure but a way to think and be ready if a period of higher intensity comes. And it is healthy to have sometimes more time for a menial task.
People get so crazy about the idea of optimization, but fail to account for severe issues that arise when time is always occupied by something, which seems to happen more and more these days...
Scotty: How long will it really take?
Geordi La Forge: An hour!
Scotty: Oh, you didn't tell him how long it would 'really' take, did ya?
Geordi La Forge: Well, of course I did.
Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.
I like Kirk was shoot first ask later unlike Picard but Picard was always “oh 1 hour - make it in 30 mins” or “1 hour - make it quick you have 15mins”
Picard is the meathead, if anyone, and actually watching all the episodes in detail and figuring out their characters you’ll realise that Kirk is twice the scholar and then some Picard pretended to be, especially accounting for the movies and later series. Kelvin timeline doesn’t count, of course.
Kirk >>> Picard.
For me it was looking like Kirk did knew he knows he doesn’t know stuff so he was meathead with ability to defer and not control what he doesn’t know.
Picard was more like he knows everything and had to maintain this aura. But was on a different level of sophistication that I value much.
Even though I love Kirk’s gun blazing.
But usually it's a case of it will probably take me this long to do a task. But there are some unknowables and someone I might have to lean on could have a sick kid for a couple days. Generally, everyone is happier if you underpromise and overdeliver including you.
An engineering manager I used to work with would drive me crazy because he had this idea of 90% schedules he got from somewhere. Which basically meant there was a 90% chance of meeting the schedule if nothing went wrong. (Which naturally mostly never happened.)
Of course, it is shocking how many projects are started without anyone knowing anything other than the end date.
In my view, if the project is of such marginal value that a precise estimate is needed, don't even start the project - instead, find something more valuable to work on.
[And just to add, I'm mostly speaking to work I'm creating and delivering--for the most part individually. And to the degree that I'm depending on client reviews, etc. that's in the contract.]
...you push people to only solve the actual problem.
This is a very strange take to enshrine as advice. If you try to solve a 50$ problem for $5k you're out ~$5k and the next project will cost $7k
If they were good, they would work on improving the flow, not pulling random numbers from their hat.
This "deadline" is a forcing function for output.
But do you know what's a better deadline?
The 4 day work week.
It may seem silly - but artificially making the workweek shorter, makes us work faster.
It's Parkinson's Law in action.
The idea that something that could be done in 5 could also be done in 4 is less about 'wasting time', but about 'aggressive prioritisation' (which may or may not involve corner cutting).
And even in the case where there is no corner cutting, I think it's a mistake to think that the work going into prioritisation has no cost or overhead, or that this is scalable for months to come.
At a personal level, I find that if I push myself to finish something "more efficiently" because of a deadline (most of which are typically arbitrary rather than organic), this has a backlash effect on my ability to do things efficiently in the projects after. I would imagine a similar risk exists at the organizational level.
"Absolutely everything" can never be done, because you have things like unknown unknowns. Things that reveal themselves further on in the project and are almost impossible to anticipate.
Alternatively, things like "improving documentation" can also be done nearly in perpetuity. There are always more use cases, caveats and scenarios to describe or examples or onboarding materials to refine for future newcomers.
These are the less-critical things that should be done on a Friday at the pace of the person who is performing them.
> I have infinite capacity for more work, as long as you are happy with the quality of the work approaching zero.
Instead the wealth accumulates in places unreachable for 99% of us.
I knew I could deliver it in 2 weeks or less, so I got busy doing other projects.
Long story short, client ran away because I didn't communicate with the third party the whole time through my friend (who I kept it in the dark) and delivered the first playable version not according to the exact requirements (how could I because it was not the final version).
I never heard/read about Parkinson's law at that time, I now understand I was just filling my available time with other stuff.
The articles adresses scope creep. You were asked for a drawing, but ended up with a cartoon "because they process just took me down that road". The deadline is helpful is limiting what the first/second/x'th iteration can be expected to do.
in my experience, setting a short deadline just means a handful of people will reply, the interviewer will extend the deadline and now in the future everybody knows the deadline will be extended anyway, so they don't bother taking your false emergency very seriously.
Sure, it may take some on the team a half hour to do some work, but for others, it will take two weeks.
You hope that over time everyone improves, but that’s just not what happens in reality with bad eggs.
That seems like an egregious difference, and I don’t think should be mentioned in such an off hand manner. Why doesn’t your team train people?
FYI, training doesn’t need to be hands-on, I think it’s often better to give employees education/training budgets. Technical team leads should be able to identify someone’s gaps, and make recommendations.
Or maybe it’s better to let someone go instead of wasting their time in a no-growth environment.
And firing is politically impossible where I am. If someone chooses not to improve, or simply does not, there are no repercussions.
It's not a matter of training, it's a matter of lack of rewards and mismatched incentives. The reward for good work is generally more work and a "token" raise at best that is never proportional with the value you added.
The market has converged on a baseline of what is typically expected out of a given role. Now sure, we can argue (and I personally agree) that said baseline has become absolutely terrible, but we shouldn't blame the people for that.
If your objective is to be an employee and engineering is purely a means to an end (to earn a salary as said employee), then delivering the baseline and getting the baseline salary is all you need to do. Any effort beyond that is a waste of time that can rather be spent on hobbies/family/etc because it will not be adequately rewarded.
It only makes sense to go beyond the baseline if you want to learn and have a plausible way to monetize that extra experience (outside of this current job). If you want to build your own product, do consulting, etc.
If the developers can't agree on an estimate it typically means that the requirements are unclear or misunderstood, or some of the developers are better equipped for the work.
That only went so far, since piling yet more work onto someone who made an earlier deadline may get them to the point where they don't perform.
Which is why I appreciated a not-for-profit company where they'd actually ask me if I needed more time, since quality was of utmost importance. At that point at that company I knew the codebase, so I'd consistently over-estimate and deliver early, since there was still a chance of hidden impacts/requirements.
I think a lot of this has to do with giving the customer less time in which to change their mind.
Tangentially related to op - but, an interesting tangent nonetheless.
Sure they can skip meals, work crazy hours to meet your arbitrary tight deadlines. But this is a time ticking bomb.
Personally I am motivated by solving problems, which strongly implies shipping working solutions. I find artificial deadlines, theatrical recognition ceremonies or financial rewards that amount to a rounding error on my compensation to be demotivating. Everybody is different.
The main problem with deadlines isn't that they're "poorly applied". It's that typically they reflect other people's priorities, which don't align with yours.
If the deadlines completely match your most efficient prioritisation scheme, then they will work, but you don't need the deadlines in the first place (unless you're lazy, but this is not what we're talking about; when we talk about Parkinson's law and inefficiencies we assume good-will from the outset). As soon as you introduce a deadline, you're basically introducing a change in the distribution of your work, which may lessen one particular item of work, but overall increases the Shannon entropy of your work distribution.
Consider the following. You have guests arriving in 1 hour. You need to clean (45 minutes) and cook (15 minutes preparation time, and 45 minutes roasting in the oven). If left to your own devices, you'll start with food preparation, and then use the baking time to clean. Bang, you've made the deadline.
The problem comes when your wife demands the house be cleaned first. Congrats. You've just made your guests wait 45 minutes for food.
Most externally imposed deadlines have the same effect. They ensure the 'cleaning' is done way faster, and completely disregard the spillover this causes. Typically because they may not even care about the other tasks in the first place; except in the sense that they care about the next deadline they set to you getting missed because you were dealing with previous spillover (which they don't care about).
Paradoxically, this makes people set stricter and stricter deadlines, in order to get people to work "faster". Which of course only causes more spillover and makes things grind to a halt instead.
By definition most people are unable to grasp the true priorities of everyone else sitting around the table after adjusting for all confounding variables such as the correct time order.
Edit: And certainly not within say a half hour meeting once per week.
Because they’re all roughly equivalently intelligent.
i.e. In say a committe of ten, it’s very atypical for there to be 1 literal genius, as the committee chairman, and 9 unsophisticated and easily predictable members around the table.
Such that the chairman can correctly predict this or that, for any of the 9 other members…
https://news.ycombinator.com/item?id=30000296
It gives a contrary perspective to this Parkinson's law interpretation, which I think is vastly oversimplified from the intent of the original quote.