As there seems to be some doubt as to whether this is a joke or not, I’d like to posit that we’re not supposed to know and that’s the point.
The author is the founder of the now-defunct YC startup RethinkDB. He learned engineering management the hard way, and he has done a lot of writing in various places that resembles this one: they’re un-nuanced bits of advice that take a strong position. I wouldn’t be surprised if the author actually stands by each of them, but he surely is well aware that this isn't mainstream “best practice” material. After all, that would be boring. We can find an endless stream of that on LinkedIn.
Personally I find it refreshing. Too much software engineering management advice is so overly nuanced and thinned down that nobody is offended but nobody learns anything either.
A lot of the author’s articles and tweets contain a way of looking at things that I hadn’t previously considered. I don’t think you need to agree with the whole thing to take whatever part out of it that resonates. And, well, they’re ultra-fast reads.
(In this particular case, I love the headline part, I think it can help us cut away stuff that seems important but isn’t. I hate the deadline part because I think arbitrary deadlines and constant crunch mode are bad. I don’t think spakhm minds that I only appreciate half of it)
> Personally I find it refreshing. Too much software engineering management advice is so overly nuanced and thinned down that nobody is offended but nobody learns anything either.
I love and bask in simplicity, but I think the reasons software engineering management advice is often overly nuanced is that it is a very complicated subject where simple approaches don't work. The number of corner cases that emerge are staggering. The most "simple" advice I would give now is that you need to know your people. Personalities and individual working styles make one strategy work great on one team and terrible on the other, and it's not as simple as the first team being good and the second one being bad.
The author is the founder of the now-defunct YC startup RethinkDB. He learned engineering management the hard way, and he has done a lot of writing in various places that resembles this one: they’re un-nuanced bits of advice that take a strong position. I wouldn’t be surprised if the author actually stands by each of them, but he surely is well aware that this isn't mainstream “best practice” material. After all, that would be boring. We can find an endless stream of that on LinkedIn.
Personally I find it refreshing. Too much software engineering management advice is so overly nuanced and thinned down that nobody is offended but nobody learns anything either.
A lot of the author’s articles and tweets contain a way of looking at things that I hadn’t previously considered. I don’t think you need to agree with the whole thing to take whatever part out of it that resonates. And, well, they’re ultra-fast reads.
(In this particular case, I love the headline part, I think it can help us cut away stuff that seems important but isn’t. I hate the deadline part because I think arbitrary deadlines and constant crunch mode are bad. I don’t think spakhm minds that I only appreciate half of it)