Software engineering topics I changed my mind on • Hacker News Board

Re: Software engineering topics I changed my mind on

#291

Post by captrb » Sun, Jan 24, 2021, 5:57 AM UTC

Aeolun wrote: post #152

dnautics wrote: post #115

Here's what i have to say about TDD (I do not practice TDD on a day-to-day basis). Even if you don't use it, you should know what it is. If you choose to use it religiously, that's probably a bad choice, but if you don't do it ever, you are missing out on a huge tool. In general, if I see an insurmountably complex challenge ahead of myself, sometimes TDD (especially detroit-style TDD) is a tool to refocus my attentio…

I think the best part of doing test driven development (or similar) is that making your code easily testable generally also makes it architecturally sound.

Yes. I like that TDD - when I judiciously employ it - makes me think about my interfaces. It’s like a pre-PR that forces me to question whether the intent is clear. It makes me reference guidance from DDD and single-responsibility-ish idioms.

Re: Software engineering topics I changed my mind on

#292

Post by spamizbad » Sun, Jan 24, 2021, 5:58 AM UTC

tasty_freeze wrote: post #281

> People who stress over code style, linting rules, or other minutia are insane weirdos I'm less concerned about which coding style, but it is important that everyone (mostly) follows the same coding style. Not all coding style rules are minutia. I've worked on code bases which have a mix of hard and soft tabs, with tabs sometimes mixed in the middle of the line, not just at the start of line, and where different aut…

I think this gets solved easily by using autoformatting tools and use them as pre-commit hooks or an informal agreement among the devs to have their dev tools run it on save or whatever.

Re: Software engineering topics I changed my mind on

#293

Post by xmprt » Sun, Jan 24, 2021, 5:58 AM UTC

woutr_be wrote: post #271

> Clever code isn't usually good code. Clarity trumps all other concerns. I'm glad I'm not the only one who thinks this way. I've had countless arguments with colleagues about this, and they always made it seem like I was the crazy one for thinking this. They would often optimize or use clever tricks in their code, to the point that unless you asked that specific engineer, nobody would understand it. In most cases, t…

Clever code that's actually significantly faster is fine as long as you document every single thing that's clever about it, even if that means writing 20 lines of comments for a 2 line function.

The worst thing is someone who writes a clever one liner without any comments because that would "ruin" the elegance of the one liner and because their code is "self-documenting"

Re: Software engineering topics I changed my mind on

#294

Post by rebeccaskinner » Sun, Jan 24, 2021, 5:59 AM UTC

thayne wrote: post #230

> Java isn't that terrible of a language True. It isn't a great language, but isn't terrible. What is terrible are the over-engineered, over-abstracted APIs that are relatively common in the Java ecosystem.

This was probably the one bit that I really disagreed with. I've never been a Java developer, but I've had to touch it a few times in my career, and have quite happily left very well paying jobs for lower paying jobs just to avoid having to write more Java. I can't rightly think of any language I would plausibly have to use in industry that I find more unpleasant than the Java and the entire JVM ecosystem (disclaimer: I've never used PHP).

I'll buy that Java might, in purely technical terms, be not that terrible of a stack, but it's just so deeply unpleasant to use, such a profoundly nightmarish vampire of morality, so utterly and irredeemably cruel in it's ability to strip all joy out of the art of software development, that I can't possibly agree that it "isn't that terrible of a language".

Re: Software engineering topics I changed my mind on

#295

Post by rmk » Sun, Jan 24, 2021, 6:01 AM UTC

RcouF1uZ4gsC wrote: post #136

d3nj4l wrote: post #72

Earlier quoted context omitted.

Also, having consistent formatting makes it very easy to read through large amounts of code. If you know how the code is laid out, you don’t need to focus on everything and can “squint” through it to get a good idea of what’s going on.

The solution to this is to use an automated formatting tool for the entire team and have it automatically run prior to review and be done with it.

This is done in many teams. Go has made it really easy via its gofmt tool. The trouble is that it's hard to do on a large existing codebase that's not consistently formatted: doing a mass format messes with the line-by-line commit history, and on occasion introduces bugs.

Re: Software engineering topics I changed my mind on

#296

Post by quelltext » Sun, Jan 24, 2021, 6:01 AM UTC

mattdeboard wrote: post #286

quelltext wrote: post #203

Earlier quoted context omitted.

Oh god, I hate the PM abbreviation. Product managers and project managers have a bit of overlap (as the former also do project management to an extent, just like engineers), but they are different and having them provides different benefits. Why do we abbreviate both with PM? I never quite know which is referred to.

Don’t forget “program manager” too

Oh god, yes.

Re: Software engineering topics I changed my mind on

#297

Post by illustriousbear » Sun, Jan 24, 2021, 6:03 AM UTC

Another low effort blog post that Hackernews readers have upvoted because it says obvious things that they agree with.

Quality on blog posts and articles is taking a bit of a dip lately.

Re: Software engineering topics I changed my mind on

#298

Post by woutr_be » Sun, Jan 24, 2021, 6:04 AM UTC

xmprt wrote: post #293

woutr_be wrote: post #271

> Clever code isn't usually good code. Clarity trumps all other concerns. I'm glad I'm not the only one who thinks this way. I've had countless arguments with colleagues about this, and they always made it seem like I was the crazy one for thinking this. They would often optimize or use clever tricks in their code, to the point that unless you asked that specific engineer, nobody would understand it. In most cases, t…

Clever code that's actually significantly faster is fine as long as you document every single thing that's clever about it, even if that means writing 20 lines of comments for a 2 line function. The worst thing is someone who writes a clever one liner without any comments because that would "ruin" the elegance of the one liner and because their code is "self-documenting"

> The worst thing is someone who writes a clever one liner without any comments because that would "ruin" the elegance of the one liner and because their code is "self-documenting"

Sadly this was some of my colleagues, no documentation and clever one liners without comments and often obscure naming conventions. And again, we didn't need the performance benefits for our use case. I think in the end it was just a play to keep some people employed, because without them we wouldn't be able to work on this part of our application.

Sadly for them the business decided to outsource and they ended up being forced to switch teams.

Re: Software engineering topics I changed my mind on

#299

Post by projectileboy » Sun, Jan 24, 2021, 6:05 AM UTC

crescentfresh wrote: post #267

temporallobe wrote: post #150

Earlier quoted context omitted.

Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their wo…

> not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.

In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors.

Re: Software engineering topics I changed my mind on

#300

Post by snidane » Sun, Jan 24, 2021, 6:07 AM UTC

> So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot.

Very true. "Best practice" are most often just "common practices" - how we've done things here forever.

That's great for standardization. It gets annoying when each team member does things their own way.

But it's a stretch to call them best. The research into what is truly best, A/B tests of various methods, or building prototypes of new experimental frameworks is rarely scheduled in sprint plans. It's actually some crazy programmers who try out these experiments in their off time based on their experience with the actual problems, which leads to truly innovative things.