Our team planned to use a new set of data tables to increase our customer knowledge and overall improve our processes. Due to our workloads, our team lead had a person (Dev X) from another team write some code to access the tables and create some usable datasets for our process. After the code was written, Dev X was asked to arrange a meeting to review the programs.
In short, it did not go well. It was not anything Dev X did, it was what did not happen that contributed to the issue. ( In Dev X defense – the code overall is easy to follow and looks efficient.)
So what went wrong and what can you learn?
Mistake #1: Presuming data knowledge
What Happened
Dev X asked first what our SAS skill level was – the team lead answered “Advanced – macro writers“. Dev X then walked us through the code explaining how SQL joins worked, purpose of LET statements, and how various SAS functions worked, etc. Frankly – it was insulting and a time waster.
What Should Have Happened
It was good to ask our skill level. If Dev X had been misled in the past, a few questions to qualify “Advanced” would have been good. “Do you use SQL to join, are you familiar with SUBSTR function, macro writers means you know LET statements?”
Once you believe the audience is advanced, then think carefully about what you need to explain. Maybe you need to explain why the SUBSTR function is used with a particular variable instead of how the SUBSTR function works. For instance, why do you only select the first 3 characters of the product code? Maybe add a PROC FREQ showing the product code – before and after. Then we could better understand why that new variable was needed for the join or see the data itself.
Mistake #2: Presuming audience can see your desktop (or inside yo’ head)
What Happened
This was a phone conference. All of us were in remote locations. Dev X sent the code ahead of time and then told us to open it. We had a hard time following which program was being discussed. Several times the other team mates were IM’ing saying “Where are we?”
What Should Have Happened
The technology to share the desktop was available. If it had not been – I think you have to go to extra lengths – “Line number 340 of the second program … blah blah.”
If we had been in a room together, I think Dev X may have had more visual clues about what was going on. Are people listening? Do they get it? Do I need to go faster or slower? The phone introduces special considerations and I think dead silence and mono-syllabic answers are deadly.
Mistake #3: Presuming you know the actual topic
What Happened
This was probably our fault. When the team lead asked Dev X to have a code review – it was interpreted more literal than was meant. Dev X explained what each line of code was doing. During the first 15 minutes, the team lead was trying to move Dev X down the path we wanted, but we were having a code review and that was that.
The reason Dev X was asked to write the code was due not only to our lack of time, but also our lack of knowledge of the data tables. None of us understood which data tables and data variables we needed for our processes, why we would choose one over another, or the tricks to working with the data. And we still don’t.
What Should Have Happened
A flowchart with the overall design how the five programs interacted with the data tables and each other. Then a quick code walkthrough that pointed out specific areas where it might be less obvious what was happening. In Dev X defense – the code overall is easy to follow and looks efficient.
Any mistakes you would add to the list? Any similar experiences? Am I being too picky/crazy/overly critical?














Outstanding tips! I have already been searching for something such as this for a while now. Cheers!