• 2 Posts
  • 33 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle


  • They work great when you have many teams working alongside each other within the same product.

    It helps immensely with having consistent quality, structure, shared code, review practices, CI/CD…etc

    The downside is that you essentially need an entire platform engineering team just to set up and maintain the monorepo, tooling, custom scripts, custom workflows…etc that support all the additional needs a monorepo and it’s users have. Something that would never be a problem on a single repository like the list of pull requests maybe something that needs custom processes and workflows for in a monorepo due to the volume of changes.

    (Ofc small mono repos don’t require you to have a full team doing maintenance and platform engineering. But often you’ll still find yourself dedicating an entire FTE worth of time towards it)

    It’s similar to microservices in that monorepo is a solution to scaling an organizational problem, not a solution to scaling a technology problem. It will create new problems that you have to solve that you would not have had to solve before. And that solution requires additional work to be effective and ergonomic. If those ergonomic and consistency issues aren’t being solved then it will just devolve over time into a mess.



  • There are markup languages for this purpose. And you store the rich text as normal text in that markup language. For the most part.

    It’s typically an XML or XML-like language, or bb-codes. MS Word for example uses XML to store the markup data for the rich text.

    Simpler and more limited text needs tend to use markdown these days, like Lemmy, or most text fields on GitHub.

    There’s no need to include complex technology stacks into it!

    Now the real hard part is the rendering engine for WYSIWYG. That’s a nightmare.


  • The ecosystem is really it, C# as a language isn’t the best, objectively Typescript is a much more developer friendly and globally type safe (at design time) language. It’s far more versatile than C# in that regard, to the point where there is almost no comparison.

    But holy hell the .Net ecosystem is light-years ahead, it’s so incredibly consistent across major versions, is extremely high quality, has consistent and well considered design advancements, and is absolutely bloody fast. Tie that in with first party frameworks that cover most of all major needs, and it all works together so smoothly, at least for web dev.




  • This is a weird take given that the majority of projects relevant to this article are massive projects with hundreds or thousands of developers working on them, over time periods that can measure in decades.

    Pretending those don’t exist and imagining fantasy scenarios where all large projects are made up of small modular pieces (while conveniently making no mention to all of the new problems this raises in practice).

    Replace functions replace files and rewrite modules, that’s expected and healthy for any project. This article is referring to the tendency for programmers to believe that an entire project should be scrapped and rewritten from scratch. Which seems to have nothing to do with your comment…?










  • C# on non-Windows is not impossible, but it’s going to require effort infeasible for school projects like that one.

    You mean winforms (The windows specific UI) on non-Windows? Otherwise this is incredibly misleading, and plain wrong.

    C# in non windows is the norm, the default even, these days. I build, compile, and run, my C# applications in linux , and have been for the last 5+ years.



  • 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


  • There is no context here though?

    If this is a breaking change to a major upgrade path, like a major base UI lib change, then it might not be possible to be broken down into pieces without tripping or quadrupling the work (which likely took a few folks all month to achieve already).

    I remember in a previous job migrating from Vue 1 to Vue 2. And upgrading to an entirely new UI library. It required partial code freezes, and we figured it had to be done in 1 big push. It was only 3 of us doing it while the rest of the team kept up on maintenance & feature work.

    The PR was something like 38k loc, of actual UI code, excluding package/lock files. It took the team an entire dedicated week and a half to review, piece by piece. We chewet through hundreds of comments during that time. It worked out really well, everyone was happy, the timelines where even met early.

    The same thing happened when migrating an asp.net .Net Framework 4.x codebase to .Net Core 3.1. we figured that bundling in major refactors during the process to get the biggest bang for our buck was the best move. It was some light like 18k loc. Which also worked out similarly well in the end .

    Things like this happen, not that infrequently depending on the org, and they work out just fine as long as you have a competent and well organized team who can maintain a course for more than a few weeks.


  • Just a few hundred?

    That’s seems awfully short no? We’re talking a couple hours of good flow state, that may not even be a full feature at that point 🤔

    We have folks who can push out 600-1k loc covering multiple features/PRs in a day if they’re having a great day and are working somewhere they are proficient.

    Never mind important refactors that might touch a thousand or a few thousand lines that might be pushed out on a daily basis, and need relatively fast turnarounds.

    Essentially half of the job of writing code is also reviewing code, it really should be thought of that way.

    (No, loc is not a unit of performance measurement, but it can correlate)