safetytrick

Being a junior engineer was a good time!

Yes, this mattered when 6 character passwords were common.

It's actually been useful for me to explain certain best practices now that I can show that the LLM cares.

Why is this name bad? Because an llm will get confused by it and di the wrong thing half the time.

Yes, I agree, we seem to need to feel "special".

Language is really powerful, I think it's a huge part of our intelligence.

The interesting part of the article to me is the focus on fluency. I have not seen anything that LLMs do well that isn't related to powerful utilization of fluency.

Python packaging is the least zen of python thing about python.

I don't think changeable code is the number one priority. The goal is to solve a problem and code that solves a problem without needing to change is sufficient.

Code that doesn't need to change is a really good sign that you've got something good.

Quoted: "Likewise, you can repeat yourself but classes only have a single (duplicated, but subtly different) responsibility."

I'm proud of my little joke on dogmas: "The only dogma I believe is that all dogmas are wrong".

I like to phrase this kind of thought as: "The only dogma I believe, is that all dogmas are wrong".

vim is late 1991, vi was 1976, sublime text was 2008. Just seems like garbage writing (very easily could be LLM).

In the article the author mentions wanting to benchmark a GPU and using ChatGPT to write CUDA. Benchmarks are easy to mess up and to interpret incorrectly without understanding. I see this as an example where a subtly-wrong idea could cause cascading problems.

With a dependency on a font. Wow, it's been a while since I've seen that.

I think they are talking kilometers

I forget that this has been a very popular strategy for a long time with more traditional databases.

Who is doing this and where can I read more? What are the tradeoffs?

I imagine that you get a a dataset that is significantly smaller but it is much trickier to keep a dataset in memory the way you could with MySQL.

It's like having a free implicit index on the customer (because you had to lookup the sqlite db file before you could start querying).

I spend a lot of time thinking about tenancy and how to handle it. Tenancy is such a common problem.

Performance is the number one reason tickets are hard to estimate. The second in my experience is security.

Time and tenancy are the number one opportunities for SQL to just be better (I always need tenancy and my Order By or at least one constraint can typically be satisfied with time).

It's okay to erect a fence that is less than ideal but please explain yourself.

Whenever I am in that expedient hack mode I've started commenting to explain my dilemma. My most valuable comments typically come out at that time.

Such and such can't be done right now because of such and such.

Often it doesn't matter if I ever resolve those comments or solve that problem I hacked through. The value comes from avoiding the rabbit hole next time.

An under-rated solution to this problem is saying No and having quality retrospectives.

Microservices adoption has largely become a cargo cult thing. It is a part of being cool like FAANG.

Instead of being cool, focus on solving your problems.

Some services just don't stop at night. Healthcare has trends but it never stops.

It just depends on the business, b2b can be very consistent. Some workloads just have predictable behavior.

I worked at a medium sized place where we had plans in place to handle the workload for our entire market on-prem (if we were ever to capture that market).

We realized that horizontal scalability wasn't important to us because we had enough of the market to know that the other half of the market could be supported on our existing solution.

I've been patiently watching for a nice way to plug in a local development DNS resolver (patiently waiting for someone to document and script the a few tiny patterns).

I'm a big Avro fan, it isn't easy to be good at but if you follow its rules it is so much easier to evolve than plain json is.

Random ids require random inserts and that is bad for performance. It isn't a deal-breaker in most situations but it is a real cost that you do pay.

ulids are beautiful little ids without many of the drawbacks and risks of other id systems. They are sufficiently unique for most work (anywhere that you don't need to actually uniquely engineer your ids) and their built in ordering and slick encoding are just icing on the cake.

Sometimes I encounter those snippets and I still have a discrete memory of writing something that "I knew my future self will understand".

That is especially frustrating.

Why is this interesting here?

You can build a toxic environment out of kindness too. You do need to coach and mentor and guide people towards the truth (regardless of if you even have it).

I also just don't have time to make everyone's ignorance my problem. I wish I did, but I don't, I have a hard enough time dealing with my own ignorance. Sometimes all I can do is point out the problem.

How to write platitudes for clicks.

This would be a really fun way to implement a "chaos monkey".