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

Software engineering topics I changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

551–560 of 704 posts

Re: Software engineering topics I changed my mind on

#551

Post by IshKebab »

user5994461 wrote: post #500

>>> Typed languages are better when you're working on a team of people with various experience levels I picked up the opposite qualm after working in a multi million line codebase in python, that goes back almost 2 decades in a large bank. Dynamically typed languages actually work, at all scale. Statically typed languages are good for simple types (int/string) but they're catastrophic for complex types (dict, map, da…

I strongly disagree. Static types have so many benefits they easily outweigh the only downside (you have to actually write them).

I'm sure it's possible to make large dynamically typed codebases work with a lot of effort and a ridiculous amount of testing but it would clearly be easier with static types.

There's a reason Typescript is so popular and pretty much every dynamically typed language has some effort to add type hints (including Python!).

There's also a reason why you see so many blog posts about large dynamically typed code bases being converted to statically typed languages or having type hints added (e.g. Dropbox) but I don't think I've seen a single large company go the other way, because that would be crazy.

Re: Software engineering topics I changed my mind on

#552

Post by TobTobXX »

thequux wrote: post #473

> Clever code isn't usually good code. Clarity trumps all other concerns. Generally this is true, but with the caveat that what actually matters is 90th percentile (or maybe even 99th percentile) complexity. If you have a choice between spreading low-grade complexity across the codebase or having one module that is nearly incomprehensible but that provides an abstraction that makes the rest of the code very simple, t…

On some project I have used this method. It us usually one or two pure functions in a single file littered with comments. It is a complete abstraction, so it has absolutely nothing in common with the DB / UI code.

Every once in a while I have to touch it. Then I ignore everything else and just focus on this one part. Pen and Pencil is the most valuable tool for this.

Re: Software engineering topics I changed my mind on

#553

Post by 3836293648 »

satya71 wrote: post #539

Solid list. I'll disagree this. > People who stress over code style, linting rules, or other minutia are insane weirdos We use Black for Python, Prettier/Standard for Typescript. Code is readable across developers and there is no question about how it should be formatted. Make this easier: > Clever code isn't usually good code. Clarity trumps all other concerns.

I read it as people who stress over what the style should be, not people who think there should be a style.

I have my opinions on what should be in .clang-format, but that's debatable and beside the point. HAVING a .clang-format and using it is a different question and something very important (obviously you should use go-fmt or rustfmt or whatever is applicable, but clang-format covers most of it)

Re: Software engineering topics I changed my mind on

#554

Post by dstola »

lillecarl wrote: post #465
mabbo wrote: post #456

Earlier quoted context omitted.

> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer p…

What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?

Politically incorrect opinion incoming: the most efficient teams are homogeneous for the same reasons that military battalions are best off being homogeneous.

1. it improves communication

2. shared experiences and culture

3. overall better team cohesion and culture building

I would go almost as far as saying that diversity is a red flag for a startup and that diversity starts to have benefits only in bigger companies

Re: Software engineering topics I changed my mind on

#555

Post by pcmoney »

hnysahglie wrote: post #549

Best one: "TDD purists are just the worst. Their frail little minds can't process the existence of different workflows."

They can they just typically don’t want to go roll about the muck once they have achieved full galaxy brain.

Mostly trolling but I do think following XP dogmatically early in my career gave me an accelerated appreciation and understanding for a lot of the other bullet points. I don’t always TDD now but I can typically tell if code was written via TDD or not just by reading it.

Re: Software engineering topics I changed my mind on

#556

Post by gilbetron »

koonsolo wrote: post #389

Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…

I have 30 years of pro experience, so I'm like you plus another 10 years of confusion. I agree with the list as well, and like your (and others) additions. I especially feel that parts about zealotry. The worst are Medium developers, those with a Medium amount (3-7 years) of experience that get their dogma from Medium articles.

Re: Software engineering topics I changed my mind on

#558

Post by erikpukinskis »

skohan wrote: post #494
thequux wrote: post #473

> Clever code isn't usually good code. Clarity trumps all other concerns. Generally this is true, but with the caveat that what actually matters is 90th percentile (or maybe even 99th percentile) complexity. If you have a choice between spreading low-grade complexity across the codebase or having one module that is nearly incomprehensible but that provides an abstraction that makes the rest of the code very simple, t…

If I understand what you're talking about, I tend to disagree - I've had a bad experience in general with "pure abstraction" layers in projects. It sometimes seems like a good idea to have this "magic" component which automates everything and takes care of all the hard stuff, but in practice it creates a whole host of problems. For instance, maybe it works at first, and then your requirements change in a way that doe…

My rule for major new abstract components is: “if you’re going to do that, you have to get it right”.

It’s fine to have a major abstraction, but it needs to actually make a problem space disappear, for some definition of “entirely”.

That means: - great code - great documentation - tested - engineering resources assigned to maintain it full time

... for as long as it takes. Until you reach that level of “makes the problem space disappear entirely”.

So when someone suggests a new abstraction, I just ask if we’re going to invest all of that. And if not I suggest we stick to just using the tools we already have.

Re: Software engineering topics I changed my mind on

#559

Post by spockz »

pvinis wrote: post #420
crescentfresh wrote: post #267

Earlier quoted context omitted.

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

we use these three questions: - what you did? - what will you do? - do you have any blockers? usually the blockers part is useful to know if anyone is having any issues with anything that others could help.

What you did is typically not useful to share. This can be seen on the scrum board. What you do want to share is your experience, what was hard/easy/remarkable or when you are stuck. Just reporting what you did goes quickly to defending your hours or something.

Re: Software engineering topics I changed my mind on

#560

Post by satya71 »

3836293648 wrote: post #553
satya71 wrote: post #539

Solid list. I'll disagree this. > People who stress over code style, linting rules, or other minutia are insane weirdos We use Black for Python, Prettier/Standard for Typescript. Code is readable across developers and there is no question about how it should be formatted. Make this easier: > Clever code isn't usually good code. Clarity trumps all other concerns.

I read it as people who stress over what the style should be, not people who think there should be a style. I have my opinions on what should be in .clang-format, but that's debatable and beside the point. HAVING a .clang-format and using it is a different question and something very important (obviously you should use go-fmt or rustfmt or whatever is applicable, but clang-format covers most of it)

Hmm. Good point
Post reply on HN