information – Holland Numerics: Blog and Forums

What does your LinkedIn profile photo say about you?

The following table investigates what you are telling a potential employer by using a specific style of profile photo. I’m taking the role of an employer here, so these are my own opinions, and my own photos. However, you may not realise that this information is what you are giving away!

I’ll leave you to decide which profile photo I prefer, but which have you got on your LinkedIn profile?

Poll: What stops you registering on this blog site?

I am curious to know why blog site visitors stop short of actually registering for Free membership, so I thought I’d create a quick poll to find out a little more, as answers to all these concerns are explained on the Home and Privacy Policy pages:

Loading ...

I will use the results of the poll to improve the blog site.

Thanks in advance…………….Phil

How Do You Successfully Debug Your Program?

For a long while now I have been reading discussions on a range of social media platforms where programmers have been asking for help with programs that don’t behave as expected. Many of these programmers have certificates relating to the relevant programming languages, yet appear to have never been taught how to debug a program. To me the ability to resolve issues in a program is the most vital skill a programmer of every programming languages has to possess, otherwise they simply cannot call themselves a “programmer” in that language. Without this skill I would only call them a “code writer”.

So is this ability to resolve issues in a program a difficult skill to learn? I would say no, because it just involves the following a set of simple instructions, with a little observation and logic. Note that these instructions are not at all specific to SAS programming, or indeed to any other programming language:

Talk through the logic of the program with a colleague. Quite often you can spot potential problems yourself while trying to explain the logic to another programmer.
Run the program, and then check the log for error and warning messages, as there should be none!
Look for unexpected empty intermediate data sets in the log.
Test your code with small data subsets first, so that you can follow the processing path of individual data records. These subsets ought to be special sample records which will exercise as much of the logic within the program as possible.
Print out intermediate data sets, especially if these are not kept at the end of the program.
Print out intermediate data values at different places in the data steps to show the effect of different sections of the code.
Fix any issues in the program and then start again from step #2 until no more problems are found.
Remove, or at least comment out, any additional debugging code used.

However, at this point I must emphasize that not all programming problems can be resolved using these steps, but these steps should be tried first before asking for help.

So how should help be requested? By following steps 1-6 above you will have already collected a lot of information that could be vital for another programmer to resolve your problem, so don’t ignore any of it, remembering that any particular bit of information may be the most important bit required to solve your problem. Therefore, most, if not all, of the following information should be included in every request for assistance:

A description of the expected output from your program.
The reason you chose to write the program in this way.
All of the program code, because what you think is the cause of any problems may not be the only cause.
All of the sample data records, or the real data records if they are causing problems and can be posted.
The warning and error messages from the log (at the very least!).

Comments can be made by registered members in a copy of this post in the SAS Skills Discussion Forum.

Sample photo	Photo description	Employer’s interpretation
	Head and shoulders view with a smile, and wearing professional working clothes	Professional, serious, but approachable.
	Head and shoulders view with a serious face, and wearing professional working clothes	Professional, serious, and may not welcome human contact.
	Full length view wearing professional working clothes	Professional, but might not welcome close scrutiny.
	Wearing casual clothes	Unprofessional.
	Wearing sports kit	Team player, but not necessarily at work.
	In vacation setting	Relaxed and has a life away from work.
	In front of company poster	May have been forced to publicise their employer’s or some other company’s name.
	No photo	Wishes to hide real identity from someone, or can’t be bothered to find a photo. Interestingly, using #opentowork without a photo shows a corrupted profile image on desktop web page!
	Company logo	Wishes to hide real identity from someone behind a company facade, which may not even be their own.
	Random non-personal photo, e.g. artwork, children, stock image, cartoon etc.	Wishes to hide real identity from someone, and also is not at all serious about business connections.
	Group photo	May want to show they are family oriented, team players, or just prefer to hide in a crowd.
	Image of single initial of First Name	Wishes to hide their face from someone, but not their identity.
	Blank single colour photo	Wishes to hide real identity from someone, but has got around the bug in #opentowork without a photo, which, at least, shows some understanding of LinkedIn.
	Background has contrasting colour	Wants to be noticed.
	Background is busy and multi-coloured, which makes them difficult to see in a smaller image	Wants to hide from someone, lacks self-confidence, or doesn’t understand how to compose a profile photo for LinkedIn.
	Image at an obvious angle, or even upside-down	Trying too hard to get your attention.
	In image, but facing away from the camera	Wishes to hide real identity from someone, or lacks self-confidence.