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

441–450 of 788 posts

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

#441

Post by tharne »

latexr wrote: post #22

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

> What you’re essentially saying is “cherish the people who care up to the level I personally and subjectively think is right, and dismiss everyone who cares more as insane weirdos who cannot prioritise”.

Theses are bullet points expressing general rules of thumb, not legal treatises. You're reading far too much into these.

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

#442

Post by dkarl »

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

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

#443

Post by kflgkans »

taeric wrote: post #412
Terr_ wrote: post #2

> Java is a great language because it's boring [...] Types are assertions we make about the world This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. In brief for non-Java folks: Checked Excepti…

The problem with checked exceptions is they are best explained and utilized in a single threaded execution model where the exceptions can be bubbled up to the operator. This is not, of course, the only way that checked exceptions can be utilized. But, all too often, that is by far the easiest way to reason on them. They represent a decision that needs to be bubbled up to the operator of the overall system. Worse, the…

The most common pattern in languages with explicit error handling, is to simply return the error (possibly with some context added) in every function up to the point where the process was started (e.g. an HTTP endpoint handler, or the CLI's main function) to deal with it.

I'm not saying exceptions are good, but I am saying that they do represent the most common error handling pattern.

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

#444

Post by mjlawson »

9rx wrote: post #416
devmor wrote: post #381

Earlier quoted context omitted.

As someone who's spent 12 years working on legacy codebases, I strongly disagree with this. Iterative work in a large legacy codebase is how you end up making your large legacy codebase larger and even less understood. Your planning should "wade into the code" from the start. I have always gotten better results by charting out flow diagrams and whiteboarding process changes than just "diving in and changing stuff". F…

> I have always gotten better results by charting out flow diagrams and whiteboarding process changes than just "diving in and changing stuff". In terms of a broad population, I am not sure there is a meaningful difference, though. You can iterate on your ideas on the whiteboard or you can iterate on your ideas in code, but the intent is the same. Either way you are going to throw it all away once you have settled on…

> Either way you are going to throw it all away once you have settled on what should be the final iteration anyhow.

I think this needs to be highlighted, because while I completely agree, I think it's often implicit, taken for granted, and neglected. Far, far too often I've seen code bases bloat because this never takes place. The sentiment at a lot of places seems to be, if the tests pass, ship it. Arguably, it may even be the right decision.

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

#445

Post by declan_roberts »

recroad wrote: post #325
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…

Developer for 20+ years. I can't even design anything without coding something.

It's like giving an estimate for a bathroom remodel for a house you've never seen. You gotta get in there first.

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

#446

Post by theryan »

kflgkans wrote: post #438
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…

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'm glad I'm not alone in that sentiment. I haven't touched react since the move to hooks. People seem to like them though?

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

#448

Post by taeric »

kflgkans wrote: post #443
taeric wrote: post #412

Earlier quoted context omitted.

The problem with checked exceptions is they are best explained and utilized in a single threaded execution model where the exceptions can be bubbled up to the operator. This is not, of course, the only way that checked exceptions can be utilized. But, all too often, that is by far the easiest way to reason on them. They represent a decision that needs to be bubbled up to the operator of the overall system. Worse, the…

The most common pattern in languages with explicit error handling, is to simply return the error (possibly with some context added) in every function up to the point where the process was started (e.g. an HTTP endpoint handler, or the CLI's main function) to deal with it. I'm not saying exceptions are good, but I am saying that they do represent the most common error handling pattern.

Right, this is largely the same idea. For things that have to be bubbled up, you wind up in the simplistic "single thread of execution by an operator" pattern. And, in that scenario, exceptions work exactly the same as just returning it all the way up. It is literally just making it easier to unwind the stack.

My assertion is that actual error handling in workflows doesn't work in that manner. Automated workflows have to either be able to work with the value where it was broken, or generally just mark the entire workflow as busted. In that scenario, you don't bubble up the exception, you instead bubble up an error code stating why it failed so that that can be recorded for later consideration. Along the way of bubbling up, you may take alternative actions.

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

#449

Post by qwertox »

MichaelNolan wrote: post #387
qwertox wrote: post #306

> Java is a great language because it's boring My issue with Java is not that it's boring, which it is not, but there is so much that needs to be done to get a simple "Hello World" program to run which also depends on an external library. It feels like you first have to build a castle just to put a bed in a room.

These days hello world in Java is just: ```void main() {print("hello world"}``` And you can skip the compile step as well and run it with just `java yourFile.Java` Since JEP 495 they have made "simple programs" very simple.

yes. main() is the room and print("hello world") the bed.

with the castle I'm referring to the whole myriad of things that must be done to be able to compile this. But, as I said, at least drop in a library, possibly via Gradle.

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

#450

Post by plorkyeran »

tehologist wrote: post #314
asdajksah2123 wrote: post #289

Earlier quoted context omitted.

> stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor) This is incredibly important. This is the kind of stuff that prevents shit like half the team using metric and the other half thinking they're imperial, or you coming up with the perfect design, but then the manufacturer makes a mirrored version of it because you didn't have the conventions agreed upon.

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 member has a strong preference for one over the other and you think it's unimportant then you should just write it how they prefer to begin with. Fight over things you think are important, not things that you think don't matter.

Post reply on HN