Nobody told me I had to be a teacher

A Tech Lead has to be a teacher? Why didn’t someone tell me?

We have this C# method. It used to be good. Small. 25 lines or less. All at one abstraction level. See Bob Martin.

One of the kids, from offshore as it happens, had a bright idea. Next morning I wake up to find that the method is now a 100 lines.

I want to tell the kids. The method is too large. No method should be more than 25 lines. And they will chop it down pronto. They are good kids. But. There is no telling how they will chop it down. If they know how to tell a story in simple, clear steps, I have not seen evidence of it yet. They can’t seem to find the shortest, most direct route, between A and B.

Ask them how to go from D.C. to Baltimore.

They will come up with this. I-495 from National Airport to I-270 and Frederick. Then take I-70 to Breezewood. Break East on the PA turnpike to Harrisburg. Finally, come down I-83 to Baltimore.

That was fun. We got to write a lot of code. Oh what a lovely route it was.

They won’t stop, look around, and find 295, the Baltimore Washington Parkway, a straight shot between the hearts of D.C and Baltimore.

So I have to teach them how to chop the method down. But there is a problem. I know how to do the work. I don’t know how to teach it to another person.

I can say, make sure all of the code is at a single level of abstraction. They have no idea what I am saying. I don’t blame them. What does the word ‘abstraction’ even mean? I don’t know how to describe it man, I just know it when I see it. You know the button that starts your car. That’s an abstraction. You know what I mean? You don’t? Well, bloody hell.

So now on to Plan C. I redo the method myself. You know, I give them advice, and an example. Guess what happens. Nothing. Two days later the silly drama repeats itself.

It turns out, they could not care less about Clean Code. They know the programming language. They know some libraries. They are decent at problem solving. They get a kick out of flipping switches and seeing results. They are having fun. They feel no inclination to examine what they are doing. Stop, step back, dig deep, see under the surface, unlearn old habits, cultivate new habits. Further, after a couple of Sprints, they also learn that I will clean up the code myself.

It took me a long time to understand how to write Clean Code. It took me much practice to do it instinctively. Do you know how much I rewrite? How am I going to get the kids to adopt a regimen of study and practice? How am I going to get them to show interest and sustain it? How am I going to get them to care?

I am only a working engineer. You are asking me to not only teach, but also to motivate.

All of this, I have to do while a project is going on; under the gun, to deliver something.

It is not going to happen.

You are not going to get Clean Code.

Unless. You hire the right people.

Focus on skills rather than role

The project manager said, that is not your role, stay in your lane. I held my tongue. But it struck me that I no longer understand the fixation on roles.

While developing software, we must make certain choices. Some of these choices are expensive to change if you get them wrong. These choices constitute architecture. See Grady Booch. Architectural decisions must happen. How does it matter who makes these decisions, as long as they know what they are doing? We need Architecture. We don’t need Architects.

The same argument applies to other work. We need business analysis, we don’t need business analysts. We need testing, we don’t need testers. You catch the drift.

If one person can do business analysis, and solution design, why not let them do it? If one person can write code and test, why not let them do it? With each fewer person in the team, you avoid an information hop. With each fewer information hop, you avoid some information loss.

Here is another argument. A designer must know the business that she creates solutions for. Why not let her learn the business first hand? Let her do the business analysis. A developer, makes better choices in the code, when he knows the essential business. Why not let the developer talk to the business? If the developer has the necessary skills, drop the middle man. Knowing what Agile has taught us, do you still want a developer that cannot test? Let the developers test; eliminate a whole moving part in pipeline.

If one person can do a job, why would you want three? If three people can do a job, why would you want six?