BI Tools

Tips and tricks for building information maps, OLAP cubes, reports, and dashboards

BI Admin

Learn your way around a SAS BI installation.

Visual Analytics

Learn your way around the SAS Visual Analytics tool

Coding & Data

Extract, transform, and load your data into the SAS BI toolset

Stored Processes

Create and design stored processes like a rock star

Home » Coding & Data

What *is* a code review?

Submitted by on 2011-10-11 – 3:46 AM One Comment

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?

Never miss a BI Notes post!

Click here for free subscription. Once you subscribe you'll be asked to confirm your subscription through your email account. You email address is kept private and you can unsubscribe anytime.
The following two tabs change content below.

Tricia Aanderud

Director of Data Visualization at Zencos Consulting
Tricia Aanderud is a SAS Business Intelligence and Visual Analytics consultant based in Raleigh, NC who works for Zencos Consulting. She has written several books about SAS, presented papers at many SAS conferences, and has been using SAS since 2001. Contact her for assistance with your next project.
Spread the love


One Comment »

  • Lester says:

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