I spend a lot of energy on the coding equivalent of the mantra "cleanliness is next to godliness".
People sometimes think this is extra work but it's not. In fact, it's anything but that.
Fastidious coding is frontloaded work. That is, I'm taking the thing that I know is hardest - keeping my design natural to my problem - and doing that work as soon as I can.
When you do that, code-cleanliness work doesn't start to stack up into a seemingly insurmountable pile.
That psychological effect, alone, is worth the "effort" but there's a subtler, more potent source of value.
Badness compounds on badness. When you let code be bad, you do bad things to get it to work. That makes the code worse.
So, allowing a quality problem to fester not only accumulates redesign work into large chunks but also accumulates work you would never have had to do if you just kept things clean.
Following is a video wherein I spend about an hour cleaning up a test library, among other things. You can think of it as a waste of time or an expression of my perfectionism if you want to, but I would like to offer a different perspective.
What if you watch the video and try to think about all the things that could go wrong if I didn't do that cleanup, this morning?
Friday, January 25, 2019
Thursday, January 24, 2019
A Friend Asked Why I Don't Have Comments
The answer is simple.
I don't like the way the blog looks with comments enabled. I think it looks ugly with this style.
If people are interested in discussion, I'm sure I can find a solution that isn't visually-jarring.
I don't like the way the blog looks with comments enabled. I think it looks ugly with this style.
If people are interested in discussion, I'm sure I can find a solution that isn't visually-jarring.
Wednesday, January 23, 2019
Intensive Coaching
I'm going through an intensive coaching experience. The idea is that I spend a full ten weeks with a single team.
I'm a little surprised with the outcome. I knew there would be an impact but the team is progressing a lot faster than I, for one, anticipated.
I don't have enough data to attribute that to the intensive experience, yet. It's also a really engaged and interested team and I suspect that has a lot to do with the progress being made.
I think people have a tendency to be a little superstitious in assigning reasons for success or failure. I don't want to contribute to that but, it's easy to see why someone who went through an experience like this one might be convinced it's the only way to coach software developers.
I'm a little surprised with the outcome. I knew there would be an impact but the team is progressing a lot faster than I, for one, anticipated.
I don't have enough data to attribute that to the intensive experience, yet. It's also a really engaged and interested team and I suspect that has a lot to do with the progress being made.
I think people have a tendency to be a little superstitious in assigning reasons for success or failure. I don't want to contribute to that but, it's easy to see why someone who went through an experience like this one might be convinced it's the only way to coach software developers.
Tuesday, January 22, 2019
American Idle
We work a lot, here. We work a lot more than we probably should.
That's not really a problem. Not long ago, where I'm sitting was the frontier. Hard work was necessary to survive and to thrive.
Yet, even in frontier times, people rested. They worked hard and then they rested. Then they worked more.
I think we lost that somewhere along the way. People feel like they need to spend every second working.
The mentality is this:
If you're not busy, you're wasting your time. So get busy.There are many problems with this.
First, you're way more effective for the period of time shortly after you've rested than you are when you've been working for a long time; at least, that's true for most people. So you lose productivity by trying to stay at full utilization. It's a self-defeating proposition from the get-go.
Next, there's the fact that the impulse to work hard continuously suggests there's something fundamentally wrong with your approach. There's a practically-limitless amount of work to be done. Work needs to be managed and sliced into bite-sized pieces with adequate funding. If heroics are required, then the work isn't really being managed. Mismanaged work is nearly-guaranteed to fail.
Finally, there's the fact that work is probably not the best part of your life. I mean, every workplace wants to be a second home, or whatever, but the reality is that most of us have something else that matters more. We have families. We have hobbies. We have charities. Those are typically the reasons why we work in the first place. Working to the detriment of our higher goals is, again, self-defeating.
So if you want to work hard, great. If you want to cannibalize your life to try to get a little more done, spare a few minutes asking yourself way.
The break will probably help you get more done anyway.
Monday, January 21, 2019
Dependencies, Not Levels
The way we teach people to be software developers doesn't make a lot of sense.
It's one of those things that sounds reasonable so long as it is described in vague-enough terms. The idea is that you build up someone's skills slowly, incrementally.
For instance, some people believe that you should start by teaching scripting. Then promote students to procedural coding. The traditional version of object-oriented design follows. Finally, assuming the person you are talking to has enough understanding of software development, you start teaching design patterns.
The same is true of test-driven development. Start with test never. Then move on to test-after. Upgrade to test-first. Promote to TDD and then, ultimately, to organization-level BDD.
Refactoring gets a similar treatment if it gets any treatment at all.
What's really being proposed is ordering alternative ideas by how difficult they are to completely master.
This doesn't make any sense because it sets up a pattern of wasted effort. You start by teaching someone something the wrong way. Then, after they've attained a modicum of mastery in that way, you tell them it's bullshit and they should do something else.
How do we expect people to react?
I'm experimenting with a different pattern: Start with a skill that doesn't have any dependencies and don't worry about mastery. Just help people get enough to start using it, which really isn't that much. As skill in that area improves, it also enables someone to start learning a skill that depends on it.
In software development, given developers who already have basic coding skills, refactoring is the skill with no dependencies. Refactoring enables design because it's way easier to imagine a new design if you have a chance of getting there safely. Design, in turn, enables TDD because it's easier to imagine using tests to drive your development process when you know you can create and refactor to designs that will enable the effort.
It seems like it's working really well.
It's one of those things that sounds reasonable so long as it is described in vague-enough terms. The idea is that you build up someone's skills slowly, incrementally.
For instance, some people believe that you should start by teaching scripting. Then promote students to procedural coding. The traditional version of object-oriented design follows. Finally, assuming the person you are talking to has enough understanding of software development, you start teaching design patterns.
The same is true of test-driven development. Start with test never. Then move on to test-after. Upgrade to test-first. Promote to TDD and then, ultimately, to organization-level BDD.
Refactoring gets a similar treatment if it gets any treatment at all.
What's really being proposed is ordering alternative ideas by how difficult they are to completely master.
This doesn't make any sense because it sets up a pattern of wasted effort. You start by teaching someone something the wrong way. Then, after they've attained a modicum of mastery in that way, you tell them it's bullshit and they should do something else.
How do we expect people to react?
I'm experimenting with a different pattern: Start with a skill that doesn't have any dependencies and don't worry about mastery. Just help people get enough to start using it, which really isn't that much. As skill in that area improves, it also enables someone to start learning a skill that depends on it.
In software development, given developers who already have basic coding skills, refactoring is the skill with no dependencies. Refactoring enables design because it's way easier to imagine a new design if you have a chance of getting there safely. Design, in turn, enables TDD because it's easier to imagine using tests to drive your development process when you know you can create and refactor to designs that will enable the effort.
It seems like it's working really well.
Sunday, January 20, 2019
Saturday, January 19, 2019
The Infinitely-Thin Tightrope
Mike didn't understand what was happening. That was nothing new.
What was different was that he didn't understand his own actions.
He hated Samantha. He despised her arrogance. He found her personality repugnant. Most of the time he interacted with her, he spent thinking he could never see her again and be happy about it.
Conversely, he loved his wife and young son. When apart, Mike often found himself wishing he were with them rather than doing whatever he was doing.
Mike loved his wife and hated Samantha yet he kept finding himself in Samantha's bed. He wanted to be away from Samantha as much as possible but found himself wondering what was the deal when she grew cold and distant.
Samantha had become a ghost walking in human skin. She was pale and jumpy. All the time. She was secretive about what she was doing and for whom.
Mike wondered how badly Kramer had scared her. Was she broken? Would she ever be the same?
...and, most of all, why did he care? He still despised her. She was a disgusting human being...but he also cared.
It was bizarre, having such conflict of feelings.
It was a warm summer's evening. The sun was just barely set, leaving a reddish-amber glow in the sky and casting a thin gray veil over everything.
Mike took a deep breath, absorbing the dryness, warmth, and fragrance of the newborn night as if it could replace the disturbing thoughts running through his head.
He flipped his key around in little circles by spinning his index finger inside the keyring.
It was a disturbingly-quiet walk across the parking lot. No sounds to drown out his thoughts. Just his footsteps on the pavement.
When he got to his car, he barely swung his keys a little too far and they spun off his finger. There was a little "ting" sound as they bounced off the door of his brand new Audi - a birthday gift from his wife - and an abbreviated jingle when they landed on the ground.
Mike sighed and looked closely at his door.
"For fuck's sake," he said. "Really?" The shiny new paint on his shiny new car was marred.
Mike sighed and started to bend down to get his keys but something raised his hackles and his spine stiffened. He narrowed his eyes and peered around without turning his head.
"God damn!" he shouted, leaning in to poke at the fresh ding on his door.
Mike spun around to face the other direction and raised his fists in the air, then repeated: "God damn!"
Quickly, he scanned the parking lot. There was nothing there but he couldn't shake the uneasy feeling.
Eventually, there was nothing to be done about it. He bent down for his keys and, when he stood up, nothing happened. He shrugged.
"Maybe I'm getting paranoid, too," he muttered.
Mike pushed the button to unlock his car. A satisfying "click" told him it was going from locked to unlocked.
He got in the car and started to drive. Everything was dead. It was a quick drive to the parkway, which was basically empty.
Mike decided to really open up his new car and see what she could do. He slammed down on the accelerator and pushed the speed...fifty, sixty, seventy miles an hour.
"Not too fast," said Kramer from the backseat. "You probably don't want to get pulled over, right now."
Mike wanted to jump out of his skin but maintained a semblance of outward calm. He cleared his throat. "Maybe I do," he said. His voice trembled, betraying his veneer of confidence. Nevertheless, he took his foot off the accelerator.
Kramer was barely visible in the rear-view mirror. He was dressed in black from head to toe. Unless you looked closely, you probably wouldn't even notice he was there. He chuckled softly.
"It might not go well, for either of us," said Kramer, light glinting off the rim of his glasses as they passed under a streetlamp. "Even if it did, there would be questions. They'd want to know where you were, recently. They'd want to check with your wife."
Mike pondered the not-so-hidden meaning for a moment, then set the cruise control. "Where are we going?" he asked.
"Just keep going, like you always do."
"Okay."
They drove in silence for a few minutes. Kramer made no effort to continue the conversation.
Eventually, as he was pulling off the Parkway and onto surface streets, Mike asked, "What do you want?"
"It's simple. Samantha knows something. I need to know it, too."
"What makes you so sure?"
"I've been watching you. All of you."
"What makes you think I'll help you."
"That's simple, too." Kramer's teeth shone, revealing a little sneer. "For one thing, I recorded some highlights of your most recent little sleepover with Samantha."
Mike's cheeks reddened. "And?" he asked.
"...and I think you two like each other. Underneath all the hate, that is."
"So?"
"So her life's in danger until whatever she knows is in the right hands."
"Your hands are the right hands?"
"I think they are," said Kramer. "What does Fred think?"
"Your car is dirty. Let's get it washed."
Subscribe to:
Posts (Atom)


