Notices by Kirill Osenkov (kirillosenkov@mastodon.social)

We could have solved world hunger instead of doing AI

Nothing makes me more scared for our profession than young developers sending me a well-written paragraph that somehow doesn't make sense

I'm announcing a bounty: I'll wire or venmo $100 to whoever fixes this:
https://github.com/dotnet/msbuild/issues/7988

I'm angry that such an impactful bug has been sitting open for a year and a half, and I absolutely don't have time to fix it myself, otherwise I would have fixed it long ago. I just can't do it all myself.

So, if anyone wants an extra green benjamin, it would be very helpful!

Someone can't build a .sqlproj in VS because this area has been historically underfunded, but hey, don't fret, VS now has two Copilots and IntelliCode.

Honey wake up, new Boeing panel just dropped

https://www.fox13seattle.com/news/boeing-mishaps-united-panel-missing

There's this modern and sophisticated logging system that's super extensible, has a ton of factories, proxies and interfaces, but I wasn't able to find a way to just turn it all off. There just is no way.

... OR IS THERE?

Regarding staying on Twitter or moving to Mastodon I'll just say this: there are trend-followers and trend-setters. Trend-followers stay where the crowd is, trend-setters redefine where the crowd is.

Some of us are cursed by the innate desire to keep things clean, maintainable and well-organized. Instead of going home to our families and having a life, we choose to stay and refactor, and clean up after other people. The problem is when the debt compounds enough it starts to slow down the whole product and maybe even doom it.

Witnessing debt in a large codebase. Small things, like tons of repeated code in tests. Instead of extracting a helper or finding existing code that does what you need, people just copy-paste or slap something together and move on.

I think it's natural that people want to get their task done and move on, and don't care about keeping the "cesspool" clean.

This is a sensitive and complicated matter and I don't know what the right thing is and what can an individual do if anything.

All I know is entropy increases. It is an inevitable process. In most cases it's an inconvenient truth that management/leadership prefers to ignore, or simply not know or care about. They're all about "business value", "delivering features", "impact", "visibility", etc.

Either some employees will fight the entropy in their spare time and at their own expense, or it will grow uncontrolled. If you see a product that was once great, but is now a bloated buggy piece of garbage, uncontrolled entropy is likely one of the reasons why.

The part that makes me the most sad is the people who choose to fight it on their own are often talented and could have had more impact doing something entirely different. But they're doing it because no one else will.

More thoughts: tech debt is low visibility, cleaning it up is discouraged, unrewarded, but also difficult and sometimes risky. Also it does take away from adding measurable value. People are not incentivized to clean it up.

Also it's never built into schedules, estimates, never prioritized or funded properly.

Explaining the need to pay some of it off is often futile, as management is simply unable to understand it if they're not engineers. It's bad for morale and productivity.

I don't know where I'm going with this, I'm just a bit sad. I don't have any ideas on what would make things better and what is even "better". Software is hard.

I’ll give you some examples. Someone went out of their way and converted a few hundred projects to SDK style. It was hard work, took a long time, but massively improved life for several hundred people as a result.

They got a bad review because of this and quit the company in frustration. This is how the team lost someone talented and motivated who tried to improve things.

Got some good wisdom in the replies in this thread, check them out!

Another person I know was working on making Windows builds faster. They found a process that took 45 minutes, and could be made significantly faster relatively easily. They approached the author of the tool, and the author replied “yes, we know. we just don’t care”. Nobody in management cared either. The person who wanted to fix it left the company.