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

221–230 of 239 posts

Re: The Stupid Programmer Manifesto

#221

Post by mcv »

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

Maybe, instead of having two password fields, they should have a single password field that you cannot type in, but can only paste in, forcing everybody to use a password vault.

Re: The Stupid Programmer Manifesto

#222

Post by mcv »

hsn915 wrote: post #140
mcv wrote: post #3

I can't tell if this is an honest call to keep things simple, or if it's meant to ridicule that idea. Because I strongly, deeply agree with some of these points, and am absolutely horrified by some of the others.

OP here. I was working on a feature for a webapp that I thought should be doable in a day, but I spent roughly a week on it. When I was done with it, I looked back and thought: wait, why did this take me the whole week? I couldn't come up with a satisfying answer. So I just decided to accept that I'm not that productive. Maybe there are things I can do to improve my speed of implementing features, but for the time be…

Wait, so you made your own database? That's the thing I'm not smart enough for. I'd rather just use an existing database.

Re: The Stupid Programmer Manifesto

#223

Post by memefrog »

nonbirithm wrote: post #56
memefrog wrote: post #15

This post is the programmer equivalent of teenage girls posting photos of themselves captioned with "I'm so ugly" to farm praise from their friends. I have come to dislike this growing trend that celebrates mediocrity and failure. Posting proudly that you are stupid, terrible and incompetent seems to result in applause and high praise. Why? Why is that a good thing? I hope this was intended to be a parody.

It may be similar to the idea that if you are deemed to have imposter syndrome, then you cannot be an actual imposter, so if people perceive you to have imposter syndrome then it's in some ways a good thing. It's impossible to know if the author has imposter syndrome or not without some way of measuring his competence. However, I think "imposter" has become a loaded term as a result of the syndrome it's associated wi…

"Imposter syndrome" is one of those terms that has lost most of its value now that it's become widely known. I don't think it has any value when it's self-diagnosed. People seem to think that being in a new job or a new environment where they are the junior automatically means they have imposter syndrome. No, you probably are junior and do need to learn new things every day. You probably do have a lot to learn before you are useful. It's likely that you are out of your depth. That's not imposter syndrome. Imposter syndrome is when you are at the top of your field but you have the irrational belief that you're actually a total fraud, an imposter, someone that doesn't deserve to be there. Yet how many threads have I seen where someone with 10 years experience talks about how they had imposter syndrome a few years earlier?

Re: The Stupid Programmer Manifesto

#224

Post by [deleted] »

hsn915 wrote: post #107
__MatrixMan__ wrote: post #50

Earlier quoted context omitted.

> Good luck getting that to run in different environments because static or not, nearly every executable has dependencies. Maybe he's using nix to parameterize his builds with the system architecture, but left it out because it didn't fit his idea for a blog post.

No. I'm too stupid to even understand what that means.

[deleted]

Re: The Stupid Programmer Manifesto

#225

Post by hsn915 »

bitblender wrote: post #195
hsn915 wrote: post #176

Earlier quoted context omitted.

You're citing an exception as if it was the rule. But even in this case, I don't have two representations of the same object. Rather I have two different object: Account (persisted) SignupRequest (not persisted) The SignupRequest is used to create the Account The signup form on the UI is about editing the SignupRequest object. This object will be sent from the UI code to the backend as-is. The backend code will use i…

In this case SignupRequest is your contract representation, Account is your storage representation, and the "backend code path" is the transformer/napping layer. >I don't have two representations of the same object. Rather I have two different object Exactly! Your api contract and your storage are ALWAYS two different objects, because they serve two different concerns. Sometimes by coincidence they can share the same…

> Exactly! Your api contract and your storage are ALWAYS two different objects

Not really. I have request objects for everything. "Search" is a request object. List pagination is a request object.

Every function exposed through the RPC API takes a request object and returns a response object.

The response object is often just a collection of objects straight from "the database".

A response to a paginated list request will contain a list of objects straight from the database, in addition to some metadata about the pagination (names: current page number, total page count).

The cruicial part is there's no "transformation" of data as it goes out from the database into the UI. There's some aggregation and grouping (an outer object that contains multiple objects), but that's about it.

Again though there's a subtlty: some transformations do occur, but they don't occur on the path from the storage to the UI. Instead, everytime I store a complex object, I also derive a "simple" version of the object and store it too.

When you request a list of objects, you get the "simple" version, and the UI displays them in summary format. When the user clicks one of them items on the list to see more details about it, the backend sends the "full" object.

Notice the underlying principle: the UI flow dictates how the storage layer stores objects.

This is the anti-thesis to the common wisdom, where the storage layer does not care about the UI, and it's the job of the intermediate layer to transform data for the needs of the UI.

Re: The Stupid Programmer Manifesto

#226

Post by xupybd »

lylejantzi3rd wrote: post #20
xupybd wrote: post #2

How can you store program state on disk like that? You'd need serialization and deserialization. A DB might be easier.

> How can you store program state on disk like that? You'd need serialization and deserialization. You need serialization and deserialization when interacting with a DB, too. You're trusting a library to do most of that for you. This is the difference between a junior engineer and a senior engineer. As a junior engineer, you don't trust your own judgement and use a library. As a senior engineer, you don't trust the l…

Yeah, this is true but I tend to hand craft my persistence to a database. I'm not sure how using files would be any easier. I'd have to manage a bunch of files on top of what I'm already doing.

Re: The Stupid Programmer Manifesto

#227

Post by winrid »

CM30 wrote: post #103
Solvency wrote: post #97

Earlier quoted context omitted.

You'd hit up GoDaddy for hosting and FTP your webpage files to it. And it'd work just as well as other website.

Yeah, this would be the way. This hypothetical restaurant would probably only need the following pages: - Home page - About Us - Menu - [Maybe 1 or 2 info pages] - A contact page (with or without a form) That's something that can be easily done with static HTML and CSS, and hosted on just about any random shared hosting service you can imagine. Assuming it doesn't become a major viral hit, it'd probably use a couple…

Godaddy's free website builder would do that fine, too.

Re: The Stupid Programmer Manifesto

#228

Post by hsn915 »

mcv wrote: post #222
hsn915 wrote: post #140

Earlier quoted context omitted.

OP here. I was working on a feature for a webapp that I thought should be doable in a day, but I spent roughly a week on it. When I was done with it, I looked back and thought: wait, why did this take me the whole week? I couldn't come up with a satisfying answer. So I just decided to accept that I'm not that productive. Maybe there are things I can do to improve my speed of implementing features, but for the time be…

Wait, so you made your own database? That's the thing I'm not smart enough for. I'd rather just use an existing database.

I mean, not really. The hard work was done by benbjohnson who is now working on https://litestream.io/ and https://fly.io/

He's the one who wrote BoltDB https://github.com/boltdb/bolt

I just put a relatively thin layer on top of it.

Now, to address your point more directly: I'm too stupid to figure out configuration, but not too stupid to figure out code. Code gets compiled and type checked. You can have tests, etc. Tractability for code is much higher than configuration.

With configuration, you have to be really smart and keep many moving parts in your head.

With code, you can be a bit dumb and lean heavily on the tooling.

Re: The Stupid Programmer Manifesto

#229

Post by collyw »

beezlewax wrote: post #194
collyw wrote: post #144

Earlier quoted context omitted.

We had a dev in my last work pushing to microservice everything (small company, only a few developers). I could tell that it was going to cause more pain than it was going to solve. Plus, every service that you add makes setting up a development machine even more difficult.

Not to mention testing all of this. Its an absolute nightmare.

Replacing function calls with network calls is only going to make things more difficult.

Re: The Stupid Programmer Manifesto

#230

Post by collyw »

yurishimo wrote: post #188
collyw wrote: post #148

Earlier quoted context omitted.

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.

It's far faster when you can look at the URL and see the parameters. I have worked on systems with both and I didn't like everything as a POST. If you want to get a page with list of objects with a filter it's a lot easier to copy paste a URL than it is to fart about in developer tools and try top recreate the POST request.
Post reply on HN