Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

581–590 of 788 posts

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

#581

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

>Everyone has a plan until they get punched in their face (by landmines in legacy code)

unless you have the old maintainer on call (I rarely did due to them leaving the company years ago) you definitely need to move slowly. rely on test suites if you are blessed with them. Submit small changes that pass tests.

BTW, nice and timely username.

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

#582

Earlier quoted context omitted.

This was the one that resonated the most with me. As soon as I start to think "Why don't they just . . . ." I know I'm in for an epiphany.

“Just”(TM) The bane of my life. Glad I grew out of that eventually. I completely agree.

At a previous employer I tried to implement a Just Jar where people had to put a dollar in every time they said "Just do...". It didn't last because the boss was the biggest offender.

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

#584
Good thoughts. I agree with much. I quite disagree with the following: “Most projects don't need to ‘scale’” I get that you’re probably referring to theoretically infinite scaling provided by stuff like microservices, containers, and serverless functions, but I do think it’s part of our job to consider the external factors that affect the functionality of our software. Similar to types being assertions about the external world, so too the design of the code and how it handles scale is an assertion about external factors. It’s important to define the bounds of what our software can handle in terms of throughput and what should happen in case those assumptions break or approach their outer bounds.

I think most projects need careful attention to handling unexpectedly large throughput gracefully.

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

#585

Earlier quoted context omitted.

> time++; // increment time This isn't too many comments, it's a poor quality comment. Try: time++; // advance 1 simulated second

What is wrong with time++; That seem obvious enough to me without any comments.

It will vary immensely on how readable the actual code base it, but what comes to mind:

1. what units? I was just caught in this with a function with a timeout. I had to look at the docs to find out this was actually in nanoseconds (stuff like this is why I came more around to verbose parameter names).

2. what's the function of the timer?

3. (potential code smell) Do I need to manually increment such a timer for the test? is the time library a necessary part of the test (or perhaps what we testing)?

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

#586
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

No. The two aspects (let's call them the craft and the minutiae) are orthogonal, they're not different level of caring about the same thing. I've seen people obsessed over minutiae and writing buggy, careless and unmaintainable code.

As with other formal aspects (e.g., testing) the quality of the code and the level of adherence to convention or forms are independent of each other; but they do both consume the same limited resource, which is the time and attention of developers.

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

#587

> Most programming should be done long before a single line of code is written What does this mean?

That you must design the system before you type it down as code. Once you make the wrong assumptions or wrong abstractions no amount or skillful coding can save you. You risk solving the wrong problem perfectly.

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

#588
post #287

Earlier quoted context omitted.

IMO it's like scrum: if your team is good and homogeneous, it doesn't really matter much what you do: it just works. Scrum and no scrum, types and no types. It's not about having rockstars or 10x engineers, it's just about having shorthands, shared knowledge, etc. If your team is varied or too large, you need things to help you out with organisation and communication. (Whether my examples of Scrum and Types are the a…

In my experience: Too large is any team larger than 10 people or any code base with more than 10,000 lines of code. Both of those would be considered tiny by most in the industry.

Hard disagree on the 10kloc limit. At a previous job, I maintained and enhanced a 50kloc monolith (written by someone else), usually by myself. My productivity was very high. At my current job, we've split a codebase that should be about 50kloc into more than 10 separate repositories; everything is still just as coupled but it's much harder to reason about and refactor. My productivity is much lower.

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

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

Depends upon the ORM. Like all frameworks, a really good one is a significant productivity boost while a bad one is faworse than none at all.

And not just the ORM, but the way it's used. If you ensure that lazy-loading is turned off from day 1 and stays off, you might be okay. But if you don't pay attention to this and write a bunch of code for N years until all the "select N+1"s you've been unwittingly doing finally force your DB to a crawl... now you're in trouble.
Post reply on HN