atridan

> Writing new systems that don’t need to exist simply to scratch an itch to write (NIH syndrome, etc.)

I've seen this so many times and it almost always ends in failure. Rewrites as well. Engineers can't resist improving a system while rewriting it (adding caching, redundancy, etc). They neglect proving core functionality is intact before making improvements. They also often neglect the thousands of man hours it took to find all the bugs in the system.

I've been building ML systems for a while and I've even seen engineers coming up with their own search/optimization algorithms. This always fails. It's hard enough to get standard techniques to work, since your data usually differs (slightly or severely) from what the technique was validated on (standard, cleaned data sets used for journal papers).

I can see GP's point and I don't see it as micromanagement. It's more like intensive investigation. I was "promoted" into management recently and I've had to change my view from "tasks getting done" to "people working together to complete tasks." Getting people to work together fruitfully is pretty difficult and even more difficult when you have a deadline you're shooting for. I don't care as much for reports back to me on progress, but I definitely like to see communication between those doing the task.

This also goes well with the rule mentioned in the article: always have at least 2 people working on a project.

I used to have a "no drinking with coworkers" policy, but I loosened that a bit. At smaller, team events I have one drink per hour. At larger company events it's one drink every two hours. In either case it comes out to two drinks per event. But, if I see everyone else getting sloshed at events, I usually step out before things get awkward.