Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

511–520 of 788 posts

Re: Software development topics I've changed my mind on

#511

Post by polishdude20 »

Kichererbsen wrote: post #179
ZaoLahma wrote: post #82

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

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

#512

Post by ben7799 »

ikety wrote: post #288

Functional programming does not prevent you from using objects Stop listening to functional programming bros. Watch someone like Zoran Horvat. While I can't cosign all of his opinions, he tries to bridge the functional/OOP gap for OOP programmers. OOP programmers urgently need to distance themselves from this binary narrative. Everyone should understand functional programming and how they can utilize functional appro…

Well said and good institutions have been teaching both for decades.

Re: Software development topics I've changed my mind on

#514

Post by withinboredom »

plorkyeran wrote: post #450
tehologist wrote: post #314

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

If a reviewer is regularly rejecting PRs because the variable names have incorrect capitalization then that's a problem with the author, not the reviewer. That is the incredibly basic shit you decide on at the start of a codebase and then follow regardless of your personal thoughts on what scheme is preferable. If/else vs ternaries is something where consistency is a lot less important, but if you know that a team me…

wtf... no.

I worked with a guy where you would try to predict what he would bitch about next. In this example, you would write it as a ternary so you don't have to hear about it ... and he'd suggest it be an if-else statement.

Nobody fucking cares which one it is; is it readable? That's the real question. Your preference of which version of "readable" it is only applies when you are the author. If you're that picky about it, write it yourself. That's what we eventually did to that guy after the team got sick of it. Anytime he'd complain about something like that, we would invite him to write a PR to our PR, otherwise, get over it. Then, we would merge our PR before he could finish.

He eventually got fired for no longer able to keep up with his work due to constantly opening refactor PR's to the dev branch.

Re: Software development topics I've changed my mind on

#515

Post by iLemming »

ertucetin wrote: post #19

> REPLs are not useful design tools (though, they are useful exploratory tools) I disagree with this. I’m a Clojure dev, and most of the time, I use the REPL to iterate on features, fix bugs, and refactor, thanks to the fast feedback loop. I used to be a Java dev—oh god, restarting the whole app after every change made me want to shoot myself in the head. Now, I use the REPL to build what I want and then move on. Thi…

Well, because Clojure actually has a "proper" REPL. Non-lispy languages don't have such REPLs, at best - they are interactive shells. The blogpost author doesn't seem to have experience with homoiconic languages, otherwise, I'm sure, that sentence would be different.

Re: Software development topics I've changed my mind on

#516

Post by jolt42 »

dtquad wrote: post #168

>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

#517

Post by Bjartr »

daxfohl wrote: post #403

Abstractions are a failure in most libraries too. Invariably something will come up that breaks the abstraction. Either new instances come up that don't quite match, or clients want new functionality that doesn't apply to all instances, or whatever. I've come to the conclusion that in almost all cases, you should avoid providing any abstraction from your own library / service, and let consumers figure out what abstra…

The best libraries provide both the abstractions and the building blocks those abstractions were built from so consumers can benefit from the abstraction when they can, but aren't blocked just because the library devs didn't consider a specific use case.

Re: Software development topics I've changed my mind on

#518

Post by jolt42 »

qaq wrote: post #92
imjonse wrote: post #56

> ORMs are the devil in all languages and all implementations. Just write the damn SQL It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables…

It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...

It seemed to me TOPLink had this figured out, and then hibernate took it all away.

Re: Software development topics I've changed my mind on

#519

Post by beders »

tasuki wrote: post #371

> Gradual, dependently typed languages are the future What's that? Idris is dependently typed. > Gradual typing is a type system that lies inbetween static typing and in dynamic typing. Some variables and expressions may be given types and the correctness of the typing is checked at compile time and some expressions may be left untyped and eventual type errors are reported at runtime. That sounds miserable. I can't s…

I can only assume this comes from an observation that once your product matures, the static types become more apparent and you have a better idea how flexible your data modeling should be.

i.e. we are gradually adding more runtime type-checks to our Clojure codebase. (Runtime check are even more powerful than dependent types)

Re: Software development topics I've changed my mind on

#520

Post by gspencley »

> Elegance is not a real metric

While I agree with this in spirit, I once made the observation that:

"Code quality can be measured by the number of occurrences of 'WTF' uttered by other developers per minute when reading a PR."

Elegance might be subjective, but how easy code is to read and understand probably can be quantified even if we don't have the best tooling for that yet.

Meaning that if 10 engineers less experienced than me all tell me that they think expressing something one way is easier to understand than another, I take that as objective feedback and change course.

Post reply on HN