Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

671–680 of 788 posts

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

#671
post #127

One more that has opened my eyes recently: Good, empathetic UI design is invaluable . Get a professional UI designer. Engineers are (in the main) appalling at it and will cost you time and sales.

In my experience, finding an actually good UI designer is hard . Obviously they exist, but I don't know how to find them. It seems many — if not most — professional UI designers don't even understand that form inputs need labels. Got any tips?

I agree, it's hard. I'm lucky that I work for a large org with a separate design department. They are the ones that initiate how our products present themselves to the user, both in terms of styling and user flow, and they spend time and effort researching with guinea pigs what works best. It's very much "Design Thinking" in action. The outcome though is a monumental improvement in how easy the product feels to use. It's an artistic activity and is thus empathetic by nature. Being initially skeptical, I was won over very quickly.

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

#672
post #68
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…

There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space. I'm fond of saying that anythi…

Thanks for writing this. It makes me question if I'm too much concerned with code hygiene vs my coworkers.

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

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

There are aspects of code that matter and aspects that don't. I lump everything that doesn't matter under "code style", and cherish those who cherish the remaining aspects.

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

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

The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them. Things I beleive: - If you're picking up on code-style in PRs then your toolchain is backward. - If you're changing linting rules every month then you're focussed on the wrong things - It's better to have a consistent style than a perfect style

in my experience half the people don't bother installing the tools. They just don't care about formatting/linting, at all.

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

#675

Earlier quoted context omitted.

The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them. Things I beleive: - If you're picking up on code-style in PRs then your toolchain is backward. - If you're changing linting rules every month then you're focussed on the wrong things - It's better to have a consistent style than a perfect style

in my experience half the people don't bother installing the tools. They just don't care about formatting/linting, at all.

Just don’t make it optional.

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

#676
post #477

Earlier quoted context omitted.

Construction and civil engineering have been unable to agree on global conventions and standards, and they have a multi-millenia head start over software engineering. The US may claim to follow the "International Building Code", but it's just called that because a couple of small countries on the Americas have adopted it. For all intents and purposes it's a national standard. Globally we can't even agree on a system…

I’d say that globally we have agreed on a system of units and measurements. It’s just the US and a handful of third world countries that don’t follow that system.

Only USA, Myanmar and Libera are switching to metric

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

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

Having a consistent code style and adhering to a set of linting rules is important, but that they exist is far more important than their particulars. I get bored very fast when people argue about the visual presentation of their code. Use a formatter and be done with it. Same with linting rules; pick a set that your team can work with. If you dial everything up to 11, you’re going to have perfectly compliant code that doesn’t do anything. Recognize that compliance sometimes makes your code worse and pick your roles accordingly.

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

#678
post #77
post #68

Earlier quoted context omitted.

There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space. I'm fond of saying that anythi…

> the formatting and conventions of the blueprint Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information. I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenat…

I don't care about code styles of my colleagues, as long as it remains consistent and sane. But sadly it usually isn't.

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

#679
I don't have a strong opinion about dynamically typed vs statically typed but I have a very strong opinion about interpreted vs compiled.

I regret how neglected interpreted languages have become. I'm much more productive with interpreted languages than compiled (or worse; transpiled) languages. The iteration time is crucial for me. I don't want to wait even 30 seconds to test a change. After 20 seconds waiting for a compilation, my brain is already going into sleep mode. I can't have that.

For most application-building use cases, I will choose an interpreted dynamically typed language over a compiled statically typed one.

When it comes to low-level embedded use cases, or high-performance systems programming I will tolerate a compilation step but I won't pretend like it's not a negative.

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

#680
post #10

> Good management is invaluable. (I went most of my career before seeing it done well) Yes, and: it's difficult to describe, must be led from the top, and extremely difficult to evaluate from above.

If the person at the top can come down for a coffee with people who endured some bad management, and ask honest, non-loaded three questions, it can be measured qualitatively but with very high accuracy. The three questions are: - What should we start doing? - What should we continue doing? - What should we stop doing? This is an immensely powerful tool. Thanks to the awesome person who introduced me this. Addenda: "T…

Good leadership doesn't have the ideas. It leverages the collective to extract the best ideas and facilitates them.
Post reply on HN