The Pragmatic Programmer is a book that deals with how you look at code and software as a whole and the process of writing the code. It is primarily emphasizing the code that finds itself in a larger software project than one would typically find in javascript on web pages. This isn't to say that the things that one learns while reading it won't be applicable (and some are very applicable at a universal level), but if you are working on things that will take you a few days at most and then move on to something completely different, the improvements that it gives you will not be as substantial.
If you find yourself working on projects that last weeks and months and remain working on the project with the same code base, the lessons that are in the pragmatic programmer are most applicable. Quick one off scripts and tweaks to existing code is less likely to benefit from the book. However, one will typically find themselves moving up to bigger projects as they learn more about the craft of coding and such will find the material in the book to become more and more applicable as they progress.
Consider lessons such as:
- When is ok software good enough?
- How bad is it to duplicate code?
- What is an estimate?
- When to use plain text (rather than machine friendly values)
- Design by contract, assertions, and exceptions
The Mythical Man Month is a book about the lessons learned in the old days (that frequently need to be learned again and again) about project management. To the extent that programmers find themselves dealing with project managers and need to know how to interact with them, its a good thing to know. However, the lessons in there are not as often directly applicable to the code that one is writing.
Consider things such as:
- Why does adding more people to a late project make it later?
- How does one organize a software development team?
- How does a project get a year late?
These things are not ones that programmers typically have to deal with - its more your manager and team lead that will find these things to be useful. And, it needs to be taken with the appropriate grains of salt from the context - the book is old (and good - but its old). Essays about bug rates in PL/I need to be taken in context that its PL/I and things have changed a little bit since then (though there's No Silver Bullet (that's another essay)).