Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

> does not reinvent things which are not necessary to reinvent.

This is one of those "eye of the beholder" things.

If I had a quarter for every time I've heard "That's a solved problem," with a reference to a dependency, somewhere, I'd be a rich man.

I tend to really avoid external (not written by me) dependencies, because I have had many problems with other people's code. Fixing someone else's badly written open-source code usually takes longer than just writing the small part of their library that I need, and it doesn't involve having to argue with them, or have my PR rejected, because I have "too many comments."

I know that's not a popular stance, around here, but it works for me. I use a ton of dependencies, in my work, but I wrote most of them.

View on HN

This is our stance too.

Even within the "batteries included" aspects of the .NET6 framework, we insist on doing certain things our way.

Some of the biggest examples being AspNetCore logging and the JSON-style configuration abstractions. We completely rip this out and do it in code-time our way. I cannot account for the exact number of hours we wasted trying to do [x] the 'official' way only to be burned at deployment & framework upgrade time. It took at least 100 hours just to realize json-based runtime config is definitely not for us.

Separately, it took me fewer than 30 minutes to write a dumbass static logger that fills a sqlite database with entries and have it wired up throughout the application. I don't think you could even read & understand that AspNetCore logging article in 30 minutes, much less have functional code in place that you can hang your hat on for years to come.

If not reinventing the wheel is about saving time, then perhaps we need to iterate the aphorism. Maybe we flip it around: Only reuse other people's code when it's for something that you don't really care about or doesn't frustrate your project's long-term ambitions.

Reinventing the wheel can also lead to difficult-to-find bugs that explode years down the road. Yeah, you could reimplement the parts of zlib you need in a couple hours, but just use zlib, even if it's a core part of your functionality.

However, as an industry we don't have a great way to know what is or isn't reliable. I've started publishing component datasheets with my utility libraries because that conveys the sort of commoditization I think we should strive for, but they haven't been very useful so far.

> However, as an industry we don't have a great way to know what is or isn't reliable.

That's the rub.

Your zlib example is one of the "Platonic Ideal of Quality Open Source" libraries. Using that is a no-brainer.

Any suggestion of rating/licensing/qualifying open-source projects, is met with ... resistance ...

It's still a full plate of old good C spaghetti https://github.com/madler/zlib/commit/eff308af425b67093bab25...

> However, as an industry we don't have a great way to know what is or isn't reliable.

I'm not sure it matters. You can assume it will be as reliable as your own buggy code that you wrote yourself. The more important question is how maintainable or replaceable is it. Once you include a dependency it becomes your code to maintain, so it had better be something that you're comfortable jumping in and getting your hands dirty with if need be.

> I tend to really avoid external (not written by me) dependencies, because I have had many problems with other people's code.

Exactly, I'd rather write 1500 lines of brand new C code to parse Wavefront OBJ files than import 300000 lines of Assimp [1].

OTOH, I'd rather import 2000 lines of mikktspace[2] code than attempt to reinvent (or even understand) that black magic.

[1] https://github.com/assimp/assimp [2] http://www.mikktspace.com/

That's fine if nobody else has to maintain your code.

If they do it's difficult to see how your solutions to solved problems aren't going to be significantly more problematic and risky than established libraries.

Not really. I'm pretty good at what I do. Feel free to see for yourself: https://github.com/ChrisMarshallNY#browse-away

Most of those repos are dogfood.

And that is all good if the developer is qualified and has time to review your work.

Far easier to use something that 1000's of others are using as well. Far more likely for edge case bugs to surface.

That said, I have to agree that it can be painful trying to get one of those edge case bugs resolved if you are the only one being impacted. In this case I may be worth just implementing your own functionality and swallowing the future support. But I think it's got to be a backup plan, not your first response.

The real problem is that most developers don't have the experience or knowledge to go beyond accepting the "use xyz library" suggestion on Stack Overflow on face value, not having the ability to review xyz library for suitability. We end up with lots of code that is just collections of dependencies where only a very small % of functionality is used and no resources are put into ensuring that using the dependency is not introducing more problems than they solve.

> Far easier to use something that 1000's of others are using as well. Far more likely for edge case bugs to surface.

Dunno, I feel this tends to drive a lot of complexity. A lot of canned solution are comically over-engineered and break fairly frequently (especially in the cloud-adjacent space for some reason). Often the code needed to integrate such a library and make it do what you need it to do may exceed the code of just doing it yourself in the first place.

What happened with Log4j also should be a lesson in why adopting needlessly complex standard solutions to problems that don't really need them is deeply problematic. Most of its users would probably have been served fairly well with a thin wrapper for sysout, possibly with a json-serializer.

> And that is all good if the developer is qualified and has time to review your work.

That's me. I'm the person that most often needs to go back into my code, six months later. I write code that I want to use, and that I want to see, months afterwards. I actually don't give a damn if I never get a single star on my repos. In fact, the fewer people that use it, the better. I still write every library as if it will be used by first responders, as I have pretty high standards.

I'm also insane about testing. If you look at those repos, you'll see that the testing code (either unit, or harness), far outweighs the code under test. Most of my test harnesses are App Store-ready full-fat applications, with localization, and documentation.

But I am not reinventing Facebook. I write end-user native apps for Apple systems. I don't have the same needs as someone writing a massive social media server.

Like I said, I do what I do, and it works for me. Your mileage may vary.

What you are saying absolutely makes sense to me for domains like device drivers.

I think it becomes a lot more questionable when your coworker wants to write their own JSON parser or HTTP server for use on a commodity x86 linux box. It’s an incredible waste of resources and a major security hazard too boot.

I wrote JSON parser and http client for commodity platform, and they are 100 times safer than everything else, partly because they aren't overengineered beyond all reason.

I don’t doubt your abilities but I personally will always go with the choice that bounds the maximum risk to myself and the company every time

Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way and nobody else can understand it once he left".

Clever code that reimplements common packages just because one person thinks it's better for their particular use case might seem like a flex when you write it, but it's a pain in the ass for everyone after you... sigh.

Good programmers know when to rewrite and when not from experience.

> Clever code that reimplements common packages

Common packages are typically not rewritten by good programmers.

Well, it's kind of too bad, that everyone seems to have such terrible confidence in their own abilities.

There's a lot of things that I'm not good at, and one thing that experience has taught me, is to own that.

But there's also a fair bit of stuff that I'm really quite good at; above average, even.

If I write something, it tends to work pretty well. If someone else does a better job than me, I'm happy to use their stuff, but I have higher standards than "Ooh, shiny!". I won't use just anything, and "Everyone else uses it!" is not really the most heavily-weighted coefficient in my calculation.

I invite people to see for themselves[0]. I have an enormous library of work out there. I don't give a damn whether or not anyone else wants to use it. I am my own best customer. I write code that I want to use, and I use that code. I have extremely high standards, and I insist that my work meet my standards.

I find it fascinating that folks are happy to cast aspersions on me and my work, without checking for themselves.

[0] https://github.com/ChrisMarshallNY#browse-away

> Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way and nobody else can understand it once he left".

I’d be willing to bet there’s more to the story in nearly every case. The non-standard way is often a deliberate choice to attempt to optimize for output, given unpredictable and unrealistic deadlines.

Then it proves futile when, for instance, the goalposts are moved again, and the last 25% of the implementation has to get rushed through. That’s when it turns into a pile of shit, and that’s when the person decides to leave. But not because of the deadline, but because of the incessant complaining, doubting, and negativity toward this developer, who got praise elsewhere for actually innovating. That’s why you hired him after all.

Nobody else apparently stepped up to help deal with the situation before it became a problem, hence the victimization. Companies like that are going to have a culture of finger-pointing and blame-throwing. Never taking responsibility for a situation they created. Problem-solvers need not apply.

This is how industries, not teams, fail. Good programmers know when to quit the rat race. Or they know how to choose companies that follow the golden rule. Take care of your people and they will take care of you.

But if someone is actually doing it to “flex”, they’re clearly not that experienced, in which case it’s also the company’s fault for giving them that much technical authority.

> I’d be willing to bet there’s more to the story in nearly every case. The non-standard way is often a deliberate choice to attempt to optimize for output, given unpredictable and unrealistic deadlines.

Yeah... I hit this... A lot, in the past couple of years. "just get it out, we'll polish it later". It was... primarily me in dev (I was doing about 90% of the app code), and there was never enough time to catch up. I've moved on, and there's now ~3 people, and they've been given more time and ability to reset schedules and... now it's all "why was this done so poorly? this is garbage", etc. I've pointed to my many messages asking for things to slow down, schedule more time, etc. Always a "later", and now that the personnel have changed, and there's "more time" for everything... most of what I did looks bad. I was the only one writing tests - left them with 500+ tests, some documentation and action/decision log docs - but no one looks at it. "This is bad". Well... sure, but it's tested, and you now can refactor, vs rebuilding from scratch (which... I'd lobbied to do 2 years earlier, before building on top of the very shaky MVP).

Reply on news.ycombinator.com