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

151–160 of 239 posts

Re: The Stupid Programmer Manifesto

#151

Post by gunapologist99 »

quickthrower2 wrote: post #79

It is all reasonable stuff for most apps that don’t need scale EXCEPT writing files to disk as a database. Doing that for “blobby” stuff like profile pic is OK but for shared data that needs granular mutation I feel you will end up with a buggy, adhoc, ill specified half of postgres in your app.

If you write data to a temporary file and then rename that file to its final name, renaming is an atomic operation on a POSIX filesystem, so you will cleanly overwrite the original file. However, you then need to deal with the risk of lost writes if another process or thread is reading/writing at the same time (i.e., sequential writes with in-memory cache, or just architect so that only one writer at a time; of course, if the shape of the data fits SQL and you don't mind compiling C libraries into your app which might remove the ability to static compile, using pure SQLite in WAL mode might be a better approach since it handles multiple writers for you.)

Even with that risk, for certain types of apps, this can be a way to avoid a database which might need a separate process to backup/dump etc, the skills of a DBA-type of person in some environments, adding yet another database to an enterprise "approved" list, etc. This technique presents a nice, clean view of real data and allows backups of just the live data directory itself. On SSD, it's also much more performant than you might expect.

It's quite possible to make the author's approach work very well with nearly zero long-term maintenance and no external database dependencies, as long as you are careful to manage the expectations and requirements.

Re: The Stupid Programmer Manifesto

#153

Post by collyw »

deltarholamda wrote: post #81

I've had similar crises of faith every now and then. I never got into Docker, and every time I read somebody's K8s horror story I get hives. I begrudgingly learned enough about systemd so I wouldn't become a hermit, but I'm not happy about it. I still more or less prefer to do Web things without the SPA-like features. Some of this is because this is what I know, but some of it is because I'm too dumb to see the benef…

I feel the same, but docker is actually a net positive in my opinion. You can learn enough of it to be useful in a fairly short period of time, though it does throw up own set of problems that need debugging from time to time.

Re: The Stupid Programmer Manifesto

#154

Post by duhsuh90 »

madeofpalk wrote: post #19
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.

Skeptical of the person who is "not smart enough to figure out docker", yet is smart enough to know about building a "web application into a self contained statically linked binary executable file". I think they are smart enough, they just don't want to, or don't see the value in it (even if they've made an uninformed decision)

Many doctors watch videos at 1.5X speed or they can not take in the information. If its too slow their brain switches off. I find I have this problem too and i havent figured out docker either even though im a ninja at programming.

Re: The Stupid Programmer Manifesto

#155

Post by ang_cire »

Solvency wrote: post #128
ang_cire wrote: post #99

Earlier quoted context omitted.

Because of things like mass assignment or IDOR, or injection attacks, presumably. Handing data from the user (untrusted input) directly to the backend unchanged is going to in 99.9999999% of cases also mean it's unchecked. "I'm not smart enough to bother sanitizing my input, or to learn about stuff that's someone else's job like security" would fit right into this "manifesto".

You're taking about securing the data itself, which has nothing to do with its parent structure.

And in the manifesto the author says

> I’m not smart enough to figure out how to transform data between different layers of the system, so I just don’t. I use the same represetnation in the UI layer and the storage layer.

That has nothing to do with the data structure, is about how the data is being represented in the backend vs the frontend. It's explicitly about changing the data itself.

Stuff like url-encoding and escaping characters are examples of transforming data to be represented differently in the backend (where e.g. it's encoded or escaped) from the frontend (where it's displayed in "proper" formatting).

Re: The Stupid Programmer Manifesto

#156

Post by whstl »

908B64B197 wrote: post #136
vsareto wrote: post #47

Earlier quoted context omitted.

Well, they do what's right according to how they learned, which may only be a local 'right' and not a global 'right'. There's so many ways to put things together that you can make it work in a lot of different ways. It becomes more art than engineering or science. Then whether your peers accept whether it was the right thing is up to their preferences too. All that comes down to the large variety of training everyone…

> It becomes more art than engineering or science. The opposite. > All that comes down to the large variety of training everyone in the field gets, from university to youtube tutorials. A big problem is that a lot of the youtube/bootcamp ecosystem focusses on "teaching what they do at the FAANG" to lure people into thinking they could get a job there by enrolling/buying whatever training they are selling. And then th…

That's a great point. Good engineering, from a distance, can look awfully like bad engineering from the point of view of a Youtuber or Blogger focused on trends.

Re: The Stupid Programmer Manifesto

#158

Post by softfalcon »

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…

We've all been there. Things take much longer than expected. This is, as you've already stated, something we come to realize in our careers.

However, I would like to share a different angle, if I may. I don't think your speed is necessarily the problem. I think your time estimation skills might need some work.

It's easy for us to think things "should be simple". Unfortunately, the modern world of software is becoming more and more diverse and complex (a symptom of software "eating the world"). It's only natural in a world that has evolved from 8086's and terminals to interconnected-everything, multi-OS, multi-platform, multi-device magic is going to be orders of magnitude more difficult to build on at any reasonable scale of business. There are just so many small things that can go wrong!

I would gently suggest you stop being so hard on yourself and instead of beating yourself up for "being slow" just take each technology one at a time. Ultimately, the way to survive in this career is embracing change and staying sane while doing it. It's not easy, but it's the only way.

As for you being dumb, I would also like to say that it is clear you choose to deeply understand the topics you put in your head. Many folks "learn enough to get the job done" and very little more. It seems you have an appreciation for deep learning. This is not a bad thing, it is usually this trait over a long time that differentiates a truly senior engineer from an intermediate one. Your path may be slower, but it is probably more thorough and more informative in the long term. Keep in mind though, this breeds imposter syndrome in your mind. When you accept you still have lots to learn, it is easy to feel like you know nothing at all. I would suggest not letting this get to you. We all feel it, it is real, we're all just trying to do our best day-to-day.

Oh, and always 2x pad all your estimates at minimum, cause if we know anything about computing, it's that it always has hiccups.

Re: The Stupid Programmer Manifesto

#159

Post by robofanatic »

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…

There is a youtube video for that https://www.youtube.com/watch?v=y8OnoxKotPQ

Re: The Stupid Programmer Manifesto

#160

Post by kayodelycaon »

bedobi wrote: post #126
kayodelycaon wrote: post #121

Sigh. I hope this is satire. Or this person is only referring to their personal projects. Otherwise, I agree with their premise and suggest they find a different career. HTTP Verbs? You really can't get more basic. At least you could try to wrap your brain around the idea that GET reads and POST writes. Not using SQL? Okay. You're spending a lot of time and effort hand-rolling your own shitty database. The combinatio…

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

Post reply on HN