C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it.
Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.
Premature optimization is the root of all evil.
One of the advantages of having to live with JUnit for 8 years is now we can look back and see which decisions we made worked nicely and which we would have done differently.
In software engineering, we have the term 'technical debt.' When you don't do a job correctly, unaddressed problems become harder and harder to solve.
Always think about how a piece of code should be used: good interfaces are the essence of good code. You can hide all kinds of clever and dirty code behind a good interface if you really need such code.
I've noticed that just about every time I find a large program with known glitches that no one seems able to fix, that program is written in C and is likely written by a programming team in a remote location.
Don't document bad code - rewrite it.
If 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself: 'Dijkstra would not have liked this', well that would be enough immortality for me.
An individual developer like me cares about writing the new code and making it as interesting and efficient as possible. But very few people want to do the testing.
Good code is its own best documentation. As you're about to add a comment, ask yourself, "How can I improve the code so that this comment isn't needed?" Improve the code and then document it to make it even clearer.
We’re no longer in the days where every program is super well crafted. But at the heart of the programs that make it to the top, you’ll find that the key internal code was done by a few people who really knew what they were doing.
Don't hurry your code. Make sure it works well and is well designed. Don't worry about timing.
All the PHP code I've seen in that experience has been messy, unmaintainable crap. Spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places.
Programming languages are like girlfriends: The new one is better because *you* are better.
Developer testing is an important step towards accountability. It gives developers a way to demonstrate the quality of the software they produce.
The flip side of the coin was that even good programmers and language designers tended to do terrible extensions when they were in the heat of programming, because design is something that is best done slowly and carefully.
We flew down weekly to meet with IBM, but they thought the way to measure software was the amount of code we wrote, when really the better the software, the fewer lines of code.
I used to be enamored of object-oriented programming. I'm now finding myself leaning toward believing that it is a plot designed to destroy joy.
An effective way to test code is to exercise it at its natural boundaries
Prolific programmers contribute to certain disaster.
My favorite language for maintainability is Python. It has simple, clean syntax, object encapsulation, good library support, and optional named parameters.
I used Agitator on some code I had unit-tested, and it made me a better tester. As an Agitar Fellow, I look forward to the leverage of working with an outstanding organization as together we continue to improve the value of developer testing.
