Interesting article. Some of those points I think are good for even a technical manager to read.

Overall it's a good read.

I disagree with what the author considers red flags. Generics, frameworks, platform-independence, and future proofing are all items I would consider important. I do agree that their costs must be weighted against their benefits.

I also disagree with the 80%/50 rule because it depends on what the definition of done is. IMO 80% done doesn't mean you can ship it right now, that's what 100% done means when you're working on the minimum viable product. Sometimes the hardest part is the first 80% and not the last 20%. I do agree that progress does not always directly relate to resource spending.

I also recommend reading the comments on that article under "show all responses". The two comments which stick out to me are 1) You should be able to trust the people you're managing and 2) If you're in a position managing something you don't understand then maybe you shouldn't be doing that.

I don't think I shared it for how to catch a bullshitter, but more for the good points to think about in how we work.  A lot of this may be standard operating procedures in their daily lives and others may not.  

My big takeaway is understanding the problem objectively and asking the right questions before forging ahead,.  What problem is this going to solve, what are the costs (not just $$ but time/people),

Some good points for day to day work process.

I totally agree, there are some good points in there about questions we should ask ourselves before we continue developing. I have seen plenty of "refactors" that made the code more reusable but there were no plans to reuse the code. By the time another developer got the chance to reuse it, the original assumptions were no longer valid and another refactor was needed.

As developers we should always be trying to balance how we solve problems with the benefits of how we solve them.