I think the ultimate boring language is golang. It is almost too boring though.
Software development topics I've changed my mind on
101–110 of 788 posts
Re: Software development topics I've changed my mind on
#102The comment about project managers is interesting. At my last workplace, the PMs -- all consultants -- were the only reason anything ever got done.
Depends on team's experience level
Re: Software development topics I've changed my mind on
#103> 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…
And that's why I don't care anymore
Yup. Doesn't matter.
Code style should be consistent and look nice, probably use the default without too much nitpicking. You have bigger fish to fry
There are better things in life to worry about
"Craft", most code goes to irrelevancy in 5 yrs. And if it doesn't it's fixable (amen for AIs)
Try to sweat up every detail right off the bat and you go nowhere
Re: Software development topics I've changed my mind on
#104Earlier 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…
That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip.
But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.
Re: Software development topics I've changed my mind on
#105> 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.
Re: Software development topics I've changed my mind on
#106> ORMs are the devil in all languages and all implementations. Just write the damn SQL This week wrote an article on this, since I found there's a lot to explain wrt this topic: https://dev.to/cies/the-case-against-orms-5bh4 On HN: https://news.ycombinator.com/item?id=42922014
I've been loving edgedb in my typescript side projects for a number of years now. I have always hated ORMs, mostly for performance and a little bit for elegance / ergonomics. Curious if you have thoughts on a solution like that?
I like EdgeDB. The only downside I see is the lock-in, that is less of an issue with SQL.
While I have not used EdgeDB, I have used Hasura, which I really liked.
Wrt the syntax of queries, I know of https://prql-lang.org which is kind of similar of EdgeQL.
Funny that EdgeDB says on its page it tries to solve the ORM problem: I strongly believe ORMs do not solve any problem, they merely create problems (as I argue in the linked article).
Wrt my thoughts: the EdgeQL queries are usually still strings (no compile time type checking, not IDE tooling). With Hasura the GraphQL interface (that EdgeDB also supports) allows one to generate a client library based on the GraphQL schema: this allows one to have compile time checks on the queries, which is really neat.
Re: Software development topics I've changed my mind on
#107> Most programming should be done long before a single line of code is written Nah. I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently. Quite often you also have eureka moments with better solutions th…
ok that sounds bad, you should have the option to go back to design, but depending on what point you find that issue, depends on how much time you have wasted?
Re: Software development topics I've changed my mind on
#108> 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…
I think the line between minutiae and craft is drawn by the effect it has on the product you're creating. Method length makes your code more manageable, for example. Placement of line breaks, not so much. At the end of the day, we aren't paid to produce code, but working software that works today and is easy to change tomorrow.
That is a purely commercial take of the matter. I don’t think it’s controversial to argue the artisans who stand out do so because they care for the craft itself. Spending an extra hour or two perfecting the shape of the armrest in the chair may not allow you to earn more money from that one commission, but it might improve your knowledge and skill and be slightly more comfortable to the sitter. If they comment on it and appreciate it, so grows your motivation and pride.
Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does.
I’m not arguing for obsessing over code formatting, but pointing out the line between “master of the craft with extensive attention to detail” and “insane weirdo with prioritisation deficits focusing on minutiae” is subjective to what each person considers important. Most of us seem to agree that being consistent in a code base is more important than any specific rule, but that being consistent does matter.
At the end of the day, we aren’t paid to eat healthily and taking care of our bodies either. But doing so pays dividends. Same for caring about the quality of your code. Getting in the habit of doing it right primes you to do it like that from the start in every new project. Like most skills, writing quality code becomes easier the more you do it.
Re: Software development topics I've changed my mind on
#109Earlier quoted context omitted.
The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them. Things I beleive: - If you're picking up on code-style in PRs then your toolchain is backward. - If you're changing linting rules every month then you're focussed on the wrong things - It's better to have a consistent style than a perfect style
Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it. Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.
IMO, gofmt doesn't go far enough. It should sort imports and break lines automatically, or you end up with different people with slightly different preferences for breaking up lines, leading to an inconsistent style.
Something like gofumpt + golines + goimports makes more sense to me, but I'm used to ruff in Python (previous black + isort) and rustfmt.
I'd say that if you're manually formatting stuff with line breaks and spaces, that should have been automated by tooling. And that tooling should run both as a pre-commit hook and in CI.
Re: Software development topics I've changed my mind on
#110> Typed languages are essential on teams with mixed experience levels I like this one because it puts this endless dilemma in a human context. Most discussions are technical (static typing ease refactoring and safety, dynamic typing is easier to learn and better for interactive programming etc.) and ignore the users, the programmers.
I think the size of the code base also matters: bigger size = having types is more important. There is a contradiction here as: bigger size = compile speed more important AND types slow down compilation. More advanced typing features slow down compilation even more.
> More advanced typing features slow down compilation even more.
C++ is a bit of an outlier here. But really people should think of typechecking as shifting fault detection earlier in the process than runtime. It doesn't matter if your test suite starts slightly quicker if you have to wait for the whole thing to run to find something you could otherwise have found with types.