- Elegance: Articulating the value of absence.
Software development topics I've changed my mind on
451–460 of 788 posts
Re: Software development topics I've changed my mind on
#452Earlier quoted context omitted.
Imperial vs Metric is a hard requirement not a convention or formatting. I have a co-worker who wants everything to be a one liner, doesn't like if/else statements, thinks exception handling is bad and will fail a code review over a variable that he feels isn't cased properly. This makes code reviews super slow and painful, it also means you aren't focusing on the important stuff. What the code actually does and if i…
> will fail a code review over a variable that he feels isn't cased properly Many projects have fairly strict rules about identifier naming conventions, so this doesn't feel so far fetched to me. The example about if/else vs ? : is pretty damning though.
Sure, but if there are actual rules, agreed to and accepted by the entire team (as opposed to one guy's idiosyncratic preferences) then there should be a commit-hook to run the code through a linter and reject the commit if the rules are violated.
Re: Software development topics I've changed my mind on
#453Earlier quoted context omitted.
What is wrong with time++; That seem obvious enough to me without any comments.
Is it ms? seconds? days? weeks? months? How far up do I have to read to figure that out? When I'm looking at a test case is broken, I ideally want context IN the actual test that lets me understand what the test author was thinking when they wrote it. Why does this test exist as it does? Why are the expectations that are in place valid? Write the comments for you-in-2-years.
Pedantic but a comment clarifying the unit of measurement belongs with the declaration of the variable, not an increment statement.
Re: Software development topics I've changed my mind on
#454Just personal opinions, I guess, I agree with most, but here are some I disagree with: - There is no pride in managing or understanding complexity Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. - Java is a great language because it's boring That is if you write Java the boring way. A lot of Java code (looking at you…
> - There is no pride in managing or understanding complexity > Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. I interpreted that one as a suggestion to avoid welcoming needless complexity because of the false sense of pride it gives you to successfully manage that complexity. To give an example, I believe C++'s end…
C++'s enduring popularity is mostly inertia from the time it was if not the only game in town, the biggest, baddest game in town, and from being the souped-up (if overly complex) successor to the previous biggest, baddest game in town.
Thousands of companies collectively have billions of lines of code in C++. Millions of programmers know it well enough to get the job done. Entire ecosystems with absolutely huge areas are well defined by C++ (and previously C).
Rewriting all this code would be a gargantuan task. It all mostly works (yes, it has bugs, lots of them, but it is still mostly doing the job). The "R" in "ROI" for rewriting it is extremely low and hard to predict, and the "I" is very high.
And that is why old programming languages live on. Not because people take pride in being geniuses or the ability to code in it, but because inertia is really hard to change.
Re: Software development topics I've changed my mind on
#455> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…
There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space. I'm fond of saying that anythi…
The construction metaphor isn't a very good fit here in my opinion.
No building is expected to have the amount of adaptability that is expected of software. It falls completely apart for interpreted languages. When is a PHP app constructed in this metaphor? On every single request? The metaphor assumes a "design once, build once" approach, which is basically no software I've ever seen used in real life. Hardware, OS, language, collaborator/dependency updates all require changes to the application code more often than not. And that's assuming the feature set stays stable, which, in my experience is also quiet rare.
Maintainability is therefore a quality dimension of software, and reduced cognitive load usually results in increased maintainability (curious if someone has a counterexample to that)
That is not to say I'm one of those people who need a specific code style to have their weird brain satisfied. But not using a linter/autoformatter at all [when available] in 2025 sounds like the opposite of "work smart, not hard"
Re: Software development topics I've changed my mind on
#456Earlier quoted context omitted.
> the formatting and conventions of the blueprint Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information. I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenat…
I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, th…
Construction and civil engineering have been unable to agree on global conventions and standards, and they have a multi-millenia head start over software engineering. The US may claim to follow the "International Building Code", but it's just called that because a couple of small countries on the Americas have adopted it. For all intents and purposes it's a national standard. Globally we can't even agree on a system of units and measurements, never mind anything more consequential than that.
Re: Software development topics I've changed my mind on
#457>Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy As a backend/systems engineer I recently had to look at a React + Typescript + MobX app from 2019/2020. It is true that that some things, especially the webpack config and Typescript loading, were outdated but the overall design and architecture of the app was still understandable and modern. With some help from ChatGPT it took very…
If there is anyone here who has time to explain to me (or link articles about) why functional components and hooks are considered to be better than class components, please enlighten me. Up until roughly 4-5 years ago I was doing small front-end React apps on the side (I'm a backend engineer) and was feeling very productive with class components. They made sense to me, concerns were nicely separated, and I felt I cou…
I only knew React until my current job, which uses Vue. I'd strongly recommend trying a framework other than React for your next project. After you're past the learning curve, it's much more intuitive.
Re: Software development topics I've changed my mind on
#458I must say that I resonate with almost all of the points stated. These particularly stood out to me: Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy ORMs are the devil in all languages and all implementations. Just write the damn SQL Monoliths remain pretty good It's very hard to beat decades of RDBMS research and improvements Micro-services require justification (they've increasin…
>Given a long enough time horizon, you'll deeply regret building on Serverless Functions
What is the regret about? I've been almost exclusively using AWS Lambda (not using the "Serverless" framework), since 1 month after AWS released Lambda in Nov 2014. I've built quite a lot on top of AWS Lambda, and I love it. It just works. It's not difficult to work with, and I don't really have to worry about scaling it. Is 10 years not enough of a "time horizon" to regret it?
Re: Software development topics I've changed my mind on
#459Earlier quoted context omitted.
5-10 years ago I was just skipping Webpack and Babel, and raw-dogging React.createElement in personal projects in order to be happy and maintain sanity. At work I would just push hard for alternatives like Parcel or Brunch. Now, with Vite I just don't mind the toolchain anymore, it just helps me instead of getting in the way. Similar to Go. All the problems I have now are of my own creation.
dumb question from someone re-entering the FE world: why is Vite necessary? My understanding is it basically strips the type information using Go (IIRC) where your typechecking is then a separate step (without transpilation). So feedback is more rapid. But, with tools like Deno or ts-node, where the type checking is apparently also off the hot path, why does Vite still exist? Is it because it connects file monitoring…
> Is it because it connects file monitoring with a dev server? Because it also somehow works non-js artifacts like CSS and image imports?
Yes and yes. Also some pre-processing such as compiling JSX into JS.
Re: Software development topics I've changed my mind on
#460mostly good advice, but he's yet another person who seems to think orms are primarily about sql generation. they're not; they're about serialising/deserialising between objects and db columns!