With the Unix philosphy in mind you most of the time write software from the bottom up, writing many utilities that does what they are supposed to do and then plying them together.

However, there's a limit to this.

The amount of small units you write should not be overwhelming and too small otherwise your brain just won't handle them and it'll overcomplicate it.

Also, there's a lot more to add to the Unix philosophy than "do one thing and do it well".

There's the everything is a file concept.
There's the modularity and compactness.
With that comes the cooperation between processing, piping and the likes.
There's the textuality and usual formats used, clear, concise, and transparent.
With that comes streaming, and favoring text UI before GUI, the GUI is just a wrapper over it.
There's the social aspect of code and the barrier to development.
With that comes open source and more contribution.
With that also comes the rebel hacking mindset, the internet culture.


There are a lot of standards like POSIX and the single UNIX specification but those are all irrelevant in my mind.

Most BSDs and Linux don't adhere to them, only the proprietary Unices do.

What a Unix-like OS is is more than that, like all big generic concept, it's social first, it's a state of mind.

The Art of Unix Programming by Eric Steven Raymond is a great piece that deals with the definition of what the Unix philosophy and mindset it.

EDIT: I think the bottom up approach of building blocks goes hand in hand with the "don't repeat yourself" rule. If you find yourself writing a piece of software and you know other programmers will use this feature over and over again then make it a module or a separate program.

Also, I've recently read that it's a good approach to always accompany a module with a software implementing the module functions.