I can, in fact, bend my view of facts to fit this metaphor. And if am also dubious about doing so, that's OK as it makes it all the more likely that I will learn something new from your post.
So why spoil that with some the arrogant demand that: "If you don’t accept the above proposition completely then nothing I have to say about software is going to work for you."?
Finding the problem and creating a solution along with focusing on the process of creating that solution in order to reduce risk of building the wrong solution. Contrasted to building a solution along with a sane dev and production environment for that solution to fit in, to increase possible iteration velocity by reducing deployment inertia.
If that's the situation you find yourself in, I cannot praise centralized logging with a good frontend highly enough because I frequently find myself trying to figure out what happened to a request, and it's like night and day.
Needing to ssh anywhere and run grep against log files is functional if there's only one or a handful of VMs, but it gets complicated with a handful of machines, and even just SCP-ing the logs off becomes time consuming if there are a lot of machines. Then once the logs are off, 'grep' quickly becomes inadequate. (And I should know, I've built some truly horrible regexps to try and grep for dates because I didn't know any better.)
All that friction means that answering the original question; figuring out a detailed internal reason for why my customer received a 500 http status response error, is just too toilsome for all but the most (as you noted) doesn't happen in .
With centralized logging, I'm able to search for a request ID and see the logs, and this is a reality as often as I need, in order to debug complex multi-system issues.
> You always have to design both “the product” your customers want and “the environment” in which your product will run in production. Thus any software product begins with two obvious categories of “work to be done.” People ignore this because it seems [counterintuitive.][going_there]
I am the author of the post and I approve this summary :)
I started taking communication and story telling pretty seriously about 9 months ago and the data on my 2 latest courses (where I tried to create a cohesive narrative of the content) shows the completion rate being quite a bit higher than my older courses.
Are there other things at play? Maybe, but I'm 100% convinced it takes more than "raw programming talent" to be a good programmer in general.
When it comes to designing library code or public APIs, I would rather use code written by someone with 5 years of writing / story telling experience and 2 years of coding experience vs someone with 10 years of coding experience but can't communicate well at all.
Chances are the 2nd person wouldn't be able to see the "big picture" stuff when it comes to designing APIs, and when it comes to API design, the big picture is the most important thing. The implementation details of each function is the easy stuff (since you're a Google search away from solving most technical problems).
There's also many other factors that matter besides your code. For instance, if I can't even find your project, or your documentation is lack luster then it doesn't matter if you wrote the most elegant code in the universe, I'm not going to use it.
Ellen Ullman
Jon Evans
