For nine years, I have developed for the web. Over the years I’ve programmed in C, C++, Python, Java, ASP, PHP, Perl, and most recently, Ruby.
Since my first job as a developer, I’ve never looked for a new job: all of my job transitions have come through friends or co-workers.

In mid 2007 I was happy working with Perl. One day a friend told me about a Ruby on Rails job. Back in 2007, Rails developers in Brazil were rare. Because of that, the employer was seeking someone who fit the company instead of someone with Rails experience. That was great for me!

After a pleasant summer, the new job’s charm wore off and I decided that I wanted to move on but continue to program with Rails. Finally, I left my job.

When I started to send out resumes I soon realized that Rails’ culture fundamentally changed the way that a Rails job search functioned. In addition to the traditional resume or CV, Rails jobs demanded to know about Working With Rails, LinkedIn, GitHub, Twitter, personal blogs and sites, discussion forum posts, participation in open source projects, and a multitude of other online presences. These new demands made me realize that I hadn’t been cultivating a comprehensive web presence, which is not uncommon for female programmers, in my experience.

At first, this realization was disturbing. Though it’s still possible to get a Rails job without a vast web presence, I was upset to realize that I hadn’t been adhering to this best practice. It was particularly jarring the first time I was unable to answer these questions to potential employer.
The practice of software development as a craft is constantly reinventing itself and this includes the processes around job seeking and reputation building. Despite all of the hours, projects, languages, and jobs I’ve previously invested in, I now realize that I need to adapt to this new developer reality of being social and visible with my work in order to win back my standing as a desirable developer and potential candidate for a Rails position. The details of how I’ll implement that strategy will be the subject of an upcoming post, but I look forward to the possibilities ahead.

To read in portuguese.

“Pair programming is a software development practice in which two programmers work together at one work station” http://en.wikipedia.org/wiki/Pair_programming.

I’ve worked with pair programming at just 1 company for 9 months, the results were both good and bad.

During the time when you are pairing you share your computer with another person. You also share your virtual life details, such as:

The one billion dollar question is: “What happens when the pair does not get along?”

If both people aren’t open to learning with from the experience, the day by day can become difficult.

Pair programming doesn’t work when one party feels the result could be better if the work was done alone. In this case, pair programming is an intrusive and negative experience.

Some people doesn’t understand this situation. To make it easier to understand I usually like to compare pair programming to driving a car and having someone beside you.

First case: Going by a known path.

Second case: Learning new path.

You are driving but now this person prefers to do the driving. If you make some mistake that person says “It would be better if I was driving.” or “If I was driving it wouldn’t have happened.”. What would you do?

Probably both of you arrive at the party in a bad mood and will try to avoid sharing the same the car again.

Maybe if you were in the car a debate would start. But, during pair programming you’re in a company and some words wouldn’t and shouldn’t be said.