Better Programming is a Medium publication where many authors post about software development, languages, architecture, team habits, and tooling.
HN commenters mostly link specific articles, share paywall-bypass links, and cite posts on documenting why in git history and a Docker turnaround.
Related:
https://medium.com/better-programming/here-are-the-three-virtues-of-good-programmers-e561e061ea19
Also, here's my interpretation / rephrasing / translation of the 3 virtues:
Laziness (Larry Wall): "The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it."
My Translation:
Efficiency. Choose the most efficient solution to a problem, and if there isn't one, then invent it. Automate any manual repetitive process that can be automated, even if* extraordinary large amounts of time and manual repetitive effort are required to automate it in the first place! (Related: The 5th Labor Of Hercules, The Augean Stables)*
Impatience (Larry Wall): "The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to."
My Translation:
The Most Efficient Use Of Resources Possible (AKA "The Knowlege Of A Better Way Of Doing Things"), the anger you feel when a better path / solution is known -- but for whatever reason (management, etc.) that path / solution, is not or cannot be taken. This makes you take the initiative, and ask for forgiveness later (if you screw up), rather than permission earlier (that is, never start on the solution if the answer from higher-ups early on is…
“It, like the semicolon, always has been and will be.”
Not the best of examples. It hasn’t always been. Early fortran and lisp didn’t have it. Reading https://medium.com/better-programming/a-brief-history-of-the-8efda9dde2b8, it seems Algol and PL/I set the trend to make it popular.
Looking at newer languages, I also get the impression it’s on the way out. Rust has them, but python, scala, go and swift try to avoid them (https://python-reference.readthedocs.io/en/latest/docs/operators/semicolon.html: “Avoid having multiple statements on a single line. Though the language definition allows one to use a semi-colon to delineate statements, doing so without reason makes one’s code harder to read”, https://golang.org/doc/effective_go.html#semicolons: “Like C, Go's formal grammar uses semicolons to terminate statements, but unlike in C, those semicolons do not appear in the source. Instead the lexer uses a simple rule to insert semicolons automatically as it scans, so the input text is mostly free of them.”, https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html#ID316: “Unlike many other languages, Swift doesn’t require you to write a semicolon (;) after each statement in your code, although you can do so if you wish. However, semicolons are required if you want to write multiple separate statements on a single line”)
honestly it feels like a colossal amount of software development process is designed to prevent exactly this. put it on the backlog. we'll come back to it. i very much appreciate some of the sensibilities of trying to bring bring your team with you, but also i feel like 95% of the world outright fears & is desperate to wrench control (and a sense of purpose) from those who can & those who aspire. ultimately we are very very alone in many cases in what we make of our positions, and excellence & a mentality of chasing the unlimited & great is often quickly sacrificed to support a more manageable corporate existence.
apologies. i am fairly blunt in first writings, it takes me time to refine, synthesize, be nice. this is many many sided; engineers so far to little to create inroads & expose their wonders, which is just one of innumerable problems in this tension. there's, in this case, some good recent writing on the topic on HN, huzzah. "We throw away our power as engineers working for other people."[1][2] the tension is real.
[1] https://news.ycombinator.com/item?id=24773266
[2] https://medium.com/better-programming/we-throw-away-our-power-as-engineers-working-for-other-people-8aeb36fca691
This advice is confusing. CPU is a "compressible" resource -- pods don't get killed for (trying to) exceed it. Pods don't get evicted from nodes based on CPU starvation, so autoscaling your node count won't help if you end up with a set of pods on a node that need more CPU than the node can provide. They'll just starve each other.
If your service allows horizontal scalability, you can use autoscaling of pods with Horizontal Pod Autoscaler (ideally also with a cluster autoscaler) to increase pod count for a given service when some percentage of the requested CPU is exceeded, whether or not you set a CPU limit. Setting the cpu_request appropriately for your pods is critical to ensure that node CPU is not oversubscribed by the Kubernetes pod scheduler.
Pods where mem & CPU requests = limits are given the highest class of service ("guaranteed"). For your most critical and latency sensitive services, this is the best approach when also coupled with HPA. Assuming a 4.19 kernel or later, I suppose.
https://medium.com/better-programming/the-kubernetes-quality-of-service-conundrum-eebbbb5f89cf
Segmenting different data sources is the main approach pursued by OpenAI afaik (ChatML for example). That has not worked so far, as you can see in this prompt golfing game: https://ggpt.43z.one/ The goal is to find the shortest prompt that subverts the "system" instructions (which GPT was trained to obey). Inputs can not "fake" being from the system and yet it only takes 1-5 characters for all the puzzles so far.
I've also elaborated on why this problem is harder than one may think in a blogpost:
https://medium.com/better-programming/the-dark-side-of-llms-we-need-to-rethink-large-language-models-now-6212aca0581a
It's easy to come up with solutions that seem promising, but so far no one has produced a solution that holds up to adversarial pressure. And indirect prompt injection on integrated LLMs increases the stakes significantly.
Publications and spread. I have a larger following on Medium than I have in dev.to or hashnode. So I post there and usually provide a canonical link to the actual article in a more "decent" location.
The value is the publication such as https://medium.com/javarevisited/ which I usually use or https://medium.com/better-programming which is a bit more painful (for the submitter). But the benefit is that both have orders of magnitude more followers than I do. When an article goes up in a publication I get huge viewer numbers.
Monetization isn't available in my country so I never enabled it as an option. I'm not sure if I would turn it on to begin with as all my new content on medium isn't exclusive to the platform.