Martin Fowler.

> I'm missing out on utilizing these tools fully.

mastering a tool doesn’t make you a better engineer, only better expert in a particular tool. And it is not the “next level”.

Next level is about getting a wider perspective and bigger picture view on your craft and your job.

On a conceptual/phylosophical level any decent book about building, engineering or designing any complex thing (preferably based on real events, not some made up boring fluff like “deadline” by Tom Demarco) would contain some gems.

I don’t know any single book that is full of gems.

To make this comment useful this is one of many examples, of a book that have couple of good ideas (about feedback system for example) https://www.goodreads.com/book/show/1501427.Managing_The_Des...

I think some of the best engineering leveling up one can do is to become an expert in other domains completely unrelated to what you’re working on now.

Furthermore, build more and read less. Programming books, while a great resource, are detached from the everyday realities for software engineering. The skillset comes from applying concepts by doing the work.

If you really want to read something, pick a popular project on GitHub in Elixir or Zig and read through its source code.

Finally, if you haven’t augmented your workflows with AI-tooling, strongly consider doing so (and I don’t mean asking ChatGPT and copy/pasting answers, but actually full on agentic programming)

The skill gap you’re concerned about now is only going to increase if you’re not using every tool to your advantage. Simply knowing a few programming languages is not enough, in fact it should barely even matter once you’ve hit a certain level of experience.

A philosophy of software design by John Ousterhout is the best software book I have read.

But, from your post it’s not clear specifically what you are looking for. If you think you will level up by learning how to apply numerical modelling techniques, then it’s probably best to focus on that.

'A Philosophy of Software Design' by John Ousterhout - https://news.ycombinator.com/item?id=37975558

None of the generic thought leadership books are particularly useful. I've noticed that the best way to keep relevant as an engineer is to ignore flavor of the day frameworks and tech but rather focus on the basics. For example, if you're working in financial modeling, one way to improve as an engineer to get better at the domain. Maybe "Advances in Financial Machine Learning" by Marcos López de Prado. You'd have to work through the math and pick up finance on the go (which I assume should be easier part). As for people doing cool stuff in Zig / Rust, what matters is the problem not the hammer they're using to solve it.

Some specifics are outdated, but I very much like a lot of the general theme of Greenspun’s Software Engineering for Internet Applications:

https://philip.greenspun.com/seia/

If you want the big picture stuff to give your vague direction more precision try giving the top articles of Ribbonfarm by year a quick skim. It sounds like bad advice but the content has broad domain applicability.

Understanding Python's data model helped me become a better software engineer. I'd recommend watching this PyData talk (James Powell: So you want to be a Python expert? | PyData Seattle 2017 - https://www.youtube.com/watch?v=cKPlPJyQrt4) and then using the official doc as a reference which is also fun to read: https://docs.python.org/3/reference/datamodel.html

I want to reiterate the points other have brought up.

Learn more about whatever domain you are writing software for, then ask what skills you need to improve to solve a problem in that domain.

Also do not get hung up on specific languages or paradigms, the overarching patterns are universal and learning them makes things significantly easier to implement.

Finally the most generic advice, Algorithms and Data structures. When you start thinking in terms of "This is the data in memory" and "This is the algorithm manipulating the data" you will "level up" quickly. Software isn't cats and dogs and random objects. Thinking in objects can be a decent way to model systems but when you get into the details you are operating on instructions and data not on objects.

Computer architecture a quantitative approach by Patterson and hennessy

It’s the real life exchange rate for algorithms and data structures. Basically understanding your infrastructure and its performance characteristics will help you design simpler ( and therefore better )systems

1) C++ concurrency in action

2) Tannenabum Networking and OSes

3) Get your domain and build something

You might find the reading list on my blog interesting, though it's more about long form articles than books.

https://mahesh-hegde.github.io/readings

I'd say anything that inspires you to move to a career that focuses on engineering, that you cannot get away by being half-ass, is a good book.

I recommend two books, none of them is technical. "Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" and "The soul of a new machine".

Once you put yourself at the edge of knife, everything you want comes naturally, because you either swim or die.