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

21–30 of 704 posts

Re: Software engineering topics I changed my mind on

#21

Post by bawolff »

Usually i disagree with these types of lists, but this one seems pretty spot on.

My only quible would be that only code quality static analysis is useful. Security static analysis on the other hand (e.g. taint analysis to find security bugs like XSS) is pretty overrated most of the time unless you work really hard to make it fit in your context.

I also think linting rules are important, not for what they actually do, but just to get everyone to stfu about variations in code style that dont matter and arguing about more important things.

Re: Software engineering topics I changed my mind on

#22

Post by dozzman »

alain_gilbert wrote: post #11
dimtempo84 wrote: post #2

I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.

I used to be an "insane weirdo", but at some point I gave up. Now, I just focus on code correctness, merge and fix the code style myself, avoiding a lot of useless back and forth. My hope is that people like to see their name when they "git blame" (what's the PC version of "blame" again?) So they will over time learn to follow the code style in order to keep their name there.

If you can, commit wholely to a parsing formatter and plug it into your CI pipeline. I've come to realise over the years that its not style I care about per-se, but consistency. With a parsing formatter and an opinionated linter, you're pretty much covered automatically across all development and developers.

Re: Software engineering topics I changed my mind on

#25

Post by baccheion »

I dislike sacrificing purity, but I am capable of doing it.

Most software is a hogpile of sh*t destined to rot. It simply won't last. Those sections that do (if it never has to be touched, it also didn't last) are usually subpar. Especially with accumulating "ship ship ship" modes, costs, and competing via speed, it'll only get worse.

Most time spent cleaning up code and improving architecture is time wasted. The startup will fail, the startup will get bought and shutdown, the project will get scrapped, the service will no longer be used, etc. What little survives will be in a state of constant turnover, one that leads to the same junk.

Any optimizations/streamlining/elegance would be to address near-term usability issues. That is, the code is unwieldy to adjust each day and so needs to be reworked. Otherwise, it's wasted effort. Further, if it will linger, then would be the time to clean and file away. On the other hand, companies may still fear refactoring at that time as it risks introducing bugs.

Most code sections that linger are not foreseen as being worthy. By then, it's too late. Other sections never matter, as they end up untouched.

Re: Software engineering topics I changed my mind on

#26

Post by bawolff »

cbdumas wrote: post #13

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql These two bullet points resonate with me so much right now. I'm a consultant and a lot of my client absolutely insist on using DynamoDB for everything . I'm building an internal facing app that will have users numbering in the hundreds, maybe. The hoops we are jumping through to break this app up into "microservi…

People always talk about nosql scaling better, but some of the largest websites on the internet are mysql based. I'm sure some people have problems where nosql is genuinely an appropriate solution, but i find it hard to believe that most people get anywhere near that level of scalability.

Re: Software engineering topics I changed my mind on

#27

Post by alain_gilbert »

dgs_sgd wrote: post #23
tuke wrote: post #3

Are the things under "Things I've changed my mind on" things you believe now, or have stopped believing? (Can't tell which way the change of mind is.)

Directly under "Things I've changed my mind on" the author writes "Things I now believe".

There is a new sentence in the "Things I've changed my mind on" section:

> Things I now believe, which past me would've squabbled with:

That phrase was not there originally when the article was posted.

Re: Software engineering topics I changed my mind on

#28

Post by mlthoughts2018 »

The author of this seems like a real joy to work with

> “TDD purists are just the worst. Their frail little minds can't process the existence of different workflows.”

Imagine thinking about colleagues as people with “frail little minds.” Yikes.

Many of the other points betray serious attitude and perspective problems, but it was forgivable until getting to that last bullet and realizing, no, this is just a person with a shitty attitude.

Re: Software engineering topics I changed my mind on

#29

Post by jogjayr »

dboreham wrote: post #10
chenmike wrote: post #5

Earlier quoted context omitted.

Just use a linting tool? Using a linter allows me to care a lot about formatting (which I do) while not consuming a ton of my team’s time enforcing it.

Then you get to have many meetings about which litter and lint rules to use.

Organize one meeting, tell everyone you don't care which one but they have to decide on one by the end of the meeting. Otherwise you're deciding one for them (phrase it as "I have a PR ready to go adding this one"). Assuming you have the sufficient authority (managerial, technical, or buy-in from your manager) for such an ultimatum, of course.
Post reply on HN