The Stupid Programmer Manifesto • Hacker News Board

Re: The Stupid Programmer Manifesto

#191

Post by nerdchum » Thu, Jun 15, 2023, 5:15 PM UTC

ang_cire wrote: post #149

nerdchum wrote: post #109

Earlier quoted context omitted.

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

You shouldnt have to "transform" the data though.

You should validate the data and sanitize the data...but if youre transforming data youre headed into a state management nightmare.

State management is the number one enemy and other than sanitizing and validating both the data and structure should be considered mostly immutable.

Re: The Stupid Programmer Manifesto

#192

Post by nerdchum » Thu, Jun 15, 2023, 5:16 PM UTC

ang_cire wrote: post #155

Solvency wrote: post #128

Earlier quoted context omitted.

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…

Yeah, other than sanitizing and validating, you shouldn't be transforming data or you're headed into a state management bug nightmare.

Re: The Stupid Programmer Manifesto

#193

Post by nerdchum » Thu, Jun 15, 2023, 5:25 PM UTC

aleksiy123 wrote: post #179

bluefirebrand wrote: post #175

Earlier quoted context omitted.

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…

I disagree completely.

If the data structure needs to be changed it needs to be changed at the beginning of the system typically the front end. And downstream code needs to be fixed to accommodate that.

Otherwise youve created 20 different state machines for each part of the system stacked on top of each each other each expecting a different data structure and returning a different data structure.

So changing anything after the system is sufficiently complex is an exercise in masochism and development will slow to a crawl to avoid breaking one of the 20 downstream black boxes.

There should only be a single data structure contract that all teams follow.

There needs to be a SINGLE data structure passed through the system originating at the beginning of the system. The data structure can be added to by code along the pipeline but never changed.

Re: The Stupid Programmer Manifesto

#194

Post by beezlewax » Thu, Jun 15, 2023, 5:29 PM UTC

collyw wrote: post #144

Cthulhu_ wrote: post #106

Earlier quoted context omitted.

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.

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

Re: The Stupid Programmer Manifesto

#195

Post by bitblender » Thu, Jun 15, 2023, 5:39 PM UTC

hsn915 wrote: post #176

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…

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 shape but there's no reason that they need to be coupled together and impossible to change independently, other than the fear of inconvenient "boilerplate" mapping logic. By doing this up front, and not even letting it enter your data model, you create a formal abstraction boundary; it's reserving the right to change two pieces of data independently. Also, mapping/transformation logic can often just be simple, pure, total functions; which are trivial test and maintain compared to anything that touches I/O.

Re: The Stupid Programmer Manifesto

#196

Post by marcosdumay » Thu, Jun 15, 2023, 5:42 PM UTC

hsn915 wrote: post #132

jerf wrote: 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.

You want computer storage to be flexible, non-redundant, and small. You have a machine capable of quickly and flawlessly integrating data from anywhere, correctness is your main concern.

You want your human representation to be specialized, highly redundant, and as large as needed so anything important is presented. Your users can't find data or keep it in memory, enabling them is your main concern.

Usually, those two sets of constraint lead to the same format on behind the scenes admin panels and nowhere else.

Re: The Stupid Programmer Manifesto

#197

Post by vsareto » Thu, Jun 15, 2023, 5:45 PM UTC

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…

>And then these people repeat what they have been told are "the best practices".

And then they get jobs which serve to validate their learning paths (maybe not at FAANG), which gives them confidence about what they learned being the right way to do things.

>Proper engineering degree teaches about gathering requirement and analyzing the problem space to understand what really needs to be done.

Well sure, but a lot of non-engineers do that too. Where's the real distinction at?

Re: The Stupid Programmer Manifesto

#198

Post by pcthrowaway » Thu, Jun 15, 2023, 5:45 PM UTC

throw1234651234 wrote: post #39

Most projects don't need Docker. I have built multiple billion-dollar-a-year company websites from scratch (no, I don't make a lot of money, just a dev) that get tens of thousands of users a day and we barely ever need more than one or two instances of anything, all of which the major cloud providers can scale out of the box with Azure App Service / Elastic Beanstalk / etc. Docker/K8S is pure hype and never fills the…

multiple billion per year with tens of thousands of users per day?

Assuming conservatively that this is 1B/year and 100K users/day, that's still $273/user/day. What are you selling?

Re: The Stupid Programmer Manifesto

#199

Post by denton-scratch » Thu, Jun 15, 2023, 5:48 PM UTC

DaiPlusPlus wrote: post #189

denton-scratch wrote: post #181

Earlier quoted context omitted.

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

> So this anti-pattern assumes that users are using some memorable password like their mother's maiden name, probably for all the services they use. Anyone using sane password practices is penalized with stupid friction. I think you're really, really underestimating how easy it is to make a typo when entering a password into a masked password box, hence the 2 fields. Also, web-browsers don't let you copy-and-paste th…

> Also, web-browsers don't let you copy-and-paste the password from one box into another

Point taken; perhaps simply having that widget that lets you see the password unmasked would be better, than forcing you to enter it blind twice (and getting it wrong twice). Fact is I don't try to copy/paste one field into the other; I paste the same stuff into both.

FWIW I'm a normal person. I don't know what OIDC is, and I've never been asked to use Passkeys (I'm proud to know nothing about Apple devices, and I don't entrust my security to "the cloud" or third parties). My password manager is local, backed-up locally. I'm already annoyed once I'm presented with a registration form, and only complete one when I'm forced to. Every extra annoyance increases my rage.

Re: The Stupid Programmer Manifesto

#200

Post by kartoshechka » Thu, Jun 15, 2023, 5:49 PM UTC

908B64B197 wrote: post #184

Cthulhu_ wrote: post #106

Earlier quoted context omitted.

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…

> I've worked in a number of projects where they decided to move to microservices for reasons they wish they had I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better. Basically, use the current job as a way to train on the stack the company you really want to work for is using. If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL…

this might come as incredibly cynic for some, but illustrates an important point - languages/frameworks/whole marketed stacks like ELK are merely tools for you to accomplish the task, which in the end is either to reduce costs or increase revenue

so naturally it doesn't matter (in long term) what you should learn to get a first job, change jobs, change domains - prioritize ROI the tool would give you in future, a job market, and your sanity :)