Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Stupid Programmer Manifesto

hasen.substack.com

Post reply on HN
Print view View original

181–190 of 239 posts

Re: The Stupid Programmer Manifesto

#181

Post by denton-scratch »

DaiPlusPlus wrote: post #167
hsn915 wrote: post #132

Earlier quoted context omitted.

But, _what_ is the point of using a different layout/structure for storage vs the UI layer? Remember I'm a 0.5x developer. If I have to write code to transform data for every kind of entity/object I need to store and have a UI to view and edit, that's way too much. I'm already very slow. No need to slow me down further by telling me I have to write so much extra code that does no useful work.

> the point of using a different layout/structure for storage vs the UI layer? By way of example, I'll point to the classic example of a New User form UI: that UI will need 2 password inputs (one for the password, the other for the "confirm password") - but your User object/schema/DB-table won't have two separate string password fields - it'll have a single binary/byte[] salted-password-hash field, and you certainly…

> the other for the "confirm password"

That always pisses me off. I can copy/paste the password from the first field into the second. Hell, I use a password manager; I pasted into the first field, so I paste into the second.

It's just a check to make sure they match. But my passwords are complicated enough that I can't remember them long enough to type the characters in the first time; I literally have to copy/paste.

So this anti-pattern assumes that users are using some memorable password like their mother's maiden name, probably for all the services they use. Anyone using sane password practices is penalized with stupid friction.

[Edit] I have an even bigger gripe about asking me to enter my email address twice. If you really aen't sure I entered it correctly, send me an email asking me to confirm.

Re: The Stupid Programmer Manifesto

#182

Post by hsn915 »

kayodelycaon wrote: post #102
javajosh wrote: post #87

Earlier quoted context omitted.

>I have come to dislike this growing trend that celebrates mediocrity and failure. That's not what this is. It's a sarcastic critique of techniques the author thinks don't justify their weight. It's a comment on the cognitive load required by the plethora of complex "best practices" that often goes without questioning. The multi-repo microservices thing really hit home for me. I only recently had to deal with this, a…

The problem is people aren't sure this is sarcastic. I've heard people say shit like this. It reads very much like "I don't like learning new things" rants I see from time to time. They've found one way they like doing things and stopped. They don't know how difficult any of the stuff they are talking about is. They just know it's something they don't want to learn.

I don't like learning new things.

Unironically.

I like learning good/useful/effective things.

Not "new" things.

Most "new" things are less capable variations of existing things that are better and more mature.

Re: The Stupid Programmer Manifesto

#183

Post by fernvenue »

CM30 wrote: post #35

Honestly, the truly 'smart' programmer isn't someone who does or doesn't use a bunch of techniques or best practices, it's the one who can look at the situation and do what's right for that particular project/job. Most of the things in this post could be the right answer if the project is a weekend side project that's going to get a few hundred views a month, or a website for a small business. Bob's Restaurant doesn'…

I think it depends on a situation where no problems occur. Often, once a problem arises, we (at least me) begin to reflect on why we didn't follow best practices initially.

Re: The Stupid Programmer Manifesto

#184

Post by 908B64B197 »

Cthulhu_ wrote: post #106
ttctciyf wrote: post #98

Earlier quoted context omitted.

Yeah, I read this post as a dig at "cargo cult" programmers who read up on google-scale programming and best practice and unthinkingly apply those constructs to their own Bob's-Restaurant-scale task at hand where they are often at best an unneeded time and complexity overhead.

I've worked in a number of projects where they decided to move to microservices for reasons they wish they had, while not fully understanding microservices or applying basic litmus tests to where to split off services. So we ended up with great puzzles like how to link an order service with an inventory service to check if there's enough inventory to fulfill an order, all through a central event bus. Then of course t…

> I've worked in a number of projects where they decided to move to microservices for reasons they wish they had

I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better. Basically, use the current job as a way to train on the stack the company you really want to work for is using.

If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL there's no incentive to help the company succeed. Especially with non-technical management, the best thing to do for ICs is often to aggressively rewrite (in the language that's trendy right now and that better companies use) and get promoted by showing off a significant output. Then jump to a better company having spent a year training on their stack at the previous company's expenses.

Re: The Stupid Programmer Manifesto

#185

Post by epups »

908B64B197 wrote: post #184
Cthulhu_ wrote: post #106

Earlier quoted context omitted.

I've worked in a number of projects where they decided to move to microservices for reasons they wish they had, while not fully understanding microservices or applying basic litmus tests to where to split off services. So we ended up with great puzzles like how to link an order service with an inventory service to check if there's enough inventory to fulfill an order, all through a central event bus. Then of course t…

> I've worked in a number of projects where they decided to move to microservices for reasons they wish they had I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better. Basically, use the current job as a way to train on the stack the company you really want to work for is using. If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL…

This is a good point. The other side of the coin is that by not moving to a modern day stack, the company slowly finds it harder and harder to attract staff to maintain it. So, keeping up with trends is not just good for the ICs.

Re: The Stupid Programmer Manifesto

#186

Post by yurishimo »

anthony_d wrote: post #177
angarg12 wrote: post #173

Earlier quoted context omitted.

OP makes the same mistake that those chaps who use Kubernetes to run an app with 10 lines of code: thinking that there is one right solution for every kind of problem. OP's approach might work for a personal project or a small company, but when you need to work in a large and complex system you start to appreciate the beauty of tools like Docker. It's cool to question cargo cult, but don't throw the baby with the bat…

I work at a very large company with very complicated systems. Fighting unnecessary complexity at every opportunity is the only way to keep things near comprehensible. A lot of the articles rules are even more important in complex environments.

Ive experienced this at work as well, even at a more modestly sized company.

You should always be chasing the simplest solution for your problem because no matter how smart you are today and how much you understand the problem and the abstractions, a year or two from now you’ll be a different person.

You might have new team members, or fewer, new management, marketing goals etc etc etc. Complexity is inherently difficult to change. My chasing simplicity, you are optimizing for potential change.

Re: The Stupid Programmer Manifesto

#187

Post by munro »

I feel like all of these could easily be flipped

>> I’m not smart enough to figure out how to manage multiple repositories with shared code, so I put all my code in one repository.

> I'm not smart enough to manage a monorepo, so I put all my projects in separate repositories.

There's no reasoning behind the opinions other than "bc dumb".

Re: The Stupid Programmer Manifesto

#188

Post by yurishimo »

collyw wrote: post #148
Supermancho wrote: post #131

Earlier quoted context omitted.

Unless there's a compelling reason...like a use case for caching (your server or an intermediate) or high volume (POSTs are larger requests), POST for everything is a good default.

Debugging is easier with GET requests, where you can see what is being sent to the server. It's not a huge win, but it's better than POST for everything in my experience.

What do you mean? You can inspect POST request payloads in browser devtools just as easily as GET requests.

Re: The Stupid Programmer Manifesto

#189

Post by DaiPlusPlus »

denton-scratch wrote: post #181
DaiPlusPlus wrote: post #167

Earlier quoted context omitted.

> the point of using a different layout/structure for storage vs the UI layer? By way of example, I'll point to the classic example of a New User form UI: that UI will need 2 password inputs (one for the password, the other for the "confirm password") - but your User object/schema/DB-table won't have two separate string password fields - it'll have a single binary/byte[] salted-password-hash field, and you certainly…

> the other for the "confirm password" That always pisses me off. I can copy/paste the password from the first field into the second. Hell, I use a password manager; I pasted into the first field, so I paste into the second. It's just a check to make sure they match. But my passwords are complicated enough that I can't remember them long enough to type the characters in the first time; I literally have to copy/paste.…

> So this anti-pattern assumes that users are using some memorable password like their mother's maiden name, probably for all the services they use. Anyone using sane password practices is penalized with stupid friction.

I think you're really, really underestimating how easy it is to make a typo when entering a password into a masked password box, hence the 2 fields.

Also, web-browsers don't let you copy-and-paste the password from one box into another - so I don't know how you're doing that: https://security.stackexchange.com/questions/149326/why-cant...

-----

I appreciate that you're just-as-annoyed with web-form tropes, cliches and irritations as I am - and when I'm building a system or UI for savvy people then sure, I'll do things like skipping the registration form entirely and just use OIDC federation or PassKeys or whatever the current-security-fad-of-the-month is - but my day-job requires me to write software for ...uh... "normal people" and part of that means having to weigh-up the support-costs of users who want a predictable and easy-to-understand that isn't too different from what they already know - and those normal-people are what pays my bills.

Re: The Stupid Programmer Manifesto

#190

Post by User23 »

kayodelycaon wrote: post #160
bedobi wrote: post #126

Earlier quoted context omitted.

> HTTP Verbs? You really can't get more basic. Every REST API codebase I've ever worked on would like a word. There's TONS of subtleties that determine whether you should be creating a GET, POST, PUT or PATCH for many different use cases. And this isn't even taking into account the hundreds and hundreds, maybe thousands of endpoints I've come across that were obviously wrong, but some Senior or even Principal dev had…

I didn't say they needed to use REST. REST is a huge mess. You can simplify it to GET = doesn't change stuff, POST = changes stuff. Basic HTML form tag stuff. For the few things in-between like self-expiring links or counters recording how many times a thing was viewed can get tossed into GET because the data you're retrieving isn't being modified. (Search can be POST if you don't like query parameters in your urls.)

GET: get a thing from a place. PUT: put a thing in a place. POST: create a new place, put a thing there, and tell me its location. DELETE: delete the contents of an existing place.

The biggest subtlety I can think of is deciding whether PUT to a place that doesn't exist is valid, and whether DELETE of a place should delete just the object or also the place too, if PUT is only valid for existing places. How to handle that subtlety is application dependent. Personally I like to architect RESTful services such that POST isn't necessary since it's hard to make it idempotent, but sometimes POST is the most comprehensible interface.

Also, I wouldn't bother using REST at all unless I was going to make everything fully discoverable via hypertext[1]. However that's not to say there aren't soundly designed non-RESTful ways to use the HTTP application protocol.

[1] https://en.wikipedia.org/wiki/HATEOAS

Post reply on HN