BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
Milouda
Obsidian | Level 7

Hello everyone.

I have a question about self evaluation.

Is it feasible that a sas programmer or a programmer in general can self assess their ability/level? if yes , how?

In real life, someone compares what they can do regrading a given situation with others, but how can I tell if my code is better than the others? Of course, I can refer to some metrics like robustness or wether it is optimized or not. Are there any metrics for the logic someone uses to get that output?

I don't know if these questions are legitimate or not, your feedbacks are the Judge;

 

1 ACCEPTED SOLUTION

Accepted Solutions
Quentin
Super User

"Is it feasible that a sas programmer or a programmer in general can self assess their ability/level?"

 

That's a very interesting question.  And not to be too high level, but I wonder if it is the same question as "is it feasible for an artist, writer, or architect to assess their own ability?"  (personally, I like the analogy between software development and architecture; but of course all analogies break down).

 

Self-assessment is always hard, other than in the simple case where you simply use a tool/metric/questionnaire that someone else has developed, which in some sense means it's not a self-assessment.

 

I think early in your my SAS programming career, it is was fairly easy for me to assess the ability of my code [LOW].  Because I was lucky to learn about SAS-L (https://listserv.uga.edu/cgi-bin/wa?A0=SAS-L) , and then went to SUGI, and was lucky to work at companies with some AMAZING SAS programmers.  So there were lots of opportunities to see code that was much better than mine.  And "better" in many different ways (clearer, using functions/features I had never heard of, faster, etc). 

 

I think as you become more advanced in SAS programming, it's not as obvious how your code would "rate" compared to someone else's code.  Because you grow aware of the varieties of criteria that could/should be used to assess code quality in different scenarios, and the answer to which code is "best" depends on many many variables. 

 

And you also realize (or at least I believe) that SAS is so big, and encompasses so many langauges that there are parts you may never learn (and may never need to).  I followed Paul Dorfman's writings on SAS-L about hashing for many MANY years before I finally tried using a hash.  And I'm now a big fan of hashes.  Was I a worse programmer before I learned hash?  Am I better programmer now?   I read Peter Eberhardt's recent DS2 book but I haven't played with DS2 yet at all.  Am I a bad programmer?

 

I think (hope) over time and participation in programmer communities, and fulfilling the responsibilities of your job(s), you start to develop your own internal metrics about what it is reasonable for others to expect from you, and what it is reasonable to expect from yourself.  And this comes from being exposed to multiple perspectives.  You will see code that is far better than yours, and code that is far worse.  You will have colleagues/supervisors who expect more from you than is humanly possible, and others who are amazed that you can run PROC FREQ.  You will experience the pains that come from writing "bad" code (hard to understand it when you read it, hard to modify, throws errors, delivers incorrect resuls without errors) and the joys from writing better code.  You'll be burned by writing bad code, and can be burned by taking too much time to write beautiful efficient code that isn't necessary for a little ad hoc request.

 

Finally, rather than worry about how to assess what your own ability level is today, I would spend time thinking about how you can grow your own ability level over the next year(s).  Have you identified areas of SAS you would like to learn more about?  Would it help your growth curve to spend more time in on-line communities, user group meetings, speaking with colleagues, reading more books, learning other languages, etc etc etc?

The Boston Area SAS Users Group (BASUG) is hosting our in person SAS Blowout on Oct 18!
This full-day event in Cambridge, Mass features four presenters from SAS, presenting on a range of SAS 9 programming topics. Pre-registration by Oct 15 is required.
Full details and registration info at https://www.basug.org/events.

View solution in original post

4 REPLIES 4
RW9
Diamond | Level 26 RW9
Diamond | Level 26

There are no standards or metrics as far as I am aware.  Programming is more fluid than that, things can be done many ways, and can be impacted by more limitations than just the users knowledge.  Even simple things such as company policy on not using XYZ can limit the programmer freedom.

The way I personally would assess code would be split in two areas: big data where using every bit of resource is necessary, and normal use where readbility simple coding and such like are more importent than saving a few miliseconds.

There are various certifications and such like out there which show a general standard someone has to be at to pass, I personally have never put much faith in such things.  Its simpler to assess someones knowldge and, more importantly theroy on how to do various things.  For instance, if someone has a background knowledge of Software Development Lifecycle - this isn't SAS particular knowledge or programming, but more of the theory of how you write, document, lifecycle manage software, then that would be more important that if they know the exact syntax of function do_something() off the top of their head.  Also, nicely written code is important, someone who wrote:

/* this is a dataastep */

data abc1; set

somedata (where=(input(d||"1960",date9.)="14JAN1960"d);run;

 

And someone else wrote:

/* Find data from main dataset with the date matching 14Jan1960 */
data date_matching;
  set somedata;
  where input(cats(d,"1960"),date9.)="14JAN1960"d;
run;

Which would you prefer?  Thats obviosuly a spurious example, but you can see things in the code which don't help the reading and understanding of the code.

Milouda
Obsidian | Level 7

Thank you RW9, I'll  keep that in mind.

 

SASKiwi
PROC Star

Please bear in mind that there are different standards of coding when doing it for different purposes. If you are doing some one-off ad-hoc analytics then the standard of your coding can be less than if you are building a regular business-critical process. In my experience many SAS developers don't appreciate this and don't put enough effort into productionising their code for business-critical purposes.

 

One of my standards for production-quality code is no log errors and no warnings and no notes indicating a data problem like missing values were created in line so and so.....if a developer can't or wont do this then it is an automatic fail in my book. There is no excuse for not producing clean code. Then when a real problem happens it is easy to spot. 

Quentin
Super User

"Is it feasible that a sas programmer or a programmer in general can self assess their ability/level?"

 

That's a very interesting question.  And not to be too high level, but I wonder if it is the same question as "is it feasible for an artist, writer, or architect to assess their own ability?"  (personally, I like the analogy between software development and architecture; but of course all analogies break down).

 

Self-assessment is always hard, other than in the simple case where you simply use a tool/metric/questionnaire that someone else has developed, which in some sense means it's not a self-assessment.

 

I think early in your my SAS programming career, it is was fairly easy for me to assess the ability of my code [LOW].  Because I was lucky to learn about SAS-L (https://listserv.uga.edu/cgi-bin/wa?A0=SAS-L) , and then went to SUGI, and was lucky to work at companies with some AMAZING SAS programmers.  So there were lots of opportunities to see code that was much better than mine.  And "better" in many different ways (clearer, using functions/features I had never heard of, faster, etc). 

 

I think as you become more advanced in SAS programming, it's not as obvious how your code would "rate" compared to someone else's code.  Because you grow aware of the varieties of criteria that could/should be used to assess code quality in different scenarios, and the answer to which code is "best" depends on many many variables. 

 

And you also realize (or at least I believe) that SAS is so big, and encompasses so many langauges that there are parts you may never learn (and may never need to).  I followed Paul Dorfman's writings on SAS-L about hashing for many MANY years before I finally tried using a hash.  And I'm now a big fan of hashes.  Was I a worse programmer before I learned hash?  Am I better programmer now?   I read Peter Eberhardt's recent DS2 book but I haven't played with DS2 yet at all.  Am I a bad programmer?

 

I think (hope) over time and participation in programmer communities, and fulfilling the responsibilities of your job(s), you start to develop your own internal metrics about what it is reasonable for others to expect from you, and what it is reasonable to expect from yourself.  And this comes from being exposed to multiple perspectives.  You will see code that is far better than yours, and code that is far worse.  You will have colleagues/supervisors who expect more from you than is humanly possible, and others who are amazed that you can run PROC FREQ.  You will experience the pains that come from writing "bad" code (hard to understand it when you read it, hard to modify, throws errors, delivers incorrect resuls without errors) and the joys from writing better code.  You'll be burned by writing bad code, and can be burned by taking too much time to write beautiful efficient code that isn't necessary for a little ad hoc request.

 

Finally, rather than worry about how to assess what your own ability level is today, I would spend time thinking about how you can grow your own ability level over the next year(s).  Have you identified areas of SAS you would like to learn more about?  Would it help your growth curve to spend more time in on-line communities, user group meetings, speaking with colleagues, reading more books, learning other languages, etc etc etc?

The Boston Area SAS Users Group (BASUG) is hosting our in person SAS Blowout on Oct 18!
This full-day event in Cambridge, Mass features four presenters from SAS, presenting on a range of SAS 9 programming topics. Pre-registration by Oct 15 is required.
Full details and registration info at https://www.basug.org/events.

SAS Innovate 2025: Call for Content

Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!

Submit your idea!

Discussion stats
  • 4 replies
  • 2353 views
  • 5 likes
  • 4 in conversation