Hi HN, may I ask about any best practices guides that you're aware of. It could be about architectures or coding in general. Something like the two below:
I have come to believe that by and large "best practices" are actively harmful as they're mostly pounded by inexperienced programmers who lack the ability to judge the applicability or zealots who believe everything should be done the One True Way™, and they (ab)use these kind of "best practices" as an argument from authority. Everyone else just says "X is better because Y", which is an actual argument that can be discussed (engaging with actual arguments discovers what the best solution for the particular situation is).
Most "best practices" are just someone's opinion anyway, and little more. The exception to this are some things like "don't use mktemp(), use mkstemp()", but these are usually not called "best practices" but "footguns" or "things that will get you in to trouble sooner or later".
Your first point reminded me of the Expert Beginner[1].
Avoiding appeals to authority (or conversely ad hominem) is important, but if you don't have time or resources to evaluate the idea directly, it's useful to consider who the advice is coming from, and who the intended audience of that advice is (it might not be you) [2].
"Our lead developer said we should do X in this situation" has a better chance of success than "I found a random blog about this thing that could work for us".
Case in point: OP linked 12factor which was originally Heroku marketing and helped drive the microservice plague that is ravaging our industry to this day.
Agreed. 12factor guidelines is one of the few really good one I still try to adhere to, even though I full agree that microservices are overhyped. I've seen so many devs to claim how they solve all the problems, without seeing any of the issues they cause (and there are many). Definitely not a free lunch.
The important part of any best practices guide is the “why”. Those “best” practices should be aiming to solve some problem(s), and it should state which one(s). If someone finds themselves with the same problem, they can leverage those solutions.
Yes, I agree, and I'll nuance my previous comment a bit by saying that I actually think many "best practices" have good advice in them, at least for some situations, and sometimes even most situations, and in that sense they often are worth reading. I just wish people would stop calling them "best practices" or even "methodologies" and would just call them "an idea I had" or "this is how I like to do things" or "here are the advantages to X". The change in tone just puts an entire different spin on things, and will ultimately be helpful for everyone as the reader will be less tempted to just accept things as an axiom, and will generally lead to more thoughtful and constructive discourse.
I enjoy both worlds - I type in the question, cut type "hello" press enter paste and enter again. This way I can be nice twice by being polite AND not wasting other people fime
I'm all for politeness, but these are people I work with, not strangers, and it's basically my job to answer their questions, and they know I'm in a different timezone, and whom I've told that they can just ask their question directly. Certainly in this context I don't think it's any less polite than "Hi there, how you doing? I'd like to ask a question: [question]".
No one is really helped with this: not the developer or support staff who wants an answer, not customer who has to wait longer for an answer.
I also answer these sort of things outside work hours (I don't mind doing that, I also get a lot of flexibility in return), and three different messages is more invasive than just one. Actually, come to think of it, it's less polite to do it the "polite" way.
The problem is not with "Hi" or "Hello" immediately followed by the question.
The problem is when people write "Hi"/"Hello" without the question, then waiting for the reply, then want to simulate a smalltalk, and only then asking the question.
In many cases they're not even thought about this question in advance, and didn't framed it or phrased it, to make it easier on the other side to understand the problem.
"If you feel it's a bit brusque to simply say "Hi" and ask the question, you can still preface your message with as many pleasantries as you see fit". Just don't submit the message with only pleasantries.
It doesn’t say to not say hello, or simply says don’t leave an empty hello without context. This makes a lot of sense especially in asynchronous teams. A notification can pull you out of flow and be disruptive, so minimize them
After 33 years of programming, after going through OOP stage and DRY stage, I have come to conclusion that WET code is best for day-to-day, long-term maintainable code. DRY always leads to over engineering and premature abstraction that falls apart the moment new requirement arises. WET code is boring and tedious but simple to maintain. It scales fairly linearly and timelines are easier to estimate.
I love this. I felt these issues a lot while working on a fullstack project in which nobody cared about anything except delivering fast. It turned out to be a great mess nobody wanted to take responsibility on.. Now I have this, which is a really good mental model IMO
Most of the rules are sourced from something Google or Mozilla said.
A lot of people don't like the word SEO but this guide is really about having better structured pages that are easier for machines and humans to understand, rather than rules that people have tried to reverse engineer out of Google to game their search ranking.
Most "best practices" are pretty flawed. The only one I found reasonable were some principles applied at NASA which mainly can be summed up as: be paranoid, limit the scope of variables, don't malloc like crazy and assert absolutely everything.
Somewhat related, does anyone have a good in-depth guide to "clean architecture"?
I'm writing a Python developer helper app, and I'm trying to learn how to correctly design it so I can stick a Textual UI on top later. Someone mentioned that I should use clean architecture for that design, but I'm not familiar with the term.
Set aside some time early on in your project just to create a small proof of concept where you actually slap on that Textual UI. That'll inform you of what's needed later on. You don't even need to merge that proof of concept, the point is just to discover what's needed.
I've done that kind of by mistake, in that I wrote some UI screens and saw how to hook them together. But learning Textual, some Python, and object oriented Python all at once was difficult for me.
Most architecture books are bad. The "quintessential" book is called "Fundamentals of Software Architecture" and it's very dry, dated, and high-level. There is also a book called "Clean Architecture" which is what they may be referring to.
What is a "Python developer helper app"? Is it a standard application with a UI, some API calls, and a DB? In that case, you may want to use a standard layered architecture approach.
Python developers are generally horrible at architecture. They will defend it as "wanting to be functional" and call other devs "dogmatic" while duplicating code all over the place and writing 5000 line files.
To deploy dev/test AWS resources, the devs have to hit a bunch of different cloud and internal sites. It's a lot of annoying and slow clicks+waits that I wanted to streamline for them. It's also full of risk because you have to copy values from one place to another, often changing them a little first.
By "standard layered" arch, do you mean model/view/controller? If so, I can read up some more on that. (I'm devops, mostly focused on terraform, and I'm trying to move away from writing bash scripts to Python)
EDIT: thank you for your answer, it's helpful to me.
Layered architecture is almost always used with MVC, but it's not MVC. It's separating your application into a communication layer (how does the front end SPA and other apps make requests against it - usually a "Controller" or "Router"), a service layer which actually processes the request, and a "Persistence" layer - logic used to save your data to a database or elsewhere. Look into FastAPI for Python
Your app would look something like the example below. Note that the significant difference from MVC, which is a bit out of style, is that the front end is in a different Single Page Application written in React or Angular. You can still do MVC if you want, but then your display and business logic concerns are really mixed. An SPA/API pattern is probably easier too.
Frontend SPA
--Angular or React - user takes action, this is sent to the API via a RESTful http request
Backend
--FastAPI router receives request, authenticates user
--Service layer actually validates the request, tries to spin up AWS resources, and returns an error if something failed. Note that you want a library here, rather than trying to pipe to CLI to run ws s3api create-bucket \
--bucket my-bucket \ or whatever.
--Persistence layer - save any data you need to the database here, if any - your app might not need this
This is different than what you’re asking about but is a GPT-powered chat with a library of over 500 best practice whitepapers from cloud providers: https://cloudwhitepapers.withcoherence.com
Hopefully the chat and functionality makes it more useful than just a guide or manifesto.
Most "best practices" are just someone's opinion anyway, and little more. The exception to this are some things like "don't use mktemp(), use mkstemp()", but these are usually not called "best practices" but "footguns" or "things that will get you in to trouble sooner or later".