stupid job postings: “bennies” edition

Posted by amy on May 29, 2007

Recently I saw a job posting that had a list of perks including “free Starbucks coffee, bennies.” Wow, I thought, do they really want to advertise that their developers need tranquilizers (possibly from all the free coffee)? Then I realized that “bennies” meant benefits, as in health, leave, insurance, retirement. Note to recruiters: benefits are important enough to be listed before free Starbucks coffee and should not be referred to with a diminutive.

Also, anyone who writes “All applicants must have the ability and desire to thrive in a fast moving team environment.” deserves whoever they end up hiring.

I’m not linking to the offenders. What if I want to work for them someday? Then I’d be embarrassed and the New York Times would use me as an example of the perils of online work life in the days of blogging.

Popularity: 6% [?]

Faster than a Daily Scrum

Posted by amy on May 25, 2007

and more efficient than a stand-up meeting:

Meeting about the day’s work over breakfast with a four-year-old.

“I need a grownup to play with me!”

“We’re meeting, hon, wait 15 minutes.”

“Okay, then I just need a box cutter and some tape.”

“Right. Max, you do the migrations, I’ll modify the controller. Meeting adjourned.”

Popularity: 4% [?]


Posted by max on May 24, 2007

The other day, Amy needed to explain to our son Ari why we had to work for money, why we had to hire babysitters sometimes, why we couldn’t be interrupted during business phone calls. The approach that seemed to work extremely well was a hand-sketched diagram, more or less a UML use case, that described the flow of cash to and from us for goods and services.

Life-UML diagram

Popularity: 4% [?]

Rails Pagination: Top Resources

Posted by amy on May 22, 2007

Today I needed to figure out how to best paginate results from an acts_as_ferret search (Go here for a tutorial on acts_as_ferret.) Kevin Clark told me that I shouldn’t be using the built-in rails pagination, though I was not the only person wondering why the hell it’s in there if I’m not supposed to use it. Lazy as always, I went looking for someone else’s paginating code. Here’s what I found. I’ll update this entry with my impressions of the code once I’ve actually used it:

Cardboard Rocket offers a paginating find plugin.

Ilya Grigorik provides a discussion of aforementioned plugin, plus the helper and view code to go along with it.

He also offers a version for acts_as_ferret paginating find.

Also, the chowhound developer provides some alternate pagination code, which I was thrilled to find, not least because I used to love the content of chowhound (way back when we ate out a lot) but hate the format (message board circa 1992). And yay, now chowhound has the standard rails look-and-feel, of which I am a big fan.

By the way, if you’re new to Rails, you should be aware that the pagination issue was a minor explosion in the rails-world. File that one away in your “rails cultural literacy” dir, and you’ll be well on your way to faking everyone out about how long you’ve been in RoR land.

Popularity: 4% [?]

Job Descriptions Update

Posted by amy on May 18, 2007

Today I happened to see a job description that didn’t suck, so I thought I’d give the company posting it a bit of free publicity in thanks. (Publicity, hah! That would imply that people are reading this blog…;-) Ontela is looking for a “demo hacker”. Though a bit verbose (*I should talk*, blabbermouth that I am), their job description gives actual examples of what the job may entail, and actual useful details about what kind of working conditions to expect:

Moderate travel (15%) may be required to get the job done – flying out to install something for a customer, for example, or coming along on to a tradeshow to make sure everything works. Also, as a young startup, we do work long hours-not just nine-to-five. In some cases, you may even need to be available during weird hours, for example if the team is off demoing in a strange time zone.

In other news, commenter Audrey points to a job description she sawthat was not bloated with business-speak, just with bias. (And Audrey: yay, thanks! Our first comment!, and sorry I am not at railsconf to keep you company with all the boys, but I didn’t want to schlep the baby. )

Popularity: 3% [?]

Our brand, again

Posted by amy on May 17, 2007

Here we are, in Internet Boom 2.0. As they are fond of saying on Battlestar Galactica, “all of this has happened before; all of this will happen again.” Join a fabulous startup, get rich quick. Take your dogs to work. We have a work hard, play hard atmosphere, and all the free $junk_food you can eat. Just completed our second round of funding.

And so goes the business cycle.

Meanwhile, how do we figure out what we want to do? We can do many things. We could advertise ourselves as general all-around techie problem-solvers, but isn’t that a bit vague? A friend with an interactive agency keeps trying to convince us to learn ActionScript 3. We keep trying to get it up for the idea, but we just can’t. If one of us could, the other could go along, but neither of us can.

We wouldn’t call ourselves expert at anything. We’re generalists by temperament, and by circumstance. It’s harder and harder to be a specialist these days: you start specializing, and your specialty goes overseas, or out-of-style. Or someone discovers that you are great at requirements analysis and there you are, talking to users, when what you wanted to learn to do better was write code.

On the other hand, our non-specialist skills are a lot better than many people’s specialties. I keep thinking my skills must be a bit rusty, given that I’ve been working mostly as a hausfrau for a couple of years now. Then a friend will tell me some story about how he discovered that the reason someone’s code was running so slow is that it was making a ton of completely unnecessary database calls. And I think, “well, duh.” Which reminds me that actually, I may not be up-to-date on my technologies, but I’m not, fundamentally, a dumbass. Which a disturbing number of software developers are. I like solving problems with code. I like solving problems with other peoples’ code even better. I like working with other people to solve problems with code. And I like working with people to solve their problems without code. And finding out exactly what problem they’re trying to solve when they come to me with some ill-conceived notion about some code they want me to write.

In general, I’m remembering how much I truly enjoyed writing software.

Which, getting back to figuring out what I’m passionate about, should tell me that even though I write great documents, I don’t want work that’s just about writing documents. I want work where I get to write code.

When I was a kid, I thought I’d be a novelist when I grew up. I was very sure of that. In college I instead became very sure that I would be a university professor, an anthropologist. My friend Nitzan and I would start a new school of thought, neo-structuralism. It would be all the rage. We would be incomprehensible and profound.

I ended up writing code because Max thought I’d like it. I don’t think he thought I’d end up a software developer. Who knows what it means to end up anything, anyway, these days, when everyone tells us to be flexible and expect to have a dozen different careers in our lives. What does ‘career’ even mean in those circumstances? Actually, what did career ever mean? Max’s father says that the whole concept of a career, as we think of it, was invented in the 70s to get more unpaid work out of white-collar employees. It’s not enough to put in our hours at the office – we also have to advance our careers. We do this not just by putting in extra hours, but by having an advertorial online presence. We have to brand ourselves and then sell sell sell. I resent this. Working on a SafeForWork blog, building my online brand, networking… there are so many things I’d really rather do with my time. And yet.

One must have money.

So I consider my brand. I consider Max’s brand. I think about what **our** brand would be, the secret that would make hiring us, as more than two minds (a *bit* more, you see), attractive.

When I figure it out, I’ll be sure to let you know.

Popularity: 4% [?]

From _A Guide to Testing the Rails_, a fantastic explanation of why we should write test code

Posted by amy on May 17, 2007

As mentioned before, tests offer proof that you’ve done a good job. Your tests become your own personal QA assistant. If you code your tests correctly, at any point in development, you will know:

  • what processes work
  • what processes fail
  • the effect of adding new pieces onto your application

With your tests as your safety net, you can do wild refactoring of your code and be able to tell what needs to be addressed simply by seeing which tests fail.

In addition to normal “did it pass?” testing, you can go the opposite route. You can explicitly try to break your application such as feeding it unexpected and crazy input, shutting down critical resources like a database to see what happens, and tampering with things such as session values just to see what happens. By testing your application where the weak points are, you can fix it before it ever becomes an issue.

A strong suite of tests ensures your application has a high level of quality. It’s worth the extra effort.

Another positive side-effect of writing tests is that you have basic usage documentation of how things work. Simply by looking at your testing code, you can see how you need to work with an object to make it do it’s thing.

The online book is a fantastic resource. Thank you, thank you, Sam-I-Am.

Popularity: 5% [?]

Testing Rails: the learning curve

Posted by amy on May 17, 2007

Max and I are trying to learn how to write tests for our rails apps. Like many things in rails, testing seems intuitive to those who understand what’s going on already, but people who claim there’s no learning curve are deluded. The first three times I opened up my test directory and started trying to write test code, I grew incredibly frustrated and confused and gave up. “What’s assigns() do? How do I write my fixtures? Why do I always stick my colon in the wrong place when going back and forth between yaml and ruby code? What should I be testing anyway?”

“Who needs tests?” I thought. “That’s what QA is for! No one can figure this stuff out! I have no frackin’ clue what is going on here, and I never ever will.”

But I kept trying. When Max and I sat down this morning to write tests for our current project, we quickly grew, yes, frustrated and confused. We snapped at each other. Max squinted a lot, and I pointed accusingly at the screen a number of times. “See! See! Do you SEE what we are doing here?!” We couldn’t get one teeny tiny little test to pass. We wanted to do pretty much anything else.

But okay, we said. Learnd-ing is hard, as Ralph Wiggum (or a certain George) might remark. We are frustrated, but we will get it.

Eventually, we got our test to pass.

Now we just have about a zillion more tests to write, and we’ll be all set.

Popularity: 5% [?]

A Word On Job Descriptions

Posted by amy on May 17, 2007

I look at a lot of job descriptions. If the perfect employee jobs came up, Max and/or I would take them. We are also always on the lookout for interesting contracts, cool companies, and weird projects. For clients who want the work done, and don’t care if I bring a nursing infant to a meeting…For work opportunities with the potential for exponential and renumerative growth. For a fast-paced, take-no-prisoners, work hard-play hard up-and-coming, learning organization. Wait, no, scratch those last two sentences.

__What we’re looking for is job descriptions that are not full of crap.__

Most job descriptions are as tedious to read as most resumes. Do they say *anything*? Can even the people who write them stand to read them? I’ll be honest – I cannot bear to read my own resume, or Max’s. Or anyone else’s really. Even the best-written resumes I’ve seen are so bland my four-year-old would eat them without complaint. That’s *bland*, baby. Same for job descriptions. Occasionally I send my resume to a company because they had a puzzle in their job description — Athena Health had a fun one) or because they have an opening for “General Rock Star” (ZoomInfo‘s clever recruiter Martin Burns attracted me with that one). The rest of the time I think, “eh, I’d rather be wiping up baby poop.”

I would like a world in which no one was counseled to pepper their resume with impactful verbs, and companies did not seek “ideal candidates” who “posess excellent communication skills” and are “self-motivated.” Resumes and job descriptions would be formatted in a kind of work-yaml:

job-title: senior software developer
    skills: RoR, mod_perl, MySQL
    experience: 4-6 years
    hours:  40 hours for salary negotiations, 55 if you ever want a raise or bonus
    location: Burlington, in a hideous office complex where the only food is a Panera
    commute: 30 minutes, door to door (i.e., at least an hour each way)
    boss: hates confrontation, won't tell you if you're screwing up. Otherwise nice.
    benefits: good for now, but next year we'll cut out prescription drug coverage
    coworkers: pretty smart, will expect you to know how the Sox are doing this year.

resume: Amy Newell
    keywords: Java, Oracle, RoR, JSP, HTML, workflow, FDA compliance, project management
    previous_employers: Newell Household,
                        Millennium Pharmaceuticals,
                        Abuzz Technologies,
                        Harvard Extension School,
                        Harvard Medical School
    education:  humanities degree, summa, Harvard College.
                Software classes at Harvard Extension,
                vague thought of getting Masters there till life got in the way.
                O'Reilly's Safari Books Online.
    good_at:    talking, writing, coding, training, requirements
    experience: mom brought home apple 2+ when I was 7.
                Husband brought home heapsort 7 years ago, been software developer ever since.
    quirks: nursing infant, hate crowds, startle easily, don't like gadgets
    projects: Teaching Fellow for Data Structures class.
              Experiment Management Software for Molecular Pathology Department.
              Clinical Exam for Fourth Year Medical Students.

That’s it. I couldn’t resist putting in some jokey parts, but if you take those out I think we’ve really got a solution to the heartbreak of job and contract-hunting. Let’s stop bombarding one another with “Implemented Tracking System that increased revenue by 17% in 6 months” and “Must be a team player.” Let’s quit with “Detail-oriented”, “compensation package”, “in search of talented individuals” and “demonstrates expertise”. Please, no more “performs a variety of tasks” or “helped to grow the business”. Let’s ban “methodologies”, “proactive”, “interpersonal skills”, and “highly motivated”. I’ve been reading Jakob Nielsen’s website, and he has a nice quote from Winston Churchill: “Short words are best, and the old words when short are best of all.”

The thing about resumes and job descriptions is that there’s really no hope that most of what we say in them is going to be particularly useful in matching people to work. All the interesting, useful things to know about jobs, and about people doing jobs, come out later, after everyone’s already committed. So can’t we all just cut the crap?

Popularity: 4% [?]

Boston Ruby Group May meeting

Posted by amy on May 10, 2007

Tuesday night we went to the boston ruby group which was having a presentation on Hackety Hack. We took Aya (five month old) with us. The place was packed. Someone gave up his Aeron chair so I could sit down with the baby, and then I turned around and saw I was sitting right in front of a guy I went to college with and haven’t seen since the turn of the millennium. So that was pretty fun. Brian DeLacey introduced the project, Kevin Driscoll told us all about the joys of teaching CS to high school students, and Eric Mill showed us how we could use Hackety Hack to view Youtube video of a guy catching a pair of glasses with his face. A kitty burrito photo was also involved, but that was not Eric’s fault.

After the break Brian Guthrie gave a presentation about Handshake, which I wish we could have stayed for. Design-by-contract is one of those things we feel we should know more about, like aspects. But Aya started looking restless, and since she’d been quiet for an hour and a half, we thought we’d better not press our luck. So we left and went to Toscanini’sfor ice cream. (I am sorry to say I believe Toscanini’s ice cream has declined in quality. I used to think it was some of the best ice cream in the world. But last night it seemed a bit gummy and muted in flavor. And expensive. )

When we got home, Aya decided to do some coding on her own, based on what she’d learned about Hackety Hack.

There were more women at the meeting than I’d been led to expect I might see. At least five, I’d say. And everyone seemed perfectly nice about the baby. I hope we get the chance to go again soon, without the baby. Maybe Max and I will take turns going.

Popularity: 5% [?]