In my experience when working on and/or leading a team, having good and clear code style/guidelines helps the members of the team understand other people’s code much more easily. It often also serves as much easier to understand historical record when looking at previous contributions. I find it’s best to leverage tooling that enforces team conventions so that programmers don’t have to “stress” about it.
Software development topics I've changed my mind on
691–700 of 788 posts
Re: Software development topics I've changed my mind on
#692> 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…
You have to read between the lines to pick that up though, so your criticism seems valid.
Re: Software development topics I've changed my mind on
#693> 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
Re: Software development topics I've changed my mind on
#694Earlier quoted context omitted.
The way I like to use OO (usually not real OO, but rather class-based languages) is to minimize its mutable state. Often mutability is merely a lack of using builder patterns. Some state can be useful as long as it's easy and makes sense to globally reset or control. It's like writing a process as a construction of monads before any data is passed into it. Similarly a tree of processing objects can be assembled befor…
Exactly. Automatically adding getters and (especially) setters to a class is something I see far too often.
I've probably written more Java than any other programming language during my career, and I've seen both good and bad ways of writing Java.
Bad java heavily uses lots of inheritance, seems to think little about minimizing exposed state, and (unrelated to this discussion) uses lots techniques I like to call 'hidden coupling' (where there are dependencies, but you can't see them through code, as there is runtime magic hooking things up).
Good java almost never uses inheritance (instead composes shared pieces to create variation on a theme), prevents mutability wherever possible, and makes any coupling explicit for all to see.
Good java still has classes and objects, but starts to look pretty 'functional'.
Re: Software development topics I've changed my mind on
#695Earlier quoted context omitted.
Maybe a new paradigm for code formatting could be local-only. Your editor automatically formats files the way you like to see them, and then de-formats back to match the codebase when pushing, making your changes match the codebase style.
It's a decent idea, but it's weird reviewing code you wrote in saying GitHub, it looks totally different. Imo not a show stopper but a side effect you have to get used to.
Re: Software development topics I've changed my mind on
#696> ORMs are the devil in all languages and all implementations. Just write the damn SQL What are the main issues people run into with ORMs? I've used Django ORM for years and written some relatively large applications using it without much problems. Complex queries and aggregations can result in quite hairy code though.
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.
Ultimately Django just doesn't fully do the object-relational mapping. It maps single rows, but that's it. So it doesn't really support objects that contain lists or sets etc. Things like SQLAlchemy can actually map data from a relational database into plain old objects. Those objects can be instantiated (e.g. in tests) completely independently of the database. Notice how in Django you can't test anything without a database being present? Why do I need to store an object in a db just to test some method on an entity?
Re: Software development topics I've changed my mind on
#697> 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…
Abhored obstructionists and covert saboteurs are also the ones that care for the details.
You need to care about right kind of details. Any specific linting is not that kind. Linting at all is.
Artisan without a proper sense could spend weeks exquisitely decorating a spoon with gaping hole in the middle. State of nearly all software is more or less horrible. Choosing the right linting rules is most often than not putting lipstick on a pig.
Re: Software development topics I've changed my mind on
#698I wonder how much of this can be qualified with "after you've been hired".
Between two university graduates with equal skills in technical interviews and splicing linked lists and recursive-descent parsing and whatever, if one has better soft skills, you hire that one.
The question is what you do between one who is better at soft skills and another who is better at doubly linked lists or group-by queries or docker orchestration or whatever tech you're asking about in the interview. Empirical evidence suggests you hire the second person and support and expect them to skill up once they're in.
If you have spare time at uni, working on both soft and techy skills is great, if you have to trade off opportunity costs, the advice I hear a lot is invest on the technical side first.
Re: Software development topics I've changed my mind on
#699> 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 can also understand the fuss better in indentation-is-structure languages like python.
Re: Software development topics I've changed my mind on
#700Earlier quoted context omitted.
To reduce your argument to its essence, you're saying typesetting is part of the craft of writing. I've yet to meet an author who believes this (other than enjoying editing their own work as output from a typewriter), and I think the same broadly applies to code. It's not that everyone thinks these things are unimportant, it's that caring deeply about doing them a particular way is orthogonal to the craft. It's somet…
More than one writer refuses to use a computer, preferring typewriters. Harlan Ellison learned how to repair typewriters after he could no longer find anyone to fix his. Stephen King wrote Dreamcatcher with a fountain pen. Authors totally obsess over details that seem irrelevant to people outside that craft.
That doesn't mean it's normal for them only use a certain typewriter because of its typeface, insist a publisher use Garamond to typeset their book for publication, or refuse to write without a certain margin.
To bring it closer to programming, in collaborative writing especially (think manual writing at large corporations), nobody is insisting that everyone indents paragraphs their way because it's better. As long as there's consistency those matters are best left to the printer. When I was younger I knew a lot of technical writers who in fact really disliked the move to Word from traditional word processors, because they didn't want to be distracted by those things.