I really enjoyed reading this post: I think it's valuable to share explorations that didn't pan out. Beyond that, as person not working in compilers, I thought that Nicholas did a great job of providing an overview of the problem at hand as well as just enough detail to start developing an intuition for why the problem is tricky.
This is very likely because without the full path your shell is using the `time` builtin function of your shell as opposed to using the binary.
The shell's builtin keyword for `time` is more limited in nature than the full `time` binary. This is true of a number of other common unix commands as well, e.g. `echo`. The manpage for your shell should describe the builtins functions.
> devs don't really know / care about running things in production
I disagree with this entirely. Devs _you have workd with_ might not have cared but it doesn't make the statement universally true. As a counter argument, some of the best software developers I've worked with were also very good at operating and debugging production software and the reverse has also been true.
I also don't buy that the two are a different mindset (at least in the domains I work in and care about). In my experience the very best people (whether they're working "dev" or "ops" roles or something in the middle care about the entire development and deployment lifecycle of the software they work on. Building a good experience in software includes thinking about reliability and availability and planning a reliable and performant deployment also requires that to be thought of in the application layer at some point.
I do enjoy reading a physical book more than an ebook but only by a little. It's interesting to me that people here so far seem to prefer technical books to be ebooks due to their short useful shelf life. I've reached the opposite conclusion - that I prefer technical books be paper only and novels/non-technical books may be either. This is because, in my experience, technical books tend to have diagrams or tables that don't render well on the Kindle and similar devices.
There's also apparently terms in the Github ToS that allow viewing and forking of public projects regardless of license. What this means in a practical sense, I'm not sure.
It's pretty simple. In a practical sense it means that the author of any license-free project on Github who finds their code used in other software can, very cheaply, C&D the authors of those packages.
I think that a big part of algorithms knowledge is knowing what exists. So even a though typical curriculum forces the learning of each of these algorithms, I think the value is in knowing the trade offs between each in terms of complexity (space, time) and ordering.
I enjoyed reading this. I can relate to the point about reading open issues of a project to know exactly what state the project is in and where it is going.
While I don't actively participate in many open source projects, I have found myself reading the mailing lists and watching the issue trackers for a few projects over the past few months and as a result I feel that I have a very good idea of what is going on with them.
