I know this is HN, and my instincts tell me posters here predominately are either ICs or managers "in the small" (line level, or at the most at the scale of the OP, in which the company is ~300).
That said, asserting that most meetings are either brainstorming or decision making, is naive. When an organization grows beyond ~100-150 people (Dumbar's Number) the org must metastasize into smaller, "self-contained", orgs that are far less than that number. Once this happens, there is need for meetings that drive accountability, closure, and alignment at scale. For example, monthly or quarterly business reviews.
These are NOT brainstorming meetings or decision-making meetings. They are meetings where leadership drives accountability and alignment by ensuring light is shined (in a way visible cross-org) on the right topics for the biz.
Instead of viewing Dunbar's number as a law, I view it as a sometimes useful, mental model. This article is about how Dunbar's number, as a mental model, breaks down when applied to social media. It makes a strong case for that.
Like all mental models, Dunbar's number is not perfect. However, readers who stop after the introduction of this article may be left thinking it's not useful at all.
I find it very useful in helping leaders in early-stage organizations that are growing fast recognize why the tools & techniques they've used to get to 30-80 people are breaking down as they approach 100-150 people. It helps frame why new tools & techniques for organization and communication are required.
Terminal.Gui really has become "WinForms-in-the-terminal". A lot of the capabilities borrow from WinForms and other popular GUI frameworks. We're not afraid of plagerising.
This is NOT "literally a port of an older curses lib to the latest .net". It is a complete API for building terminal UI applications using .NET that leverages curses under the covers when running in a non-Windows environment (on Windows it uses the native Windows console APIs).
For completeness, Terminal.Gui is built on top of a "Console Abstraction Layer" (CAL; I just invented that term), via the "ConsoleDriver" base class. There are four subclasses provided:
- CursesDriver: Uses curses and is the default on Linux/Mac.
- WindowsDriver: Uses the Windows console API and is the default on Windows (only works on Windows)
- NetDriver: Uses the .NET console API and works on all platforms
- FakeDriver: Used for unit testing.
NetDriver is the slowest. WindowsDriver is the fastest. CursesDriver is the biggest bugfarm ;-).
The Terminal.Gui library itself doesn't provide any special means for dealing with state. However, the full power of .NET Core is available for devs to do whatever they please.
Because I (apparently incorrectly) assumed a lot of people would appreciate the fact the mouse works so well.
Also, because getting the mouse to work well (across Windows, Mac, Linux, etc...) is freaking hard and the Terminal.Gui team is proud of their work ;-).
We view the mouse as optional. We want the mouse to work perfectly, but it should be optional. If any of the library doesn't work well with just a keyboard, please submit an issue!
https://www.kindel.com