Earlier quoted context omitted.
There is a class of people who refuse to see computer programming as an art. They try to shoehorn it into being an engineering discipline and comparing it to authoring a book (something you can't give timelines on or T-Shirt size) probably horrifies them.
Ah, the joys of overloading. Do you mean "art" as the high-brow stuff we see in galleries and are produced in volumes of dozens per artist-years? Or do you mean "art" as the more common stuff that's produced by artisans are the rate of dozens per week? Because to me it's more the latter -- I'm an artisan, not an artist.
Software development topics I've changed my mind on
561–570 of 788 posts
Re: Software development topics I've changed my mind on
#562> ORMs are the devil in all languages and all implementations. Just write the damn SQL It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables…
Statically-typed queries written in a mini-DSL within your application language seems like such a joy!
But then the configuration is a hassle. The DbContext lifecycles are a hassle. The DbContext winds up a big ball of mutable state that often gets passed all up and down your call stack, reducing the ability to reason about much of the code locally. Was this instance initialized with or without change tracking? How many and what changes have been applied? Were these navigation properties lazily or eagerly loaded?
And it promises to keep your domain persistence ignorant with its fluent configuration syntax. But then you have compromise on that here, then compromise in it there.
Pretty soon, you realize that you started out building a project for domain X or domain Y, only to realize that you're trying to shoehorn domain X/Y behavior into your Entity Framework app.
Re: Software development topics I've changed my mind on
#563> Monoliths remain pretty good > It's very hard to beat decades of RDBMS research and improvements > Micro-services require justification (they've increasingly just become assumed) That is so true. I am still deploying good old .war files to full blown Java app servers backed by simple SQL databases (all clustered and stuff) with some handwritten cli tools and a Jenkins server. Shit is fast, shit scales, shit just wo…
Re: Software development topics I've changed my mind on
#564> 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…
If you want to compare to artisans - they were stressing about details that customers see, details that customers don’t see were to cut corners on. Making fuss about indentation in code file is not artisanal. It is insane weirdo if we are charitable and if not clueless and childish.
Sure, but there's two differences between artisans and programmers.
Firstly, most artisans produce sellable products. Once the customer has bought an item, they would never see it again. I'm pretty sure that if there was a minor error on a self-produced table or a vase and it was standing in the artisan's own living room, they'd not be able to unsee it, and still work to correct it.
Secondly and more importantly: code is not just the product that programmers work on, it's also the workshop that programmers work in. And you bet your ass that artisans are very anal about the layout and organization of their workshop. Put away screws in the wrong box, or throw all the dowels of multiple sizes in the same container? The carpenter will fire his apprentice if it happens more than once; place your knives in the wrong place in a kitchen and the chef will eat you alive; not properly wearing or storing safety equipment can be a fireable offense in many places.
To me, a code review is how you close your workshop for the week: tools are cleaned and stored, floors are tidy enough to walk around, and the work area is available so I can come back on monday and be productive again. I shouldn't have to spend monday cleaning glass shards because someone left a hammer standing straight up on a glass table - or chasing down last week's lunch because someone left the fridge open and now the cheese has grown legs.
So no -- making fuss about code style and quality can certainly be artisanal (maybe not about indents specifically, but can certainly be about textual organization). Because the code is the workshop, and you know the next time you will enter this room it will be because of a high-priority demand and you can't afford to spend half your day cleaning up what you couldn't be bothered to do last time.
Re: Software development topics I've changed my mind on
#565Earlier quoted context omitted.
> OO is not evil, but it also shouldn't be your default solution to everything. With Smalltalk and Objective-C both being effectively dead at this point, that really only leaves Ruby (and arguably Erlang) as the only languages that are able to express OO. And neither of those languages are terribly popular either. Chances are it won't be your default solution, even if you want it to be.
> and arguably Erlang Curious about your case for this. I don't know a lot about Erlang other than "it's what Elixir is based on" or whatever technical jargon is more accurate. I thought it was functional.
I was mostly riffing on the time Joe Armstrong, creator of Erlang, said that Erlang might be the only object-oriented language in existence. Although he's not exactly wrong, is he?
> I thought it was functional.
I think that is reasonable. Objects, describing encapsulation of data, are what define functional. Without encapsulation, you merely have procedural. Of course, that still does not imply the objects are oriented...
For that you need message passing. But Erlang has message passing too! So there is a good case to be made that is object-oriented.
Re: Software development topics I've changed my mind on
#566> ORMs are the devil in all languages and all implementations. Just write the damn SQL It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables…
As far as I know this is a very oldschool view on how to treat dbs, but I still think this is the only correct one.
I hate ORMs with a passion - they're just a potential source of bugs and performance issues, coming from either bugs in the engine, devs not understanding SQL, devs misjudging what query will get generated, leaky abstractions etc.
It's big enough of an ask to understand SQL itself, it's the height of folly to think you can understand SQL when it's being generated by some Rube-Goldberg SQL generator, especially if said generator advertises that you don't need to know SQL to use it.
Re: Software development topics I've changed my mind on
#567Earlier quoted context omitted.
Is it ms? seconds? days? weeks? months? How far up do I have to read to figure that out? When I'm looking at a test case is broken, I ideally want context IN the actual test that lets me understand what the test author was thinking when they wrote it. Why does this test exist as it does? Why are the expectations that are in place valid? Write the comments for you-in-2-years.
Do you not know the conventions of your project? Doesn't your project have a convention that all time is in ms (second, weeks...)? If your project doesn't have that convention such that everyone knows than the code should be timeMs++; You may also have a time type and so you can use your IDE to examine the type.
networkTimeMs++; // Callback occurs after timeout
timeSec++; // Advance time to check whether dependent properties update
utcTime++; // Leap second, DON'T advance ntpTimeRe: Software development topics I've changed my mind on
#568> 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 th…
Re: Software development topics I've changed my mind on
#569> 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…
Re: Software development topics I've changed my mind on
#570Earlier quoted context omitted.
I have done frontend as well as backend and moved to backend only, because the endless hype traing jumping, cv driven development and config and library churn was just too much of a comedy. And it is still happening. Now it is people switching "routers" and version upgrades for nodejs and version upgrades for typescript and deployment platform and ... The list goes on. This kind of thing is much much less pronounced…
You don't have to follow hype when doing frontend, you can pick whichever technologies you want and stick with them for years. Part of being a good frontend lead is personally is not falling for the hype, and only adding packages I know will a. be supported for the foreseeable future, b. have an exit plan if those technologies aren't supported, and c. keep an eye on my juniors/seniors to make sure they're writing sen…
As a full stack developer, your chances of being or becoming the frontend lead are reduced, as you don't have focus like a frontend only person, who will play that card subtly, that they are the specialist and you are not. And frankly, as a full stack developer, why would I even want to become a frontend lead and sacrifice the part of development, that is much saner? For the frontend lead it also pays well to follow the hype, raise the frontend to "modern level" and get paid senior salary.