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.

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

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/

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).

While those are all good guidelines (though I'm not too sure about 6) a 'master' programmer should probably know when to break each of those rules.

In the end programming is about telling a computer what it ought to do. Making this process as easy as possible is the sign of a good programmer, but there's no reason the process has to be limited to writing code, so talking about what code makes a good programmer seems reductive.

Also in this view 6 is usually a mistake as it makes it harder to communicate, not easier. That said some things don't make sense, and therefore probably shouldn't look like they make sense either.

One of the aspects of mastery (that I've observed in others) is being able to say yes to 99% of requests but knowing how to steer projects away from that one feature that will cause complexity to explode without delivering commensurate value.

5 and 6 are super hard decisions. You never really know what your code will be used for in the future, especially not if you make libraries.

I try really hard to do this and over the years I've found myself more than once caught out by something that I wished I had foreseen but did not and, conversely, I have spent a lot of time preparing code for changes which seemed to be likely to happen but that never did.

This is a really good point. Engineers are constantly trying to predict the future, but ability to do so often does not depend on engineering skills at all. Often it is completely out of your control.

Instead of trying to make code "extendable" I found that it is much better to make code "disposable".

Do not hope you'll make the right prediction. Expect to be wrong and be able to recover fast.

Knowledge of the domain and general experience with similar domains helps. My horse sense about what's likely to change has improved with time. As far as #6, you don't want to outright limit change because the future surprises, but use a YAGNI-ish view of unlikely changes to keep the system simpler. In other words, you don't make it hard to change, you just don't spend complexity on things unlikely to change. You only spend abstraction-related complexity on things likely to change.

> which are not likely to happen in the future.

Making that determination is something you really only get good at with the experience of making the wrong determination too many times.

> 4. Readable by programmers who'll work with that code in the future. That could be juniors or seniors, that depends on a particular company and project.

Underrated. Layers of unnecessary abstractions or clever solutions (e.g. complex types in python when simple would do) is a mark of a junior engineer.

"Rewrite all the things in X" is how you get 1 year of experience 10 times, instead of 10 years of experience. It's also how your company burns through tons of money for little substantial result.

Are we talking about industry programming? A good programmer knows how to get in and out, and retire early, and spend the rest of their days working on projects that fulfill their needs

Very nice summary here and I agree 100%.

> Uses commonly accepted approaches, libraries, style

I would argue NOT to do this if you're writing Java. Java paradigms are awful, lead to way too many layers of abstraction, and code that is impossible to debug because your stack traces are just 30 calls of ".invoke()".

> Readable by programmers who'll work with that code in the future.

And yet Perl became popular.

Java was the language of choice when I was at university. The way they described it to us, was that everything about it was designed with teamwork (and large teams) in mind. I don't know how well it really did that even by the standards of the era of its introduction, but it has the air of plausibility.

Certainly, I expect anyone who is used to that style to prefer to encounter and work with Java written in that style over Java written in the style of C.

> And yet Perl became popular.

As I recall, the joke being that it was a "write only" language.

> As I recall, the joke being that it was a "write only" language.

Yeah, which is why I question how it go so popular.

"Write only" means nobody works with it once it's been written ;)