[This also serves as a reminder for myself of some of the most important things to remember always.]
“A Little Architecture” by Uncle Bob Martin
“The important decisions that a Software Architect makes are the ones that allow you to NOT make the decisions about the database, and the webserver, and the frameworks.”
The SOLID Principles of Software Design
“The goal of software architecture is to minimize the manpower required to build and maintain the required system.”
“Respecting Levels of Abstraction” by Jonathan Boccara
“I deem respecting the levels of abstraction to be the most important principle in programming, because it automatically implies many other best practices.
“abstraction is characterized by what a particular piece of code intends to do as opposed to how it is implemented”
“Growing Object-Oriented Software Guided by Tests” by Steve Freeman and Nat Pryce
“All code should emphasize ‘what’ it does over ‘how’, including test code.”
“The Most Important Design Guideline” of Scott Myers
“Make interfaces easy to use correctly and hard to use incorrectly.”
“The Right Attitude to Deal with Legacy Code” by Jonathan Boccara
“… What’s the right attitude, then? I was lucky to learn it very early in my career from my fantastic manager, Patrice Dalesme. A few weeks after I came in, Patrice gave us the following piece of advice: consider that the code you’re working on is your code. Even if you haven’t written it yourself, and regardless of how good or bad you think it is, this is your code, and you have responsibility over it.”
“Don’t Get Obsessed With Design Patterns” by Joel Rodriguez
“I believe that knowing object-oriented design principles and applying best practices like SOLID, KISS and YAGNI are far more important than design patterns themselves. If you apply these principles, patterns will come out naturally.”
“7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development” of J. B. Rainsberger
“The fundamental theorem of agile software development says this: If you want to estimate little things, you have to refactor, because refactoring is how you reduce accidental complication; and only by driving accidental complication down as far as you possibly can will your relative estimates have any meaning…”
“…Therefore if you’re gonna estimate, you’d better refactor, which means Scrum cannot work without XP.”
“Don’t Overwhelm Yourself Trying to Learn Too Much” by John Sonmez
“I think the best way to improve your skills and to learn what you need to do is to do the learning as close to the time you need the information as possible –- just-in-time learning.”
“Staying relevant as a programmer” by Mattias Petter Johansson or MPJ
“Are we forever cursed to do this constant tooling rodeo, where we try to hold on in the job market for dear life, learning new tools as the plop up all over the place?
“Instead of trying to predict the future, which we humans are really bad at — just look at sci-fi movies from the 60-ies — you should learn the stuff that doesn’t change around a lot.
“Three Paradigms” by Uncle Bob Martin
…But in that same 40 years software technology has barely changed at all. After all, we still write the same if statements, while loops, and assignment statements we did back in the ’60s. If I took a programmer from 1960 and brought him forward through time to sit at my laptop and write code; he’d need 24 hours to recover from the shock; but then he’ll be able to write the code. The concepts haven’t changed that much.
“This Is How We Do It” by Terence McGhee
“The key to growing in this occupation is to realize that neither the languages that you love or the frameworks that you’re familiar with are the keys to your success. Because the field is so new and because the core fundamentals of programming today are almost exactly what they were from the beginning (Sequence, Selection, and Iteration), your ability to advance is not hinged on language particulars or framework features.”
Please Don’t Learn to Code by Jeff Atwood
“Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems. Don’t celebrate the creation of code, celebrate the creation of solutions.”
“… But here’s the thing. We all feel like phonies sometimes. We are all phonies. That’s how we grow. We get into situations that are just a little more than we can handle, or we get in a little over our heads. Then we can handle them, and we aren’t phonies, and we move on to the next challenge.”
Curb code rot with thresholds by Mark Seemann
… Rules make great training wheels. Once you become proficient, the rules are no longer required. They may even be in your way. When that happens, get rid of them.
“How to Win Friends and Influence People” by Dale Carnegie
“Are You Epistemologically Self-Conscious?” by Dr. Jason Lisle
“The Great Debate: Does God Exist?” — Dr. Greg Bahnsen versus Dr. Gordon Stein
“Resolving the Liar’s Paradox” by Steve Patterson