Yeah, but that's not what we're talking about here.
RTF has many more features than markdown can reasonably support, even with your personal, custom, syntaxes that no one else knows :/
I use markdown for everything, as much as possible, but in the context of creating a RTF WYSIWYG editor with non-trivial layout & styling needs it's a no go.
I mean... Every serious operating system already has some form of keyring feature right?
The follow on. Lots and LOTS of unrelated changes can be a symptom of an immature codebase/product, simply a new endeavor.
If it's a greenfield project, in order to move fast you don't want to gold plate or over predictive future. This often means you run into misc design blockers constantly. Which often necessitate refactors & improvements along the way. Depending on the team this can be broken out into the refactor, then the feature, and reviewed back-to-back. This does have it's downsides though, as the scope of the design may become obfuscated and may lead to ineffective code review.
Ofc mature codebases don't often suffer from the same issues, and most of the foundational problems are solved. And patterns have been well established.
/ramble
Someone who shares their experiences gained from writing real world software, with introspection into the dynamics & struggles involved?
Your age (or mostly career progression, which is correlated) may actually be a reason you have no interest in this.
How difficult would you expect it to be to go back and produce ADRs for significant decisions in the past that resulted in the current architecture and structure of a small-medium sized project?
Hard agree.
Less code is not a positive metric to measure your implementation by, and is not a valid premise to justify itself. Often increasing the complexity (again, LOC is not an indicator of complexity), tanking performance, and harming the debugging experience is a common result of the mentality. Things that make software worse.
Not all one-liners are bad ofc, that's not the argument I'm making. It's about the mentality that less code is more good, where poor decisions are made on a flawed premise.
each line of code is a millisecond round their neck
My man here thinking performance optimizations= fewer lines of code ๐๐๐
Well, let's start with which ones you have looked at, and why they aren't to your liking.
If you're trying to build a company then stop using Blazor, and start using react/vue...etc for your frontend and make an Asp.Net API.
If you need a web app, then use well known technology to do it. Otherwise you're just playing in the sandbox, not building something that can be built quickly, and can be easily onboarded to.
So many C# devs are scared of FE tech, learning how to use it effectively will only make your work better, and speedier.
Essentially, use boring technologies and be pragmatic.
A codebase is different than the language itself enabling many ways to do the thing.
You may not think it's likely to cause problems, but have you actually onboarded non c# devs onto new C# projects?
I have been for the last 6 months and let me tell you it really opened my eyes to new problems. One of those is that there are many ways to do the same thing, which has been a consistent pain point for non-c# devs, and has been hurting adoption and general sentiment.
Honestly I didn't think much of it till now, and didn't think it would be that big of a deal. Turns out it is.
To be fair it's not a good comparison to compare an IC role against a management role for time breakdown.
Doesn't appear to show any charts on Chrome for mobile...
Seems to be a responsiveness issue, because it goes away in landscape mode, and the charts show.