Change

Years later.... I've determined that maintaining a blog is not a task that comes easily to me. I tend to update it, at first, a few times a week then I somehow forget to do it. That's not conducive to readership and it also makes keeping up with where you were last a bit of a chore. Still, let's try again.... Let's talk about change. Change is a constant and, because it IS a constant, it should be, if not openly embraced, welcomed as an embarrassing sibling; you may not want to invite them over, but, hey, they're family. And like that sibling, change can be scary. However, especially in technology, you have to get comfortable with change - it happens faster in this field than any other.

Bob and Weave

Have you ever had dealings with clients, co-workers, or just about anyone where, when you ask a fairly straight-forward question, what you get back is a great deal of talk that ends up not answering the question? For me, that usually means that they aren't wanting to be direct. If they aren't wanting to be direct then you have to think there must be a reason. Then you start wondering what the reason might be and you ask yourself, "Why do they not want me to know the answer in the first place?" Trust starts to erode. You're left with evaluating their actions against the words they just threw out at you. That's all that you can do; evaluate and decide if what they are telling you even remotely jibes with what they are doing. In the meantime, you move on and wait for the next time that they evade your questions....

Clarity

I was asked today, "What is the monkey?" Well, the monkey is whatever is jumping up and down on your back demanding attention. It's the next big idea, the annoying glitch that won't go away, the irate customer or co-worker. Just about anything is the monkey. And the blog is about dealing with those little items of daily interest. Manage the monkey. What's jumping up and down on your back?

I was ruminating on software development and managing various personality types. There are software engineers who architect their projects and there are programmers who do not. Both are viable under certain circumstances though I believe most would agree that some form of well-considered engineering is better than seat-of-your-pants gun-and-run. That said, I thought that a reasonable person with some modicum of respect for his or her fellow coders should 'respect the architecture.' That is, when working on a system/project/piece of code that is not your own which was given some form of thought by someone else, it is a matter of disciplined good graces that, despite what you think of the code and how it might be improved upon, you should do your level best to develop code similarly to the initial design. For example, if you don't, for some odd reason, appreciate the use of interfaces but the owner of a system you are working on uses them for device objects and you are asked to add a device object to his system, you should use the interface the owner uses. What do you think?