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.

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!

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.

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.

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.

You can save, load and export your diagrams. Nothing is stored on a server, and localstorage is used to persist the state between page refreshes.

Comments URL: https://news.ycombinator.com/item?id=46654283

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46650753

Points: 4

# Comments: 0

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.

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.

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.

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.

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.

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.

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.

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.

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.