Specs are extremely terse and dry, and I never liked reading them. I pushed myself to read a few and now I find myself craving that kind of technical documentation in my work. The WebAuthn spec is pretty interesting and also has some even more interesting drama on GitHub issues.

My reading list at any point is tied to whatever I am doing in my private or professional life. If my boss asks me to help grow the company my reading list will contain a bunch of stuff about company growth. If I have money to invest but no knowledge of investing -- you will see me listening to investing books while cooking, taking walks, commuting or long distance driving.

Basically, whenever I face a problem I look around for literature to help me with it.

I really hope to have an original problem in my life. Until then I assume that whatever problem I have there is somebody who wrote a solution to it and if I can't find it it is just because I wasn't searching hard enough.

People / Soft Skills:

* How to win friends and Influence People - Dale Carnegie

* Secrets of Consulting - Gerald Weinberg

* Peopleware - Tom DeMarco & Timothy Lister

* Nurtured by Love - Shinici Suzuki

* Turn the Ship Around! - David Marquet

* Never Split the Difference - Chris Voss

http://dhemery.com/articles/resistance_as_a_resource/

http://dhemery.com/articles/managing_yourself_through_change...

Macro Skills:

* Toyota Production System - Taiichii Ohno

* Workplace Management - Taiichii Ohno

* Thinking in Systems - Donella Meadows

* Fifth Discipline - Peter Senge

Agile:

* Extreme Programming, Explained (2nd ed.) - Kent Beck (the annotated bibliography is a goldmine)

* Chaos: Making a New Science - James Gleick

Programming:

* Implementation Patterns - Kent Beck

* Test-Driven Development, By Example - Kent Beck

* Refactoring (both editions) - Martin Fowler

* Refactoring to Patterns - Joshua Kerievsky

* Practical Object Oriented Design - Sandi Metz

* Functional Programming in Scala - Chiusano & Bjarnason

* Growing Object-Oriented Software, Guided By Tests - Freeman & Pryce ("The Goose Book")

* Modern Java in Action - Raoul-Gabriel Urma

* Java Concurrency in Practice - Brian Goetz

* Grokking Algorithms - Aditya Y. Bhargava

Architecture:

* Righting Software - Juval Lowy

* Release It! - Michael Nygard

* Site Reliability Engineering - Beyer, et al. ("The SRE Book”)

* Domain Driven Design - Eric Evans

* Introduction to Permaculture - Bill Mollison and Mia Slay

* Fun with a Pencil - Andrew Loomis

Design:

* All books by Edward Tufte, especially “The visual display of quantitative information”

* The Elements of Typographic Style - Robert Bringhurst

* Understanding Comics - Scott McCloud

* Design of Everyday Things - Don Norman

* Notes on the Synthesis of Form - Christopher Alexander

* The Timeless Way of Building - Christopher Alexander

I can’t tell you how valuable it’s been at times to understand how packets flow over a network. When ECONNREFUSED first rears its ugly head many developers tremble. Over time you learn it’s just a slog of debugging. Emotional control while programming is invaluable.

Also, the realization that people skills are actually no less important than tech skills in a tech setting.

Yes, and this is hard to accept: they are more important than technical skills. I have worked with many truly brilliant engineers who didn't see their ideas implemented because they didn't have good social/conversation skills. The most common version of this is the engineer who gets miffed/irritated/pissed off if people don't accept their ideas after 5 minutes of explanation. Meanwhile, the hustler whose code totally sucks gets the win because they know how to schmooze the business folks (or literally just tell the best lie).

Hard technical skills are not enough for most people to be successful. There are the outliers with "super programmer skills" (and here I'm thinking Linus Torvalds / John Carmack level status) who are just so indisputably expert that they should be heard. But even then they may not get the win. You have to know how to talk to others.

So, the way I think about it instead is that I’m just another type of system that can be maintained, improved, evolved. And my communication with others is simply an interface. And, well, any engineer can grasp the idea that easy to use and well thought out interfaces are valuable and worth working on.

"I think a good place to start is through the service design lens — “This is Service Design Thinking/Doing,” Jon Kolko’s books, and IDEO’s handbook (all available on Amazon). These are all practical, business-oriented works, and will give you the language and tools you need to interact with service designers or conduct your own explorations.

In the tech side, I still think there’s a lot of value in reading through Booch and friends, even if you don’t go on to use UML in a formal way, and even old, deprecated approaches to modeling (think Shlaer-Mellor) can be valuable as an introduction to more modern (and generally more complicated) approaches to domain modeling.

For more academic and less practical works, look into philosophers of language and communication (Rorty, Habermas, Latour, etc) — if you don’t have a background there, try the “Very Short Introduction” series, which gives a good grounding before moving into further secondary or primary literature. What you get from these writers is a way to think about language, communications, and complex systems, so you’re building a conceptual toolkit. (Analytic philosophy, which is another, “mainstream” branch of philosophy, also has applications in the formal comp-sci route.)

Sociology and STS (Science and Technology Studies) kind of occupies a practical middle-ground between philosophy and design; I’ve often said that when we do service design, we’re really just doing folk sociology. There’s no shortage of textbooks, but I’d recommend looking into academic field guides for ethnographic studies (a fancy term for “going out and talking to people about what they do”) and ethnomethodological studies (a fancy term for “going out and talking to people about what they believe”). While the service design books will give you practical tools for conducting workshops and research programs, sociology books will give you a firm grounding on why those tools are used, and how to theorize effectively on what you uncover. I also like measurement theory, which is a branch of psychology concerned with understanding how to define measures and metrics — great tools for clearly defining data and reporting.

Finally, in addition to all this, consider digging into a corporate finance text or two; the three legs of the stool are product and service design; technical and operational architecture; and finance and sales. If you can read your company’s balance sheet and cash flow statements, you’ll be in a much better position to understand where you need to target investments, what the likely return on investment will be, and how much cash (or debt) is available to make things happen. Start building up a good knowledge base in all those areas, and you’ll have the tools necessary to know the “where, how, and why” to apply the “what” of technology to your organization’s problems. "