My experience has been that 'programming' is largely about learning best practices, single responsibility, modularity, writing efficient, clean code. There are no real special books necessary for this, just read the industry standard recommendations.

But if you want to set yourself apart from others you need to study software design and architecture, and follow the big industry names on social channels. Designing software is more of an art and figuring out how to do it isn't immediately obvious or easily attainable from books. It takes years of experience and wide reading, and a lot of what I've learned about it has come from social media, not books.

Which big industry names on social media would you recommend following?

And sign up for a Mastodon instance and create a software list. These people are much more candid there than they are on Linkedin.

https://www.youtube.com/watch?v=bmSAYlu0NcY

* Thinking Forth by Leo Brodie

* Lisp In Small Pieces by Christian Queinnec

* Compilers (the Dragon Book) by Aho, Sethi, and Ullman

* Smalltalk-80 (the Blue Book) by Goldberg and Robson

But on the non-technical side, the book that probably had the biggest impact on my career was "What Color Is Your Parachute" by Richard Bolles. It is what convinced me I could transfer my skills from video game dev into another field and how to come up with a plan to do so.

- Structure and Interpretation of Computer Programs: this helped me understand the different types of recursion; how a problem can be modeled for the code to solve and how those designs can evolve and how the paradigm I'm using (functional or OOP) can help me

- Refactoring: this book helped me understand the different patterns we can use to alter code. Giving them a name and symptoms is a great way to apply and communicate with other coders. I recommend this book to everyone.

- The little Lisper: this really helped me get recursion. Like really. Although I could use a refresher.

- Clean code: look... this book is bad. Like, really bad. But, at the time I read it, and in the languages I used (Python, C, R) we didn't have many rules on how to write and organize our programs. And I wanted to improve on that skill. And this book gave me pointers and made me think about those ideas. I don't recommend it around, because for many people Clean Code can become a dogma really easily. But if you can question and critique and reach out to other resources and is an advanced beginner to coding, I can see this book bringing value.

- An Elegant Puzzle and Staff Engineer by Will Larson: those helped me get clarity on the role of the technical team in an organization. A team that produces code as the main driver of impact in a product/service. I lump them both because I read them back to back and don't remember, exactly, which is which. But une is more focus on a tech leader and the other a tech specialist.

- Unix and Linux System Administration Handbook: whenever I need to interact with some unix technology, this book delivers in terms of giving me a nice historical view and presenting the common tooling around the tool. This helps me interact with stuff programmatically much better. Be it GRUB, X, SAMBA, this book gave me the necessary introduction I needed, much more organized and thought out and with useful references than the average blog post you will find in the wild.

And I'd like to recommend this Ask HN on problem solving books

https://news.ycombinator.com/item?id=33797862

Not a book but I learned what not to do and what to avoid in my earliest days of programming from the super opinionated tool JSLint.

This was my go to reference to learn CSS https://www.amazon.com/CSS-Pocket-Reference-Visual-Presentat...

As for language design I am mostly self taught through a lot of trial and error. For me it’s all about functions and variable scope. After that everything else is just a statement, expression or a data structure. With that I can write just about anything, make it scale, and keep it super simple to read.

Learning different kinds of things, e.g. distributed databases, functional languages, metaprogramming methods, etc makes you appreciate what they can do and makes you better because you can choose to apply some of those structures in more popular environments when they are beneficial (e.g. use of immutability vs shared mutable states).

Working on larger codebases with many developers, and for a long duration lets you grow from programming to software engineering for longer term goals that optimize effectiveness both in implementations but also the people processes that can work well or poorly depending on the choices made.

Agreed.

work on code bases written by people that are much more skilled than you

Two problems here. First, you can’t really be sure if they are skilled or publicly confident. Although learning confidence is useful too, for the same reason.

Second, you can only see what they do, not what they learned to avoid. The best way to get better is to write your own code, assuming you’re at least fluent. That will teach you what to avoid and you also learn your general predispositions and code anxiety/perfectionism levels. Good reflection on that will improve you a lot. I don’t think just parroting someone’s code makes you better, unless you’re very beginner.

I once had to work the codebase of a consultant who build up his business by having less of a T profile and more of a slightly thick, incredibly long _____ profile. His code was attrocious and borderline impossible to refactor because he never stuck to a language long and consistently enough to actually learn anything resembling code discipline or hygiene. He was always too busy learning the quirks of the language and framework, which took precedence over elegance

Usually you can go to GitHub, find a project with a lot of stars for the language you want and start browsing the code. It is worth paying attention to the general attributes of good codebase: tests, documentation, build automation. If all this is there, then most likely you will definitely find something interesting or new for yourself.

Refactoring by Martin Fowler

System/370 Principles of Operation by IBM

One background I will respect is mathematicians, it is always a joy to learn from them and the can model very nice abstractions. Again, in my personal experience, no claim how general this is or that there are no exceptions.

This is a different field. Many software engineers have no clue how to set up networks or administer things like routers or firewalls. At the same time IT people usually don't know how to write things like backends for web apps.

Its vast if you approach it top down (higher abstractions to lower abstractions), seeing all the different languages/frameworks, but if you approach it the other way, you realize that every higher abstraction is pretty simple.

When you start learning things like python, or js, and then move to things like C++/C/Rust, or learn frameworks like react, you get left with a sense that each one of those things is like a separate thing where you have to memorize patterns of how to do stuff.

When you learn from the ground up, like understanding how a CPU works, every new thing that you learn immediately fits in to what you already know as a simpler way to do a combination of low level CPU operations, and you immediately recognize patterns. Memorizing syntax becomes unnecessary, since you can figure things out on the fly.

To give you a real example, most leetcode problems that get asked in interviews pretty much involve some pointer manipulation under the hood. So when you work with enough low level C and assembly, figuring out how to do things more efficiently without copying data around, you can pretty much ace leetcode medium problems without studying.