Live data from Hacker News

The Stupid Programmer Manifesto

hasen.substack.com

161–170 of 239 posts

Re: The Stupid Programmer Manifesto

#161

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…

Great point about debugging.

We're currently trying to simplify a monolith that is too hard to maintain, and the biggest issue for us that debugging is heavily impacted the call-stack size. Sometimes 100 functions before it gets to the point you want. All this due to very complex class and function hierarchies.

I'm responsible for a rewrite of some modules and I'm personally gonna stick with simple stuff.

Re: The Stupid Programmer Manifesto

#163
Smart is not chosing a particular techology (whether simple or complex), smart is choosing the right technology for the problem at hand.

The primary difference between good and bad developers is good developers understand context. Every tool, technique, and practice were developed in a particular context to solve specific problems. Good developers understand the contex and limitations. Bad developers use the golden hammer or follow all “best practices”.

The OP calls all the technologies they dont use “bullshit”,so they are probably a bad developer. But a good developer might choose exactly the same set of techonologies for good reasons.

“Keep it simple” is a great principle, but it is also bordering on a platitutde because determining what is simple is not trivial.

Re: The Stupid Programmer Manifesto

#164
post #26

Earlier quoted context omitted.

Yeah, I really can't tell if it's satire. Especially things like this: > 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. OK, well then you might need to gather a little more work experience and meet the repercussions of decisions like this one. Or maybe the OP is a contractor and neve…

> contractor and never has to deal with the repercussions of their actions. This doesn't match my experience of contracting. Not caring about code quality and then leaving others holding the bag of sh*t is frequently what "ladder climbers" do, and those are, by definition, on payroll rather than contractors. For a contractor, there is no ladder to climb, but willingness to get one's hands dirty is definitely part of…

> For a contractor, there is no ladder to climb,

The trick is to refuse to adopt the job-title "contractor" - simply refer to oneself as a "consultant" - it goes a long way.

Fun-fact: there's no rule against contractors/consultants earning equity in their clients' projects either: apparently I can artificially raise my hourly-rate by 20% during the post-interview negotiations, then sweet-talk the client into letting me have token equity in exchange for a 16% pay-cut. Simply do this for every small gig you get and eventually it works out as a pretty-nice personal-ladder to early-retirement.

...not that I want to retire, really - the idea terrifies me because I simply can't do anything except work :/

Re: The Stupid Programmer Manifesto

#165
Obviously great article (for real) but it's sad that so many people still misunderstand containers and orchestration.

> I’m not smart enough to figure out docker confiuration [sic], so instead I compile my web application into a self contained statically linked binary executable file.

That might be fine for something that needs to run once. What if it crashes? And what about everything else that's required. Database, centralized cache, queues, workers, load balancers.

You can't build a fully functional product without those and what are you going to do Install all of the dependencies on a VM, by hand? What if you have to migrate to a different machine for whatever reason? Are you going to write scripts to automate all that and test them and change them and test them again? What if your program crashes? Are you installing supervisor? Will you turn your nice little binary into a daemon and deal with the whole initd/systemd configuration? What about the development environment? Are you going to do all that again when you switch laptop or when you hire someone?

(I personally prefer a PaaS like Heroku, Vercel or Render but that's besides the point)

Complexity very quickly gets out of control. What if you could, instead, define what your project requires in terms of environment, services, dependencies, networking etc. and just give it to a magical (today we'd say "AI powered") DevOps entity that makes sure everything runs smoothly no matter on what machine it's running, assuming it has enough resources? Locally you'd just run a single command and the whole thing would magically come to life.

That's what Docker and Compose/Kubernetes are. A very convenient abstraction layer that makes it very easy to define your underlying architecture in a declarative way and have something else worry about how to get there.

And, let's be honest, it's not even that complicated. You get 80% of the benefits with (less than) 20% of what Docker etc. are capable of. I learned how to use it once 8 years ago and I'm still using it to this day, just occasionally googling the odd command or Dockerfile keyword. I've seen the same with git. So many people just memorize a few commands and can't be bothered to learn how it conceptually works.

I guess I just went on a long rant here but I'm really surprised how, in a constantly evolving industry like tech, there are so many people who are afraid of learning something new or to change how they do things, sometimes out of pure irrational spite or fear of whatever is new. Reminds me of the bit from Brett Victor's talk "The future of programming" where (paraphrasing) he says "binary people thought assembly was a bad idea and assembly people thought C was a bad [...]" etc. etc.

Re: The Stupid Programmer Manifesto

#166
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…

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…

It's ok man. I don't need to be cheered up.

It's completely fine to accept your situation without giving up on improving it.

The problem is when people refuse to acknowledge reality because they really hate certain labels and are too invested in not having that label apply to them.

I'm slow and it's ok.

I'd like to become faster in the future.

But for now, I'm slow, and that's ok.

Re: The Stupid Programmer Manifesto

#167
post #132
post #101

Earlier quoted context omitted.

That's a particularly weird one in light of starting out with "I only use statically typed languages", because it's basically trivial in a statically typed language. You have "type UIData", "type StorageData", and functions/methods to convert back and forth between them. Those functions/methods may need additional parameters, which will be documented by the mere act of calling for them in the function signature. You…

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 must never show that in the UI.

As for your (reasonable!) concerns about having to write-out repetitive types/models that all share similar (though hardly ever identical) data/fields/shape: I agree it's tedious, but that's what we have scaffolding-tools for (granted, I often end-up having to write my own scaffolding and templaying tools...), so for a simple CRUD application just design your database and have the scaffolding tools take care of the rest, including stubbing-out a functional UI (and this is why Ruby-on-Rails was huge when it first came out: it took-away all of the drudgery in CRUD web-applications - but then all the other frameworks/platforms improved their scaffolding-stories and RoR is certainly less attractive in comparison now.

-----

Oh, and of course, ChatGPT et al. is also incredibly effective at scaffolding entire solutions from scratch, e.g. from last month: https://bit.kevinslin.com/p/leveraging-gpt-4-to-automate-the

Re: The Stupid Programmer Manifesto

#168
post #166

Earlier quoted context omitted.

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…

It's ok man. I don't need to be cheered up. It's completely fine to accept your situation without giving up on improving it. The problem is when people refuse to acknowledge reality because they really hate certain labels and are too invested in not having that label apply to them. I'm slow and it's ok. I'd like to become faster in the future. But for now, I'm slow, and that's ok.

I'm also slow. It is also okay.

I have met many, many brilliant engineers. They fly real fast and really far. The funny thing about it is that they tend to crash and burn sometimes too. Sometimes they even break orbit, but even then, someone has to stabilize that orbit from time to time.

Life takes all kinds of people. Folks who are willing to simplify things while ignoring fads are just as useful as those who jump into the unknown of new technologies.

What you think of as a weakness you need to compensate for so you can get work done is what other employers will consider an asset because you refuse to add complexity where it is unwarranted. What you call "slow" others might call wisdom.

I'm really not trying to cheer you up. I'm sharing facts from over a decade writing software being the "slow one".

Re: The Stupid Programmer Manifesto

#169

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…

[deleted]

Re: The Stupid Programmer Manifesto

#170
post #132
post #101

Earlier quoted context omitted.

That's a particularly weird one in light of starting out with "I only use statically typed languages", because it's basically trivial in a statically typed language. You have "type UIData", "type StorageData", and functions/methods to convert back and forth between them. Those functions/methods may need additional parameters, which will be documented by the mere act of calling for them in the function signature. You…

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.

Because most of the development work isn't done in the initial creation phase, but in the maintenance, debugging and extension phase.

And if you're a slow and unskilled developer, you want to minimize the the pain in the second phase.

(That goes for all developers, skilled or unskilled of course.)

Post reply on HN