A few days ago three of us were talking back from the Devonshire Square market after having enjoyed the warm, sunny weather by eating our food outside. The topic of conversation had wandered but had eventually rested on careers. Specifically, we had hit upon the topic of how to decide on what one’s next position might be. How can one decide between staying at an existing job or leaving to something else? If the decision is to leave, then how does the decision between different positions on offer get made?
The question seems to be easy to answer by just listing out specific aspects one could be looking for: look for a higher salary, look for better working conditions, look for a place that has less overtime, take the one where you’ll learn the most. This hasn’t answered the question at all! It has actually made the question even harder to answer by obscuring the issue with too many details and, at the same time, not providing any way of deciding which of these specific aspects the decider cares about.
To get to the real answer, you have to first ask yourself a very different question: what are you hiring this new (or your existing) job to do for you?
Are you looking to have it pay off your debts? Move you to another country? Teach you a new skill? Allow you to have time to fish?
If you look at the job as a product to be bought or a service to be hired, what are you hoping to get out of it?
Once the job to be done is clear, then the choice between the different aspects above will be, if not easy, at least guided toward a goal.
Recently, puppet got a new way of defining environments. Along with the new environments, came a new way of handling the caching of the environments inside the puppet master. I found out that what puppet is now doing, and was doing in the past, wasn’t well understood by users and so this post is to get rid of some of the mystery.
I’m going to cover what an environment is internal to puppet, what the caching of an environment is, and what it isn’t, and what it used to be. In other post I’ll cover how to evaluate your situation and tune the environment cache and your workflow.
Continue reading “Understanding Environment Caching in Puppet”
Every team that I’ve worked with has eventually come to ask the question: when is it done? And they don’t just mean “done”, they mean, when is it “done-done“? Every time, for whatever reason, this seemingly innocuous question becomes a sticking point of a lot of conversations. Sometimes everyone can agree on what it takes, but there ends up being concerns about the feasibility of the definition in practice. Other times there is some dissent about the points of done related to what is actually in the team’s control. All of these are perfectly valid concerns. Some of those concerns point to larger, organization problems that are being faced and some point to fear of tackling what at first looks like a daunting mountain of change to reach “done-done” of knowing when you are “done-done”.
Continue reading “You’re done when”
Are you a rational, logical person? When you are given the data about a situation, do you change your mind? I would be willing to bet that you like to think about yourself in that light. I know that I do.
However, I know that I still hold beliefs in spite of some data. If you give me some data about a situation, I’m not very likely to believe it. I might accept it, I might even agree with it, but I won’t likely change my thought process that you, as the presenter of that data, think I should be changing. Why is that?
Continue reading “You’re Wrong and Can Never Be Convinced Otherwise”
The other day at work I was implementing a new feature and found myself in a nice little, self-contained bit of code. I was adding the ability to parse a pair of query parameters from an HTTP request into an optional Period (a class used to represent a period of time in the application). After TDDing my functionality into place I reached a fully functional version but cringed every time I looked at it. I normally try to refactor during the TDDing but I just couldn’t see what to do until I had a bit more meat to work with. Once it was all in place I had enough to start chopping away at it.
Continue reading “An exercise in refactoring”
Modern Java? Isn’t that an oxymoron?
At XPDay this year Julian Kelsey and I presented a session entitled “Refactoring to Functional Style”. It seemed to be pretty well received and drew a lot more people to the room than, I think, either Julian or I ever expected. The theme of functional style in Java, and other common languages, continued throughout the conference. The ideas showed up in several other sessions as side topics and in one more session specifically about testing functional style programs that was led by Nat Pryce. There seemed to be a new way of working in Java that was starting to emerge.
Continue reading “Toward a Modern Java”
So you think that new module of code that you just whipped up is just fine? You even wrote it with a pair or two! All of the names are the best that you could think of, the thesaurus is still smoking as it sits next to your keyboard. Control flow effortlessly flows from one expression to the next. Data dances in happiness for the structures that you have decided to use. This is not in any way going to be a maintenance problem!
Are you sure? Have you tested it? No, not that kind of testing. I trust that you have a good set of unit tests. Maybe even some nice acceptance tests that were looked at, or provided, by your stakeholder. No, what I mean is have you tested that it won’t be a maintenance problem?
Continue reading “UX Test Your Code”