She's got a lot going on here but it really works to my eye. The burgundy/lime green combination is one I've fallen for before, but I actually was inspired by the more general formula of printed dress, denim jacket, scarf, and tights...
 |
| From theminuteglass.com |
...which I took in a much more sedate direction in my version.
Red/black lightweight knit faux wrap dress (thrifted, Walmart), $1.67/wear+
Black denim jacket (JNY), $3.54/wear
Black and white houndstooth scarf (Target), $2.38/wear
Black leggings
Tall black boots by Fitzwell, $3.18/wear
Outfit total: $10.77/wear
But sometimes subtle print mixing rather than bright color mixing is what you're in the mood for.
In other news...This week I discovered an error in the syntax file that is used to build an important data file that we use all year in my department to track our "customers." This is an old syntax file, developed by a guy who is no longer around but who continues to haunt my work through his erratic, lacking-documentation style--I have never worked with this syntax directly but when I found something I thought was odd, I talked to the analyst who built the file using this syntax and indeed there was a problem.
Well, I would argue that there are LOTS of problems with it because (like every other piece of syntax I've seen that this guy developed) it violates all kinds of best practices. For example, he has a series of mysterious steps that recode data into the same variables. After picking apart what the hell he was doing, you figure out that he recodes the variable so that he can sort it in various ways and copy data from one record to another. So because he wants value E to come after value K when he sorts the data, he recodes E to L. But what happens when later the value K is changed in the underlying data base to value P? A small disaster. You sort on the values and instead of getting K (i.e. P) then L (i.e. E), you get L (i.e. E) then P (i.e. K). And you copy the values of other fields wrong, too. Oops.
The other analyst totally owned the error in that she didn't go through this syntax to update it when we knew that value K changed to value P. But seriously, this guy's stuff is really screwy, so I'm not surprised that she missed it. It really shouldn't take that much time to figure out what someone's syntax is doing. There are two issues really. First, the syntax is just strange and often not well-written, it seems to me, so it's not easy to track what's happening. I don't know how much of this is his logic is not my logic and how much is that it's not really structured very logically. He also often makes things a lot more complicated than I think they need to be. Second, he never adds comments about WHY any of this is happening. Sure, it's often apparent, but many times it isn't...because he has written something to accomplish a purpose that we no longer have, that nobody knows we should have, or can no longer actually be accomplished with the syntax that exists because of changes in the database or the data (or our institutional practices or....).
Also, you really shouldn't be recoding into the same variable over and over again, thereby losing the original data value. That's why the handy RECODE...INTO exists. It is no more work to recode into a new variable (sort_variable) and give the value you want to be last a new value like ZZZZZZZZZZZZ, which will really always be last unless our database gets very, very strange.
Too bad he wasn't a student in my lab section of research methods in psychology. I could have cured him of this n00b mistake.
Remember: Friends don't let friends routinely recode into the same variable!
No comments:
Post a Comment