111–120 of 320 posts
Alternate framing: be prepared to "Do Things that Don't Scale" ( http://paulgraham.com/ds.html ) when your organization is small.
Not a fan of pg, but his schlep essay is a better alternate framing of this article (if my reading comprehension is accurate...): http://www.paulgraham.com/schlep.html
> You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest. Ah, this is so good. I think you could swap “trick” for “talent” and this would read just as true.
> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized. The team couldn’t agree on which issues to tackle > I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized. Honestly, this is one of those traps a team can fall in…
> Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars. I agree with this statement and your other points. I’ve noticed a more insidious variant of this behavior: the expectation of interruptions. Some groups have such frequent priority shifts and/or a culture of fire fighting or door knocking such that even with a r…
We went from recognising that requirements may change after planning to zero planning and telling developers what's the next priority for the day, day by day.
This lack of planning and product definition is also what drives the lack of documentation, which is another big problem in 2021.
I don't expect going back to waterfall but also not what's going on nowadays. Hopefully we'll bounce back in the middle at some point.
I have to wonder what magicians think of the 80/20 rule. The trick probably needs all 100% and the grind it takes to get there.
The same actually goes for tech too, but here the answer is often that the 100% product isn't on the market yet, and by the time it is finished the need for it no longer exists.
Earlier quoted context omitted.
That's an entire family of tricks called card forces. I used to have a whole routine based on them. Here's a blog post with three of them: https://conjuror.community/best-card-forces/ I had about a 50% hit rate on the natural force. You just fan through the cards and time it so they pick the one you want. Wouldn't work for the tea trick, but works fine if you have a fallback.
Thanks for the link. Of the three techniques mentioned, one (the entire deck is all the same card) obviously doesn't withstand any scrutiny; one (riffle through a deck and skip to your chosen card when they say stop) feels like it'd be too risky for a trick that took days to set up; and one (the "natural" force) says "please pay us to learn the secret." I don't think the trick that's the show pony of this blog post h…
Or maybe indeed the magician doesn't use any of those. Another aspect of magic I've read in profiles of Ricky Jay and Teller is that they hunt down and pore over old magic books, looking for less-common techniques and setups to adapt.
Earlier quoted context omitted.
Honestly, I’d have approached it differently. Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed. This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead. Put another way - if everything is important or “must fix”, nothing is. So to the author: that seemed like a waste of time.…
> Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed. This seems like a great idea: technical debt bankruptcy. In reality, you're throwing away hugely valuable data that people spent real time and effort producing for you. See also: https://www.jwz.org/doc/cadt.html
https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...
Earlier quoted context omitted.
I think being able to sit down and do work is more about removing distractions than improving focus. Also, I'm curious about these statements: > There's a growing perception that traits like work ethic, focus, and motivation are fixed attributes that one is born with (or without) rather than abilities that are developed over time Really? Who believes this and why? > but then turn around and tell me that they're only…
No it’s not. Speaking as someone who specifically has this problem: even eliminating all possible distractions does not do the trick.
> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized. The team couldn’t agree on which issues to tackle > I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized. Honestly, this is one of those traps a team can fall in…
Honestly, I’d have approached it differently. Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed. This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead. Put another way - if everything is important or “must fix”, nothing is. So to the author: that seemed like a waste of time.…
It's great for individual contributors who don't care about understanding the product and are probably going to be in another team in 3 months.
In a previous job I did what the author did and it helped building an understanding of the project and with knowing at any time the list of the top X things we had to fix.
> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized. The team couldn’t agree on which issues to tackle > I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized. Honestly, this is one of those traps a team can fall in…
> For example, I once joined a team maintaining a system that was drowning in bugs. There were something like two thousand open bug reports. Nothing was tagged, categorized, or prioritized. The team couldn’t agree on which issues to tackle > I spent almost three weeks in that room, and emerged with every bug report reviewed, tagged, categorized, and prioritized. Honestly, this is one of those traps a team can fall in…
Honestly, I’d have approached it differently. Close everything older than 2 weeks. If it’s important/relevant, it will crop back up. If it’s not, then it stays unfixed. This can be really uncomfortable to do. But it’s how I’ve rescued a couple of teams that I’ve led as either an EM or Tech Lead. Put another way - if everything is important or “must fix”, nothing is. So to the author: that seemed like a waste of time.…