Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

711–720 of 788 posts

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

#711
post #496

Earlier quoted context omitted.

> I (16+ years developer) prefer to iteratively go between coding and designing I have an extra ten years on you and couldn't agree more. There are two jokes: - A few months of programming can save weeks of design. - A few months of design can save weeks of programming. Inexperience is thinking that only one of these jokes is grounded in truth. Recognizing which kind of situation you're in is an imperfect art, and in…

The difference between DRY and YAGNI is experience. Both are predicting the future, and you can only do that by having watched code evolve.

What's that saying? "Once is a mistake, twice is a coincidence, three times is a pattern".

Having to write something once, just write it.

Having to write something twice with small differences, think about it.

Having to write something three times? Consider refactoring.

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

#712
post #702

Earlier quoted context omitted.

The main problem is if you are not very careful it leaks its internals (ie. the relational model) into everything it touches. That's what the N+1 query problem is. Business logic shouldn't have to know that certain attributes will cause database queries. By carefully writing managers and having a rule to never use querysets anywhere else you can avoid it, but it requires everyone to understand this and all the Django…

The default test runner creates the test database automatically yes, but you can create Django model objects without touching the database, just use the class like a constructor and don't save it: Person(name="Foo", age=30)

OK, now try that with my ridiculously simple TodoList example, e.g. `TodoList(items=["item", "item2"])`. You can't do it! Nor can you construct an empty list then add items to it etc.

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

#713

Earlier quoted context omitted.

In my experience: Too large is any team larger than 10 people or any code base with more than 10,000 lines of code. Both of those would be considered tiny by most in the industry.

Hard disagree on the 10kloc limit. At a previous job, I maintained and enhanced a 50kloc monolith (written by someone else), usually by myself. My productivity was very high. At my current job, we've split a codebase that should be about 50kloc into more than 10 separate repositories; everything is still just as coupled but it's much harder to reason about and refactor. My productivity is much lower.

Agree, people underestimate the cost of interfaces that don't sit exactly where they need to sit (which is almost always the case)

http://number-none.com/blow/john_carmack_on_inlined_code.htm...

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

#714

Earlier quoted context omitted.

I do think there's value in manual formatting some code sections. For example, very large arrays, or alignment of semantic parts of a group of mathematical expressions. Ultimately, I think the only thing that matters is that the code is readable, consistent and you don't spend much time on how it looks. That said, if you have team members who somehow can't or won't copy the surrounding code style, then automatic lint…

See it like this - in 10 years when here is no original dev working on this, will this project still have the same code style? With a nice .editorconfig the probability is very high that it's mostly consistent. I can guarantee you any manual rules will be long forgotten and the IDE style will reign supreme - only your old "manual" formatting will stick out like a sore thumb.

here are the rules we enforce inside `pyproject.toml` https://gist.github.com/v3ss0n/3b0a8ac808f6930ea04e4ada62d90...

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

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

This is baldfaced relativism. It only takes a moment of reflection to understand the absurd consequences of this position. For example, how it becomes meaningless to speak of caring about the craft if there is no objective definition of what exactly one should care about, or what is important. It ceases to have intersubjective relevance.

> What you call “stressing over minutiae” others might call “caring for the craft”.

So what? The presence of disagreement is not an argument in favor of relativism and subjectivism. People can be wrong, and they can be wrong about what is valuable. Value is not subjective. The fact-value dichotomy is false.

That's the general principle. As far as this particular example is concerned, the author didn't say things like code style and linting rules have absolutely no value. They have some value. The question is how much, especially in the grand scheme of things, and whether one's concerns, attention, and efforts are proportioned to the objective value of such things. That's how this question should be framed. The author's position, charitably read, is that it is objectively irrational to obsess over such things.

If you wish to rebut, then go ahead and provide an argument, but don't retreat into the bollocks of subjectivism.

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

#716
post #652

Can someone explain the ORM thing to me? I’ve been a developer for 8 years but never really worked on an app that was really database dependent. ORMs for me have always been convenient, and the performance has been fine. I understand there’s obvious tradeoffs I’m making, and in some cases full control is necessary, but I’ve never seen it happen. What level of complexity does an app need to get to before an ORM become…

Personal pet peeves: * They hide the queries. When your DB or cloud service gives you a printout of your 10 slowest queries, you then have to figure out what object code that relates to. And then is there even a way to fix it, or are you stuck with the ORM? * LINQ-specific: Love the tech, but it's unclear whether my .wheres() are being sent upstream properly, or if I'm downloading the whole database and filtering it…

>When your DB or cloud service gives you a printout of your 10 slowest queries, you then have to figure out what object code that relates to

Not if you have proper telemetry set up... Tooling like instana was extremely useful for me to diagnose exactly where SQL statements caused issues

>Extra magic: if you've read a class from the db, pass it around, and then modify a field in that class, will that perform a db update: now? later? never?

For hibernate if you understand the concepts of:

- application level repeatable reads

- it's dirty checking mechanism

- when the session is flushed / entity lifecycle

That 'magic' isn't magic anymore. But every abstraction is leaky (even SQL)

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

#717
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 craft is the result, not the process.

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

#718
post #608

Earlier quoted context omitted.

I've seen and poked at a lot of the ORM-hating on here, and whenever I can get people to give specific examples instead of generic theory-level stuff, it's either not a problem in Django or Django has a fix you just need to learn about and use. The fixes have sometimes even been there for over a decade. It seems be leaps and bounds ahead of every other ORM out there.

The main problem is if you are not very careful it leaks its internals (ie. the relational model) into everything it touches. That's what the N+1 query problem is. Business logic shouldn't have to know that certain attributes will cause database queries. By carefully writing managers and having a rule to never use querysets anywhere else you can avoid it, but it requires everyone to understand this and all the Django…

>That's what the N+1 query problem is. Business logic shouldn't have to know that certain attributes will cause database queries.

I really don't get these arguments because in some form or another, ALL abstractions are leaky.

Example:

A novice developer might write a @OneToMany in hibernate without knowing the internals of the abstraction, causing n+1 problems. Two paths forward:

1. blame the abstraction

2. Learn (some) internals of the abstraction in order to use it correctly: dont do eager fetching, use join fetches, ... ( There's also tooling like hypersistence optimizer, digma, jpabuddy that comes to mind)

And by that same logic, would you berate somebody writing 'plain SQL' which - when expected with the query plan - turns out to be a very unperformant query?

Again, two options:

1. blame the abstraction

2. Learn (some) internals of the abstraction: analyze the query plan, perhaps write some indexes,...

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

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

I think you can apply what Stephen Fry say in the following video to programming : https://www.youtube.com/watch?v=J7E-aoXLZGY

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

#720
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

I know this sounds insane, but I used to work on some big svn codebase with many developers, without any fancy formating tools AND no one cared about consistent style.

One interesting thing that happened was the ability to guess who wrote what code purely based on coding style.

Post reply on HN