At some point, you develop complex interdependencies with other systems. You need sophisticated caching for optimum build performance. Techniques like GitOps are unsustainable at a certain number of engineers/commits per hour.
308 karma · joined January 29, 2021
At some point, you develop complex interdependencies with other systems. You need sophisticated caching for optimum build performance. Techniques like GitOps are unsustainable at a certain number of engineers/commits per hour.
Bespoke CI is easy to build but no one wants to be in charge of rolling out a critical security patch to that on-prem box no one's touched since that consultant from 2 years ago.
I find this to be an odd take, given context in the article. It sounds like the writer is simply contrasting her own leadership style with her boss's, as an example of how they complement each other.
Hierarchies make us uncomfortable because they challenge our egos. I've noticed this particularly in classic programmer personalities: smart, introverted, highly skilled. Many of us spend our entire careers as ICs, as leaves on the corporate tree. It's easy to become cynical.
"The VP sits around chatting people up all day and droning about OKRs while I just shipped a million dollar feature / resolved an expensive outage / built a tool that will dramatically increase engineering efficiency. What value does _he_ bring to the table?"
Unfortunately this is an enormously unproductive attitude that will kneecap your career. No org is a meritocracy -- but what does meritocracy even mean? We sort everyone by IQ? Or "performance", measured by lines of code committed per week?
On a final note I'll add that hierarchies get things done. Imagine working for a company that functioned as a democracy, with all the attendant discourse, campaigning, checks and balances. I would personally find the inefficiency intolerable. Better to work for a single idiot than a committee of a dozen geniuses.
1. Run the same suite tests additional quality checks (linters, etc) on PR branches that you run on mainline
2. Run branch CI against the merge commit for your PR branch (i.e. include your changes as well as latest mainline)
3. Avoid long-lived branches.
If you run into frequent merge conflicts and incompatible changes in an area of your codebase such that your team needs to integrate individual commits every half-hour instead of keeping 1-4 day feature branches around... That sounds like a code and/or organizational smell.
However!
> Using pull requests for code changes by your own team members is like having your family members go through an airport security checkpoint to enter your home. It’s a costly solution to a different problem.
I actually do like this analogy -- but it's not PRs that are the problem, it's mandatory reviews. And the cost/benefit of mandatory reviews varies widely depending on how senior the engineers on the team are, how much their work overlaps, and what their average tenure on the team is.
Don't credit unions already provide this service?
There's also something to be said for having such a dominant, established brand. Lego is a cultural icon, beloved by multiple generations. Picking up a knockoff kit is sort of like taking your kid to a random local theme park instead Disney World. While in theory the two options have similar features (rides! characters running around in costume!) they are of course not the same.
I myself have often wondered if what doctors do couldn't be automated. You have the primary care physicians who seem to run on a loop of "listen to symptoms" - "order tests" - "prescribe medication" - "refer to specialist". And the specialists themselves seem to follow their own loops. Many surgeons for example, perform the exact same procedure day in/day out for decades. Surely well-trained robots, not prone to fatigue or loss of dexterity as they age, could produce superior outcomes.
But they haven't been replaced yet, just like I haven't, so I assume there is more going on there than what looks from the outside like repetitive manual labor.
Someone should make an AI-generated crypto-influencer persona. Virtual YouTube, Twitter presence. Mint a new coin once per week, hawk it to the masses. I bet they could make decent money.
I am afraid that as long as humans are writing code there will be other humans in charge of ensuring their work is profitable. We won't be able to do away with executives just yet, unfortunately.
I actually think how "clean" your code is depends on lots of factors. Eg.
(a) Do you care if your coworkers find it easy to modify your code?
(b) Do you feel a sense of ownership over the code you're touching?
(c) Does your organization reward delivery speed without any checks for code quality? (eg. no culture of code review)
(d) Is the code a proof-of-concept that needs validation from users before further investment?
WFH is indeed wonderful for parents and families, but if you try to do it without childcare, you're not going to be working much.
My own hard-line requirement when it comes to naming services is that they should be a single word with some relationship to the service's purpose. Ideally a common English word, but proper nouns are permitted if they improve clarity. Brevity must ALWAYS take precedence over clarity. There's only so much you can express in a name anyway; a detailed explanation of exactly what a service does should exist in documentation.
Otherwise you end up with long names like "horizon-blob-profile-server" or "batch-process-execution-engine". Multiple words lead to ambiguity. Inevitably you end up using dashes, camel case, underscores, or no differentiation at all in order to represent word boundaries in different systems, because VCS, filesytems, domain names, and cloud systems all have different sets of permitted characters. This makes automating your infrastructure painful.
And of course people resort to acronyms when discussing the services, which means everyone is forever getting the dfkg service confused with dkfg. "Whoops, I deleted the wrong database!"
Surgeon? Just spackling the same old organs day in day out, with the additional downside of potentially killing someone if you have an off day and place a brick upside down.
Professional football player? It's repetitive manual labor! Often performed outdoors in inclement weather. High likelihood of involuntary retirement due to workplace injury.
Executive? Staring at endless spreadsheets all day... With rows and rows of those brick-like rectangular cells...
All fun aside, I don't think many bricklayers could find it within themselves to complain about making 200k a year to work in jeans and a hoodie in an air-conditioned building with foosball tables and free snacks.
Have a single team start practicing GitOps, with an eye to eventually accepting contributions from other dev teams. Establish good patterns in IaC repos, write documentation, add linters and other static checks over time. Tools like Atlantis and ArgoCD can provide deployment automation as well as rollbacks, with opportunities for manually diffing and reviewing changes before applying them.
Edited to add: if your "GitOps" implementation involves anything more complicated than the standard "short-lived PR to mainline" pattern, you are doing it wrong. Avoid environment branches at all costs and follow continuous delivery -- deploy incremental changes frequently.
Take a group of people from the 1900s and drop them in to the US in 2022, they would likely experience obesity at similar rates.
It's not that people made more virtuous choices in 1900, it's that food was scarcer, less palatable, and more nutritious, and physical activity was a part of daily life.
A busy suburban parent in a 2-income household did not need to squeeze in time to make a home-cooked meal and a Peloton workout around a 9-5 desk job with an hour+ car commute.
Obese people are discriminated against in healthcare, employment, and social settings.
Furthermore, numerous studies have show that fat shaming does not lead to weight loss. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6565398/
Shockingly, it turns out if you tell someone with 100 lbs to lose that they are a disgusting lazy piece of shit doomed to an early grave, they tend to withdraw from health care and other social settings, seek comfort in unhealthy habits, and suffer from anxiety and depression. They may give up on their health entirely. After all, if you've struggled your entire life to lose weight and made little progress, then what's the point?
Categorizing a patient as overweight or obese is not discrimination. Dismissing their health concerns or providing lower-quality care because they are fat is. [2]
[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4853419/
[2] https://journalofethics.ama-assn.org/article/weight-bias-hea...
HN is full of people who will accept nuance and complexity in technical discussions. Why not in this area as well, where individual biology, cultural expectations, economic incentives, and environmental factors intersect with personal choice?
I recommend reading the book, the entire point of which is about shifting one's health efforts from an exclusive focus on weight to a more holistic view.
I.e. even if you can't drop that last 20 pounds (and many people struggle to do so, especially as they age), you should still eat a healthy diet, exercise, limit alcohol intake and avoid smoking.
I have never met a fat person who wasn't aware they are fat. I do know two people who have failed to lose significant weight even after bariatric surgery physically restricted how much they could eat.
After even the most extreme medical intervention fails and you are still obese, what can you do? Stay inside your home forever so that thin people are not forced to look at you? Never eat a piece of cake in public? Never go shopping, never date, never dance?
Of course not. In the end the only choice is to live your life anyway, in spite of your reduced opportunities and the judgment you receive from others.
If you're brave, you might even dare to post photos of yourself on Instagram.
> Measure your baseline inflammation levels and see how they fluctuate with lifestyle choices (nutrition, exercise, sleep, stress) so that you can make the right choices for you
> Be Golden works by using an at home finger prick based blood testing kit and a digital platform
I'm not sure what "story" is left to be told here. It's pretty self-explanatory.
I'm a thoroughly average 33-year-old, for what it's worth :) I don't mean to imply that we shouldn't continue strive for growth and development as we age, but I certainly am not as mentally quick or energetic as I was ten years ago. There is very little chance I will suddenly transform into jwz or John Carmack or <insert name of legendary hacker here>.
On the bright side, I am a better communicator and strategic decision-maker, and am more satisfied with my life as it is.