How Experienced Programmers Talk
Yesterday, I wrote about a high-level overview of how a programmer should communicate.
In that, I devised a simple 1–2–3 plan on how to make technical and interview presentations.
Today, I am going to go into detail, and define the most basic building blocks of programming communication.
Because detail is where the devil lies.
Why this is necessary?
I realized it the hard way.
During the early part of my career, my talk was filled with tech terms. If I wanted to describe a simple class relationship, I would go on like this:
Class A has two methods: getConfiguration() and postMessage(). Using getConfiguration(), class B first gets the configuration. Then it calls postMessage(), which accepts a configuration object as an argument.
This was during the time of our bi-weekly status meeting!
Everyone yawned. My boss thought I was an intern. In reality, I was quite senior but had rarely participated in collaborative design with real programmers.
My tasks mostly included getting the specs from the client, designing the features, and delivering, with no intermediate stage of collaboration, Q/A, or whiteboarding.