Code the shortest path first

Maybe I'm not senior enough, but I think this misses the point. If I'm not prototyping, I don't try to "code the shortest path first", I try to code using the most popular libraries, and the most concrete, broad-strokes, fundamental abstractions, towards a goal of improving understandability.

At the end of the day, most code is deleted anyway. But even then people still need to understand it. I am attempting to write in the "lingua franca" and to make it clear to myself and others what I understand about the problem.

I agree with the sentiment but not the examples:

> spend days setting up a CI/CD pipeline

This should/does take minutes. It's like 15 lines of YAML for most CI providers. Ideally it's a part of the template you use for new code.

> use a cool new library they just found

Integrating a useful lib that makes the code simpler should be done from day 1. Don't code your own platform lib and switch to SDL halfway through development. Don't code your "tracer bullet" on Win32 API calls when you're going to be using libuv. And like CI/CD, integrating libraries into the build should be painless

> if it’s software that’s going to ship, it needs tests

Oftentimes the tests are the only way you know if the code is even minimum viable, even manages to be the "tracer bullet". Ok you implemented a new feature, what says the code even runs and doesn't segfault immediately if there's not a test to build the new code into and run? Not comprehensive tests, but something

Hi! Yes I couldn't find a better source, here's excerpting from the book--

"We once undertook a complex client-server database marketing project. Part of its requirement was the ability to specify and execute temporal queries. The servers were a range of relational and specialized databases. The client GUI, written in Object Pascal, used a set of C libraries to provide an interface to the servers. The user's query was stored on the server in a Lisp-like notation before being converted to optimized SQL just prior to execution. There were many unknowns and many different environments, and no one was too sure how the GUI should behave. This was a great opportunity to use tracer code. We developed the framework for the front end, libraries for representing the queries, and a structure for converting a stored query into a database-specific query. Then we put it all together and checked that it worked. For that initial build, all we could do was submit a query that listed all the rows in a table, but it proved that the UI could talk to the libraries, the libraries could serialize and unserialize a query, and the server could generate SQL from the result. Over the following months we gradually fleshed out this basic structure, adding new functionality by augmenting each component of the tracer code in parallel. When the UI added a new query type, the library grew and the SQL generation was made more sophisticated. Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. It simply is not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you're on target, adding functionality is easy."

They later list some of the advantages of this approach-- - Users get to see something working early - Developers build a structure to work in.

And differentiate it from prototyping--

"The tracer code approach addresses a different problem. You need to know how the application as a whole hangs together. You want to show your users how the interactions will work in practice, and you want to give your developers an architectural skeleton on which to hang code. In this case, you might construct a tracer consisting of a trivial implementation of the container packing algorithm (maybe something like first-come, first-served) and a simple but working user interface. Once you have all the components in the application plumbed together, you have a framework to show your users and your developers. Over time, you add to this framework with new functionality, completing stubbed routines. But the framework stays intact, and you know the system will continue to behave the way it did when your first tracer code was completed."

It's still a great book 20 years later, I highly recommend picking up a copy.

It's contextual, and the author is presenting it as universal.

If you don't know how to build the thing, the author's advice is on the right track. If you're unfamiliar with the problem space, just bang away at it. Write that god object, that 500 line function, hardcode all the things. You wouldn't be able to come up with useful abstractions so don't bother trying. Get your stupid terrible code to work, the tiny demo operational, and then take a step back and understand your creation and refactor.

If you do know how to build the thing, if this is your 5th time writing a task scheduler and you know what the ground work for a new one should look like, trust your instincts.

Also conflicted, but I find myself happier working with "the dumbest thing that barely works" for a first release of something. To me, this is "optimal engineering under uncertainty".

Obviously, there are limits. And maybe a difference in perspective here reflects our respective typical uncertainty.

I'd rather optimise based on user feedback and with production traces than "in a vacuum".

Very often I don't even know if the feature or product is a good idea or how much / whether anyone will actually use it.

Optimisations usually come at the cost of some flexibility and this can hurt when there's a need to evolve the product in a direction I didn't expect (and for some reason that happens way more often than it seems like it should).