You can usually embrace this even in an organization that demands estimates. To me, a line manager's key job is insulating the workers from the business so they can get things done. The key tool at your disposal is scope. I remember watching this talk a long time ago and in the time since it's combined with a few other ideas I've read about death marches. That's when everybody working on the project knows the deadline is literally never going to work, and yet you all keep marching. A simple way to unpack that involves thinking of projects as being a combination of cost, time, scope, and quality. You can only control three. Trying to control all four leads to a death march.
If you just work by starting with a deadline, a lot of it slots into place. A point at which we need to ship/demo/whatever then you can work backwards. Using projection, not estimation, you can spot things are slipping early, often earlier than estimators realize, and you need to either move the deadline or cut scope. Reducing scope is usually easier than you think. Your customer doesn't know all the cool things you wanted to build. They only know what you put in their hands. If you agreed to more, you can talk it out. Focus on what's most important. This happens all the time and it's not the big deal many people make it out to be. Also, for big projects, iterate. Don't just promise the whole thing in a year. Promise a part in a month or two. That's a great way to get feedback early and fix things before they're fully load bearing.
Not only that, just counting tickets really does give you a projection that's fairly accurate. I've used it before when estimates had months and my calculations showed years. Years later, I was right. When estimates can be as much as 200% wrong and projection is usually within 20%, it's insane not to switch.
This works because a ticket represents one unit of work from start to finish. There's a bunch of overhead in starting, testing, shipping, and so on. So each unit tends to scope about the same amount of work. That is, roughly one chunk of work someone wants to finish before doing another thing or the amount of complexity they can manage in one go. It also means it doesn't matter who's scoping as long as they're scoped together. They'll bucket into roughly the same size. What size doesn't matter too much. Just that they're about one unit of work.
This really does work. It's how I manage my team. The entire process can be summed up as make an ordered list of things to do and then do it. Repeat. It really doesn't need to be more complicated. Simultaneously, any process missing one of those components is doomed. The most often missed part is ordered list. If you have a vague sense of priority you'll end up with all sorts of informal channels of power attempting to pick their own winner among the work to be done.
I could drone on but I'm certainly not right about what will work best for your team. There's a lot of things to try, but here I'd suggest mostly, try less. Try cutting things. It's too easy to add and too hard to remove. Do the hard thing and see what happens. You can always add it back if you all worked better before. You'll probably find that more substantive things will start getting done but you feel like less is happening. That's because everyone will be busy doing instead of talking about doing.
Pretty neatly sums it up. The software industry has always had faces, people for whom the entire point of technology is to make the cover of some magazine, arms crossed, looking smug for the camera. To find themselves an interview so they can stroke their ego in public.
Focus on these losers long enough and that'll be all that's left. The stories we tell sculpt the future we see. These days the story is that if you work hard enough, some techbro can buy your work to claim it as their own so they can climb atop their pile of stolen valor like a dragon's hoard. If you refuse, they'll just light a pile of Saudi investment money on fire to undercut you and drive you out of business. Guess who this story really appeals to and attracts to the industry. Guess who it drives away.
Early Woz got me hyped, Aaron drove it home, Ken and Rob gave me a tradition to inherit, and at least a dozen more have done their part too. I consider myself a proud hacker. Not a great one mind you, just proud. Take it apart and put it back together purely for the discovery and fun it brings. Make it do things you shouldn't be able to because the limitations drive creativity.
If you listen to the story though, that's antithetical to the point of technology. I should only care about it in so far as it generates capital. Exponential growth. Unicorn. Sell that baby and become rich beyond your wildest dreams.
I make money to have time to play with the technology, not the other way 'round.
This is a pretty great introduction to group theory from the prospective of a distributed systems programmer. Really useful stuff. It starts by mentioning abelian groups offhandedly in order to poke fun at the impenetrability of the jargon of group theory compared to how easy it is to understand the concepts involved. If you understand idempotency, you already have an intuitive understanding of things like commutativity (which is what items in an abelian group share). If you don't, this talk makes it really easy to understand what properties resilient distributed systems tend to try and design upon and why.
Yeah, I think that elegantly sums it up. We're in so deep on economy as speculation at this point that basically nothing about a company matters beyond attracting investment. It's companies looking to get in on yield farming. It means the economy is mostly a measure of how compelling the collection of FOMO stories seem. This is why you've got runaway. If your FOMO story aligns with a lot of other companies stories, this only further boosts the FOMO.
Cryptocurrencies showed that the economy as an exchange of goods and services was only incidental, not explicit to generating the needed speculation. Making and selling (or more likely renting out) things is now only there as props in telling these stories to earn the real money. That is, people giving you heaps of cash in exchange for stock. Basically anything you can invent by typing numbers into a spreadsheet that buyers can trade amongst themselves will work. Stock these days fits the bill because you don't have to pay dividends. Why not? The story goes that if you did that, you wouldn't be growing as fast. Conveniently this reinforces the FOMO narrative.
Whenever someone whinges that the stock market is up or down and somebody inevitably retorts back that the stock market isn't the economy, I'm actually starting to think they're wrong. The stock market really has become the economy. Anyone with power has so much money tied up in the stock market, that to them, their ideas, what they think is important, the stock market weighs heavily in every decision. Everyday people aren't like this, they need bread and circuses which are becoming ever increasingly more expensive (because doing that makes the stock go up). But to those setting policy direction in government and companies, the stock market really does drive their entire outlook.
Look, if 99.9999% or more of your wealth was in this one vehicle, most people really would do everything they could to prevent their wealth decreasing even if it meant destroying people and the planet to do it. You're only going to live 30-50 more years tops. Problems for later generations or suckers less fortunate are superficial compared to your retirement portfolio.
If you've never edited Wikipedia, give it a go. It's way simpler than you probably think it is, especially for the often undervalued work of citing sources or fixing grammar and/or punctuation. You're likely going to read a bunch of Wikipedia anyway. Take the extra few minutes to help fix problems when you see them.
A great run through many of the noodly little details of Unix processes, signals, alarms, select, poll, and more. Includes a go through the self-pipe trick which I hadn't thought about until now, but is a neat way to simplify. I'm really happy when someone explains something by working a solution to a problem with all the trade-offs left in. Doubly so when the explanation also includes all the hairy bits of the implementations instead of leaving them as a stumbling exercise to the reader.
