Like BillKSmith I tend to go straight to sketch code rather than something that looks a little like code but doesn't morph directly into anything in particular. That gives me a head start in writing the actual code and also helps me think about testing.

So for your sample I might write something like:

use strict;
use warnings;

my @tableLines = FetchTable();

for my $tableLine (@tableLines) {
    next if $tableLine->{expressionLevel} >= 100;
    
    print "TableLine->{geneID} TableLine->{expressionLevel}\n";
}
[download]

which is at least as good as the pseudo code at elaborating the idea for the program, is insignificantly harder to set down, and focuses attention on important elements of the program that are unclear in the pseudo code (what does PRINT geneID IN table really mean?). In the real world these days tools like pseudo code and flow diagrams (for code) are seldom used and are of limited utility compared to things like test driven development.

If this is a homework exercise it may still be worth sketching the program as I have done above and then "reverse engineer" the pseudo code from it. If my sketch code captures your intent then the pseduo code you have as it stands is fine.