reggieband

I don't care about the formatting, I care about the available data types. JSON is just easy to use since it includes arrays/hash-tables and it is already supported by a large number of tools.

If you look at the Attr type definition you can see they support many primitive types including Int, Float, Bool, String, Duration, and Time. So if I had a record type, like a customer I could do:

    slog.LogAttrs(slog.ErrorLevel, "oops",
        slog.Int("customer_id", 123456), 
        slog.Float("customer_balance", 12.42)
        slog.Time("customer_updated_at", ...))

But I would prefer a structured data type there. Something more like:

    { "customer": {
        "id": 123456,
        "balance": 12.42
        "updated_at": ...
        }
    }

In fact, I'm not sure how I'd go about supporting arrays as Attr except with keys like "item_0", "item_1", etc. Or maybe serialize it into a representation like comma separated values. But now I'm coupling my log to a custom serialization/deserialization - I'd rather just use JSON once again since most tools will know how to handle it.

I see some asking for stack support in the logs, and that is something I would be looking for. Often when an error happens on a server it might be inside some generic utility. At least with a stack, you might realize that all of the calls to that utility function are coming from the same location a few steps up the stack. In my experience that can significantly speed up identifying the root cause of issues.

I'm not sure I like the way they are handling attributes either. One pattern I strongly discourage on projects I work on is formatting data into the log message. When I've had access to decent log aggregation tools (e.g. Splunk, Datadog) I like to generate reports on error messages. That is usually possible with regex magic but in my experience it is much much cleaner to have a static unchanging message for all messages. I then store all additional details in a separate part of the log line. I tend to prefer JSON for those details since it is well supported and even parsed by default by many tools. Another benefit of JSON for those additional details is that it is supports arrays and hash-tables. The attribute system proposed here doesn't seem to have that same hierarchical attribute support.

IMO, unified, clean and consistent logging is one of the most underrated techniques for maintaining long running services.

I am reminded of the story of the fat cat that I recently read in a Brothers Grimm collection. In case it is not familiar to you:

A cat and a mouse decide to team up and store up some surplus food for hard times. They agree during abundant times to both put a little extra fat into a shared pot. They then store the pot in a safe place. The cat, however, is overcome by hunger even in the abundant times. Every few weeks the cat sneaks to the pot and takes just a little bit, maybe just a few licks at a time. Over the course of a couple of years of sneaking and small stealing the cat manages to completely deplete the pot. Then hard times hit, as both expected. The cat and the mouse both go to the pot together to divide their savings. But when they lift the lid they both gasp in surprise that the pot is empty. The mouse slowly realizes what must have happened. The cat is guilty but won't stand being accused and so it turns on the mouse and eats it.

My whole life I had heard of the rich upper-classes described as "fat cats" but I didn't really understand the message until I read the story. From at least 2008 we were supposed to be saving for the next crisis. Yet here we are at the next crisis and low and behold the pot is empty.

The reason we fall for this over and over again is that the short-term memory of civilization is shorter than the cycles these things happen over.

Originally when I started out in the gaming industry in the early 2000s. There were close to zero code tests written by developers at that time at the studios I worked for. However, there were large departments of QA, probably in the ratio of 3 testers per developer. There was also an experimental Test Engineer group at one of the companies that did automated testing, but it was closer to automating QA (e.g. test rigs to simulate user input for fuzzing).

The most careful programmers I worked with were obsessive about running their code step by step. One guy I recall put a breakpoint after every single curly brace (C++ code) and ensured he tested every single path in his debugger line by line for a range of expected inputs. At each step he examined the relevant contents of memory and often the generated assembly. It is a slow and methodical approach that I could never keep the patience for. When I asked him about automating this (unit testing I suppose) he told me that understanding the code by manually inspecting it was the benefit to him. Rather than assuming what the code would (or should) do, he manually verified all of his assumptions.

One apocryphal story was from the PS1 days before technical documentation for the device was available. Legend had it that the intrepid young man brought in an oscilloscope to debug and fix an issue.

I did not say that I know any developers who've never let a bug or performance issue enter production. I'm contrasting two extremes among the developers I have worked with for effect. Well written programs and well unit tested programs are orthogonal concepts. You can have one, the other, both or neither. Some people, often in my experience TDD zealots, confuse well unit tested programs with well written programs. If I could have both, I would, but if I could only have one then I'll take the well-written one.

Also, since it probably isn't clear, I am not against unit testing. I am a huge proponent for them, advocating for their introduction alongside code coverage metrics and appropriate PR checks to ensure compliance. I also strongly push for integration testing and load testing when appropriate. But I do not recommend strict TDD, the kind where you do not write a line of code until you first write a failing test. I do not recommend use of this process to drive technical design decisions.

It's such a tiny thing, but my pet peeve is exclamation marks in error messages.

"Something went wrong!" is something I see a lot of engineers do. I don't usually call it out but it bugs me whenever I see it.

TikTok scares me in the same way that DALL-E scare me.

DALL-E is very, very good, but still obviously flawed. But behind the flaws I know it will get better. Like the original iPhone vs. the crazy powerful phones we have now. Or the original 3d games like Doom or Duke Nukem 3d compared to modern PC graphics. Or the insane quality of modern movie CGI. In 5 years or 10 years this AI tech to generate incredible images will advance at a similar pace. (Shout out to GPT-3 in this space as well)

I don't think we fully understand how TikTok is connecting to our subconscious but it is doing it in a way that most people agree is unsettling. And we are at the very beginning of this journey. There is no way to predict if this is going to be good or bad without us doing it. And every company now realizes that it is both easy to achieve and tremendously effective.

This makes me wonder if a future job description will be the equivalent of an AI whisperer. Someone who learns how to prompt AI so well that it becomes their job.

I once interviewed with a crypto exchange and after getting the offer I noticed it was for contract and not full-time as had initially been offered. I went back to them and said I had a similar compensation offer for full-time from another company and if they wanted me to consider contract with them then they would have to raise the offer. Their response was an offer to pay me directly in bitcoin.

I love this idea and I could see myself using it in 1:1 meetings with my direct reports.

One of the advantages of getting older is the experience one gains. It is often the case that I can relate a current situation to one that has occurred in my past. This can help me make good decisions by anticipating expected similar outcomes to the most obvious approaches.

Yet the other side of this is I can find myself droning on about old war stories to junior engineers. What I mean to be well-intentioned advice can turn into a monologue. This is especially true when I am giving advice "off-the-cuff" in response to situations brought up in 1:1 meetings with direct reports. I might struggle finding the best way to communicate my experience. This can cause me to rephrase the same idea several different ways in an attempt to clearly convey my thought.

I feel this kind of tool could help me focus more on listening to the people I manage.

I don't know if it is the same word but it reminds me of a joke a Brazilian friend told me when we were discussing how it can be hard to translate jokes. He mentioned that someone who shits a lot is a common insult in Brazil.

The joke goes: A young man visits the family of his girlfriend for the first time. At one point the father of the girl pulls him aside and tells him that he is no good for his daughter. The father wants a rich man for his daughter. He tells the young man "you can't buy my daughter a nice house, you can't buy her a nice car, you can't buy her nice clothes, I bet you can't even afford to buy her toilet paper". Later, as the young man and girl drive home she notices he is upset. She asks if her dad maybe said something to him. He said, yes, he told me you are a big shitter.

I know this is a crazy thought and not inline with a lot of the blizzard hate - but why don't games like this allow more gifting style mechanics?

I consider the Twitch gift sub market. And I consider that weird crypto game Axie Infinity. It seems we are only considering the purchasing power of whales that want to flex. What about whales that want to collaborate. Whales that want to demonstrate their generosity.

I remember a reddit post about a guy who had a rich friend that would constantly take him on wild adventures that the poorer friend couldn't afford. The rich guy didn't care about spending the money and the poor guy was good company.

I think an interesting monetization mechanic would be a game where the pay-to-win aspect was in the recruitment and outfitting of other players. So as a poor player I could have the opportunity to earn high-level gear based on the spending of a whale whose campaign I was joining.

I have fear that the cathartic pessimism we sometimes enjoy ironically is turning into a chronic fatalism. It's like a habit that has become an addiction. I think the author was in a discussion that started as a fun catharsis for all involved and then devolved into an addictive argument that the author felt they needed to win.

There is a cliché which goes: "Expect the best. Prepare for the worst". Articles like this only seem to get the second half of that while clearly violating the first half. A well balanced response to crisis is benefited by both.

I think the author is not actively aware of the importance of expecting the best, both of the world and of their colleagues. I feel their arguments are weak due to this imbalance.

I've been thinking about a life-sim type game with a rogue legacy type spin.

Basically you get N actions per day (3, 5, 7, whatever works) that depend on your characters age. You might start as a baby in some random family archetype (poor/rich, dumb/smart, lazy/athletic, etc.) and after a few years you get control of the daily decisions your character makes at a granular level. Like, study in the morning, play in the afternoon, watch TV in the evening. These are more "influences" and your character can kind of rebel. Like if it gets too stressed because you are forcing it to study/work all the time then the character has a stress break and maybe gets drunk in the evening.

As the character gets older the available tasks change. As a toddler its games and light-learning, as a pre-teen it is school and sports/hobbies, as a teen it is education and social activities, as a young adult part-time jobs or university, as an adult marriage, raising kids. Perhaps as you get older you get more actions e.g. N actions per day increases.

Eventually you get to retirement then death and then you can choose one of your kids to continue the legacy. Or you can start over with a new random kid in a random family.

The gameplay would be simply choosing one of a few options available to your character at each time step. So you have N time steps per day and M available actions. The M actions are chosen in a weighted random manner from a set based on your characters abilities which changes over time, maybe some light RPG skill tree system. Could possibly be managed with a "card" system as well and would possibly shoe horn into Slay the Spire type mechanics. Overtime both positive abilities and negative abilities compound. Like, if you have too many "curse" cards in your deck, maybe your only options for an evening decisions are "drink alcohol", "ruminate on past failures", "argue with spouse".

In some sense, think of it like the day-to-day mechanics in Persona 5 mixed with the character building of The Sims. The goal of the game is to make many lifestyles possible. e.g doctor, lawyer, rockstar, president, social worker, janitor, game developer, soldier. The more difficult job types (e.g. CEO of a massive corporation, Senator) might take multiple generations to work towards.

This is a fair criticism of how I chose to tell the story. The line you quoted was supposed to refer to the character introduced in the second paragraph and not to a generic stereotype of aged man.

I can see how my choice of wording created an implication that people who have grey beards are old and that it is this oldness that contributes to their unwillingness to learn. The familiar cliche of "you can't teach an old dog new tricks".

What I actually hope to communicate is that there is a hubris which leads some to believe their skills do not require updating. The caution is that sooner or later this hubris may lead to sudden downfall. People may call on you in their time of need and you will fail. And this failure is not because of your age, your intelligence or your willingness to work hard. You will fail because you became overly comfortable with a passed status quo and you let your skills get out of date.

I see a trend of well-written, evidence backed articles where large, well funded sites are making a case to deprecate jQuery. These fact-based investigations into problems faced by their dev team result in a reasoned decision to remove a dependency that no longer justifies its cost. I encourage everyone to introspect if their defense of jQuery is on an equal technical footing to these types of investigations.