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

171–180 of 239 posts

Re: The Stupid Programmer Manifesto

#171

Post by aleksiy123 »

bluefirebrand wrote: post #129
nerdchum wrote: post #113

Earlier quoted context omitted.

Less state changes the better. Managing state is the number one enemy on software.

I agree wholeheartedly. I don't understand why everyone insists on repackaging the same data over and over. Store it in one format in the database. Read from the database and transform it. Package that into a TO object and send it over the wire. Receive the TO object and repackage it into your local context Take the local context and repackage a bunch of parts of it into each view model as necessary. Everyone just wa…

Because you don't want couple your data model with your public contract. it allows you to change them independently.

When it comes time to change your data model you can't without bubbling it all the way through the to the public API which may not be desirable.

Repackaging the data at every level means you only have to change the transformation at one of those levels.

For small projects this isn't a big deal.

But if you are working on a large project with multiple teams you have public contracts at multiple levels. You don't want to wade through 10 layers and 10 teams of changes because you change the way you store and compute some attribute.

Re: The Stupid Programmer Manifesto

#173

Post by angarg12 »

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

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

Re: The Stupid Programmer Manifesto

#174

Post by kayodelycaon »

taneq wrote: post #125
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…

> The combination of things suggests to me they have can't or don't want to deal with with non-trivial mental models. You mean… they’re stupid? Like they say in their title?

Being limited in time, effort, or ability isn't stupid. I've got my own mental hardware limitations with reading math and some functional programming languages. Bad enough I don't put in the effort to learn certain things.

Now, writing an article conflating limitations or lack of desire with intelligence shows... poor self-awareness.

But yeah, I prefer not to say stupid when I can be more specific. :)

Re: The Stupid Programmer Manifesto

#175

Post by bluefirebrand »

aleksiy123 wrote: post #171
bluefirebrand wrote: post #129

Earlier quoted context omitted.

I agree wholeheartedly. I don't understand why everyone insists on repackaging the same data over and over. Store it in one format in the database. Read from the database and transform it. Package that into a TO object and send it over the wire. Receive the TO object and repackage it into your local context Take the local context and repackage a bunch of parts of it into each view model as necessary. Everyone just wa…

Because you don't want couple your data model with your public contract. it allows you to change them independently. When it comes time to change your data model you can't without bubbling it all the way through the to the public API which may not be desirable. Repackaging the data at every level means you only have to change the transformation at one of those levels. For small projects this isn't a big deal. But if…

If you are working on a large project with multiple teams and you change something like that you better version it or make sure it's backwards compatible anyways.

Otherwise you're going to break something downstream and you're still going wade through all of those layers, and now it's less obvious what broke because everyone is re-bundling your data into their own formats.

And I am not advocating for dumping your DB rows directly onto the wire for the frontend to fumble.

I am just saying it's silly to write a frontend and backend in a super modular, decoupled way when they are actually just a single service.

Re: The Stupid Programmer Manifesto

#176

Post by hsn915 »

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…

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 it as-is (ignoring the json encoding/decoding).

There's a code path in the backend that takes SignupRequest and uses it to create a new Account.

Re: The Stupid Programmer Manifesto

#177

Post by anthony_d »

angarg12 wrote: post #173
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'…

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.

Re: The Stupid Programmer Manifesto

#179

Post by aleksiy123 »

bluefirebrand wrote: post #175
aleksiy123 wrote: post #171

Earlier quoted context omitted.

Because you don't want couple your data model with your public contract. it allows you to change them independently. When it comes time to change your data model you can't without bubbling it all the way through the to the public API which may not be desirable. Repackaging the data at every level means you only have to change the transformation at one of those levels. For small projects this isn't a big deal. But if…

If you are working on a large project with multiple teams and you change something like that you better version it or make sure it's backwards compatible anyways. Otherwise you're going to break something downstream and you're still going wade through all of those layers, and now it's less obvious what broke because everyone is re-bundling your data into their own formats. And I am not advocating for dumping your DB…

Not if the public view on the data doesn't change. Just the storage. That's sorta the point. To not have to version if you just change the underlying storage model.

For example let's say for whatever reason we were storing a duration as an int. But instead we decided to migrate it to start time and end time.

Do we need to force that change on everyone downstream and add a new major version API? Or can we just compute the old duration from the new attributes in the transformation.

Even in your example do we really need to change the frontend in this case? For small projects the extra boiler plate probably doesn't out weigh the benefits but for large projects it absolutely does.

Re: The Stupid Programmer Manifesto

#180

Post by Nickersf »

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…

I've made several "Bob's Restaurant" websites for clients. Early on I thought just that. "This can be statically implemented using the core web technologies HTML and CSS" - It wowed the client visually at first and they signed off on the product agreeing that the simple site was enough for them. Then the client wanted their Facebook, Google Maps, and Instagram integrated throughout the site over time. Now the site has JavaScript in its stack and external code running on it via APIs.

Early on the client wanted to make changes to the menu, and have a feed of events from their Google calendar. I implemented a Google Calendar feed script. Enter the world of dates in JS and learning how to use OAuth to hook into their feed. The client was getting confused as to why all this work had to be done for such simple little features and there was extra cost associated, and at the same time requested that they can CRUD menu items. I told them we need a CMS for that. They didn't like hearing the was more time and cost associated. By this time the statically implemented, elegantly designed Home | Menu | About site delivered the purpose of a visual mockup rather than a website that will help the business retain and add growth.

It could be said that this story is one of not planning and getting the spec right with the client, which in part is true. The part that was wrong is that the site could be this simple CSS HTML static site when in fact, even for a small business lacked the features and flexibility needed. Initially, the client and I decided that we would have me make the changes and updates to the static food and drink menu pages. This turned out to be very inefficient for both parties. Small businesses often don't want to pay hourly rates to have minor updates done on their website, which was the case because I don't work for free.

In the end the HTML/CSS site had a CMS, Database, and multiple external services. I learned from this moving forward and came up with the right stack for the scale of business I work with. However, in the late 2010's I noticed more small businesses opting into products like Squarespace and Wix, and selling clients with certain small businesses (nick nack shops and local bars restaurants) on custom site builds was getting harder.

Back to the original post. I get the point of the blog was to make a statement against unneeded complexity. Sure, however, it's important to remember that the work of producing digital products is inherently technical and complex. Developers should strive to be a smart programmer and spend time picking the right tools for the job.

Post reply on HN