> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. I wish he'd say which people are the weirdos: the ones who say let's just pick a standard and rigorously enforce compliance, or the ones who complain about the burdens of compliance and try to undermine enforcement. I'd say the latter. I'm surprised he didn't feel the need to be specific.
Software development topics I've changed my mind on
521–530 of 788 posts
Re: Software development topics I've changed my mind on
#522> ORMs are the devil in all languages and all implementations. Just write the damn SQL What are the main issues people run into with ORMs? I've used Django ORM for years and written some relatively large applications using it without much problems. Complex queries and aggregations can result in quite hairy code though.
I can give an example for Prisma. It joins in code, not in SQL. We realized this way too late because we assumed an ORM is optimally structuring code. It wasn't. This, along with the fact that SQL is already a definitive language, made us realize that ORM's are stupid and utterly useless. I'm talking about the ones that try to pretend they're code, and not a query. There are multiple ways you can design an ORM though…
- https://www.prisma.io/blog/database-vs-application-demystify...
Re: Software development topics I've changed my mind on
#523Earlier quoted context omitted.
Most programming is actually figuring out what already exists and what (and more importantly: why) the requirements are. This is best done long before a single line of code is written. I think the author is taking a wider view of "programming" than the actual writing of code as the end product. Some of the most important work I've done is spend the time to argue that something doesn't need to be done at all.
This makes me think it would be really cool to tie code sections to slack conversations or emails. There's always commit messages yes, but most product decisions on why something was done lives in slack at least where I've worked. Even an AI tool that takes a slack thread and summarizes how that thread informed the code would be cool to try.
Re: Software development topics I've changed my mind on
#524Earlier quoted context omitted.
> Functional programming does not prevent you from using objects It's a bit like how doing single-entry bookkeeping doesn't stop you from doing double-entry bookkeeping.
That's probably the most incorrect analogy. If I have objects, I can change their state in the middle of any bookkeeping. There should be a different name for functional programming with mutable objects.
Double-entry is harder to grasp, but it has certain properties, like being able to sum along rows or columns. With that property, you can then make assertions like "if anything is off by a cent, then there has been a mistake and it needs to be looked at again."
On the other hand, single-entry is much simpler, you can just record a figure for a date with a reason, and be done with it. It widens the pool of employable candidates, it's easier to onboard new employees, and you don't have any elites screaming at you for doing accounting the wrong way.
If you take a hybrid approach and mix the two, then on average you only have to fill in 1.5 entries per transaction, so it's easier and faster than double-entry, but you can still express some transactions with two entries if it's more elegant, on a case-by-base basis.
Re: Software development topics I've changed my mind on
#525>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…
"frontend" is the wrong word, he should have said "web". Writing desktop UIs or mobile apps tends to be elegant. And probably "SPA frontend" as server-side UIs are also much cleaner.
Re: Software development topics I've changed my mind on
#526Earlier quoted context omitted.
Yeah I wonder if his experience is mostly using JavaScript, which is absolutely impossible to maintain at scale. Most of my team comes from primarily backend-dev roles and they've all grown to love TypeScript over Python.
I have done frontend as well as backend and moved to backend only, because the endless hype traing jumping, cv driven development and config and library churn was just too much of a comedy. And it is still happening. Now it is people switching "routers" and version upgrades for nodejs and version upgrades for typescript and deployment platform and ... The list goes on. This kind of thing is much much less pronounced…
Part of being a good frontend lead is personally is not falling for the hype, and only adding packages I know will a. be supported for the foreseeable future, b. have an exit plan if those technologies aren't supported, and c. keep an eye on my juniors/seniors to make sure they're writing sensible long-term code.
The gnashing of teeth over the "upgrade cycle" I think speaks to poor team planning/leadership than it does for the actual tech now.
Re: Software development topics I've changed my mind on
#527> Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy My feeling is that a lot of negativity towards the frontend stems from assuming that the entire field is like React and its community. It's really not like that.
I think Frontend (or maybe slightly expanded App Development) is a greatly underappreciated skill. It's easy to throw a UI together, but to do it in a way that is obvious to your user's, can be maintained and can move at the speed the business needs is a tough ask.
I enjoy the challenge, and have found a great niche for myself doing exactly that.
Re: Software development topics I've changed my mind on
#528Re: Software development topics I've changed my mind on
#529Re: Software development topics I've changed my mind on
#530Earlier quoted context omitted.
"None" to represent any type of failure sounds similarly fundamentally flawed too.
That's why you need not just an Either/Result type, but proper monads so that you can use the same functions with both.
Today I write C# at my job and I could not be happier with the usage of exceptions.