Do-everything workplace managers like Asana and Trello promise organizational utopias. But they reveal limitations that date all the way back to the factory floors of the 1900s. //

If you put something on a digital kanban board without enough information, it is no more useful than it was before you created the task. Workforce software is offloading the job of managing projects to countless mini-projects, each only as useful as the skill and utility of the individual user. And we can’t expect each user to be both a maker and a self-manager, especially with the imperfect tools on the market. When we line up the Trellos, Asanas, Wrikes, Airtables, and endless clones of the same inherent project-management misses, their differences matter less than their end results—to paraphrase Anna Karenina’s line about families, each project-management app promises the same happiness, but each creates unhappy users in its own way.

Often the path of least resistence. Here's some ideas that assume that your management is set in concrete on this, and simply won't be moved from having their own Super Special Just for Me Status Reports. Cause... let's face it... sometimes status reports are not about status, they are about ego. Here's some tips to minimizing work

• Never provide more than they want. State it clearly, concisely and unambiguously.. but that often means figuring out what the manager thinks of as "clear", "concise" and "unambiguous".

• Do not provide extra info unless you need them to take action. And then, consider whether you want it in a status report, or a phone call. Some of this is knowing where the status goes. They are tremendously useful red flags when you know who they will go to and how the reader will be reading it.

• Due date is usually the LAST date - I have never heard a manager say "hey, you gave me status too early!!!" - minimize the context switch and send status when you've finished the last reportable thing for that project.

• Keep a secret one true status report - It doesn't matter if it makes sense only to you - a status report that lets you build the others quickly will save a lot of time. It is also a wonderful thing if you work in a high-audit field where people with long lists of questions come to you asking to to prove that you know or did what you said you knew or did.

Thirty years ago, Linus Torvalds was a 21 year old student at the University of Helsinki when he first released the Linux Kernel. His announcement started, “I’m doing a (free) operating system (just a hobby, won't be big and professional…)”. Three decades later, the top 500 supercomputers are all running Linux, as are over 70% of all smartphones. Linux is clearly both big and professional.

For three decades, Linus Torvalds has led Linux Kernel development, inspiring countless other developers and open source projects. In 2005, Linus also created Git to help manage the kernel development process, and it has since become the most popular version control system, trusted by countless open source and proprietary projects. //

Regarding creating Git and then handing it off to Junio Hamano to improve and maintain, Linus noted, "I don't want to claim that programming is an art, because it really is mostly just about 'good engineering'. I'm a big believer in Thomas Edison's 'one percent inspiration and ninety-nine percent perspiration' mantra: it's almost all about the little details and the everyday grunt-work. But there is that occasional 'inspiration' part, that 'good taste' thing that is about more than just solving some problem - solving it cleanly and nicely and yes, even beautifully. And Junio had that 'good taste'." //

I very much don't regret the choice of license, because I really do think the GPLv2 is a huge part of why Linux has been successful.

Money really isn't that great of a motivator. It doesn't pull people together. Having a common project, and really feeling that you really can be a full partner in that project, that motivates people, I think. //

I write very little code these days, and haven't for a long time. And when I do write code, the most common situation is that there's some discussion about some particular problem, and I make changes and send them out as a patch mainly as an explanation of a suggested solution. //

Because all my real work is spent on reading and writing emails. It's mostly about communication, not coding. In fact, I consider this kind of communication with journalists and tech bloggers etc to literally be part of my workday - it may get lower priority than actual technical discussions, but I do spend a fair amount of time on things like this too.