Aug

27

According to that source of all knowledge on the interwebz, Wikipedia,  “Gaslighting is a form of psychological manipulation that seeks to sow seeds of doubt in a targeted individual or in members of a targeted group, making them question their own memory, perception, and sanity.”

Have you ever had a brilliant, super-competent friend who doubted her own competence?

I’ve often seen this happen to women in technical jobs, and it’s happened to me. Here’s what happens. You work with a man or a couple of men. (In theory it could be women, or men could do this to other men but I personally have only seen men do this, and usually to women). No one knows everything (duh!). You are an expert in Python, Ruby, JavaScript, PHP and Objective C. You’ve developed some pretty cool iOS apps, been part of some successful teams.  Bob suggests that the team really needs an Android app, but, 

You don’t know Java, do you, Joan?

You suddenly realize,

“Oh, my God, I don’t! How did I miss learning Java?”

Part of gaslighting is “using what’s important to you as ammunition”. If you’re a woman who has been in software development, mathematics, statistics or science for a long time,  it’s no doubt important to you and you’ve overcome a lot to stick it out and get where you are.  It’s important to you to be competent and knowledgeable and having someone question that is disconcerting. 

Gaslighters wear you down. It’s the death of a thousand cuts. Bob will insist that the prototype of the next app has to be built for Android because it’s the largest market share, “Of course, that leaves you out of the prototype build  because we need experienced Java developers.” “I’ll bet you’ve never used Android Studio.”

Gaslighters are also experts at reframing things, so much so that you don’t think of the fact that the last five prototypes were done for iOS and there was no problem porting to Android.

Gaslighters can also be good at getting other people to go along with them. If Bob repeatedly tells Sam that Joan isn’t a good fit for this project because we really need an Android developer for this prototype and Joan has no expertise in that area, “she mostly just does testing on iPhones”, Sam may believe him, after all, she’s admitted she has no expertise with Java. So, Sam is not going to consult with Joan on any technical issues, which wears Joan down even further. 

I agree with Stephanie Sarkis that some gaslighters may do this unintentionally and subconsciously. They are, in my experience, trying to make up for feelings of inferiority by making themselves look better by comparison and getting other people to depend on them. 

It doesn’t matter whether it is deliberate or not. The effects are insidious.

I used to think, “Suck it up, buttercup. If some clowns don’t think you have the technical chops, prove them wrong.”

I still think that to some extent, but I can see that it can be really difficult if you are constantly pricked with an endless series of whispering questions of your competence, both behind your back and to your face. It’s exhausting to always be trying to prove your abilities in the areas where you are knowledgable at the same time explaining that no, you have never used (insert any language here because no one has used all of them). I’ve seen women who really enjoyed coding move into marketing or project management giving the reason, 

It just wasn’t fun any more.

You may already be the solution.

Three of us, mutual friends, were at lunch one day and one woman mentioned she had been offered a terrific job but it was for “an expert in the field’ and she didn’t consider herself an expert. Her other friend and I immediately interrupted her,

What? Are you nuts? You are the very definition of an expert!

Then, we proceeded to list all of her amazing accomplishments because she really is incredible. 

Stick with people who see you in the best possible light

I have a great advantage in protection against gaslighters in that I married the right person. Recently, we were drinking beer with a friend who referred to me as “testing the games” and The Invisible Developer corrected, 

She doesn’t just test the games. She makes them, too.

It’s not often someone questions my technical ability around my husband, but when it does happen, he speaks up for me 100% of the time. That’s a big deal because he is not at all one to draw attention to himself. He’s not called the Invisible Developer for nothing. 

It’s not just him. I’m super fortunate to have a group of friends and colleagues who are really supportive and collaborative people who always have my back. 

If you are the problem, you have a problem

Maybe you are scoffing dismissively at this point that if Joan was any good none of this would have bothered her. You are making a snide comment over your cubicle that real developers don’t need anyone to tell them they’re good. People often feel uncomfortable around gaslighters, even if they can’t give a reason. They are right, too, because once Joan leaves, you’ll need someone else to disparage to make yourself feel superior, maybe Sam.

If Sam has a choice of his next project, it’s probably not going to be one with you. If he does get stuck working with you, after all of your comments about Joan, Sam is going to expect that you are God’s gift to Android development, that, in fact, your middle name is Java and the language was named after you. Imagine his response when you turn out to be nothing special.

What I’ve seen happen to the gaslighters eventually is that no one wants to work with them. Even though Bob thinks he’s a 10X software developer, for some reason no one wants him on their team. He tells himself it’s because they’re jealous. 

In the meantime, though, Joan is now managing the marketing department.

Don’t end up like Joan

Years ago, on the More than Ordinary podcast, I had my lovely daughter , Julia, as a guest to talk about what it’s like in boarding school. After saying, that “First of all, it’s nothing like Hogwarts … ” she went on to add

No matter where you are, you can find people to study with, to help support you to reach your goals. And, if not, well, just be that person for yourself.

So, if you find yourself being questioned so much that you start questioning yourself, try finding friends and colleagues who support you and remind you of your awesomeness. If for some reason that’s not an option, I suggest this. Remind yourself. Sit down and write down all of your accomplishments. Then, next time Bob questions you tell him, 

“Shut up you little prick. I’ve done amazing things, and I’m going to be here long after you’re gone.”

Okay, well, maybe you shouldn’t say that out loud at work, but if you do, I won’t blame you. 

In my day job, I make educational games, like this one where a Mayan god thing drags you into the past. Yes, it teaches math.

Mayan guy
Aztech Games: Not made with Java – yet – but that’s just a coincidence

Aug

25

About ROUND(100) years ago, I took a couple of COBOL courses. I never coded anything in COBOL after the classes, but the concept of a table look up has stuck with me.

Just like it sounds, this is used when you want to look something up in a table. For example, if I have ICD-10 codes, which are used to classify diagnoses, I could look up J09.X2 in a table and see that is “influenza”.

There are several ways to do this with SAS, including using PROC FORMAT, a one-to-many merge with either the data step or PROC SQL , a bunch of IF statements and a macro.

One way I learned very early on to do this in SAS was to use a PROC FORMAT.

Say I have a bunch of possible codes for outcomes for my program and they are coded 02 = applies all the way to 32 = “Post-employment services” .

PROC FORMAT; 
VALUE stats
0 = “referral”
2 = “applicant”
6 = “evaluation”
8 = “closed”
10 = “eligible”
12 = “IPE complete”
14 = “counseling”
18 = “training”
20 = “service complete”
24 = “service interrupted”
22 = “employed”
26 = “successful closure”
28 = “closed after service”
30 = “closed before service”
32 = “post-employment”
;

Another option, if I wanted to combine categories, like those who had a successful and unsuccessful outcome, is to do it like this :

PROC FORMAT;
VALUE stats
0, 2, 6, 10 , 12, 14, 18, 20  = “open case”
24, 28, 30 = “unsuccessful”
22, 26 , 32 = “successful closure”
;

In either case,  if I just wanted to have the type of service printed , I could use a FORMAT statement , like this.

FORMAT status_type stats. ;

If I wanted to create a new variable I could use the put function to put the original value into a new variable using the format.

DATA testy ;
  SET mydata.vr_codes ;
  recoded_status = PUT(status_type,stats.) ;

Is there any advantage of PROC FORMAT over doing 20 or 50 IF statements?

I can think of several. First of all, you can use the same PROC FORMAT repeatedly.  If you need to do the same transformation with several different data sets, you can just do the format procedure once, include one PUT or FORMAT statement in each data step and you are done.  Second, since you can store formats permanently,  if you haven’t gotten around to learning macros yet, this can be one method of using the same code over and over in different programs. Third, it’s just less messy to type, which seems trivial until you have 300 values to recode. 

Some day I might write a post on user-defined formats, especially how to store and re-use them. Today is not that day. In the meantime, I highly recommend reading this paper on building and using  user-defined formats by Art Carpenter while you are waiting.

I live in opposite world. I blog on SAS and statistics for fun and make games for a living. Check out Making Camp Premium. Learn about Ojibwe culture, brush up your math skills, learn more English and have fun. All for under two bucks.

Making Camp scene with buffalo, deer and rabbit

Aug

12

 

“I don’t document my code because if you really understood the language, it should be obvious.”

– Bob

Bob is an arrogant little prick.

Here are just a few reasons to document your code.

  1. Other people may need to modify it because, despite your assumed brilliance, there may be other people in the universe capable of maintaining your code when you get a promotion, take another job or get your sorry ass fired.
  2. Six months from now, you may need to look at this code again. After 11 other projects have intervened, you’ll be trying to figure out what the hell the prev_grant_yrs variable was supposed to measure. Every time I add comments to a project, I say to myself, “Future me will thank me for this.”
  3. If you use Title and Label statements, there will be additional clarity not just for you as a programmer but also for the users.

Here is an example

This comes from a longitudinal analysis of a vocational rehabilitation project. There are only two comment statements in this snippet, however, there is a LABEL statement which explains that the prev_grant_yrs variable is the number of years a consumer was served under the previous grant. There was a significant change in operations in the current grant cycle, but when this five-year cycle started there were a number of people already on the caseload who had been determined eligible under the previous administration.

data by_year ;
set mydata.vr2018 ;

** USES YEAR FUNCTION TO GET THE YEAR OF INDIVIDUAL PLAN OF EMPLOYMENT ;

*** AND OF APPLICATION TO THE PROGRAM ;


ipe_year = year(ipe_date) ;
app_year = year(app_date);

if ipe_year ne . and ipe_year < 2008 then prev_grant_yrs = "5+" ;
else if ipe_year < 2012 then prev_grant_yrs = "2-4" ;

  else if ipe_year > 2011 then prev_grant_yrs = "0-1";

LABEL prev_grant_yrs = "Years Under Previous Grant"
ipe_year = "Year IPE written"

app_year = "Year applied"

;

The first procedure, I simply wanted to get a closer look at the people who had been getting services for more than five years under the previous grants. It’s important to add that second title line so readers know this isn’t ALL long-term consumers but those who had been long-term users coming into the current grant cycle.

TITLE "Check long-term consumers";

TITLE2 "Getting services 5+ under the previous grant" ;
proc print data= by_year ;
where prev_grant_yrs = "+5";
id username ;
var ipe_date app_year prev_grant_yrs ;
format ipe_date mmddyy8. ;

The second procedure, I wanted to see how consumers served in the current year were doing. Why do I have grantyear as a variable in the VAR statement when it is clear from the WHERE statement that only people from 2018 will be included?  Because the person who gets the output won’t see that WHERE statement. Just having “current year” in the title is not enough because next January someone looking at this might think it was for 2019.  I could have included 2018 in the title, but including it as a variable on the output both acts as a validity check for me and lets the user, my customer, know that the data are correct.

TITLE "Current year consumers" ;
proc print data=by_year ;
where grantyear = 2018 ;
id username ;
var grantyear status status_type ipe_year;
format ipe_year mmddyy8. ;

A few of the individuals served by this project did not have an Individual Plan of Employment. I wanted to see if the people missing an IPE just hadn’t had time to complete it yet or if they never came back and did it. An IPE is the first step in getting project services, so, if they had a missing date for a year or more than they had just dropped out. Again, the second title line tells the users what I’m trying to do here.

TITLE "IPE YEAR by Application Year";
TITLE2 "Note: Missing IPE consumers had ample time to complete IPE";
proc freq data=by_year ;
tables ipe_year*app_year/missing ;

So, you get the idea. Elegant code is nice, correct code is essential.

You know what is essential?

A young person once asked me,

“No offense, but why are your services so much in demand? It’s not as if there aren’t a lot of people who can do what you do.”

Okay, first tip, young people, when you find yourself saying, “no offense” you should probably just stop talking and then you definitely won’t offend anyone. Actually, I was pretty amused. It’s true that lots of people can do frequency distributions, if-then-else statements and cross-tabulations (although, in my defense, that’s not ALL I did on this project).

One essential skill is make your analyses easily understood by your co-workers and customers.

As a wise person once said,

“Mystery novels should be figured out. Code should be read.”

Wonder what else I’m writing these days?

You can get A Different Kind of Textbook, our family group text, for $2.99 as an ebook.  We definitely are a different kind of family.

Contacts : bios of family members

 

Blogroll

WP Themes