I'd agree with most of the article except the "The day-to-day always gets boring" segment. If you don't like yourself, traveling merely results in not liking y

I'd agree with most of the article except the "The day-to-day always gets boring" segment. If you don't like yourself, traveling merely results in not liking yourself somewhere else. If you are boring, going somewhere exciting merely results in an exciting place now including qty one boring person. If you don't like your job, being forced to participate in a hackathon will result in increasing the hatred of the job not loving it. The diversity part especially was racist, all brits are the same, all greeks are the same, there is more to diversity. Note how that section also neatly excludes all potential employees with social lives or family lives outside of coworkers due to the relatively intense level of required coworker socialization, yet categorized that very exclusion as diversity. This is especially striking on a holiday weekend, I had a lot of fun this weekend without a single coworker being involved, not even a phone call, so far anyway. It would suck from a stress standpoint never being able to get away from work, or having to give up holiday family time just to put food on the table. An unmentioned advantage is there is some (ugh) synergy in the two separately described issues of elimination of giant monoliths and rotation of personnel. However, eliminating "can grok the entire system architecture" as a precondition of writing code doesn't mean nobody needs to grok the entire system architecture. One way I've handled "Too Long; Didn’t Learn" professionally is to just fix stuff on a higher level. In the article there is an example of a boring inside tool acting as a "fake-Spark". Well why not just re-implement in Spark? The reason why not might tie into the other paragraph that paraphrases to "micromanagement is not fun", but just job hop until you find a professionally managed company then its all good.