HN user

bytefish

82 karma

https://www.bytefish.de

Posts6
Comments34
View on HN

What usually happens in my experience is, that a home-grown Data Access Layer usually turns into a bad "ORM light", because materializing results is repetitive and tiring work. You want to abstract it away.

As a .NET developer I think EF Core has made the right call here, by allowing you to write SQL where it's needed and still use its infrastructure for all the tedious work of materializing your results.

Admittedly in 2014, the time the article was written at, I've also felt using OR-Mapper is a dead-end. But in 2026 the world isn't black and white.

I had, yes. But those had also been rewritten with Gemini from ground up, because it caught way more edge cases, than I did. Which is fascinating and frightening at the same time.

I think my vibe-coding success also has to do with the problem being not that “novel” and prior art exists.

Nevertheless still impressive.

This resonates with my experience.

I have several Open Source projects and wanted to refactor them for a decade. A week ago I sat down with Google Gemini and completely refactored three of my libraries. It has been an amazing experience.

What’s a game changer for me is the feedback loop. I can quickly validate or invalidate ideas, and land at an API I would enjoy to use.

The first and most important lesson, that I try to each every young developer starting in the industry: Go home after clocking in your hours negotiated in your contract. Drop your pen. Go home. Sleep well.

And I hope, that every sensible senior developer in here does the same. Lead by example. Maybe it would prevent a few burnouts in this industry.

And if you are a manager, then send your people home after they have clocked in their negotiated hours. For their own well-being. It’s your responsibility. And if it’s not working, then force them to go home.

I hope you are better by now and got through the tough time. All the best for you!

As for the tree analogy and open source.

Yes, you cannot build years of community and trust in a weekend. But sometimes it's totally sufficient to plant a seed, give it some small amounts of water and leave it on its own to grow. Go ask my father having to deal with a huge maple tree, that I’ve planted 30 years ago and never cared for it.

Open Source projects sometimes work like this. I've created a .NET library for Firebase Messaging in a weekend a few years ago… and it grew on its own with PRs flowing in. So if your weekend project generates enough interest and continues to grow a community without you, what’s the bad thing here? I don’t get it.

Sometimes a tree dies and an Open Source project wasn’t able to make it.

That said, I’ve just finished rewriting four libraries to fix long standing issues, that I haven’t been able to fix for the past 10 years.

It's been great to use Gemini as a sparring partner to fix the API surface of these libraries, that had been problematic for the past 10 years. I was so quick to validate and invalidate ideas.

Once being one of the biggest LLM haters I have to say, that I immensely enjoy it right now.

We mourn our craft 6 months ago

To me, it’s super exciting to play ping pong with ideas up until I arrive at an architecture and interfaces, that I am fine with.

My whole life I have been reading other people’s code to accumulate best practices and improve myself. While a lot of developers start with reading documentation, I have always started with reading code.

And where I was previously using the GitHub Code Search to eat up as much example code as I could, I am now using LLMs to speed the whole process up. Enormously. I for one enjoy using it.

That said, I have been in the industry for more than 15 years. And all companies I have been at are full of data silos, tribal knowledge about processes and organically grown infrastructure, that requires careful changes to not break systems you didn’t even know about.

Actually most of my time isn’t put into software development at all. It’s about trying to know the users and colleagues I work with, understand their background and understand how my software supports them in their day to day job.

I think LLMs are very, very impressive, but they have a long way to go to reach empathy.

The lost art of XML 6 months ago

What I miss the most about the XML ecosystem is the tooling. And I think, this is what most people are sentimental about. There was a time it was so easy to generate contracts using XSDs and it made it easy to validate the data. OpenAPI slowly reaches parity to what I worked with in 2006.

But what I do not miss is the over-engineering that happened in the ecosystem, especially with everything SOAP. Yes, when it worked, it worked. But when it didn’t work, which was often the case when integrating different enterprise systems, then well… lord have mercy on me.

Sometimes I still use XSD to define a schema for clients, because in some areas there’s still better tooling for XML. And it gives me the safety of getting valid input data, if the XML couldn’t be validated.

And in the enterprise world, XML is far from being dead anyways.

[dead] 6 months ago

Delete only works within a time frame and if there are no comments yet. I didn’t think quick enough and instead of posting the link twice I’ve edited it to this. Lots of bad decisions on my side. Now it’s also too late to edit.

It takes literally a click to deactivate it though. One could argue about Bing Search being the default, but I didn’t run the user surveys to see, which is best for the average user.

Making software is 20% actual development and 80% is maintenance. Your code and your libraries need to be easy to debug, and this means logs, logs, logs, logs and logs. The more the better. It makes your life easy in the long run.

So the library you are using fires too many debug messages? You know, that you can always turn it off by ignoring specific sources, like ignoring namespaces? So what exactly do you lose? Right. Almost nothing.

As for my code and libraries I always tend to do both, log the error and then throw an exception. So I am on the safe side both ways. If the consumer doesn’t log the exception, then at least my code does it. And I give them the chance to do logging their way and ignore mine. I am doing a best-guess for you… thinking to myself, what’s an error when I’d use the library myself.

You don’t trust me? Log it the way you need to log it, my exception is going to transport all relevant data to you.

This has saved me so many times, when getting bug reports by developers and customers alike.

There are duplicate error logs? Simply turn my logging off and use your own. Problem solved.

If it is a program level error, maybe a warning and returning the error is the correct way to do. Maybe it’s not? It depends on the context.

And this basically is the answer to any software design question: It depends.

I have never been in a project, where estimates were spot-on, and I do this for 15 years now. By now hundreds of features have floated by the river and hundreds of meetings have been held.

Estimations are often complicated, because there are way too many variables involved to give accurate estimates. Politics within companies, restructuring of teams. The customer changes their mind, the reality you've expected is slightly different, your architecture has shortcomings you find out late in a project, the teams your work depends on disband, … and a million other things.

Theoretically you could update your estimates in a SCRUM meeting, sure, but to be honest, this has always been nothing but a fantasy. We rarely do work in a void. Our features have been communicated higher up and have already been pitched to customers. In a fully transparent and open organization you might update your estimates, and try to explain this to your customers. In reality though? I have never seen this.

While this sounds very negative, my take on it is not to waste too much time on estimates. Give a range of time you expect your features to fall into, and go on with getting your work done.

I have once migrated my repositories to Codeberg, but have moved back to GitHub.

While I despise a lot of features on GitHub, Codeberg is sadly lacking the gravitational pull and visibility. I know, someone has to start, but as a single maintainer I need collaboration to keep the projects alive.

It’s great to see Apache Baremaps being mentioned. It’s a great project and I saw its first iterations. Really amazing they have built a community around it.

Although my library in Apache Baremaps probably plays a minor role only (PgBulkInsert for Postgres COPY protocol), it’s great to see it chugging on all this data day by day.

If you are using SQL Server, then SQL Server Database Projects are an amazing tool to work with. I found them to generate high-quality migration scripts and it makes it easy to diff against an existing database.

ORMs are good up until the point you need to include SQL Views, Stored Procedures, Functions, User-defined Types… which is usually the point the ORM abstractions begin to crack (and every SQL Server database I use include them).

For PostgreSQL I usually hand-write the scripts, because it is easier, than fighting against an ORM.

I heard the Redgate tooling is also great to work with, but I’ve never used it personally.

It provides a runtime, that sandboxes your application and requires you to give explicit permissions for file system operations and network requests.

This limits the attack surface, when it comes to installing malicious dependencies, that npm happily installs for you.

So yes, I was wrong and my previous comment a hyperbole. A big problem is npm, and not JavaScript.

My point about the staggering amount of dependencies still holds though.

I feel super uneasy developing Software with Angular, Vue or any framework using npm. The amount of dependencies these frameworks take is absolutely staggering. And just by looking at the dependency tree and thousands of packages in my node_modules folder, it is a disaster waiting to happen. You are basically one phishing attack on a poor open source developer away from getting compromised.

To me the entire JavaScript ecosystem is broken. And a typo in your “npm -i” is sufficient to open up yourself for a supply-chain attack. Could the same happen with NuGet or Maven? Sure!

But at least in these languages and environments I have a huge Standard Library and very few dependencies to take. It makes me feel much more in control.

Once you start with LINQ you basically see it everywhere. It makes you think different about structuring your code, which is a good thing. It makes you think about immutability and pure functions, leading to more robust code.

But it’s also a fine line, when to use it and when not to. While LINQ is easy to read and make sense of, it is far from being easy to debug. Especially on inexperienced teams I tend to limit my LINQ usage and try to write more “debuggable” code. But that’s my approach, I would love to hear other peoples thoughts on it.

For a lot of problems it’s a good idea to talk to customers and stakeholders, and make the complexity very transparent.

Maybe some of the edge cases only apply to 2% of the customers? Could these customers move to a standard process? And what’s the cost of implementing, testing, integrating and maintaining these customer-specific solutions?

This has actually been the best solution for me to reduce complexity in my software, by talking to customers and business analysts… and making the complexity very transparent by assigning figures to it.

This. Also DevExpress and Progress Telerik do not invest into their WinUI Controls at all, and that’s a sign they don’t buy into WinUI neither.

WinForms and WPF are currently the only viable frameworks for Line of Business application. I have yet to see a WinUI3 application in the wild.

I know, that I am just a single data point, but Scheme took the fun out of programming in my computer science studies. Of course I do understand, that it makes teaching lambda calculus obviously a lot easier and is a better vehicle for teaching theoretical computer science concepts, than say, Python.

But at the same time Scheme is limited to academia and has near zero practitioners outside academia. So the Scheme ecosystem is tiny compared to Python or Java.

Yes, you could argue, that "Computer Science" is not mere "Software Development" and academia shouldn't bow down to industry and shouldn't be a tool to provide "programmers". But again it's also important for motivation to apply the language, algorithms and concepts in other fields. Learning also has to do a lot with motivation and experimentation.

And this is a "hot take", but I always had the feeling back then, that courses are often bound to the professors curriculum and sometimes their books, so I am not surprised about resistance to changing the language.

That said, I was glad, when the Scheme lectures were over. Now I am a Software developer for more than a decade and have to admit, that learning Scheme didn't make me a better programmer at all. If I'd stayed in academia I might have a different opinion.

A decade in software development taught me: it always depends. It’s never a good idea to speak in absolutes.

Your development workflow depends on your product, on your team, their skills, on your organization and so on.

As with everything you need to carefully evaluate, if Trunk-based development is a good fit for your product, your team and your organizational structure. Sometimes it fits well, sometimes it’s not a good fit.

I think a lot of people dismiss gitflow and its feature-branched model as too complicated. Yes, it feels so slow, right?

But it gives inexperienced teams a very clear and documented workflow, especially so, if you need to support multiple versions of your product in the wild. It clearly dictates how to do bugfixes and hotfixes, that need to be done in multiple releases of your product.

Could you achieve the same with Trunk-based development? Maybe? Could an inexperienced team come up with it on their own? I don’t think so.

See, it always depends.

Microsoft is dogfooding Copilot in their dotnet/runtime [1] and dotnet/aspnetcore [2] repositories. This is the only time I have seen a company using its own AI Tools transparently. Yes, they label it an experiment, but I am pretty sure it’s mandated use within Microsoft.

I am an “AI skeptic”, so clearly I am biased here. What I am seeing in the repositories is, that Copilot hasn’t made any substantial contributions so far. The PRs, that went through? They often contain very, very detailed feedback, up to the point line by line replacements have been suggested.

The same engineers, that went up stage at “Microsoft Build 2025” to tell how amazing Copilot is and how it made them a 100x developer? They are not using Copilot in any of their PRs.

You said it’s a religion. I’d say it’s a cult. Whatever it is, outside the distortion bubble, this whole thing looks pretty bad to me.

[1] https://github.com/dotnet/runtime/pulls

[2] https://github.com/dotnet/aspnetcore/pulls

I have seen many actually.

Imagine having a huge amount of applications all using the same database, which is, like I said, often enough the main integration point in a company. The applications you are maintaining are written in, let’s say Java, C#, Python and C++. They are too important, too large and a rewrite is way too risky.

How would you start to get this under your control? By moving common logic in a shared C++ DLL probably? Rewrite all those applications at once, in a heroic effort? I for one take the pragmatic approach and extract common business logic shared between all them into a Stored Procedure.

The Stored Procedures are invoked by all applications, so instead of maintaining 10 implementations, I maintain 1. Suddenly you have a common data access path! The 1 implementation will be drowned in a shitload integration tests, because this is what really matters.

Of course, a Stored Procedure doesn’t prevent you from shooting yourself in the foot! But in my experience, it’s way harder to shoot yourself in the foot using a Stored Procedure, that you can inspect the Query Planner for… than hunting down Monster-Queries for weeks, generated by a LINQ provider.

As for the INSERT, UPDATE and DELETE: With SPs, you’ll have fine-grained control, which columns are updated instead of needing to expose all properties in your application code and praying for an ORM to not accidentally update “columns I don’t own”, because of some convention applied by the ORM.

If you are in the lucky position of owning the database and don’t have to maintain legacy applications, I see resistance to Stored Procedures. Then go ahead and build an API all applications are going to use.

But if you don’t own the database and need to maintain dozens of mission-critical applications, Stored Procedures are a tool worth knowing.

I am not going to dismiss your experience here. Stored Procedures can turn into wild monsters. Pair it with Triggers and you are in for chasing a noodle.

But it's also a reality, that relational databases often become the main integration point in companies. In those environments it’s hard (next to impossible) and dangerous to use something like ORMs.

Often enough I don't "own the tables" and I don't "own the columns" for lack of a better word. The DBA only gives me SELECT and EXECUTE permissions on the database. How am I going to work here without Stored Procedures?

And while this sounds weird, these limited permissions are to protect me from accidentally writing to wrong columns. Wrong columns that could impact systems, I didn't even know about. Is it possible to write to the same columns with a Stored Procedure? Of course! But it's not as dangerous as giving an application fat UPDATE permissions.

By using SQL Views I can build a data model upon these tables for reading the data, and build a more consumable data model. And you mentioned C#: I can use EF Core to query these Views with LINQ. Stored Procedures are used to store data to multiple tables in a "legacy database" within a transaction.

This could also be done with EF Core, but I need to explicitly log all changes to the data. How should this be done without a Stored Procedure or Triggers? CDC doesn't help a lot here.

To me it's a business problem, a communication problem and a technical problem. You would have to solve all for a unified graph to succeed. And that's super hard.

For the communication problem, you'll need to break the "sweet isolation within autonomous teams". You'll need someone to hop between the teams and analyze their data models. It's usually not enough to share a data schema. You'll need to actually sit down with humans and ask questions.

The technical side is by far the easiest one. Share a fat schema, like Microsoft does with Microsoft Graph, and dictate all of your teams to use it. Problem solved. Yes, this requires a lot of empathy and frustration tolerance, because in my experience all software developers (me included) are drama queens.

The technical side can only be solved by dictating and enforcing it. You need management buy-in and authority for this, if you don't have the authority and all teams are still free to roam... you can come up with the best solutions, it won't work.

The hardest part is the business-side. If you have highly optimized processes people have been trained on for 20+ years, it's usually not possible to change processes and associated terminology.

So... You need 100% buy-in from decision makers, that it's useful and the cost of this monumental work is going to pay off in a lifetime.

For all reasons mentioned in the article, I wouldn’t post such a question on Stackoverflow. It doesn’t fit. And I see their reasoning. Just raise an issue in the CoreWCF issue tracker. What’s the worst thing to happen?

The CoreWCF folks would be delighted to have a reproducible example, and they are best suited for answering the question. They have written CoreWCF after all! And if you don’t feel comfortable with raising issues? There’s also a Discussion feature on GitHub, where you can ask more free form questions.

And once you fixed or analyzed the issue with the CoreWCF team, you could write a blog post about it and share it with anyone having a similar issue.

That’s how I do these things.