What makes a good macro author?
There are various views on what makes a good macro author. There are some "rules of thumb" in use that are misleading as they apply to one industry and not another. For example, a macro writer who knows that their end user is a non-programmer will put a lot of checking into the macro parameters so if something is wrong it will give a meaningful message to the user because otherwise the user will have no chance of understanding an error message in a log. But if the end user of the macro is another SAS programmer then much less parameter checking might be used. So approaches can differ and you should be aware of that. But apart from these different approaches, I would say that there is one thing that distinguishes a good macro author from a bad one and that is their code is easy to follow even by junior SAS programmers. There will be a simplicity and clarity that shines through their code such that even though the macro might be doing something complicated, the code you look at seems simple and easy to follow. Of course, in the code they might be calling macros the junior programmer has not heard of or using techniques the programmer has never seen before, but still the code will be understandable. So lacking actual examples of their work that demonstrate this simplicity and clarity then you need to find out from your prospective macro writer how they think people would react when reading their code. You want them to say that they think it would be easy for any other programmer to understand. You have to rely a little on their honesty for this.SQL or not SQL?
"SQL or not SQL?" - that is the question! You will know whether yours is an SQL shop or not. Some pharmaceutical companies and CROs use it extensively while others do not. Some macro authors will readily put SQL in their code and some will not. It is not easy for a non SQL programmer to turn into an SQL programmer and nor is it easy for an SQL programmer to turn into a data step programmer so choose a person that fits your SQL / no SQL standards the best. But if it is a non SQL programmer you are after then the programmer should at least have used SQL as sometimes there is no alternative to using it (like merging a date with date ranges and cartesian joins) and a skilled programmer should be aware of this and be able to reach for SQL as a tool if they need it.
Know the Spectre reporting macros
A macro author who is new to Spectre will see typical output from the two major reporting macros (%npcttab and %unistats) and will likely jump to conclusions about what the macros can and can not do. But these macros are more flexible than first meets the eye. It is important that the macro programmer knows the capabilities of these two macros well.Utility macros
Avoid "reinventing the wheel" when writing reporting macros and learn to split tasks into identifiable chunks. This is more easily said than done and achieving it comes with practise. Many common useful tasks can be put into macros and they already have been !! Spectre contains a set of utility macros that you can call that will make writing reporting macros quicker and easier. And if these are validated macros then validating a reporting macro that calls them will be easier. So be aware of what utility macros exist within Spectre. If what you want isn't there then it should be on my old web site. You should never need to write a utility macro of a non-statistical nature because there is a 99% chance that it is already there.You can see a full list of Spectre macros, including the utility macros, by clicking on this link.
A fuller set of utility macros can be found on my old web site by clicking here. Special attention should be paid to the function style macros that are listed first. Once you get used to using these, you will wonder how you ever managed without them. They can be used as a sort of meta-code when writing complex macros once you learn to think with them. An alphabetical list of macros can be linked to here.
%popfmt
The importance of the %popfmt macro can not be overstated. Any extra reporting macro that gets written will probably need to call the %popfmt macro. A macro author needs to be able to "think" with this macro in the way described on the page about it. The global macro variables that it sets can be very useful in allowing macro parameters to default. For example, you should never have to set column width parameters for treatment arms as what gets written into one of the global macro parameters is a list of column widths that you can use as defaults in any new reporting macro. You can link to a full description macro from the main page or link to it here.Reports fitting the page
The two main reporting macros in Spectre will default to exactly fitting the output table to the page width. For an example of the logic look two thirds the way down the code of %unicatrep. The macro programmer should stick to this convention unless it conflicts with site standards.Other techniques
The macros that come with Spectre employ techniques that you have maybe never seen before. You can learn more about this by reading the macro code. My old web site has a page "Tips on writing SAS macros" that might be of use. You can link to it here.
Use the "Back" button of your browser to return to the previous page