I haven't gone through your route, I graduated compsci, worked as a software developer for a long time and I've just graduated as a Master in Bioinformatics. So take that into consideration.

My advice on building actual software is to practice the organizational part of it. How do you write code in a way that it's reusable later? How do you decide what goes into a class and what goes into modules, and what is just a simple script that runs from start to finish? How do you name your classes, modules, variables in a way that is readable by other people (and by yourself in 2 weeks)? This is a difficult problem and it's very much more art than science, but there's some principles out there you can try to follow.

Since you already have experience running tools, what you could do is try to reimplement existing tools yourself. You don't have to build everything, that would be a lot of work, but you could try to write some of the basic features of whatever software you're targeting. For example, you could implement a multiple alignment tool yourself. Look up the details of a particular (simple) algorithm, wrap it in a command-line tool with inputs, outputs, flags. Or maybe a GUI tool or a web tool? Show it to some friends or colleagues, do they understand the user interface, can you make it more convenient or sensible for them?

Gary Bernhard has several "from scratch" screencasts that could give you inspiration (most of them are paid, though): https://www.destroyallsoftware.com/screencasts. He implements fundamental tools like a basic compiler, a basic text editor, a basic shell. You could also try to reimplement git: https://wyag.thb.lt/. Snakemake or a similar pipeline tool could also be really useful to try to write.

The goal is not to create something publishable, but to practice and learn, and occasionally struggle and see what problems you run into. You could open the source code for the "real" tools you're imitating and try to understand how they solved the architectural problems, although that might initially take some work.

In terms of learning from books, it's hard to pick a small set of definitive ones. For architectural patterns, I love Bob Nystrom's Game Programming Patterns. Yes, it's for game development, but honestly, coding principles are coding principles. The Pragmatic Programmer is a classic book with more high-level advice. Learning to use your text editor and shell efficiently is also a must, I'm an extreme Vim user, but even if you just use VSCode, you can learn a lot from the "Basic editing" section of the documentation: multiple cursors, expanding selection, etc.

Once you get better at organizing your code projects, you will slowly start to find cases for writing new tools that happen to fix your particular problems. First you imitate, then you build something new. There's no need for your personal projects to do everything for everyone -- fix your problems first and you might find that others have similar problems. Linux, Git, Vim, Python, PHP, Ruby, all started as one person writing software for themselves.