The Continuum's compensation package

The other day, talking in the phone with someone, he asked me what were the advantages of working on Continuum, the company where I am working since August. He meant it mostly in the monetary sense but I didn't fully understood until he asked about specifics such as complementary health insurance [1].

And the answer is no: Continuum, as most small companies in Chile, doesn't offer any monetary extra besides your salary. Unfortunately, at least on my country, the extras are a privilege that you usually only get from big corps.

However, being a small company let them offer something that big corps don't tend to offer (or simply can't):

• You matter. A lot. You can change the company. No, no, not only you can change it, you do change and shape it week after week. When you realize it, you feel really good. And empowered!


• We can use really comfortable clothes. Want proof? Here is our CEO, in the office:
  


• You will constantly learn. Even if your project isn't teaching you too much, we try to do pair programming, and learning tricks from your coworkers is part of the reason why pair programming is fun. And we have "Lecture & Beer" every Friday, when you will learn what your coworkers have mastered lately. And you will lecture your coworkers from time to time. Teaching is, in my experience, the most effective way to really learn.


• If you get drunk in the office you won't get punished. Well, I can only confirm that this rule is valid for "Lecture & Beer". And perhaps only if you aren't the speaker ;-)


• The company feels like a group of friends. The whole company.


• You can speak your mind. No politic games here.


• You work from 8:30 to 17:30. For Chilean standards that's 5 hours a week less than most places. And leaving around 17:30 is great, you avoid the horrible traffic and/or the horribly crowded subway.


• You get your birthday off.


• You can work with cool foreign companies like Hashrocket. More importantly, you can work and have fun with cool people from other cultures, learn a lot, improve your english, etc.


• You are encouraged to participate on conferences and related events. The company has hosted meetings for three different user groups so far! And a few months ago the whole company took the Friday off to attend to a conference outside Santiago.

Sounds like a good compensation package to me!

Update: Oh, and we have four weeks of vacations, which is one more week than usual!

[1]In Chile by law at least 7% of your raw income must be spent on health insurance. However, since the regular insurance coverage ranges on the 70% - 90%, a common compensation from employers is to give complementary insurance that may cover (part of) the difference

Python command line tricks

Here is a couple of useful tricks you can perform on any machine with Python installed.

1. Serve the current directory via HTTP

$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

Quite useful for sharing files on a network when the usual file sharing systems fail and/or you don't want to mess with accounts/passwords just for transmitting a couple of files.

2. Create a debugging SMTP server

$ sudo python -m smtpd -n -c DebuggingServer localhost:25

If you need to test an application that sends emails but don't have an email server installed on your development machine, by running the Python's DebuggingServer you will have one. It won't deliver the incoming mails but will print them on the standard output so you can see if the application is sending the emails correctly and also inspect the content easily.

External incentives don't work with programmers

The surprising science of motivation is a very good talk by Dan Pink that explains what most people with (real) experience in the software programming field already know: If someone isn't internally motivated to work on something (for “something” in the set of jobs that require the use of cognitive skills), external incentives such as bonuses won't fix that. Moreover, as demonstrated by studies (look at the video for the details), they often hurt. Joel Spolsky provides a plausible explanation:

“But when you offer people money to do things that they wanted to do, anyway, they suffer from something called the Overjustification Effect. “I must be writing bug-free code because I like the money I get for it,” they think, and the extrinsic motivation displaces the intrinsic motivation. Since extrinsic motivation is a much weaker effect, the net result is that you’ve actually reduced their desire to do a good job. When you stop paying the bonus, or when they decide they don’t care that much about the money, they no longer think that they care about bug free code.”

—The Econ 101 Management Method

So now you have another proven fact that explains why passionate, motivated developers are so valuable. But don't forget to see Dan's talk: it's a very good one and takes less than twenty minutes.

Quick Solution: MySQL gem on Snow Leopard

A few days ago I got the following error on a Rails application (after installing the mysql gem) on Snow Leopard:

  Error: uninitialized constant MysqlCompat::MysqlRes  

If you ever encounter this problem, uninstall the gem and reinstall it in the following way:

ARCHFLAGS="-arch i386 -arch x86_64" gem install mysql  -- --with-mysql-dir=/path/to/mysql/dir/ --with-mysql-config=/path/to/mysql/dir/bin/mysql_config

[Solution taken from here]

Dynamic Languages Meetup in Santiago de Chile!

This Wednesday is the second meeting of the Dynamic Languages group. The first one was great, with more attendance than expected: ~20 enthusiast, all of them quite passionate. We had a good time meeting each other and learning what we expect of the group we are forming. A lot of different topics for discussion popped out, ranging from marketing of dynamic languages on the local market to the technical differences between languages, while also touching other interesting topics as the state of the job market for dynamic languages in Chile.

This time, we will focus on some of those topics by doing a handful of Lighting talks presenting the topics (so you won't be lost if you didn't come to the first meeting) and then open up the discussion.

So, if you are around Santiago (or Viña/Valparaíso -- we had some attendants from there in the first meeting and will probably host a future meeting outside of Santiago) and have interest on dynamic languages such as Python, Ruby, Javascript, Lua, etc., please come and share your experiences with a group of fellow enthusiasts that will be eager to learn and build our own community!

Click here to check out
The Lenguajes dinámicos - Chile!

Django-Jython 1.0.0 released!

Yes, it's a long overdue release for the collection of tools to use Django on top Jython that began its life after my Google Summer of Code project in 2008. If you don't know what I'm talking about, take a look at the shiny new documentation to get an idea of what it includes.

There is something that makes me happy to release it now instead of some months ago (original plan was May or June). That's because I can say now that django-jython is not a solo project anymore: It's got two huge contributions from other developers of the Jython community: Josh Juneau and Jacob Fenwick who wrote the Oracle and MySQL database backends, respectively. Thanks to both of you guys for moving the project forward! I'm also grateful for the useful bug reports from other members of the community who has helped us to make a better release.

The release is meant to be used with Django 1.0.4 and Jython 2.5.x and here is a copy of the important points of the release notes:

• Added Oracle backend


• Added MySQL backend


• PostgreSQL backend: Works on Django 1.1.x


• War command: Fixed problems when using multiple apps from a package not belonging to the project.


• PostgreSQL backend: DecimalField works as expected


• Added doj.VERSION following the same convention as django.VERSION


• Stand-alone documentation included on the distribution

Next goal: Release 1.1.0 next month, featuring full compatibility with Django 1.1.x (and hopefully some new database backends too!)

Software Architecture, the US, Outsourcing, and R&D

The U.S. Is Outsourcing Away Its Competitive Edge is an interesting article. I'm not a business person (yet!) so I won't comment on the core message of the article. But this argument resonated on me:

“In many cases, R&D and manufacturing are tightly intertwined. Unless you know how to manufacture a product, you often cannot design it. And, to understand how to manufacture it, you have to have manufacturing competencies and experience. The notion that you can design a product in the serene world of the R&D laboratory without any knowledge of the rough and tumble world of production is ridiculous”

— The U.S. Is Outsourcing Away Its Competitive Edge, Harvard Business Review

I drew the obvious connection with that in our field is called as ”Software Architecture“ which, while reasonable in theory, ends up in practice with a bunch of Architecture astronauts: People who stop thinking on the real problems and solve abstract issues using whatever high-level “design language” they think is the equivalent to what the real architects draw.

For these folks, coding is too boring. And you know, they already did their share of coding and finally got away from that. Which tells me that they never liked coding too much, by the way.

So the solution is to "outsource" coding to the more junior coworkers. Which is were I draw the parallel with the article which talks about the US and their massive outsourcing of technology production while still wanting to keep the edge on R&D. Which sounds like a problem.

If you think that coding is sometimes boring (and I can agree about that!) and you feel tempted to take an software architect role which is being sell as the position in which you will still do the entertaining part of the work (the one in which your brain gets some exercise) while leaving the rest to something else, think about that again. It will probably work at first (since your experience with real coding is still fresh) but it won't work at long term. You can't tell people how to code and what to code if you stopped coding and solving real problems a while ago.

Not to mention than “coding” with diagrams is boooring, improductive and and almost useless anyway.

So I'm on the camp which thinks that the right answer is the technical leader, not the architect. One who will need experience, for sure. But who won't throw away that experience by completely change his role! He will still code and test and make releases and make mistakes (which is when he will continue building experience!)

“Experience is what you get when you don't get what you want”

— Dan Stanford

And this in turn takes me to the agile camp. Not only because I agree with the core principles like people-over-processes. But because I think that the whole parallel with civil engineering made by the traditionalist and waterfall-ish model is dead wrong. Civil engineering need to plan a lot because changing a building on the fly isn't exactly easy. But we not only can change our systems on the fly, but people expect to be able to change them.

We don't need architects who aren't up to get their hands dirty and participate in the coding process. Because, in the software-engineering-as-civil-engineering parallel, the real equivalent of what the civil architects do is the code, not the diagrams.

Which brings us back to something I mentioned before in passing: Coding can be boring, tedious sometimes. In my view, the appropriate solution is to change to a better language that let you write code which is closer to a description of the underlying design. DSLs and that sort of stuff.

And yeah, diagrams can be a useful tool in the thinking process (and even better tools as high-level, introductory views of the systems), but stating that they are the design/specification is admitting defeat.

This is also why I think that agile practices are somewhat dependent on programming languages. They can't be completely separated like a set of practices that you can use regardless of what you are using to build whatever you are building. But I'm digressing to a different topic, and this is enough for today.

My final advice, however, is that if you like to program but find it increasingly boring and the offered “solution” by your current company is to become an architect, counter by offering the real solutions. Or move to a better company, if that doesn't work.