Reclutamiento

Esto es en respuesta a la Carta abierta de un desempleado a los entrevistadores

A veces hago entrevistas laborales. Una de nuestras oficinas está en México. En mi compañía NO hacemos pruebas psicométricas, y solicitamos currículums sin foto, edad o información personal. Mi interés principal es 1) Eres listo, puedes escribir código al nivel que requerimos?, 2) Trabajas sin tenerte que decir qué hacer a cada rato? y 3) Tienes pasión por escribir software y por ayudar a otros a escribir software?

Evidentemente, todos los candidatos van a decir que sí. La cosa es probarlo. La validez de los metos con los que probamos cualquier cosa en cuanto a reclutamiento es lo que está en cuestión aquí.

Continue reading “Reclutamiento”

Some of my thoughts on Git

Git is the version control system I am using now. I find it useful for my needs in particular since I do at least a part of my work on locations that don’t have network access. Git uses a federated model – you have all the repository history, and you can commit even while you’re not connected.

If this sounds attractive to you, read on to see how you can use git as the sandbox for your svn repository and to learn about the features of git.

Continue reading “Some of my thoughts on Git”

Agile Chronicles Blog: A few good managers

This is awesome..

Development: “You want answers?”
Marketing: “I think we are entitled to them!”
Development: “You want answers?!”
Marketing: “I want the truth!”
Development: “You can’t handle the truth!!!

Son, we live in a world that requires software. And that software must be built by people with elite skills. Who’s going to build it? You, Mr. Marketing? You, Mr. Sales? You, Mr. Finance? You, Mr. Human Resources? I don’t think so.

Agile Chronicles: A Few Good Managers

technorati tags:, ,

On the topic of assertions

Every assertion should be thought from the standpoint of

  1. What was expected
  2. What actually happened

Translation: assertTrue should always, always have a message.

Consider the following:

assertTrue(mv.getViewName()
    .startsWith(myController.getSuccessView()));

This will only return “assertion failed”. Which is great, but how do we know what happened? If this is buried on one of the lunt automated remote builds, how am I supposed to know what is going wrong? Which is the expected? What actually happened?

A much better version of the same looks like this:

assertTrue(
    "Was expecting something like "
        + myController.getSuccessView() + " but was "
        + mv.getViewName(),
    mv.getViewName()
        .startsWith(myController.getSuccessView()));

Same assertion, but now it tells me more specifically what’s going on and I can fix bugs with it. Once I set this on the test, it becomes easy to see what was going on.

I recently had a Saturday with some other Bay Area developers where we did a lot of thinking about testing, so expect some more advice in the future as I collect my notes.

Remember the goal of unit tests is to “find bugs” (thanks Harry!). An assertion without an associated message merely notifies you that a bug occurred but doesn’t actually “find it”. As you are writing your unit tests, make sure you find it as well.

technorati tags:, , ,

Hunting vs. Gathering – our cavemen brain

I’ve spent the last few months implementing GTD and I’m still getting used to it, although I feel I’m achieving a comfortable rythm. One of the big “ah-hah” moments in this process however is the difference between our “hunting” and our “gathering” brains. The basic premise of dividing your time in “collecting without doing” and then “doing without collecting” is what makes you feel like you’re “in the zone” when you’re doing stuff and gives you a relaxed feeling when you’re done collecting your stuff.

After doing this for a little bit and then having a small crisis on a Scrum project (where requirements for the current sprint kept changing during the sprint). I realized that one of the big sources of mental stress is precisely trying to do both at once. Our brains just don’t seem to be able to handle it.

The way I see it, our brains are pretty much still cavemen brains, used to running out and hunting deer for a very long period of time, and then going out and foraging for food for another long period of time. If you get into a “chase” mode when you’re foraging, it means you’re the one being chased, and it automatically fires our stressors.

technorati tags:

Don't try this on a scrum team, kids!

FullDuplex.org provides us with a funny list of things to do to “look busy”.

Here’s a few tips I’ve learned in my short time on this earth that have kept me from getting too much accomplished.

fullduplex.org » How to Do Nothing at Work, and Get Away With It

He goes on to explain his “tips”.

It left me thinking two things. First, I’m very glad he’s not on my team, second, the value of scrum and agile methodologies to get rid of the dead weight. Here’s my response to it:

I’m a lead in a web development team, and I manage and assign work for web developers. This is the behavior that gets you fired from my team.

Let’s analyze it shall we?

Look Busy/Look Stressed: We’re a Scrum team, we meet every day to talk about what we did the day before, what we will do today, and what roadblocks we have in our way. So why aren’t you asking for help? I have no use for web devs with such little people skills that they won’t even ask other members of their peer group for help. If you can’t be on a team, maybe you should go independent and not work on a team.

Speak Quickly/Hide/Break Limb/Make Excuses/Never Leave your office/rearrange furniture,etc: The only thing here that may work is breaking a limb. And even then if that happened to you it would make you a prime candidate for pairing with another developer. All the others, your non-activity would show up on the cvs commit log. In my team we have a great cvs mailer that shows colored differences of what you did, and I check it daily.

Choose a Profession people don’t understand: Your manager is probably not a techie, or he’s as lazy as you are about checking your work. You’re a perfect example why only techies can manage techies, and techie managers need to code at least 20% of their time on the current project so they can keep their skills. Also following the cvsspam list helps understand the issues.

So you see, using Scrum or other Agile methodologies underscores the lack of value of these people and will make it obvious who needs to drop off your team. Either that or they’ll shape up via peer pressure, which in the long run will make the ex-lazy team member happier as well.

technorati tags:, , ,

Two year-olds and the scientific method

As I watch my little one play with his trains (he’s still pre-videogames) I can see the essence of the scientific method playing over and over with his hands and his eyes.

Try to put the big train and attach it to the little train. It doesn’t work. How about the toy car? Nope, not that either. At the end he has all the magnetic pieces put together properly and then says "choo-choo!" as he pulls the locomotive. Now he’s trying to place a small "Jojo Circus" figure as a "passenger" on top of the train. He pulls it a couple of times but it keeps falling, until he realizes that the bendy legs fit perfectly around the oil tanker car. Then he pulls everything apart and tries it again, this time in a different configuration.

Will Wright on Wired: 

Just watch a kid with a new videogame. The last thing they do is read the manual. Instead, they pick up the controller and start mashing buttons to see what happens. This isn’t a random process; it’s the essence of the scientific method. Through trial and error, players build a model of the underlying game based on empirical evidence collected through play. As the players refine this model, they begin to master the game world. It’s a rapid cycle of hypothesis, experiment, and analysis.

Wired 14.04: Dream Machines

 
Think about this when you write your next piece of software – these are the people you are writing software for (after all, most young adults grew up playing videogames).  The previous generation read a lot more than they experimented. The new generations try things out first, then collect their experiences and blog about them, then maybe read someone else’s experiences to find kindred spirits. So make your software easy to experiment with, and make most everything undoable.

technorati tags: ,