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

381–390 of 788 posts

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

#381

Post by devmor »

VyseofArcadia wrote: post #161
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…

Iterative work is THE way to work in large legacy codebases. The minute you wade into the code, all of your planning is moot. You don't know what's lurking below the surface. No one knows what's lurking under the surface. Except maybe Dave, because he vaguely remembers about 15 years back talking to some guy who wrote some code 30 years back about it. Greenfield, absolutely design up front you lucky devils, but itera…

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

Frankly, I'd say it's the opposite for greenfield development. Doing iterative work to build out a new product and make changes as you discover needs you didn't account for makes a lot more sense that flailing around making holes in something you don't fully understand that is tied to active business needs.

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

#382

Post by mixmastamyk »

hackflip wrote: post #169
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…

Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?

The old Carlin bit, was going to mention. :-D. I think he used, “asshole.”

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

#383

Post by mr_tristan »

This list does resonate, but I’d make some tweaks to express things slightly better. For example:

> Most programming should be done long before a single line of code is written

I would say “most engineering should be done before a single line of production code is written”.

Formalizing a “draft process” is something I’m really trying to sell to my team. We work in an old codebase - like, it’s now older than most of the new hires. Needless to say, there’s a whole world of complexity in just navigating the system. My take: don’t try to predict when the production code will be done, focus on the next draft, and iterate until we can define and measure what the right impact will be.

The problem is that there’s a ton of neanderthal software engineering management thinking that we’re just ticket machines. They think the process is “senior make ticket, anyone implement ticket, unga bunga”. What usually happens here is that we write a bunch of crappy code learning the system, then we’re supposed to just throw that in a PR. Then management is like “it’s done, right” and now there’s a ton of implicit pressure to ship crap. And the technical debt grows.

I haven’t quite codified a draft process, but I think it’s kind of in line with what Chris here is talking about: you shouldn’t worry about starting with writing production code until you’re very confident you know exactly what to do.

Ah well, it’s a fun list of opinions to read. Chris’ WIP book is an interesting read as well

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

#384

Post by zelphirkalt »

phailhaus wrote: post #262
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…

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 in the Python ecosystem, but also existent, while many packages are written based on bad conceptual foundations, just like many (majority?) of NPM modules are.

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

#385

Post by dionian »

FrustratedMonky wrote: post #98

"Objects are extremely good at what they're good at. Blind devotion to functional is dumb. " Guess this hits home. But Blind anything is bad. I spent a decade blinded by objects being everything (original gang of four book). Then a decade where everything is functions. Why not pass a list of objects to that function.

objects for data, functions for behavior

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

#386

Post by smallerfish »

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…

Apparently Graal lets you hotswap. I tried getting it working about a year ago, but couldn't figure out how to install it with Gradle toolchains, so gave up at that point. I should probably look at it again. Anybody using this?

https://www.graalvm.org/latest/reference-manual/espresso/hot...

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

#387

Post by MichaelNolan »

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.

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

#388

Post by [deleted] »

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.

[deleted]

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

#389

Post by hasley »

bluGill wrote: post #309
pinoy420 wrote: post #261

Earlier quoted context omitted.

How many errors are actually recoverable. I bet most thrown exceptions could be replaced with a printf(“it went wrong here”) for all their utility.

I disagree. The real value of exceptions is you can skip 6 levels of functions that have lines like status = DoThing(); if(status != allIsWell) {return status;} C++ embedded for a long time has said don't use exceptions they are slow. However recent thinking has changed - turns out in trivial code exceptions are slow but in more real world code exceptions are faster than all those layers if checks - and better yet yo…

Do you have any references for that? I used to avoid exceptions on small Cortex M0/M3 devices as well.

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

#390

Post by bluGill »

smallerfish wrote: post #349
bluGill wrote: post #298

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

Do you not know the conventions of your project? Doesn't your project have a convention that all time is in ms (second, weeks...)?

If your project doesn't have that convention such that everyone knows than the code should be

timeMs++;

You may also have a time type and so you can use your IDE to examine the type.

Post reply on HN