Advice
And I’m okay. Indeed, last week saw a payoff for one of those hygiene things you do because you know that you “should”. A Logging Story Allow me to share what happened (feel free to skip this section). We receive orders from a number of different sources. In addition to EDI, we have spreadsheets, flat-files, and we even originate a few ourselves under Vendor Managed Inventory (VMI) agreements. One of the things we’ve done recently is create a single “process pipeline” such that once orders enter the pipeline, their processing from that point forward...
In one of his characteristically long essays, Bill Whittle expounded at length on the genius of John Boyd. The essay is political and not necessary to understand my point, so follow the link at your own risk.
At any rate, Boyd proved a tactical theory of aerial combat by repeatedly winning a challenge to the best Air Force pilots in Nevada. The challenger would start by having Boyd in a perfect kill position at thirty thousand feet over the Nevada desert. Once the challenger yelled "Fight’s on!", Boyd had 40 seconds to reverse their positions.
Winning that challenge repeatedly and consistently...
Reading the beginning of Joel’s second section of his talk at Yale clarified one reason I find myself so at odds with much of the hard-core Dependency Injection crowd (has Joel really achieved the level of fame that we can dispense with using his last name as Phil Haack suggests? Did you know who I meant right off?). Anyway, I am an in-house developer in a small company and that has a huge effect on my architectural decisions.
In-house Development
I described it a couple of months ago as simply "small company development", but Joel’s right that the more significant aspect...
I’ve been putting off a follow-up on Dependency Injection for a couple of months now. The amount of heat I anticipate receiving is so disproportional to the probable light gained that it makes me hesitate. This weekend, I picked up on a stream of referrals from a post at InfoQ that mentions my Dependency Injection post (though not the follow-ups). It does a reasonable job of spelling out the conversation that happened, though I was feeling picked on until it brought in Eli Lopian’s contribution to the discussion. In whole, it’s a good summary. The real pile-on happens in...
In many companies developer career progression is deceptively straight-forward; Jr. Programmer, Programmer, Sr. Programmer, Team Lead, Architect, Sr. Architect, Bob (Bob being the semi-mythical entity referred to in obscure comments, worshipped by now-extinct aboriginal tribes, and rumored to haunt the sub-sub-basement).
The differentiation between these positions starts off with how much you know. A Sr. Programmer is a Jr. Programmer who knows his tools inside and out and can complete assigned tasks quickly and without a lot of supervision. Around Team Lead time, however, progression stops being about what you know and starts revolving around your ability to choose wisely...
I found Scott Adams' (yes, that Scott Adams) blog post today about The Power of Choice interesting. Particularly at the end where he says this:
The next time your mate or co-worker is butting heads with you over a decision, recast the situation as their choice.
For example, let’s say you favor Option A, and someone else wants Option B for reasons that seem to you irrational. You are at an impasse. Change the question to this:
“Okay, do you want Option A with this risk, or do you want Option B with this other risk? It’s your call.”
When...
I was thinking today about something I learned the hard way and how I wish someone had taught me what to look for earlier in my career. Then it occurred to me that perhaps I could perform that service for others.
He Hates Me!
Have you ever found yourself in a situation where someone important where you work doesn’t seem to like you very much? I have. In fact, at my first real programming job (programming in Pick of all things) my manager’s boss obviously had a hard time with me. I would hear from my manager that her boss was...
There's a reason that my personal blog is named The Rabid Paladin—I form opinions easily and express them strongly, even as I attempt to maintain an even keel through my sense of integrity. What this means is that on those occasions when I enter an argument with the purpose of informing and/or convincing others, I try to remain open to valid points from other perspectives and the possibility that I might be wrong.
Letting Bias Show
Too often, people arguing their case will paint alternatives in as bad a light as possible—perhaps believing that their misrepresentations make their arguments stronger. The...
I've been considering this post for a while now, but have been afraid to actually write it. So here's the thing: I've noticed that most of those who talk about how evil Microsoft is don't bother supporting that assertion. They tend to assume the rightness of their position and hence the wrongness of whatever it is that Microsoft has done. Microsoft stifles technology! Microsoft is a monopoly! Microsoft engages in unfair business practices!
Do they really?
No Consumers Were Harmed in Making This Software
There's a couple of problems with the whole monopoly thing. For one, at least in the U.S., being...
I wrote last month about winning arguments in IT. Earlier this week, Phil Haack asked a question (through Twitter) about things he could do to help convince a company to create an in-house QA department. Well, it turns out that I did exactly that at XanGo—successfully pushed for and oversaw the installation of an in-house QA department. I thought it might be a useful follow-up to the previous post to use this as an example of how I "won" that argument.
Concentrate on What is Best for the Company
This is the key, the whole key and nothing but the key to winning...
Steve Harman had a post back at the beginning of the month about stuff you'd tell a young developer. It's a reaction to a similar piece by Jeremy Allison. It's an interesting topic, so I thought I'd waste a few pixels on it myself.
If it's not what you love, don't do it
I wouldn't generalize this to other fields, but for software development, I think this is a good thing to keep in mind. A lot has been made in the past by career counselors and other gurus about "finding your bliss" or similar nonsense. I think that's mostly a crock. You...
Have you ever found yourself in a situation where you know what's the best thing to do, but are unable to convince anyone else that you are right? Developers know that even simple problems have more than one solution. Developers who have worked on a team of more than one have probably been in a situation where they just knew that the team was heading in the wrong direction and that they had a solution that was more elegant, easier to program, and better to maintain.
Higher profile developers often find themselves trying to explain their solutions to non-technical people...