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

Software development topics I've changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

81–90 of 788 posts

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

#81

Post by sgarland »

CrimsonRain wrote: post #62
sfn42 wrote: post #52

Earlier quoted context omitted.

I'd say avoiding long lines is one of the most important rules. I regularly have 2-3 files open side by side, I don't want to have to scroll sideways to read the code. 80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't real…

Functional code is more chained and need more space often. Descriptive names are better; tends to be longer. Buy ultrawide. 80 is for aholes who like to use small laptop and then force it on everyone else. 120/150 is reasonable. 200 is great.

200 is entirely too fucking long, and I code on a 43” 4K. I try to stay under 90 in deference to others, and if it looks better breaking at 80, so be it.

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

#82

Post by ZaoLahma »

> Most programming should be done long before a single line of code is written

Nah.

I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently.

Quite often you also have eureka moments with better solutions that just would not have happened unless you had code in front of you, which again makes you approach the problem entirely differently.

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

#83

Post by andyish »

> People who stress over code style, lining

You can do it whatever way you want but match the style of the project. I've worked on too many projects where someone decides their way is best and you end up with a mix of everything.

If you want to change the code style, okay, but change it everywhere and don't forget to test everything you've changed.

> Frontend development is a nightmare

But is it weird I kind of enjoy it every so often/

> Elegance is not a real metric

You're dam right it's not! Next time someone proudly presents a super elegant, refined, and minimalistic solution I'm going to phone them at 3am on a Saturday and get them to debug it while screaming at them about lost revenue or something.

> DynamoDB is the worst possible choice for general application development

Oh man, the amount of times I've seen some form of noSql and it's used as a relational database. 9/10 some rendition of SQL is more than sufficient.

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

#84

Post by hliyan »

Retric wrote: post #77
hliyan wrote: 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 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, that's why. We just need to ". Just then it struck me how we can't do this in software engineering, even when the project is basically a bog-standard business app: CRUD API backed by an RDBMS.

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

#85

Post by whstl »

CrimsonRain wrote: post #62
sfn42 wrote: post #52

Earlier quoted context omitted.

I'd say avoiding long lines is one of the most important rules. I regularly have 2-3 files open side by side, I don't want to have to scroll sideways to read the code. 80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't real…

Functional code is more chained and need more space often. Descriptive names are better; tends to be longer. Buy ultrawide. 80 is for aholes who like to use small laptop and then force it on everyone else. 120/150 is reasonable. 200 is great.

Yep.

And the laptop excuse is not even valid, I used a 11" MacBook Air for 10 years and even back then 80 always felt extremely limiting for me.

I just tested and: even when zooming +1 on VSCode and leaving the minimap open I can fit 140 chars without any horizontal scroll.

People demanding 80 columns always have some crazy setups, like an IDE where the editor is just a minuscule square in the centre, like an Osbourne 1 computer.

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

#86

Post by v3ss0n »

>People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.

This sticks out like sore thumb to me and I think you are coding solo for 10 years. If you manage to lead a team of developers or work with them you are screwed without linting rules and standardized code style. Even if they are applied it takes months to get to a get a team working in harmony - without them it will be a disaster.

- merge conflict hells because code style diferences - bad for code reviewers - bad to ready everyone's different code sytles.

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

#87

Post by olavgg »

One thing that I have never been more sure about after 20 years as a software developer, is that Hibernate is awesome! Seriously, it saves me ton of time and tinkering. It has support for native queries, and it is simple to transform your custom query into JPA entities. Using Hibernate has never been easier with the introduction of LLM, tell it what it needs to do, and see beautiful Hibernate examples code.

In my Spring Boot applications I log every SQL that is generated, and quickly spot unoptimizations, like lazy loading of entities instead of using join.

How ORM's behave in other languages and frameworks, like Python, Go, Rust is probably another story.

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

#88

Post by SushiFreak »

> DynamoDB is a good database

I cannot agree with this. I've constantly ran into issues around where you can insert data into with an attribute name such as "status" and then when you query it, it says you cannot query with a reserved keyword.

There is a myriad of other issues I've found and when asking around chat groups and forums, people universally dislike dynamo db.

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

#89

Post by binary132 »

hliyan wrote: post #68
latexr wrote: 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…

There is definitely something to be said for the idea that a shitslop engineering blueprint which still conveys correct design (maybe; who knows really?) is shitslop, whether or not the design is sound. In the case of software engineering, the blueprint is the implementation, too, so it’s not just shitslop blueprinting, it’s also shitslop brickwork (totally sound bones though I promise!), shitslop drywalling, shitslop concrete finishing and rebar work — and maybe it’s all good under the hood! Totally fine if all you’re building is a shithouse! But I think you get where I’m going with this.

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

#90

Post by cies »

Kototama wrote: post #11

> Typed languages are essential on teams with mixed experience levels I like this one because it puts this endless dilemma in a human context. Most discussions are technical (static typing ease refactoring and safety, dynamic typing is easier to learn and better for interactive programming etc.) and ignore the users, the programmers.

I think the size of the code base also matters: bigger size = having types is more important.

There is a contradiction here as: bigger size = compile speed more important AND types slow down compilation. More advanced typing features slow down compilation even more.

Post reply on HN