Hacker News Reader

Comment by projectant | Hacker News Reader

I'm concerned about the lack of type annotations. What about XSS prevention? Maintainability? An API? How are people supposed to use this code in future projects? Your variable names don't conform to Code Complete. This code smells funny. Haven't you read clean code? And I don't think it's general enough. What if people want to add columns, but preserve formulas? What made you think you shouldn't use React for this? At least Vue, come on.

ah, if only we could all code just what we needed, instead of over-engineering solutions to problems we wished we had

View on HN

This seems to be code golf, which would answer most of these questions I think. Maybe I'm missing some sarcasm in your comment, it's early!

I'll take his comment as a joking sarcasm anyway.

Yes! It's confusing seeing as it is the top comment but clearly everybody gets it and appreciated the joke. It's perhaps just too chillingly accurate ;).

ha ha, you're absolutely right on each and every point, but for your information: you can add columns by adding more letters after "ABCD"

All of the things you mentioned are best practices when building something that you want other people to use in production. The author was trying to build this with the absolute minimum amount of code as an exercise so I don't think any of your comments here apply.

I think the last line makes it relatively clear that the preceding statements were meant as a joke.

Well, this spreadsheet as it is now isn't very much useful. In fact it is annoying at best. Only programmers will find it amusing and precisely because of how small the code is. No one is actually going to use it ever.

good thing we made it just for fun, then

I wasn't criticizing your work, but the commenter above, which sounded like it would be great if all software was like that.

XSS prevention, maintainability, code reuse, good variable names, good-smelling code, readability, and using popular libraries are not "over-engineering". They are 95% of what makes someone a good employee instead of a shitty one.

With modern languages and tooling, you can have the benefits of most of these things at little-to-no additional cost. If any of these require something complicated and "over-engineered", I'd instead describe it as "bad engineering".

No.

Rule one is making code that works correctly and quickly, in a short about of time. This is 100% of the job.

If you think that "maintainability" and "readability" and "popular" libraries, and "code reuse" and "good variable names" and code that "smells good" to you, help someone do that, then great: That's an argument we can have just by pointing to anyone who gets rule one without those things.

However.

There's another kind of person - and there's a lot of them - who thinks those things are important by themselves, and that putting those things ahead of what I think are rule one is ever acceptable.

The number of times I've heard some "experienced" programmer say with all earnestness that we should ask for another 1/4 million dollars of tin so that he can use his "clean" (but slow) algorithm makes me wary of anyone who uses those words you just used in seriousness.

That's the person the parent comment is mocking.

> There's another kind of person - and there's a lot of them - who thinks those things are important by themselves, and that putting those things ahead of what I think are rule one is ever acceptable.

I think you totally understood my humor. Thanks!

I saw a good blog in 2011 about how it is a waste of time to overbuild things since mostly you are only ever going to use that code for the specific purpose you are writing it, and you'll likely never need to generalize and you'll probably chuck it out anyway and start from scratch.

Obviously there are a bunch of caveats to that and it's not always true that's the case but I think it's a very useful counterpoint to the profession's current best-practice obsession. If you keep it in mind, alongside all the best practices, and you make a choice about approach in any given situation based on appropriateness, rather than just robotically applying best practices or giving into that common Engineer's temptation to overbuild, this counterpoint can help you build quickly just what's needed, which is effective, exactly like you said.

No problem. And I agree almost completely:

I don't think those caveats are obvious to a junior (or otherwise inexperienced) developer. Maybe some of them are obvious, but I don't think anyone runs into these enough daily that programming by dogma actually helps.

And yet I do see value if there are rules! Why should we think about having "good variable names" or not if most of the time "good variable names" don't cause much harm, and most of the time not having them does?

It's just that I don't think this is a real problem; I don't believe anyone actually makes that choice.

I think if something doesn't have "good variable names" (as an example), then it's possible someone was programming who couldn't think of good ones (to which the rule wouldn't help anyway), and it's possible that these are good variable names, and that it's our opinion that is wrong (perhaps because we don't yet understand what we're looking at). NB) I'm not saying both are equally likely.

To put it another way, how can one recommend programming by brute force, "as long as you've got "readability" and "popular" libraries, and "code reuse" and "good variable names" and so on... What can we possibly add to that list that will be even a good substitute for a few decades of experience successfully delivering software?

A good employee making shitty products :).

I mean, security and maintainability is important, but the most secure and maintainable code is always the code that didn't get written in the first place, which makes not writing unnecessary code a no.1. way of making the result not suck.

In that case I am writing millions of lines of secure code every day. Just the other day I didn't release a wordprocessor, making it 100% secure.

Yes! So am I! It's a shame that the airlines refuse to use my perfectly secure avionics code I didn't release.

</comments>

Reply on news.ycombinator.com