If your workflow requires a copy of this page, the simplest way is to copy everything below the line and paste it into a word processing doc. If you would prefer that I generate one for you, email me at whblondeau@gmail.com. I'll happily and promptly send it.

Bill Blondeau Workplace Practices

General observations and guidance

I've seen a lot. Some of it took a long time to register, to analyze, to puzzle over. Here are some of the most useful insights.

Treating coworkers decently is a key form of cost containment. Really. Whenever you do or say something—intentionally or not—that makes a coworker's day worse, you have just done something more than injured a person's feelings. You have imposed a cost on the organization's productivity. That cost may in fact propagate, may take on a life of its own.

Disclosure: treating people decently, in any context, is my personal and ethical preference anyway, so this finding is predictable. But, as mentioned, I have seen a lot. In the workplace, courtesy, kindness, and forbearance really do rise to the level of key principles. Jerks should not be permitted to dominate the tone.
Everybody underestimates the cost and impact of technical debt. Technical debt occurs in requirements analysis, architecture, design, code; in documentation or the lack of it; in testing or the lack of it; in user experience elements. It always ends up taking longer and costing more than anybody expects. I fight for technical solvency: the control and reduction of technical debt.

Slow is smooth, smooth is fast. I've seen this again and again: Being in a hurry leads to mistakes. It's important to remain methodical under pressure; important to take care not to let things fall through the cracks; important to not get careless; important to not take risks that end up creating lots of of wasted motion.

Things I learned as a consultant

I worked as a consultant for most of my career. Being a consultant is a somewhat different thing than being a staff employee. The lessons drawn from the difference are significant.

My workplace stance is collaborative. I try to help out. I try to keep the project's success in mind. I provide decision support whenever I see the likelihood that someone will benefit.
"Sometimes the final value a consultant can give a client is to shoulder all of the blame and carry it out the door." —Cap Gemini onboarding training
There are two general kinds of consultants: the kind that hoards knowledge in order to become indispensable, and the kind that gives knowledge away with both hands so as to be freed up for the next cool thing. Three guesses which way I went... I never looked back. I help my coworkers learn anything they want to learn.

Kind of programmer I am

This is weighted towards work as a software developer, but illuminates any kind of job I do. Some of the principles apply to work in general.

I'd rather design my way out of a code problem than code my way out of a design problem.
Treating coworkers with respect is more important than winning the language war or platform war or the struggle over paradigm.
I believe code is read more often than it's written, so clarity pays off. I write code to be clearly readable. I leave useful inline comments. I document my projects.
I believe testing works best when it's a three-legged stool:
- Behavioral or definitional testing that declares what the application does at the top level;
- unit testing;
- proper composition of tested units. Especially if it's declarative / functional composition.
I'll take declarative over imperative, whenever I can get it.
I like peer review and I want it. Yeah, everybody's busy, but I want it.
I dislike stunt coding, and try to avoid it even when i'm feeling brash.