daily.
me: i looked into the customer dev's project and even though it's C#, i can use it as a source of inspiration for my own C++ library.
PM: okay, maybe we can even still use it, so that you use a C# dll with your C++ code.
me: ...
other colleague: that's a bad idea. it can already be a challenge to use unmanaged c++ in dotnet, but the other way round it's even more difficult. C# and C++ are languages that behave quite differently and it will be hard to implement a correctly working interface.
PM: okay. well... then please analyze this project's complexity in terms of LOC and create a class diagram, so we get an idea of how complex it is.
me: sure.
PM: hmm... maybe we should split this topic. since dev x will also rely on your library, analyze this project together with him, each of you look at another part of the classes.
me: that's.... i think that's a bad idea. implementing this functionality in this library is my job, not of dev X. he won't be involved in implementing any of the funcionalities and for him, it shouldn't matter how this works.
PM: yeah, but since we are prototyping, maybe we should just violate the "separation of concerns" rule.
me (internally): (ノಠ益ಠ)ノ彡┻━┻

in the end i could convince him to do it my way, but for fuck's sake... when was the last time he actually succesfully implemented something? 🤦‍♀️

Management has been promising we'd leave .NET framework for 2 years now. Never fucking happens. A new ASP.NET project was just started last week and yup, OF COURSE, its .NET Framework 4.8.

I'd even be happy with one of the earlier .NET Core versions at this point for fucks sake. I have no clue why tech leads are so happy to create a brand new project on a deprecated framework version.

And yes, I have checked thoroughly. Our whole infrastructure works with .NET Core onward. People are just too lazy to learn new stuff.

Stuff like switching to .NET 6, actually doing unit testing, improving our CI/CD pipeline, refactoring problematic codebases, etc. -> all this stuff is the kind of things they promise me I can work on later whenever I'm so bogged down with work that I'm looking for a light at the end of the tunnel. All empty promises.

Ideally we should be on .NET 6 since its LTS and just stay on the LTS versions as the year goes on.

I was introduced to an Oracle dba working for one of the companies licensed for them

I was just starting out a few years in
Was using MySQL and dotnet to develop our system

Cost effective

Bastard gives me a kind of smirking smile after talking about basically representing a fucking catalog of use cases no real development and says "it just takes more to get this position"

Few years later oracle buys MySQL , the product he smirked about

Guess their system was really only good for Wal fucking Mart

Burn in hell oracle !

I don't think it could be more .net core than this: Several parts of the application ended up failing because of a too long URL. For example we used a List to store selected items in an array and they each looked like this:
&model.selectedIds[n]=true
The server side made more sense but we were running late with the project so we just went with it and hoped no one would use this feature.

When windows forms required me to dispose of a certain control derivative manually using a .dispose() call because dynamic control creation was causing a memory leak in dotnet, which instead of fixing, microsoft documented, vaguely.

Went on a Hackathon with two friends. They didn't do shit. This week, they told me that they only knew c#, so we should switch to that. (I use Linux so I shouldn't have accepted that) Just learned that they are going to a maths camp this week and the deadline is next Sunday. Dotnet core CANNOT PARSE FUCKING JSON. I'll rewrite it in node.js, and hope that I can type fast enough to finish in time. Fuck me, fuck my lazy friends and especially fuck Microsoft for saying that they support Linux while providing a dotnet for Linux published in 200-fucking-5

Yesterday I spent many hours debugging obscure compilation errors.
At the end of the day I was like "Fuck it, I'll think about it tomorrow morning".

This morning the compilation works fine. No errors. It's the same code as yesterday.

I'm raging

Why are JavaScript coders called engineers (ie front end engineers, node engineers) but dotnet and Java are called developers?

Little, sad story:
dotnet add package Microsoft.Extensions.Configuration.Json
error: There are no versions available for the package 'Microsoft.Extensions.Configuration.Json'

There is no microsoft packaging technology that works out of the box. Ever.

We're using a setup with c# dotnet backend and js (React) front end... and do one in VS and the other in VS code. Any way to get one IDE to handle both properly? It's a huge pain but my manager told me that's just how they do it

I fucking hate entity framework.
It turns 10 mins of work into fucking hours of stress and bloat and shit.

It’s the one thing in dotnet that I cannot fucking stand.

Literally did a bit of work in 10 mins (using ef I might add), but because it’s not the”ef way” I need to create an extra table/class and then fuck about mapping the relationship in a complicated way to do what I had just done in only a few lines of code with one table.

Spend over an hour trying to get it to understand the relationship before I gave up for the day. Fuck it

Upgraded my project from .NET 6 to .NET 7.

Looks like some kid who writes shit in JavaScript and pats themselves on the back has had some input on System.Text.Json

JsonDerivedTypeAttribute

In most businesses, self-proclaimed full-stack teams are usually more back-end leaning as historically the need to use JS more extensively has imposed itself on back-end-only teams (that used to handle some basic HTML/CSS/JS/bootstrap on the side). This is something I witnessed over the years in 4 projects.

Back-end developers looking for a good JS framework will inevitably land on the triad of Vue, React and Angular, elegant solutions for SPA's. These frameworks are way more permissive than traditional back-end MVC frameworks (Dotnet core, Symfony, Spring boot), meaning it is easy to get something that looks like it's working even when it is not "right" (=idiomatic, unit-testable, maintainable).

They then use components as if they were simple HTML elements injecting the initial state via attributes (props), skip event handling and immediately add state store libraries (Vuex, Redux). They aren't aware that updating a single prop in an object with 1000 keys passed as prop will be nefarious for rendering performance. They also read something about SSR and immediately add Next.js or Nuxt.js, a custom Node express.js proxy and npm install a ton of "ecosystem" modules like webpack loaders that will become abandonware in a year.

After 6 months you get: 3 basic forms with a few fields, regressions, 2MB of JS, missing basic a11y, unmaintainable translation files & business logic scattered across components, an "outdated" stack that logs 20 deprecation notices on npm install, a component library that is hard to unit-test, validate and update, completely vendor-& version locked in and hundreds of thousands of wasted dollars.

I empathize with the back-end devs: JS frameworks should not brand themselves as "simple" or "one-size-fits-all" solutions. They should not treat their audience as if it were fully aware and able to use concepts of composition, immutability, and custom "hooks" paired with the quirks of JS, and especially WHEN they are a good fit.

Kernel Simulator has its own Forecast library (implemented by me) and stole it! Anybody should be able to use this particular library without having to deal with the rest of the "master app."

DIVORCE!!!