3 ms·

> When you can't ask "Why?" anymore without it being silly, that's when it's time to run tests and propose solutions. In the past year, I started a new role as

> When you can't ask "Why?" anymore without it being silly, that's when it's time to run tests and propose solutions. In the past year, I started a new role as a head of engineering for an existing team. I literally spent the first month asking "why" about nearly everything. The most common answers ended up being "I don't know, it's what we do", which was closely followed by some justification that boiled down to being a workaround for some anti-patterns. E.g. Q: "Why do we log this error at DEBUG level?" A: "It happens so often that it fills the logs when we log it at a higher level". Me: :(

mcbutterbunz 3y ago
This is why its a good idea to tell new hires to not be shy about asking "Why?". They haven't had enough time to become numb to the idiosyncrasies of the organization. At some point, you start to live with all those little problems, forget they are actual problems, and you just live with them until someone asks "Why?" and you respond "yeah, why DO we do that?"
- wmidwestranger 3y ago
  "Brenda came up with it, isn't she awesome?" Most common type of answer I've received, which is a bit of a bummer.
  - fatnoah 3y ago
    I'm literally dealing with that as we speak. Some architecture developed by the Staff Eng. on a team that's really not workable and was causing the team to run in circles. Ultimately, I had to jump in and ask a lot of questions about the implementation. i.e. Why was it built that way, along with the related questions about what goals of the implementation were (elegance, speed to delivery, future-proofing, ability to parallelize code effort, etc) and what app/business problems the code was solving.
landemva 3y ago
Lucky you to have found a place that allows those inquiries. Not many exist anymore.
hinkley 3y ago
One of my newer talking points is that logs are for new problems, existing ones get stats. In theory logging should be more efficient than stats, but in practice, we use logging frameworks that are fractionally as complex as our stats frameworks, and at any rate nobody reads logs and probably haven't for at least ten years. Once your cluster size is more than about 3 servers you need aggregated logs. What we read is the output of log aggregators, and log parsing libraries are doing a lot of work. Way more than the ingestion side of a telemetry service, which is parsing a very simple message schema. I'm always a little surprised how much engineers undervalue graphs until they see one that catches problems. I'm not entirely sure where that comes from, but I've known a few who have trauma from bad graphs causing drama. There's a lot of human factors around charting and most developers are largely blind to human factors concerns, even as they catch themselves making category errors with bad charts.
gunshai 3y ago
This should surprise basically no one. I do aspire to be in a role where I can endlessly ask people why it is exactly they do the thing that they do. All the while dodging the following scenario. "We just have to ask... What is it exactly that ya do here?"

mcbutterbunz 3y ago

This is why its a good idea to tell new hires to not be shy about asking "Why?". They haven't had enough time to become numb to the idiosyncrasies of the organization. At some point, you start to live with all those little problems, forget they are actual problems, and you just live with them until someone asks "Why?" and you respond "yeah, why DO we do that?"

wmidwestranger 3y ago
"Brenda came up with it, isn't she awesome?" Most common type of answer I've received, which is a bit of a bummer.
- fatnoah 3y ago
  I'm literally dealing with that as we speak. Some architecture developed by the Staff Eng. on a team that's really not workable and was causing the team to run in circles. Ultimately, I had to jump in and ask a lot of questions about the implementation. i.e. Why was it built that way, along with the related questions about what goals of the implementation were (elegance, speed to delivery, future-proofing, ability to parallelize code effort, etc) and what app/business problems the code was solving.

landemva 3y ago

Lucky you to have found a place that allows those inquiries. Not many exist anymore.

hinkley 3y ago

One of my newer talking points is that logs are for new problems, existing ones get stats. In theory logging should be more efficient than stats, but in practice, we use logging frameworks that are fractionally as complex as our stats frameworks, and at any rate nobody reads logs and probably haven't for at least ten years. Once your cluster size is more than about 3 servers you need aggregated logs. What we read is the output of log aggregators, and log parsing libraries are doing a lot of work. Way more than the ingestion side of a telemetry service, which is parsing a very simple message schema. I'm always a little surprised how much engineers undervalue graphs until they see one that catches problems. I'm not entirely sure where that comes from, but I've known a few who have trauma from bad graphs causing drama. There's a lot of human factors around charting and most developers are largely blind to human factors concerns, even as they catch themselves making category errors with bad charts.

gunshai 3y ago

This should surprise basically no one. I do aspire to be in a role where I can endlessly ask people why it is exactly they do the thing that they do. All the while dodging the following scenario. "We just have to ask... What is it exactly that ya do here?"