DynamoDB is not good, it's OK. Capacity upscaling and downscaling is too slow to be useful. You need to over-provision.
Software development topics I've changed my mind on
131–140 of 788 posts
Re: Software development topics I've changed my mind on
#132Earlier quoted context omitted.
I think the line between minutiae and craft is drawn by the effect it has on the product you're creating. Method length makes your code more manageable, for example. Placement of line breaks, not so much. At the end of the day, we aren't paid to produce code, but working software that works today and is easy to change tomorrow.
That is a purely commercial take of the matter. I don’t think it’s controversial to argue the artisans who stand out do so because they care for the craft itself. Spending an extra hour or two perfecting the shape of the armrest in the chair may not allow you to earn more money from that one commission, but it might improve your knowledge and skill and be slightly more comfortable to the sitter. If they comment on it…
> be slightly more comfortable to the sitter
That's kind of my point: the end cannot see, or feel, minutiae. If they can, it's not minutiae.
> Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does.
The code still isn't the product in that instance. It's the educational process. In many cases, clarity != beauty. This is why the best written tests often duplicate code, rather than being curated exercises in DRY.
> we aren’t paid to eat healthily and taking care of our bodies either
Yet programmers insist to be paid. Obviously taking time to grow on your own, on your own dime, is self-enriching for all the reasons you describe.
Re: Software development topics I've changed my mind on
#133> Typed languages are essential on teams with mixed experience levels I'm 30 years in now, and on balance, whilst they have clear advantages, I'm still not convinced that typed languages are essential, particularly for low level or module programming.
Interesting take, to me it is not so much about the type of coding (high vs low level) but more about the size of the project.
Dynamic languages work great for scripting and rapid prototyping, but if you are working with a team maintaining a large monolith, I would rather have a statically typed language and avoid at least a class of runtime issues due to dynamic typing.
Case in point, I love writing my Jupyter notebooks with Python but am amazed that entire platforms like Dropbox (and instagram?) chose Python as their default language.
Re: Software development topics I've changed my mind on
#134Earlier quoted context omitted.
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 Osbourn…
And 140 chars aren't enough for two files side by side with 80 chars. With a readable font size and a narrow font about 90 chars is a good limit on a 14" laptop screen. Coincidentally that same limit then allows for three files side by side on the average desktop screen - or a browser window at the side for reference.
If you can live with a single file on screen that's great, but the utility of two is far greater than having a chunk of the screen empty most of the time because of a few long lines.
Re: Software development topics I've changed my mind on
#135> Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy My feeling is that a lot of negativity towards the frontend stems from assuming that the entire field is like React and its community. It's really not like that.
The much bigger problem is that you not only have to deal with the technical challenges, but also the visual design challenges where non-technical people have all kinds of opinions that you have to deal with. Things get really nasty once you have to implement features that emulate non-web functionality like right-click menus and the UI becomes an inconsistent mess.
Re: Software development topics I've changed my mind on
#136>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 harm…
He's not saying you shouldn't do it, he's saying you shouldn't stress over it. The "run the language's standard formatter before commit and then get on with your life" approach.
Everyone on the team need to agree to the linting rules before using linters. Else they will keep wirting their code according to their habits , and then they start to modify the rule that dosen't fit their bad habits when linters hints to fix the code.
> run the language's standard formatter
Even with very smart linters like `ruff` it cannot fix all of the linting errors. You have to hand fix many of them.
What linter do you use that can just run and forget?
Re: Software development topics I've changed my mind on
#137> 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…
To me "craft" is about keeping code efficient, scalable, extensible, well-tested and documented. Code style is more about what naming convention to use, tabs vs spaces etc. - it's nice to have it consistent, but no need to spend more than 5 minutes arguing about it.
Tabs/spaces is a non-issue, agreed - IDEs handle it.
But surely naming convention contributes to keeping code documented, extensible and efficient?
A deviation from the norm leads to people thinking x does not exist in a large code base, leading to them implementing duplicate methods/functionality, leading to one instance evolving differently enough to cause subtle bugs but not enough to be distinct, or leading to one instance getting fixes the other does not etc?
Sample size of 1, but I've seen it happen unfortunately.
Re: Software development topics I've changed my mind on
#138> Code coverage has absolutely nothing to do with code quality
Ehhh..lots of nuance to this one
Re: Software development topics I've changed my mind on
#139> 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…
Following non functional stylistic rules to the letter as if they were on the level of SQL injections or memory leaks isn't "craft". It's cargo culture weirdness.
Sure, have a style and a linter. Be DRY. Don't lose your head over it though.
Re: Software development topics I've changed my mind on
#140> 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…
It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...
Starting with raw SQL is fun. But at some point you find out you need some caching here, then there, then you have a bunch of custom disconnected caches having bugs with invalidation. Then you need lazy loading and fetch graphs. Step by step you'll build your own (shitty) ORM.
Same thing for people claiming they don't need any frameworks.