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

141–150 of 239 posts

Re: The Stupid Programmer Manifesto

#141

Post by JohnFen »

efields wrote: post #108
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'…

That last point is key. I’m a fan of SaaS solutions but I also wonder if more organizations could unlock more value by just having a 1x programmer (with well defined _objectives_) on staff.

> I also wonder if more organizations could unlock more value by just having a 1x programmer

They probably already have such programmers. Actual 10x programmers are exceptionally rare. Having an entire team of them is extremely unlikely.

Re: The Stupid Programmer Manifesto

#143

Post by 908B64B197 »

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…

> Not using SQL? Okay. You're spending a lot of time and effort hand-rolling your own shitty database.

I've seen this before.

It crashed and corrupted most files because the author didn't understand how file IO really worked (he also created a ramdisk thinking it would be faster).

Fortunately, someone took a memory dump of the process some times before and most data was recovered.

Re: The Stupid Programmer Manifesto

#144

Post by collyw »

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…

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.

Re: The Stupid Programmer Manifesto

#145

Post by collyw »

Parmenidea wrote: post #90
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'…

How would you host the Bob’s Restaurant website?

Facebook seems to be the ultimate in simplicity for small restaurants. Has a number of advantages, like built in chat, picture hosting and a feed of posts.

Re: The Stupid Programmer Manifesto

#146

Post by stevemethiew »

collyw wrote: post #145
Parmenidea wrote: post #90

Earlier quoted context omitted.

How would you host the Bob’s Restaurant website?

Facebook seems to be the ultimate in simplicity for small restaurants. Has a number of advantages, like built in chat, picture hosting and a feed of posts.

[dead]

Re: The Stupid Programmer Manifesto

#147

Post by gavinhoward »

Boy, I feel this.

I am also a 0.5x programmer. I write dead-simple C; I don't even touch web development, which I consider more complex than C development with Valgrind.

In fact, I've spent nearly 3 years writing a build system. That's how slow I am, and it's made some acquaintances laugh at how long I've worked without result.

But in reality, I'm not just building a build system. I'm also building my own stack, a la [1], including replacing as much of libc as I can and changing the OS API's I use.

I think that soon enough, this stack and this simplicity will become my superpowers and make me a 10x programmer.

Being a stupid programmer means you won't be clever. And if you're not clever, you will be able to debug it, even though it is twice as hard to debug than to write. [2] Good debugging is a superpower in itself.

[1]: https://youtube.com/watch?v=443UNeGrFoM

[2]: https://www.defprogramming.com/quotes-by/brian-w-kernighan/

Re: The Stupid Programmer Manifesto

#148

Post by collyw »

Supermancho wrote: post #131
kardianos wrote: post #127

Earlier quoted context omitted.

I'm okay with it until the database. For http verb, I'm onboard with just using POST for everything. The database is one area that you need more care. Even if just SQLite, storage persists and especially if this is for a company, needs to persist past you.

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.

Re: The Stupid Programmer Manifesto

#149

Post by ang_cire »

nerdchum wrote: post #109
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".

Sanitizing data is string based not data structure based though.

Well first off, that's not correct anyways; type-conformancy is a very valid and important part of data sanitization.

E.g. does the SSN consist of 3 valid integers split on dashes? If not, it ain't a proper SSN. Catching that typeError is much safer than trying to roll regex or character allow/blocklists.

But also, the manifesto never mentions data structures.

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

Transforming data means actually changing the data, not the data structure that houses it. The author is explicitly talking about making changes to the data itself.

Re: The Stupid Programmer Manifesto

#150

Post by pm »

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…

There are plenty of reasons why something you think should take a day might take a week. We often (fallaciously) assess a problem as "easy" without considering the context in which it has to be incorporated, i.e. the codebase. The duration is moreoften a function of the complexity of the codebase, rather than the complexity of the isolated problem.
Post reply on HN