Hacker News Reader

Comment by apetresc | Hacker News Reader

> Allow me to propose a model of thinking about code: there's infrastructure code and there's business logic code. > Infrastructure code is exciting, powerful code that exposes easy-to-use interfaces that solve difficult and tricky problems, like talking to browsers (Flask), talking to databases (the Django ORM, SQLAlchemy), dependency injection frameworks (incant), serialization (cattrs) or defining classes (attrs, dataclasses). > Business logic code is boring and unexciting code that enables you to solve problems and finish tickets and sprints at your day job.

What a weird take, unironically asserting that the only "exciting" code is the glue, and all of the actual things software does is just an excuse to build more frameworks.

View on HN

The hardest lesson I’ve learned in turning a programming hobby into a programming career is the following:

The vast majority of truly impactful code is really boring at a technical level.

So, yes, that’s sometimes why people write frameworks: to get some excitement in their code.

I like to say something along the lines is “80% of all development should be really boring otherwise you didn’t do enough planning or you’re working on < 1 year old start up”. To me the real excitement isn’t from the code working it’s from a whole team making something that works because that is way more challenging.

If you only worked in companies producing web applications, writing CRUD routes all day is indeed incredibly boring. The glue at least gives you the opportunity to work with a larger range of technical subjects.

The author wrote cattrs, which is “Complex custom class converters for attrs.” (attrs is a library that preceded dataclasses and is more powerful). Guess he just likes the stuff.

It rings true though doesn’t it? At least in my professional experience, I primarily have run into the “fun” technical problems that require theoretical knowledge when working on infrastructure. It makes sense, because lower on the stack means higher leverage and fewer abstractions from the hardware.

I feel exactly the opposite.

yeah obviously

calculating that 38302 + 8204 = 46506 is pretty boring

noticing that ∀x,y: x + y = y + x is more exciting, and it's a lot more exciting when you can prove it

group theory? continuous braingasm

changing the report code so that an invitee who rsvps to an event even though the host has marked them as 'not coming' still shows up as 'coming'? that's pretty boring; it solves today's problem

writing a practical extraction and report language so that you need only a third as much code to define that report, but also all the future reports you write? that's exciting as fuck, it makes the rest of your life better

generality in software is highly desirable, just as in older branches of math; it's the difference between subsistence and progress

I found those definitions to be a weird line. But, I believe the overall premise is you use types for large projects that many people will be interfacing with and making small changes to. You go cowboy when it's some fun scripts.

This is not limited to type annotations. The same typically applies to comments, documentation, tests, etc. It's just one of the many code quality tools available to you (at a slight cost) , and one typically applies those tools where they have the most benefit: code that is often reused or reread.

Reply on news.ycombinator.com