Over my career, I’ve come to realize there are some important truths that you should keep in mind. The senior people have experience. Pay attention to them. Senior people have seen more and likely have insight into subtle and/or complicated issues. They do not always have insight into your issue. But, their experience should not… Read More »
When developing code, most of us would rather spend time writing code or talking to users to understand their problems than to spend time on process. Process does not need to be a dirty word, although most developers would disagree. Processes Suck Most processes imposed from outside the team suck. Partially, that is due to… Read More »
In almost every field, people will grab onto some belief without any (rational) reason. Programmers often act and seem to believe that they are actually rational people and would not hold an irrational belief (at least where our field is concerned). When you look at your fellow developers, you can usually spot counter-examples. Like many… Read More »
Any time you have a long-term data structure, it’s important to have some form of unique identifier used to look up or recognize the structure. It doesn’t matter if the long-term data is a database record, a document in some form of storage, an object, or whatever. If the data lives for a while, you’ll… Read More »
One approach for design trade-off is between Until recently, I tended to treat the second and third as the same. With some more thought, I’ve convinced myself they are not.
I see a lot of development advice that assumes the developer is working on a green field application. Many of the tools that “make a developer’s life easier” are also designed mostly for use in creating new applications. Most of my experience as a professional developer (or whichever title you prefer) has been improving and… Read More »
Over the years I have noticed a habit among some developers that I’ve come to call Aphorism Driven Development. Many best practices are taught and remembered through the use pithy statements. Although these statements are easy to remember, they can’t capture the full context and connotations of the practice in question. If someone never learns… Read More »
Any solution to a problem involves trade-offs. One of my managers a long time ago used to be fond of saying some variation of There are an infinite number of solutions to a problem. A subset of those will work. A subset of those will work well. A subset of those are actually worth doing.… Read More »
It’s time for another post in my intermittent series of Best Practices Gone Bad (BPGB). This time we’ll cover the dark side of the Single Responsibility Principle (SRP). According to Robert Martin: A class should have one, and only one, reason to change. The basic concept is easy. Every object or method should be responsible… Read More »
The comments from Ian and rlb3 have made me think a bit more on what I said last time about Chronistic Coupling. One thing I didn’t make perfectly clear is that I’m not advocating avoiding Chronistic Coupling at all costs. Any real system will require some amount of Chronistic coupling. The key design point is… Read More »