Readit News logoReadit News
reggieband commented on Discussion: structured, leveled logging   github.com/golang/go/disc... · Posted by u/philosopher1234
jayd16 · 4 years ago
Isn't letting the log library do the formatting a common practice? That way you can get formatted logs and the library can cluster logs by the format string instead of the final output.
reggieband · 4 years ago
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.

reggieband commented on Discussion: structured, leveled logging   github.com/golang/go/disc... · Posted by u/philosopher1234
reggieband · 4 years ago
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.

reggieband commented on The gathering crisis in the UK   antipope.org/charlie/blog... · Posted by u/aydnina
reggieband · 4 years ago
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.

reggieband commented on I have complicated feelings about TDD   buttondown.email/hillelwa... · Posted by u/jwdunne
mikkergp · 4 years ago
>I've worked with guys who have never written a single test yet ship code that does the job, meets performance specs, and runs in production environments with no issues.

I'm curious to unpack this a bit. I'm curious what other tools people use other than testing programatic testing; programatic testing seems to be the most efficient, especially for a programmer. I'm also maybe a bit stuck on the binary nature of your statement. You know developers who've never let a bug or performance issue enter production(with or without testing)?

reggieband · 4 years ago
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.

reggieband commented on I have complicated feelings about TDD   buttondown.email/hillelwa... · Posted by u/jwdunne
reggieband · 4 years ago
I could write an entire blog post on my opinions on this topic. I continue to be extremely skeptical of TDD. It is sort of infamous but there is the incident where a TDD proponent tries and fails to develop a sudoku solver and keeps failing at it [1].

This kind of situation matches my experience. It was cemented when I worked with a guy who was a zealot about TDD and the whole Clean Code cabal around Uncle Bob. He was also one of the worst programmers I have worked with.

I don't mean to say that whole mindset is necessarily bad. I just found that becoming obsessed with it isn't sufficient. I've worked with guys who have never written a single test yet ship code that does the job, meets performance specs, and runs in production environments with no issues. And I've worked with guys who get on their high horse about TDD but can't ship code on time, or it is too slow, and it has constant issues in production.

No amount of rationalizing about the theoretical benefits can match my experience. I do not believe you can take a bad programmer and make them good by forcing them to adhere to TDD.

1. https://news.ycombinator.com/item?id=3033446

reggieband commented on Cut the cutesy errors   alexwlchan.net/2022/08/no... · Posted by u/panic
reggieband · 4 years ago
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.

reggieband commented on TikTok’s Poison Pill   calnewport.com/blog/2022/... · Posted by u/yarapavan
reggieband · 4 years ago
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.

reggieband commented on DALL·E 2 prompt book [pdf]   dallery.gallery/wp-conten... · Posted by u/tomduncalf
reggieband · 4 years ago
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.
reggieband commented on Ask HN: Worst experience receiving an offer?    · Posted by u/treyfitty
reggieband · 4 years ago
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.
reggieband commented on Show HN: I built an app for when I talk too much in online meetings   unblah.me/... · Posted by u/interleave
reggieband · 4 years ago
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.

u/reggieband

KarmaCake day2802February 8, 2008View Original