Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What is “good taste” in software engineering?

seangoedecke.com

Post reply on HN
Print view View original

221–230 of 245 posts

Re: What is “good taste” in software engineering?

#221

Post by 01HNNWZ0MV43FF »

Etheryte wrote: post #50
chii wrote: post #41

Earlier quoted context omitted.

> everyone else says "pshaw, anyone could have written that!" it really depends on the problem domain tho, doesnt it? Would you call the fast inverse square root[0] code good taste? [0] https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...

Being a good fit for a given purpose doesn't mean that something is in good taste. That piece of code is very performant, yes, but I'm pretty sure none of us would want to meet it in code review, save for a few niche edge cases. To draw a parallel from fashion, for most part, arctic snow gear does not win fashion prizes, but it does keep you alive. There's a time and place for both, doesn't mean that everything usefu…

> I'm pretty sure none of us would want to meet it in code review, save for a few niche edge cases.

It does no I/O and has no action-at-a-distance. The float-long-float casts are the worst part.

If a coworker brought it to me with a performance justification and some unit tests I'd be pretty happy to pass it.

Re: What is “good taste” in software engineering?

#223

Post by cardanome »

JKCalhoun wrote: post #139
t43562 wrote: post #86

> In other words, immature engineers are too inflexible about their taste. They know what they like, but they mistake that liking for a principled engineering position. I have come across this although I think quite experienced engineers can suffer from this kind of immaturity. Aeons ago I used to help friends with their Computer Science assignments. I remember the temptation to rewrite their code because I didn't li…

"Good taste" I have found comes from experiencing "good" API's and other "good" code. You know good code (and API) when you see it — and in time you should be able to write it as well. In short though, it's hard to have good coding taste when you are new to the field. (But, as you point out, it's not true that experience guarantees you will acquire taste — you have to both be looking out for it, recognize it, and be…

I don't think code is inherently bad or good without defining the exact context and purpose of the code.

It all depends on what field you are in, the business requirements, the team and so many other factors.

What is the most important aspect: Easy to extend, easy to read or most optimal performance?

Is your team more comfortable with the functional style of programming or OO?

Do you follow existing conventions your team has established or current best practices?

Do you implement everything yourself or do you use external libraries?

Do you write code that makes you look smart using tech that looks good on your resume or do you use the simplest method to solve the program?

The is no one right way to program.

Re: What is “good taste” in software engineering?

#224

Post by renshijian »

This news story about AI simulating taste reads like a romantic dance between technology and humanity. It quietly suggests: One day, when you long for your grandmother's braised pork, you may no longer have to search through a faded recipe—AI can "taste" the perfect amount of sugar color and cooking time through the screen, allowing the flavors of memory to transcend time and space. Most touchingly, this technology attempts to gently translate the most intimate human sensory experiences—those indefinable "mother's taste" and "first love's dessert"—into the language of data. It's like a time machine for the sense of taste, immortalizing the destined-to-disappear world of everyday life in the digital world. When algorithms begin to understand the nostalgia inherent in sweet and sour spare ribs, technology truly possesses the warmth of humanity

Re: What is “good taste” in software engineering?

#226

Post by sevensor »

lukan wrote: post #216
idontwantthis wrote: post #211

Earlier quoted context omitted.

Asking questions is always the best way to correct someone (Hey Socrates). You avoid triggering defense, and if it turns out you were wrong, you don’t sound like a jackass.

You still have to be sensible in the way how you ask questions. Very possible to intentionally or unintentionally insult and trigger lots of other things just by "asking a question" (my speciality).

I try to channel Terry Gross. “You say it’s very important to frob the encabulator before and after you linearize the splines? Interesting, tell me more about that.” I don’t just want to correct bad code, I want to understand the misunderstandings that produced it and fix those. Otherwise you just wind up with more bad code.

Re: What is “good taste” in software engineering?

#227

Post by sevensor »

t43562 wrote: post #86

> In other words, immature engineers are too inflexible about their taste. They know what they like, but they mistake that liking for a principled engineering position. I have come across this although I think quite experienced engineers can suffer from this kind of immaturity. Aeons ago I used to help friends with their Computer Science assignments. I remember the temptation to rewrite their code because I didn't li…

> Principles are a bit subjective and if you lean on them all the time without thought it's a sort of laziness - you're not really examining the situation and what it merits.

I think there’s a very important developmental stage for programmers where they buy in to a set of principles past the point of all reason. It can be maddening to work with them at this stage. They’re all in on type systems or OOP or hexagonal architecture or what have you, and everything looks like a nail for that hammer. But eventually, some of them see the shortcomings of the one true way and come out better programmers for it.

Re: What is “good taste” in software engineering?

#228

Post by mrheosuper »

idontwantthis wrote: post #211
stronglikedan wrote: post #154

Earlier quoted context omitted.

I don't ever tall a junior that they are doing something in a less-than-optimal way. I always ask them why they're doing it that way. At the end of each conversation, one of us has learned something. Sometimes I learn an alternate approach, and sometimes they learn why their alternate approach won't work in the long run. Either way, it's never a confrontational conversation.

Asking questions is always the best way to correct someone (Hey Socrates). You avoid triggering defense, and if it turns out you were wrong, you don’t sound like a jackass.

"Do you know where you are wrong ?" will definitely trigger people's defense

Re: What is “good taste” in software engineering?

#229

Post by fragmede »

cardanome wrote: post #223
JKCalhoun wrote: post #139

Earlier quoted context omitted.

"Good taste" I have found comes from experiencing "good" API's and other "good" code. You know good code (and API) when you see it — and in time you should be able to write it as well. In short though, it's hard to have good coding taste when you are new to the field. (But, as you point out, it's not true that experience guarantees you will acquire taste — you have to both be looking out for it, recognize it, and be…

I don't think code is inherently bad or good without defining the exact context and purpose of the code. It all depends on what field you are in, the business requirements, the team and so many other factors. What is the most important aspect: Easy to extend, easy to read or most optimal performance? Is your team more comfortable with the functional style of programming or OO? Do you follow existing conventions your…

> Do you write code that makes you look smart using tech that looks good on your resume

> The is no one right way to program.

Those two statements taken together makes me suspect you think there is.

Re: What is “good taste” in software engineering?

#230

Post by Zanfa »

maccard wrote: post #102
medstrom wrote: post #73

Earlier quoted context omitted.

Can you paint an example of a "partially broken compass" engineer?

I've worked with engineers who can happily write greenfield code that passes the spec, but fails on any inputs that are not clearly defined as valid. In an effort to fix this, they add layers and layers and layers of complexity and edge cases to the app logic, and intermix the actual app logic with handling invalid input. something like func isEven(s string) bool { num, _ := strconv.Atoi(s) return num % 2 == 0 } beco…

I’ve definitely seen way too much code like the examples above. Another side effect to this is it tends to leak all over and can result in exponentially more code. What would’ve been a 2-line change at the API boundary, becomes ten lines of manual edgecasing every time it’s used in business logic and results in impossible states that need even further typing and handling. And don’t forget the tests that now need to cover invalid inputs everywhere, not just the API boundary.
Post reply on HN