Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

241–250 of 704 posts

Re: Software engineering topics I changed my mind on

#241

> People who stress over code style, linting rules, or other minutia are insane weirdos Really great post, although I do really value good, consistent code style. Readability really matters (imho). You can even use writing concepts like parallelism if you are feeling fancy to make things even easier to read.

I don't understand this claim of readability. If it were true, then you wouldn't be able to read a code base with a different code style. In truth, the switch takes about 10 seconds for me to get used to. Which is about 10,000 times less that the time I've wasted debating code style with other developers that insist that "consistency" is a useful goal without justification. There is exactly one concrete goal that I h…

Cognitive load is real and that 10 seconds is more load you have to put onto your mental ram to get anything done.

It’s easy to not notice it until it’s not.

That’s why autoformatters are better in general. There’s no argument, it’s just how it is, and it’s dealt with.

Re: Software engineering topics I changed my mind on

#242

Earlier quoted context omitted.

It's especially useful with the newbies, as they are most likely to attempt to reinvent the wheel, due to lack of knowledge/experience. Also, in the age of WFH stand-ups are a replacement for lunch conversations, the most rudimentary block of team building. I think that if you're not doing stand-ups or something like that since March you're probably losing team coherence.

There is not much wrong with reinventing the wheel. It is a less efficient use of time that often results in a beneficial serendipity. The opinion that reinventing the wheel is somehow a supremely evil satanic ritual is what prevents original solutions and allow expert beginners to become shitty decisions makers.

You are totally right but probably assuming you have a top notch and easily discoverable documentation that can guarantee that newbies won't spend 15 days reimplementing "that bash script you need once a year or so" that do the job in 2 minutes.

However even if this case you might get lucky and end up with a new script that do the job in 30 seconds and everybody in the team have learn that documentation is very important.

Re: Software engineering topics I changed my mind on

#243

Earlier quoted context omitted.

> I grew up with digital tools only. This implies that you exclusively use digital tools, so my first question would be: have you tried using pen and paper for things? It's really hard to give compelling examples of where pencil/pen and paper are going to be better than digital tools because everyone is different. If you want to try it out, I recommend simply keeping a pad and a pen at your desk and when you're stuck…

> have you tried using pen and paper for things? Yes. If I can express something through writing (as with the cases you mention), there is no faster, more convenient tool than a note taking app + keyboard. It's instant, archived, editable, and globally available (where there's internet of course). If it's an idea that needs to be visually designed (shapes, graphs, space), I find that I can mostly do this by redefinin…

Are you a visual learner at all? Or an artist at all?

Like, do you ever draw shapes, or correlate shapes?

Have you ever drawn a flowchart for somebody?

Re: Software engineering topics I changed my mind on

#244
post #84

Earlier quoted context omitted.

> Imagine thinking about colleagues as people with “frail little minds.” Yikes. He's not thinking about ALL colleagues, but "TDD purists". And even so, it's obviously a turn of phrase to dismiss the hardcore purism, not something the author generally feels about such people in their entirety.

Absolutely not. Setting up a strawman “absolute purist” (and yes, this is a strawman - no, you haven’t worked with real people taking the extreme strawman TDD position that could magically justify this) and then using needlessly insulting or belittling language to condemn the fake strawman is totally ridiculous. Your attempted defense of it is not acceptable. You could just as easily say something like, “People who t…

>and yes, this is a strawman - no, you haven’t worked with real people taking the extreme strawman TDD position that could magically justify this

No strawman required. There are real devs with extreme TDD zealotry. It's very possible that the author has worked with such devs, and I see no reason to doubt his experience. Your use of the word "strawman" above, doesn't magically make such devs which push TDD with zealotry as some silver bullet solution not exist.

The only reasonable reading of your point then is that those devs are not enough to justify the phrase "frail little minds". It would take some far more extreme, non-existent in the world, level of TDD zealotry (what you call a "strawman TDD position") to justify sthe use of a phrase.

But that's just you setting an arbitrary criterium. Which neither the author, nor I share. I'm fine with using the term "frail little minds" for people with real-world levels of TDD zealotry. I furthermore understand that it's just a phrase used by the author to refer to devs that can't get over their (real world level) TDD zealotry, that it doesn't imply anything about them otherwise, and that it's not a big fucking deal.

>See how that’s not dehumanizing?

No, I fail to see how the authors turn of phrase was dehumanizing. I leave such characterization to actually dehumanizing things, for example racism.

Re: Software engineering topics I changed my mind on

#245
post #151

> Functional programming is another tool, not a panacea. That's extremely true and I am not denying it. I'd like to add the nuance that us the Homo Sapiens seem to operate better when we are pushed into the right direction. Giving us too much choice -- like global mutability and OOP in general -- can cause analysis paralysis and make people do all sorts of panicked dumb choices in their software projects. As a guy wi…

> So while FP is just another tool, it's also a framework for thinking that helps people make better choices I’ve been getting more into functional programming this past year (via Clojure, though my day-job is mostly JavaScript/TypeScript) and this is the big takeaway for me. Type theory and monads may have their place, but thinking about separating logic from side-effects is, I think, the most valuable aspect of fun…

I agree that separating logic from side-effects is an excellent lesson that easily translates to less functional programming languages.

Another thing I tend to do now is order function arguments as if the programming language had partial function application. You can see this in JavaScript by comparing lodash to lodash/fp. I think once this practice is established on a team, it can help bring a more uniform feel to the code.

Re: Software engineering topics I changed my mind on

#247

It's good list. Except the TDD rant. TDD can be reframed as codified specifications with test verifications. Then, the TDD purists do have a point.

Then it’s not (edit: pure) TDD.

The TDD purists I’m familiar with think if you write any code before you write the tests, you’re doing it wrong.

Re: Software engineering topics I changed my mind on

#248
post #204

Earlier quoted context omitted.

Every time I mention the goodness of pencil and paper I get downvoted by so many youngsters. Some people will always disagree about some points. It's in their nature.

I disagree. The best medium is a whiteboard or a blackboard :p. (Really though, something about paper makes me afraid to "commit" things which make the pieces of paper no longer usable. Something made to be erased seems to be the trick for me).

And I find a whiteboard a bit more intimidating. It kind of implies performing your writings in public.

A notebook is a very personal thing. =)

Re: Software engineering topics I changed my mind on

#249

Earlier quoted context omitted.

There is not much wrong with reinventing the wheel. It is a less efficient use of time that often results in a beneficial serendipity. The opinion that reinventing the wheel is somehow a supremely evil satanic ritual is what prevents original solutions and allow expert beginners to become shitty decisions makers.

You are totally right but probably assuming you have a top notch and easily discoverable documentation that can guarantee that newbies won't spend 15 days reimplementing "that bash script you need once a year or so" that do the job in 2 minutes. However even if this case you might get lucky and end up with a new script that do the job in 30 seconds and everybody in the team have learn that documentation is very impor…

It's a matter of balance. No simple rule of thumb exists.

Sometimes it results in a much better solution, great! Sometimes it's a new wheel but with more awkward square-ish corners. Sometimes (and this is the worst because it's hard to explain) it is actually better but still likely has been a waste of the engineer's time - high cost vs low benefit, also often cooccurs with lack of team's capacity to maintain the new thing.

Re: Software engineering topics I changed my mind on

#250

Earlier quoted context omitted.

Absolutely not. Setting up a strawman “absolute purist” (and yes, this is a strawman - no, you haven’t worked with real people taking the extreme strawman TDD position that could magically justify this) and then using needlessly insulting or belittling language to condemn the fake strawman is totally ridiculous. Your attempted defense of it is not acceptable. You could just as easily say something like, “People who t…

> and yes, this is a strawman - no, you haven’t worked with real people taking the extreme strawman TDD position that could magically justify this No strawman required. There are real devs with extreme TDD zealotry. It's very possible that the author has worked with such devs, and I see no reason to doubt his experience. Your use of the word "strawman" above, doesn't magically make such devs which push TDD with zealo…

I think this whole thread is an example of The Weak Man argument in action, it’s neat to see it in real life just after it was posted on HN.
Post reply on HN