Today was my first day at a new job. I knew much of the people who works there, so culture wasn’t a real breakthrough for me.

So, I arrived in the office by 11:00 am, said ‘Hi’ to my friends (it’s really good to be back, guys), and by 1 pm (one lunch hour included) I was ready to work. I had it all installed, permissions given on the projects I would be working and a thin documentation ready to be read.

I spent another hour or two reading and talking to people who were on my project and started delivering real code. That means I had barely 3 hours of environment setup, organization setup, chair adjusting, etc and was GETTING THINGS DONE. When I began thinking about it, I was totally amazed.

This is the kind of organization mindset I think brings this kind of result:

  • Leave development stuff to development people: permissions, servers, environment, documentation, everything; If they’re smart, they will know what to do. If they’re not, don’t hire them :).
  • Plan! Plan to have everything needed when people arrive. Map your risks, act accordingly when needed. Don’t overplan, though: there is stuff that is unpredictable;
  • Don’t assume risks you don’t have to: If you don’t have to micromanage something, don’t do it. Why would a company want to run an e-mail server? Google Apps delivers it all! Calendar, Docs, Sites, Groups, Mail! With GMail user interface and functionalities!

That being, I couldn’t have had a more productive first day at any new job. It was a marvelous experience, and I am looking forward to improving it even further.

What about you? Any good/bad situations on a new company set up you would like to share? Comment!


This theme is beggining to feel old, but I think there are some thoughts I could share about it.

At first, Apple won’t let flash go inside its iPhone OS environment. Their reasons are on an open letter written by Steve Jobs. The other day, Adobe responded Apple using Apple’s way of target marketing: humiliating and mocking their adversaries.

We all know what’s in it. Apple is not required to let flash in, and they want people to work with their environment, learn to work with their tools. Damn, maybe they can even use Objective C to write real Mac applications. So, it becomes clear that Apple is not wrong here, they are only protecting themselves from the outside world (and trying to make some money, does anyone have a problem with that?).

But I have a real problem with an item on Apple’s “Thoughts on Flash”.

“First, there’s “Open”.”

Are you serious, Apple? You’re questioning Adobe for not being “Open”? So, what is your concept about Openness? It’s incredible that they can blame Adobe for not being “Open” AND say “You know, I know we’re not open. But we strongly believe that all standards pertaining to the web should be open.”. There is no need to study Apple’s way of doing business to know they don’t believe in what they are saying: They tell it to you themselves!

Apple, you have a great number of reasons to keep Adobe out. You do want to have a share on the sold apps, you don’t want people to be publishing games without your aknowledge, both because of the share and because of the apps’ quality. I can understand that much… I believe freedom of choice gives the best user experience, and would bring the best of luck to your iPhone OS platform.  You don’t, and it’s OK!

You don’t need to be making lame excuses to do something that is perfectly within your rights. Just do it and deal with the outcomes, but don’t use fallacies to make people infer you’re something that you’re not: An open, standards-supporting company.

Google has just launched Jarlsberg – A Web application that generates web applications full of vulnerabilities. Jarlsberg is a great idea for people who work with web development/security. Just access to learn more about ir. For the impatient: access and try to find some exploits!!

I’ll give it a try and will write more about it later.

I’m directly from brhackday, SP! The event is amazing so far, I’m sure I’ll have plenty of stuff to blog on the next days (YQL is amazing, Yahoo! is getting more social, everything is very exciting around here).

But I want to talk about the project we chose to implement here for the competition (Thanks Leonardo and Gustavo, you’re being great so far! Hope we can make a great project out of this):

We’ll cross routes (from and to anywhere anywhere) with traffic and weather information (from the official traffic agencies) in São Paulo, to help users choose what route to take when using google maps.

So, what do you think? Will it be useful for you guys? Have already seen anything like this?? Any extra feature you would like to have in this system?

Any feedback will be greatly appreciated!

EDIT: There is a traffic layer on google maps, and it works pretty well. Don’t know why we haven’t seen it before, but it showed up here just before we begin the work. Actually, I think they used the exactly same structure we intended to use. Anyway, we dropped this project to work on a more useful one.

I just received my registration confirmation to Yahoo! Open Hack Day Brazil 2010! I have a lot to study now, so you should expect to hear a lot about Yahoo! services (YQL, YAP, YUI3, Meme, etc) around here in the next weeks!

If you haven’t registered yourself yet, there’s still time! Go to and sign up!

Anyone else going? Any Yahoo! APIs you have experience and would like to share? Do so in the comments!

A couple of weeks ago, I was called to solve a problem on a project. I had no particular expertise in the task at hand: XPath. We had to write an XPath expression to find a piece of data inside an xml document.

Both the XPath processor and the xml document generator (it was being generated automatically) were black boxes. That means we couldn’t change the xml file nor the XPath processor. The problem was a simple one: The XML document was generated with a default namespace, and we didn’t knew how to process it. I wrote a (simple) XPath processor to test the behavior of the expressions we were using and, after an hour or two, we discovered the problem and the solution (For the curious: we were using //<tagname> and had to use //*[name()='<tagname>’]. To check the difference, RTFM).

Then I asked myself: Why were I trying to get a solution to the problem before getting a deeper understading of the underlying technology? Then I realized that this behavior divides programmers in two groups: Scholar programmers X Practical programmers.

The Scholar programmer is the one that, reagardless the time/cost constraints, is only worried in learning. He manages to get some things done once in a while, but it is not that common. He is mostly worried in learning, and is closely related to Resume Driven Development. This guy can be useful to your team, if you can make him work based on deadlines.

The Practical programmer is the entire opposite. For him, the important stuff is to get things done right away. He is obsessed with solving the next big problem. Do not be fooled: This guy can ruin your team. He will get things done and all… But he will not learn new stuff. He insists that you should keep using your old solutions, instead of trying new stuff. In the end, his short term decisions will make everyone’s life harder.

Obviously, no one can be 100% on one side nor on the other. “Virtue is in the middle” applies really well to this situation.

So, where do you fit better?

I retweeted this, but I found it so interesting I wanted everybody around here to take a look at it.

Even if you forget about the language-specific stuff (very smal, well placed part on the end of the slides), the message is awesome.

Really, it changed the way I think about programming languages. You should REALLY go through it.

EDIT: Good to notice the text @wycats used on his original tweet:

BTW: I personally find a great summary of the philosophy behind Ruby

If you never learned ruby (You should, shame on you, you had this, this and a ton of other reasons), this phrase should make you begin now.