What features would you want in a logger?

Here's what I'm planning so far:
- Tagged entries for easy scanning of log file
- Support for indenting to group similar sequential entries
- Multiple entry types (normal, info, event, warning, error, fatal, debug, verbose)
- Meta entries, so the logger logging about itself, e.g. disk i/o failures.
- Ability to add custom entry types, including tag, log-level, etc.
- Customizable timestamp function
- Support for JS's async nature -- this equates to passing a unique key per 'thread'; the logger will re-write all the parent blocks for context, if necessary. if that sounds confusing, it's okay; just trust that it makes sense.
- Caching, retries, etc. in the event of disk i/o issues.
- Support for custom writers, allowing you to e.g. write logs to an API rather than console or disk.

How about these features?
- Multiple (named) logs with separate writers (console, disk, etc.)
- Ability to individually enable/disable writing of specific entry types. (want verbose but not info? sure thing, weirdo!)
- Multiple writers per log. Combined with the above, this would allow you to write specific entry types (e.g. error, warning, fatal) to stderr instead of stdout, or to different apis.
- Ability to write the same log entry to multiple logs simultaneously

What do you think of these features?
What other features would you want?
I'm open to suggestions!

@Apple iPadOS an iOS teams: you puZies.

You release one buggy iOS / iPadOS after another, each piling on features and bugs, without fixing crowd documented long standing defects.

But what really pisses me off is when you don't have the balls to own up to your mistakes. This is at least the 3rd time you have re-released an iOS / iPadOS update under the same version number. This time it is 14.5.1

I have iPadOS 14.5.1 installed and the iPad is now telling me I need to update to 14.5.1. Just own up to it, you released buggy shit and you need to release another bug fix days after... call it 14.5.2. Call it like it is and we respect you. Try to hide it and you lose our respect, you pussies.

If Microsoft did one thing right, they defined the release sequencing:
X.Y.Z

Changing X means rewrite the manual it is so new and improved (🖕🏻 you Adobe and FileMaker)

Changing Y means it is an update with more features than bug fixes but not a generational change that constitutes a rewrite of anything (🖕🏻 you macOS team for bastardizing with 10.X.Y)

Changing Z means you fixed your stuff, we respect you for owning up to your mistakes.

Man-up Apple, grow some balls and stop confusing people with trying to cover up your screw ups. It's all about the Z.

a "landing page", that was just any and all features of the application forced into one huge, unbearably slow, indeniably confusing page.

which took months of work. which i said beforehand "nobody will use it". which now, through the magic of user tracking, is proven to be used by nobody.

Every assignment is done by reference in JavaScript... like why? Lemme use a pointer when I need it.
ES2016 looks so much like Java, I swear nobody will notice if they added pointers... and over 9000 more confusing features.

I am the technical lead in a project which uses a C# based framework. It's a lot of drag and drop, and C# scripts can be embedded for fancy stuff.

Scripts in general are not hard to do, it's harder to understand the business rules rather than the code itself.

I got hired as a junior to build this project from scratch as an MVP, and we need another junior to add enhancements and minor changes required from our end users. Since management wants me to move on working on more mid-senior development stuff, I'm supposed to be only supervising the juniors work (in the hopes that one day they'll be able to work on their own).

We've had bad luck filling this position. Our last hire is a guy like 17 years older than me, supposedly with experience in said framework but OH DEAR GOD.

Fucktard can't understand requirements and corrections, isn't able to deliver a 20 line script without fucking up. I give him a list with 3 mistakes to fix and only fixes two, crap like that.

Now, hear me out, the mistakes are stuff like:

- Unused variables
- Confusing error messages
- Error messages written in spanglish (mix between Spanish and English, we're located in Latin America)
- Untested features, this is the worst of all.

You may say "but he's a junior", sure. But as I said, he supposedly has experience, more years in IT than me, and fine, you're allowed to fuck up a few times on your first tasks but not make the same mistakes over and over, specially since we've already sat down and addressed these issues in presence of the CTO.

Fuck this guy. I genuinely dislike him as a person also, he is from another latin country and we have some serious cultural differences. For instance, he insists on sucking your ass constantly, being overly well manered (we already saluted with the whole team at the daily stand up, stop saying hello, good day, regards in each of your fucking chat messages or task submissions), and other mannerisms that are hard to translate, but whatever, all of these attitudes are frowned upon here. They're not necessary, we just want to keep it simple, cordial and casual and see you deliver the crap that you're being paid for with a decent level of quality.

On Monday the CTO comes back from vacation, I'm looking forward to that meeting, gonna report his ass, there is evidence everywhere on our issue tracker.

QA: There is a bug on this screen

You: Nope. In fact, it's a new feature

Hi there!

I've been worrying about the following problem for months now and I don't find any solution. Maybe anybody of you can lead me the way.

We are developing a software suite which consists of a number of desktop applications:

* 12 applications written in C++; all over 20 years old; further development by 5 or 6 guys (one man armys) - mainly bugfixing, changes of law implementations, small features
* 2 applications we are currently writing in C#; completely new developments of existing C++ applications; scrum teams with at least 5 guys; this is, where we put our focus in

These applications (C++ and C#) are sharing some core assemblies and are interacting with each other. So they are not independent.

We organize them in a mono repository in one huge solution, which consists currently of about 500 projects.

Advantages:

* With all projects in one solution and through project references, Visual Studio takes care of the right build order
* Code navigation is superb - every single line of code is accessible - this makes refactoring easy
* Every developer can map the branch and build the whole suite locally
* Debugging on the local machine is easy
* DevOps pipeline is straight forward - it just have to build a single solution

Disadvantages:

* The huge solution is extremely slow.
* If you want to build the solution or you want to debug (which does essentially the same as a pre step) Visual Studio is building a lot of projects, although they haven't been changed. Their detection is buggy. So sometimes you wait 2 minutes until it starts the app. That slows us down a lot.
* Full builds need about an hour, because its building the same projects (even if they haven't been changed) over and over again (with ready made nuget packages this could be improved a lot I think)
* If a core team member changes some core apis, he is changing the calling code too, although he doesn't know the calling code, because another team has written it. I don't think, that's best practice and it doesn't scale.
* Often, a C# developer has to mess around with C++ building problems, because the C++ projects are in the same solution
* It gets more and more confusing and frustrating, because there is no clear organizational seperation between apps and nobody can't just focus on his app alone.

Idea:

I was thinking about putting the whole framework and core projects in a new solution (around 100 projects). Then we could take all old C++ projects and put them also in a new solution (around 200 projects). This would leave the newer projects (new applications - C#) in the existing solution.

This should speed up things, and would be a first step to better seperation, BUT:

How should the integration process look like?

Scenario: Core team is changing an API in our framework

Current process: Because all projects are in the same solution, they change the calling code too. So it's immediately integrated and the app developers just have to do "get latest".

New process (?): Core team is providing the changes through a nuget package (new version). So does every developer now has to keep track of if there is a new package version and if yes, do the integration? And how can we coordinate the different teams, so they are upgrading all at the same time? Because we ship our applications as a suite, all apps has to use the same versions. Or should we automate the integration process? Is there a best practice?

I have to add, that our core team is making changes very frequently, so the integration process will have to happen often.

Any ideas/feedback/inspiration?

Thank you so much in advance!

Trying to configure a smartphone which was already optimized for elderly users, with a more simplistic launcher, larger font size etc.

But the underlying Android 7 and its apps still keep showing up with their inconsistent UI and nagging messages and suggestions.

Is it even possible to configure any Android device to make it really simplistic and distraction free like, say, a classic NOKIA before the age of smartphones?

Culprit no. 1 Google and Android system. Suggestions about features keep recurring, even after stating that we are not interested in the feature.

Culprit no. 2 WhatsApp, unfortunately still the most popular messaging app in Germany, so this crappy bullshit software by Mark Fuckerberg's company has to be installed. Even to me as a tech savy developer, WhatsApp has a confusing user interface that tries to promote features like status (their versions of stories) without any option to hide / turn off.

How shall an 80 year old senior learn to use the app when they previously only used SMS and voice calls? I don't know.