I’ve been posting about a few principles that have helped me minimize the pain of understanding complexity in my own code. See part 1 of this series where I briefly discussed leaving yourself and others notes about the “why” of your design decisions. And see part 2 for discussions about simplifying your code.
Continuing with the movement towards simplicity; whenever possible make functions and scripts single use and encapsulated. We can think about breaking functions (or scripts) down into their smallest useable parts as simplification, or we can talk about it as encapsulation. We broke down a confusing custom function into separate parts in order to improve readability. What we also gained was some compartmentalization and modularity. It’s difficult to separate the two principles of simplicity and encapsulation.
Continue reading ‘I’m just a stupid developer, don’t confuse me… part 3 of 3′
). Drawing liberally from 
Speak your Mind. Using Comments, part 1.
Recently I was on a family trip to Pittsburgh. We were walking around the campus of Carnegie Mellon and I saw this memorial brick;
It got me to thinking about some of the monster databases that I have had to take over for clients. When I take over a project, often I am spending a great deal of time just trying to figure out what the developer was trying to do.
Our earlier posts on this blog are generally concerned with improving the user experience(better printing workflow) or getting more out of your data (One Report two sets of summarized data). Today I would like to return to that lowly person, the developer. Anything that I can do that can make my job easier will make be a better developer and ultimately make my customers happier. Or as my grandfather would say to my grandmother, “What would you do if I got hit by a bus?” Continue reading ‘Speak your Mind. Using Comments, part 1.’