yearolinuxdsktp

Scala’s downfall is the culture of writing libraries with the most esoteric syntax imaginable. It’s the opposite of Ruby’s “program with pleasure”—-it is “program with maximum cleverness” and “if it doesn’t look like an obscure math equation or symbol soup, it’s probably not idiomatic Scala.” Java’s designers were opposed to operator overloading due to potential for abuse, and did Scala deliver living proof/nightmare scenario of that.

Now I still want operator overloading, because I favor enabling instead of disabling approaches, and I want, for example, new numeric types to have natural syntax that blends in with built-ins, or an equality operator that works consistently. I’ll even settle for += append to strings and collections.

But even Scala standard libraries take operator use to wild extremes. Apparently it’s not enough to use + to append collections, you must use ++. Except Vec you can add with +. There’s ++= and ++=:, and /: and :: and ::: and ?^ and ?^.

Spark Scala interface introduces =!= for inequality comparison. There’s |@| from Cons library. Don’t get me started on Akka. SBT introduces <++=

Surprisingly you can’t override ==, so Spark implements ===. And specs2 testing library implements ====.

I found it to not at all be confusing once I got used to it—-I find it less confusing and more reliable in practice.

Speaking from 20+ years of Windows use with a local menu bar and 7 years of Linux desktop where I switched to a global menu bar—-it was an instant improvement in quality of life.

I no longer have to hunt for a narrow menu bar strip, just throw the mouse all the way up, and hope to never hunt for it ever again.

Happy to pay 42% higher Patreon fees in exchange for ease of subscription control, visibility, safety and ease of payment with in-app Apple payments.

It’s funny seeing people call 78% operating margin too high, while we all know that software VCs demand 90% margin from their startups, and if it wasn’t Apple, people here would call that an excellent business.

Completely incomparable! It is not a bigger disaster. John Grubber is being an aesthetic stickler -— “comically sad icons”, “indiscriminate transparency” leading to things that are ugly, hard to grab-to-resize rounded window corners, icons in menus “ruining Mac’s signature menu system.”

If you think that adding icons all over the place to menu items RUINS it, I think you’re either in a MacOS “purist stickler” category (which John Gruber is in), or you’re hyping things up for clicks. Because no sane person would call this ruining the menu system.

And new icons “comically sad”? Someone call the whambulance. I saw the new icons, and they are fine. Sure, they are different. But I am not laughing and/or crying about them, and I bet most people don’t find them comically sad either.

I hear you on the line of thought that here at work we do work and we keep personal things to ourselves.

I also commend you on your concern for doing things that appear fake, because people indeed are good at spotting fakeness. And I bet they appreciate that you are not acting fake, because that’s often refreshing to see, and they probably value what you have to say more as a result, and quite likely respect you considerably because of that.

For birthdays, wish the employees a happy birthday. You don’t need to get a cake or throw a party (getting cakes for birthdays stops scaling past 10 employees). But everyone should feel a little bit special on their birthday. If you don’t feel that way on your birthday, or you grew up in a family that didn’t celebrate birthdays (e.g. in a Jehovah’s Witness cult), it can be difficult to understand why it matters. But look at it as a technical challenge: can your manager “database” of people hold a birthday field? And can you trigger a smile and a “happy birthday!” greeting on each employee’s birthday? You probably can. The risk for fakeness is quite low (so don’t get a cake and make a big deal out of it), your effort is very low, but the upside for employees is a higher feeling of you caring about them as a person.

Death of a loved one is a really important thing to be aware of. Grief fucks people up and it takes at least a year to come back for it. Grieving employees will need more time and space, and are likely to struggle more. They will come back. And they will stick around more if they felt supported. Offer them to take some time off right away and support them by making sure they can take at least a few days off right away. So if someone tells you of a death of a loved one, you must take note! There’s no good advice to give, so don’t feel pressure to give any advice. Offer condolences and acknowledge that it really sucks (“I’m so sorry for your loss, I can’t imagine how difficult it is right now”). You have to be aware of this as a people manager, because your people.

Religious observances? I’m meh on that one. You can try to develop curiosity about it if the employee talks about it. Ask them why is the observance important to them? If they don’t talk about it, I leave it. For winter time, it’s happy holidays, and done with it.

Okay, a new baby is another one that’s important because your employee will have reduced sleep or be sleep-deprived and have a whole lot of new worries. Be more forgiving with the schedule, let them leave work ad hoc for baby emergencies. You do that, they are much more likely to make up work on their own time as gratitude. Ask them how they feel they are handling the workload—-is there an opportunity to change the type of tasks they are doing? Maybe they are not in a position to be writing deep design docs while they are sleep-deprived. I don’t know, but you can check in when you do your one-on-ones.

Write down their spouse or partner’s names, and write down their children’s names. Keep it in your personal manager file. You probably don’t have people with 5+ children. It’s not a lot. It’s hard to remember. But if the employee feels like they don’t have to say “my son” or “my daughter” or “my wife”, but can just say their names to you and you know who they are, it makes them feel more comfortable and more like a human being. This is another one where it’s hard to be fake—-nobody expects you to remember these things, but it sure feels nicer if you do.

Regarding feeling like you have to fake it till you make it, it’s like picking up a new habit. You have to practice. You will get better at it. It’s part of your job as a manager.

If you find it exhausting, adopt things incrementally. What’s most exhausting? Why is it exhausting? Is it because it’s on top of everything else you’re already doing for 40 hrs a week?

As a manager, you have to care about the people, because they are human beings. It’s a part of your job. You can’t not do your job. If it means you spend less time being technical, so you can spend more time managing people as people and not feel exhausted, then that’s what it means. Push back on your manager to make room to do more people stuff and less technical stuff. You can’t spend 90% of your time being technical and 10% managing, unless you have completely self-directed staff. You’re a person too—-and if you job is to manage, you must make time for it, and if there’s not time for it, then that’s your boss’s problem. If your boss doesn’t think it’s a problem, that’s on you because you haven’t told them.

Managing engineers is like herding cats. They won’t respond to lashing. And cats don’t show that they are sick because they don’t want to show weakness. So if you don’t ask about what’s going on in their personal lives, you’ll be blind to how it’s affecting their work. And because ultimately they get paid to do work, it is therefore in your interest (and company’s interest) to not be blind to how their personal life is impacting their work.

Going back to “fake it till you make it” or brute-forcing until you get better at it—-what you’re not considering is the additional information you will get or increased personal response/appreciation from your people. It might feel like brute force at first, but consider the very real possibility that it can start feeling like a smart thing to do because of the results.

I admit this is way over my head, I am still trying to grok it. This seems to require an existing model to start from—-I am not sure how one would arrive at a model from scratch (I guess start from the same weights on all items?)

I think the point about A/B testing in production to confirm if a new model is working is really important, but quite important is to also do A/B/Control testing, where Control is random (seeded to the context or user) or no recommendations, which helps not only with A vs B, but helps validate that A or B isn’t performing worse than Control. What percentage of traffic (1% or 5%) goes to Control depends on traffic levels, but also requires convincing to run control.

I think one important technique is to pre-aggregate your data on a user-centered or item-centered basis. This can make it much more palatable to collect this data on a massive scale without having to store a log for every event.

Contextual bandit is one technique that attempts to deal with confounding factors and bias from actual recommendations. However, I think there’s a major challenge to scale it to large counts of items.

I think the quality of collected non-click data is also important—-did the user actually scroll down to see the recommendations or were they served but not looked at? Likewise, I think it’s important to add depth to the “views” or “clicks” metric—-if something was clicked, how long did the user spend viewing/interacting with the item? Did they click and immediately go back or did they click and look at it for a while? Did they add the item to cart? Or if we are talking about articles, did they spend time reading it? Item interest can be estimated more closely than just views, clicks and purchases. Of course, we know that purchases (or more generally conversion rates) have a direct business value, but, for example, an add to cart is somewhat of a proxy of purchase probability and can enhance the quality of the data used to train (and thus a higher proxy business value).

It’s probably impractical to train on control interactions only (and also difficult to keep the same user in control group between visits).

The SNIPS normalization technique reminds me of the Mutual Information factor correction when training co-occurrence (or association) models, where Mutual Information rewards items less likely to randomly co-occur.

Who remembers Model-Driven Architecture and code generation from UML?

Nothing can replace code, because code is design[1]. Low-code came about as a solution to the insane clickfest of no-code. And what is low-code? It’s code over a boilerplate-free appropriately-high level of abstraction.

This reminds me of the 1st chapter of the Clean Architecture book[2], pages 5 and 6, which shows a chart of engineering staff growing from tens to 1200 and yet the product line count (as a simple estimate of features) asymptotically stops growing, barely growing in lines of code from 300 staff to 1200 staff.

As companies grow and throw more staff at the problem, software architecture is often neglected, dramatically slowing development (due to massive overhead required to implement features).

Some companies decided that the answer is to optimize for hiring lots of junior engineers to write dumbed down code full of boilerplate (e.g. Go).

The hard part is staying on top of the technical (architectural and design) debt to make sure that feature development is efficient. That is the hard job and the true value of a software architect, not writing design documents.

[1] https://www.developerdotstar.com/mag/articles/reeves_origina... A timeless article from 1992, pre-UML, but references precursors like Booch and object diagrams, as well as CASE tools [2] You can read it here in Amazon sample chapter: https://read.amazon.com/sample/0134494164?clientId=share

Thank you this document is so much more straightforward than most YouTube videos covering the same.

You can also put these into settings.json.

They likely were running data on EBS volumes instead of bare metal SSDs, due to ease of recovery (a failed instance does not lose data on the attached EBS volumes). You can only run your DBs on bare metal SSDs if you are prepared to lose a node’s data completely.

In fact, many instance types no longer have any ephemeral storage attached and it’s a default practice to use EBS for root and data volumes.

There are some instance types that have extremely fast EBS performance (EBS io2 Block Express), which has hardware acceleration and an optimized network protocol for EBS network I/O and offers sub-millisecond latency. However, these are expensive and get even more so if you go up in IOPS.

Even if the rollout was atomic to the servers, you will still have old clients with cached old front ends talking to updated front ends. Depending on the importance of the changes in question, you can sometimes accept breakage or force a full UI refresh. But that should be a conscious decision. It’s better to support old clients as the same time as new clients and deprecate the old behavior and remove it over time. Likewise, if there’s a critical change where you can’t risk new front ends breaking when talking to old front ends (what if you had to rollback), you can often deploy support for new changes, and activate the UI changes in a subsequent release or with a feature flag.

I think it’s better to always ask your devs to be concerned about backwards compatibility, and sometimes forwards compatibility, and to add test suites if possible to monitor for unexpected incompatible changes.

And think about what it’s like for humans as well—-spreading a feature over several repos with separate PRs makes either a mockery of the review process (if the PRs have to be merged in one repo to be able to test things together), or significantly increases cognitive overhead of reviewing code.

False. Mongo never pretended to be a SQL database. But some dimwits insisted on using it for transactions, for whatever reason, and so it got transactional support, way later in life, and in non-sharded clusters in the initial release. People that know what they are doing have been using MongoDB for reliable horizontally-scalable document storage basically since 3.4. With proper complex indexing.

Scylla! Yes, it will store and fetch your simple data very quickly with very good operational characteristics. Not so good for complex querying and indexing.

If you’re doing a restructuring of the company, i.e. mass layoffs, you’re allowed to do it regardless. In some states FMLA/PFMLA a company is automatically presumed a retaliation firing if it’s done within 6 months and the onus is on the company to prove it wasn’t—-the mass layoff is the cover, and large companies know it.

However, the fact that they cancelled her health insurance a week before returning and demanded she returned on a certain date or she’d be terminated despite a demonstrated disability, that’s pretty whack and might be hard to defend as company-wide restructuring.

Heavy mocks usage comes from dogmatically following the flawed “most tests should be unit tests” prescription of the “testing pyramid,” as well as a strict adherence to not testing more than one class at a time. This necessitates heavy mocking, which is fragile, terrible to refactor, leads to lots of low-value tests. Sadly, AI these days will generate tons of those unit tests in the hands of those who don’t know better. All in all leading to the same false sense of security and killing development speed.

We know that severe stress (such as trauma) leaves chemical marks on the genes, potentially passed down to the offspring. For example, this paper writes about an “accumulating amount of evidence of an enduring effect of trauma exposure to be passed to offspring transgenerationally: https://pmc.ncbi.nlm.nih.gov/articles/PMC5977074/

Though “lived experience” can encompass a lot of things, it definitely encompasses severe stress.

For example, constantly worrying about money because you’re poor can definitely put you under severe stress. Also, growing up without secure attachment to your caretakers, being asked to do role reversal (having to take care of your parents as a child), things like that will generate complex PTSD.

Additionally, warnings can be built into the clients themselves. If you connect to a host with less than 2 weeks cert expiry time, print a warning in your client. That will be further incentive to not let certs be not renewed in time.

This is why I appreciate JetBrains IDEs having a local history tracked automatically. It helps go back instead of relying on frequent commits.

This is a good example of a benefit of certificate-based authentication option for MongoDB, because you need to at least present a valid client certificate to transmit any data.

Us-east-1 is far far from least reliable. It’s one of the more reliable ones. Smaller regions tend to have more reliability issues affecting the entire AZ.

This analysis is skewed due to the major incident in 2025. What was the data for 2024 and over the last, say, 5 years? So the proclamation of least reliable of us-east-1 is based on 1 year of data, and it’s probably fair to say that at least last 3 years if not 5 are a better predictor of reliability.

us-east-1 also hosts some special things, so it will have more services to lose.

It’s not a myth, it’s a sound software engineering principle.

Every comment is a line of code, and every line of code is a liability, and, worse, comments are a liability waiting to rot, to be missed in a refactor, and waiting to become a source of confusion. It’s an excuse to name things poorly, because “good comment.” The purpose of variables should be in their name, including units if it’s a measurement. Parameters and return values should only be documented when not obvious from the name or type—for example, if you’re returning something like a generic Pair, especially if left and right have the same type. We’d been living with decades of autocomplete, you don’t need to make variables be short to type.

The problem with AI-generated code is that the myth that good code is thoroughly commented code is so pervasive, that the default output mode for generated code is to comment every darn line it generates. After all, in software education, they don’t deduct points for needless comments, and students think their code is now better w/ the comments, because they almost never teach writing good code. Usually you get kudos for extensive comments. And then you throw away your work. Computer science field is littered with math-formula-influenced space-saving one or two letter identifiers, barely with any recognizable semantic meaning.

I think the technique is important to have in your vocabulary, but I think the examples given are a weak sell.

In the example given, I would have preferred to extract to a method—-what if I want to load the config from somewhere else? And perhaps the specific of strip comments itself could have been extracted to a more-semantically-aptly named post-processing method.

I see the argument that when extracted to a function, that you don’t need to go hunting for it. But if we look at the example with the block, I still see a bunch of detail about how to load the config, and then several lines using it. What’s more important in that context—-the specifics of the loading of config, or the specifics of how requests are formed using the loaded config?

The fact that you need to explain what’s happening with comments is a smell. Properly named variables and methods would obviate the need for the comments and would introduce semantic meaning thru names.

I think blocks are useful when you are referencing a lot of local variables and also have fairly localized meaning within the method. For example, you can write a block to capture a bunch of values for logging context—-then you can call that block in every log line to get a logging context based on current method state. It totally beats extracting a logging context method that consumes many variables and is unlikely to be reused outside of the calling method, and yet you get delayed evaluation and single point of definition for it.

So yes to the pattern, but needs a better example.

Engagement: make sure that every member of the team is either on the incident bridge or has dropped what they are doing to watch you diagnose the problem. The more eyes on the problem, the more awareness of the pain will be absorbed by all. If members need to leave to get food or put children to bed, tell them to order delivery and to ask their spouse to do their job. Demonstrate human touch by allowing them to turn off camera while they are eating.

Comprehensiveness: propose extreme, sweeping solutions, such as a lights-out restart of all services, shutting down all incoming requests, and restoring everything to yesterday's backup. This demonstrates that you are ready to address the problem in a maximally comprehensive way. If someone suggests a config change rollback, or a roll-forward patch, ask them why are gambling company time with localized changes, and ask them why are they willing to gamble company time on technical analysis?

Root Cause Analysis Meeting: spend the entire meeting time rehashing the events, pointing fingers and assigning blame. Be sure to mention how the incident could've been over sooner if you just restarted and rolled back every single thing. Be sure to demonstrate out-of-the-box thinking by discussing unrealistic grandiose solutions. When the time is up, run the meeting over by 30 minutes and force all to stay while realistic solution ideas are finally discussed in overtime. This makes it clear to the team that nothing is more important than this incident's RCA--their time surely is not. If someone asks to tap out to pick their kids up after school, remind them that they are making enough money to call them an Uber.

Alerting: be sure to identify anything remotely resembling leading indicators, and add Critical-level wake-you-up alerts with sensitive thresholds for those indicator. Database exceeding 50% CPU? Critical! Filesystem queue length exceeding 5? Critical! Heap usage over 50%? Critical! 100 errors in one minute on a 100000 requests per minute service? Critical! Single log line indicating DNS resolution failure anywhere in the system? Critical! (What if AWS's DNS is down again?) Service requests rate 10% higher than typical peak? Critical! If anyone objects to such critical alerts, ask them why do they want to be responsible for not preventing the next incident?

So never fly in or out of DCA, and avoid anywhere near Venezuela.

+1 I agree 100% use it everywhere and let LS/IDE infer it.

On top of that:

* Reduce refactoring overhead (a type can be evolved or substituted, if it duck types the same, the autos don't change)

* If using auto instead of explicit types makes your code unclear, it's not clear enough code to begin with. Improve the names of methods being called or variable names being assigned to.

I can see explicit types when you are shipping a library, as part of the API your library exposes. Then you want types to be explicit and changes to be explicit.

I would caution that microservices should be architected with technical concerns first—-being able to deploy independently is a valid technical concern too.

Doing it for organizational scaling can lead to insular vision with turf defensive attitude, as teams are rewarded on the individual service’s performance and not the complete product’s performance. Also refactoring services now means organizational refactoring, so the friction to refactor is massively increased.

I agree that patterns should be used where most appropriate, instead of blindly.

What pains me is that a language like “Cloud-Native” has been usurped to mean microservices. Did Twilio just stop having a “Cloud-Native” product due to shipping a monolith? According to CNCF, yes. According to reason, no.

It’s changed, but is a wash:

On the positive side, my electronic toothbrush allows me to avoid excessive pressure via real-time green/red light.

On the negative side, it guilt trips me with a sad face emoji any time my brushing time is under 2 minutes.

Internal release notes:

* consisting of PRs merged since last release. (This is better than manually updating CHANGELOG. Do not allow direct commits to main w/o a PR.)

* internal audience is engineering, PMs, customer success & support, these do not leave the company.

* PRs can be examined for more context if needed. This is a good enough balance between noise & automation.

* If you use a working tracking system like JIRA or GitHub issues, join the PRs w/ the system to output priority and other labels (like Feature/Bug). This will help internal stakeholders quickly identify how important each line is. Sort by priority and/or group by labels.

External release notes:

* manually updated log of important changes, such as new features or other larger changes. These do not include all bug fixes.

* visible to customers.

* do not mention version numbers, only dates. You do not want to leak how often you release, or customers will start demanding release notes per version or dictating your release schedule.

When you fix bugs for customers, tell them what day/time the bug fix went live.

Obtaining set of PRs merged since last release is non-trivial, but doable.

Plus users are now defaulted to a faster, less deep GPT-5.2 Thinking mode called “Standard”, and you now have to manually select “Extended” to get back to previous deep thinking level for Plus users. Yet the 3K messages a week quota is the same regardless of thinking level. Also, the selection does not sync to mobile (you know, just not enough RAM in computers these days to persist a setting between web and mobile).

No plausible explanation? I disagree.

It’s about the social safety of transitioning. The paper you referenced is from the UK, which is famously a TERF island (trans-exclusionary radical feminists). In the TERF island, it’s much less safe to be a trans woman than a trans man. Adolescents can sense the risk of being a trans woman is much higher, so many trans women stay in the closet and don’t come out.