Showing posts with label strategies. Show all posts
Showing posts with label strategies. Show all posts

Wednesday, March 25, 2009

Notes


Lately I've noticed how very helpful notes are - not just notes I've already taken, but the writing of notes itself. Here are situations, some more common than others, in which writing notes helps me:
  • To-do lists. I don't write large or ongoing to-do lists and keep them for weeks, but I find them helpful for a few tasks I need to do within a couple of days.
  • Breaking down a task. Sometimes when I'm not sure how to tackle something, or just can't quite get myself started, I can write it down in tiny steps and get kick-started that way.
  • Handling confusion. When I get confused about a problem - at school or work - writing out my questions and concerns (neatly, in complete sentences, slowly) is often surprisingly helpful. I will either get an answer to my problems or great insights about how to approach them. (The picture with this post is an example of some of this type of note-taking; I took these notes a few minutes ago and they have jump-started a task I had completely stalled at.)
  • Reading difficult material. Recently, I've been trying to read some math journal articles. I decided that since I write down things like axioms and theorems when I take notes in class, I might as well directly copy them from journal articles as well. And guess what? It helps! A lot! I think the process of slowing down and being methodical makes me a lot more likely to understand material. I have also found this works wonders for reading math textbooks. It feels silly to copy out the exact lines of an example worked in the book, but it aids understanding immensely.
In general, I have found that all kinds of thinking tasks are aided by pencil and paper. I think I just find it much easier to concentrate on one thing at a time and work it out slowly and carefully if I am trying to create a written record at the same time.

Wednesday, March 18, 2009

Cooking Experiment

not my actual cookingFor the past few months, Ed and I have been trying to make and eat dinner together more. We've stuck pretty well to our original goal of having me cook for us twice a week and him once a week. A meal is typically weekday dinner or weekend brunch, and we try (and have so far managed) to include protein, vegetables (and/or fruits), and some kind of starch. I often include a whole grain when it is my turn. (I did not make the meal in this picture, but it looks like my type of thing.)

Last night, for instance, I made boneless pork chops (broiled in the oven), brown basmati rice (plain, but cooked with salt and butter), and asparagus (sauteed in a pan with olive oil, crushed red pepper, and garlic). It made a very pretty meal, actually, and the asparagus was pleasingly spicy.

Here is what I have learned so far:
  • I much prefer cooking for the two of us to making my own dinner, even though when I cook for just myself it is much easier (because I don't make such elaborate things).
  • I actually really enjoy making dinner for us.
  • I prefer cooking several things to making a one-pot dish. I am especially fond of the protein/starch/vegetable trio, often with a very plain vegetable.
  • Any kind of fish can be cooked with oil and butter in a pan and come out delicious.
  • Excluding (bizarrely) restaurant food, I view food cooked by other people with suspicion and distrust.
  • I like to control what we have for dinner.
It's been really exciting to learn that I can pretty easily make a variety of reasonably healthy meals, and that I enjoy doing so.

Tuesday, February 24, 2009

Enjoyment Can Regress

Mosch and I used to go on a lot of hikes, bicycle rides, etc., and over time I noticed a very strong pattern: experiences that were difficult in the moment often magically transformed into enjoyable after they were done. I could be miserable, sweaty, and working way too hard, and later on say, "Man, that hike was awesome!"

Once I realized this, the point of enjoyment moved backwards in time. I would start thinking the hike was great immediately after we got done. And then eventually I started really enjoying the hike while still hiking. I don't know for sure, but I think there was a causal relationship - the knowledge that I would later feel that I had enjoyed the outing led me to enjoy it in the moment.

I'm finding the same thing with math these days. I keep saying that Ed and I talk about math a lot and implying that it's fun, but in the moment, it's often actually difficult and frustrating. He raises a lot of questions that I don't want to go into because, damn it, I want to get where I'm trying to go, not take a lot of painful side trips. I don't want to work "uphill" all the time. I want to only talk about the parts I understand. I certainly don't want to learn anything new.

But later, I invariably retrospectively enjoy the conversations. It's not just that I enjoy having had them; I actually feel as though, in retrospect, I enjoyed them at the time. The memories are pleasurable. And I now feel that enjoyment regressing, happening earlier and earlier. Sometimes I am even aware of enjoying the math conversations in the moment.

Does this happen to other people?

Friday, February 06, 2009

Work Process Considerations

I am always interested in noticing strategies for maximizing one's performance (alternately, minimizing one's effort) at work, and today I was thinking about two related strategies: error and change management. I wrote once before about parnas partitioning (writing code in such a way that it will be easy to change in the obvious ways later), and this is related, but not specific to computer science.

One question to ask yourself when you have to choose a method to accomplish something at work is, "How easy will this be to fix if when I screw it up?"

For instance, a coworker recently had to update 100 records in a program that has an Access database backend. Had it been my project, I would have gotten the identifiers for the 100 records, put them into Excel, put the new field values next to them, imported the spreadsheet into Access, and then run a query to update them. What she did instead was to open each record individually in the program, and do each update. This would make me crazy to begin with, but it also had the unfortunate result that, once she realized she had made a mistake, she had to do it all over again. If you make a mistake in my plan, you can easily just correct the Excel spreadsheet and reimport it, or fix the import query, or whatever is required. The data is entered once and it's stable.

This kind of technique is important to me because I make a lot of mistakes. I bet other people do too.

The second question to ask yourself is, "How easy will this be to change when they want me to change it?"

I try never to change something such that I can't pretty easily change it back, since "Put it back the way it was" is such a common request. I make new data rather than overwrite old data where appropriate. And I try to keep my changes somewhat modular, so that if they want to keep some changes and discard others, that too is possible. In your specific job, you probably know what types of changes are commonly desired, so you can set yourself up to make those as easy as possible in advance. It saves a lot of frustration and grumbling (on your part) later if you can treat changes as expected rather than aberrant.

Some common ways of making changes easier include making sure there are backups of old files, storing intermediate results, and using notes and/or naming conventions to keep things clear. You will definitely not remember, three months from now, how you generated this file or what you did to it, so make sure you give your future self a way to recover that information.

Here ends installment eleventy-seven in the Tam's Obvious Work Advice series.

Wednesday, January 21, 2009

Rocks and Sand

When I was in middle school, I saw a demonstration by a Christian group that, though I'm sure it is completely cliched, stuck with me. The leader had a something like a pitcher (your life), some large rocks (god, i.e., the important stuff), and a lot of sand (the unimportant stuff). She proceeded to demonstrate that, if you put the sand in first, the rocks would not fit, but if you put in the rocks first, the sand would still fit. You can get what you want if you put the important things first.

In middle school, that metaphor didn't fit my life particularly well (though I continued to ponder it), but these days it really does. I have found in particular that absolutely nothing happens unless I make a specific plan to do it. And this is true of hobbies as well, especially the ones that I share with Ed.

Having sex. Doing some math together. Watching a movie. Cleaning the house. Exercising. Eating dinner together. None of it will occur if we don't say, "We can do this tonight," or, "Tomorrow let's do that."

Even though I find this phenomenon a little frustrating, it also means that one of the central problems of life (not doing the things I want to do) is largely solvable through this very simple tactic of asking myself, "What do I want to accomplish today?" It doesn't really require a To Do list, because the things I'm talking about are regular things that you don't tend to forget. I know the house needs cleaning on a regular basis. I know I want to spend time with Ed doing math. I just have to be planful so that these things actually occur.

Monday, June 02, 2008

Durable Goods Moratorium

I am declaring a moratorium on purchases of durable goods, starting now and effective through August. This means no new clothes, furniture, kitchen supplies, toys, etc. - basically anything that is not consumed. (Obviously it would be much more radical to try to survive without groceries, paper products, cleaning supplies, etc. I'm not that radical.)

I think I have everything I need at this time, so I hope I can stick to this.

Thursday, October 25, 2007

Updates Planned

I haven't posted here in for-freakin'-ever.

Partly it's because I've just been busy. Partly it's because one of my regular readers isn't speaking to me, and that's painful to think about. And partly...hell, I don't know. The most interesting parts of my life are things I can't write about here.

But I plan to write a series of small updates on various facets of my life, and I expect I'll keep this blog more updated after that point.

I wonder how long it will be before anyone even finds this post?

Wednesday, June 06, 2007

Radical Honesty, Part 2

Please start with Part 1, below.

Now that I've made my own default views somewhat clear, I can talk about what radical honesty is, and the implications. Ed's words to me were that he defines the central imperative of radical honesty as, "Be as open as humanly possible, and then minimize harm." (That's a loose paraphrase, not a direct quote. Feel free to correct me in the comments, Ed.)

I would break it down into two imperatives: never lie, and always share relevant information. To me, it's akin to a monastic discipline like abstinence or silence. I had a lover with whom I practiced radical honesty, a long time ago, and it was a real challenge, and led to a lot of insights, but it was very difficult and made our relationship pretty dramatic at times. I think it's a good thing to try at least once, assuming you have a partner willing to try it with you.

There are two related things that I'm really enjoying about Ed, and one is directly this matter of honesty. Sometimes he says exactly the wrong thing, and other times he says something so great you can't believe you're hearing it; you believe him in the latter cases because of the former. And because he (compulsively? by choice?) brings up problems almost immediately (which I know partly from tracking his relationship with Mel on their blogs, and hearing about it from him), you really can know that "no news is good news" - it's really not likely that he's saving up things to gripe about later. And if you ask him a question, you'll get a (sometimes painfully) true answer. All of this has a way of being comforting even while it is challenging.

I'm experiencing this as a relief from Mosch's more strategic approach to honesty, but, as I have told both of them, I could just as easily experience Mosch's tact and care as a relief from Ed's bluntness.

I know from the past that I am capable of radical honesty when I choose, so I am trying this with Ed as well. I had an opportunity recently to reassure him in a way that was so cost-free and so ultimately meaningless, and yet so potentially painful to withhold, that only an idiot or a total jackass would have withheld it, and yet I did so because answering the question that way was not quite truthful. And when I told him later that I would have answered differently for anyone else, he thanked me sincerely for the honesty. The guy knows what he wants, and so far he can take it as well as dish it out.

His wanting it doesn't make it the best strategy for me. Probably my best strategy given his preferences would be to do enough to give the appearance of radical honesty, while still being strategic the rest of the time. But I am willing to risk harm to my interests - and to his - in order to actually give him what he wants in this way.

Or at least to try.

Radical Honesty, Part 1

This is something that Ed believes in, and Sally asked in the comments if I would explain it, because it sounded to her like something that is not a very good idea. I suspect what it sounds to her like it means is exactly what it does mean, but it's a fairly fertile topic.

I think most people's approach to honesty is fairly unexamined, and mostly consists in claiming to be honest, and then telling the truth or lying according to what seems like a good idea at the time. Most people are honest enough, but people who claim not to lie at all are, IMO, either self-delusional or untrustworthy. Everyone lies sometimes, as well they should.

My general view of communication is a strategic one. I really want to be understood, and to understand others, so I'm a big proponent of openness where it's possible (i.e., not always with one's parents) and appropriate (i.e., usually not at work). Honesty greatly aids in openness, in addition to its other benefits (it's easier, it lets people trust you, and it's more ethical in its own right).

But in general, I think it's important to maintain your sense of ownership of the privacy of your own mind. If you see openness as an obligation, you may (my sense is) start lying to yourself just so that you won't have to tell difficult truths to others. I really have no qualms at all about people lying about things that are not the asker's business anyway. And I have very few qualms about another class of lying - where the purpose is not to deceive, but to withhold information that would be counterproductive (to mutual goals) to share.

At the same time, my desire to understand other people makes me behave in certain ways that encourage honesty. I resolved early in life not to be possessive, for the simple reason that it makes people lie to you. This is also behind a lot of my acceptance of others. Where it isn't safe to tell the truth, almost everyone is prudent enough to lie. I try not to make people lie to me. (I often refrain from asking questions that would likely tempt someone to lie, for instance.)

I should continue this in another post.

Friday, March 23, 2007

Estimation vs. Guessing

When I was a kid, some book I had contained an exercise like this. Try to guess how big around your waist is, it said. It probably had a space to write down your guess. Then it recommended a technique for getting an estimate. Put your hands at your sides and use them to estimate how wide you are at the waist. Now assume your body is pretty circular. If you multiply your estimated width by 3, which is approximately pi, you can get an estimate of the circumference (diameter * pi = circumference of a circle). If you write down that estimate and then actually measure around your waist, it's probably much closer than your original guess.

I don't know if this book was trying to make a point about estimation or one about geometry, but lately the idea of estimation has come up a lot in my life. I think current school curricula for kids put more emphasis on this than when I was a kid too.

In any case, recently in our Software Engineering Principles class, Dr. Paul asked us to discuss amongst ourselves how we would set up a software testing program, how we would estimate the time that the testing would take, and how we would decide when testing was finished. So we talked about this for a few minutes, sharing what we'd learned from various readings, until the conversation ground to a halt.

"Are you done?" he asked us. We nodded, more or less.

"What did you decide?" he asked.

Our general answer was along the lines of, "Nobody knows, you can't really estimate it, and anything you come up with is just going to be kind of a way to justify your gut, so you just kind of release the software when you think it's ready."

He became theatrically angry with us. His general point was that any method of estimation would be better than a guess or "gut feeling" and that if he would accept a guess or gut feeling from anyone, it would be people with years of experience running successful projects, not a bunch of college seniors. Oops.

Let me give you a sense of how hard it is to estimate "how long testing will take." You could do it like this:

  • Our software has 100,000 line of code.
  • We know from the literature that very good programmers usually introduce about 4 bugs per line of code if the code is not too complex.
  • That means our software has about 400,000 bugs.
  • Except we had some really good reviews while we wrote this, so we bet we found half of 'em already, so there might be 200,000 bugs left.
  • Our software isn't that important (it's not for a cancer radiation machine or the Mars rover or whatever), so we can release it when 85% of the bugs are gone.
  • This means we need to find and fix 170,000 bugs in order to release our software.
  • We have a team of 20 people and we think each person can find 15 bugs per week. We think we can fix them at about that rate too.
  • So we estimate it will take about 57 weeks to test and debug this software.
Now let me point out that this is not a very good way of estimating this; an experienced person might well scoff at it. Common sense suggests that all of the numbers used could be way off.

Nevertheless, if you instead just "guess" how long testing will take, you'll most likely be off by as much as an order of magnitude (so you might guess 2 months when it will really take 20 months). Any intelligent estimation technique will get you much closer than that.

The other advantage of estimation over guessing is that you can learn from mistakes. If I made the estimate above for an actual project, and the testing instead took 80 weeks, I could see places where the model was wrong - were there way more bugs than we thought? did people find a lot fewer per week than we guessed they would? were we still finding really critical bugs even when we were no longer finding very many bugs in general? This would allow me to make a better estimate for the next project. It is much harder to adjust your gut; you can only use very crude adjustments like "I'm always too optimistic" or "things take twice as long as I tend to think."

Sometimes time estimation can brighten your day too. If you have a stack of 200 forms to process, it might feel like you'll never finish, but if you time yourself while you do 5 and find that 3 minutes have elapsed, you know you can finish in two hours, not counting breaks. So really, if you're starting in the morning, you'll easily be done by lunch.

Budgeting is another example of estimation's superiority over guessing, but that's a whole topic of its own.