The amazing forgiveness of software


One of the things I like most about developing software is the fact that you can recover from most mistakes with very few long term impact.

Bugs are unavoidable, and most of the people involved on programming deeply understands that is something we all live with.  So,  there’s no hard feelings, once you find a bug, you fix it and immediately move on. Not only no one thinks that you’re a bad developer because you write bugs, but typically the impact of a bug is not that problematic.

Yes, there are some bugs that are just terrible. And there’s always the risk of losing data or do some catastrophic operation on production. But those are comparatively rare, and with the proper practices, the risk and damage can be reduced. Most on the day to day operation involves mistakes that have a much limited effect. Software development is more about being bold and move fast fixing your mess, than it is to play safe (within limits, of course).

This can affect production data! Show warning sign!

This can affect production data! Display warning sign!

Because the greatness of software is that you can break it on purpose and watch it explode, and then fix that problem. In a controlled environment. Without having to worry about permanent effects or high costs. And a good test is the one that ambushes the code and try to viciously stab it with a poisonous dagger. The one that can hurt. So you know that your system is strong enough against that attack. And then iterate. Quickly. It’s like having a permanent second chance to try again.

Not every aspect of live is that forgiving. I guess that a lot of doctors would love to be able to do the same.

Do you mind if we start the trial again and the jury forgets everything, your honor?

Do you mind if the jury forgets everything and we start the trial again, your honor?

Respect Driven Development


I think that one of the most overlooked components on any sane company culture is Respect. That’s probably true also for any relationship, also outside work environment, but I think is usually forgotten when nice places to work are described.

When I look back about the things that bothered me the most, most of them are related to disrespect, even in relatively minor form. It can be personal disrespect or not respecting the work itself or even the customers. Probably because is something engraved, it’s easy to take for granted when it exists, and to identify more problems deviating from the lack of it when is not present. We typically talk about how great cultures are innovative, open, communicative, fun, collaborative, etc. but one of the prerequisites that makes these values worthwhile is Respect, both to your coworkers and to the work itself.

R-E-S-P-E-C-T  Find out what it means to me

R-E-S-P-E-C-T
Find out what it means to me

Without Respect, ideas are accepted mostly depending on who present them, and need to be imposed. Even when there are explicit request for ideas, they take the shape of “suggestion boxes” where no one really looks into them. So, in practice, being proactive is discouraged unless you’re in a power position.

When there is Respect, ideas can be freely exchanged without fear of not being talking seriously. They are also welcomed from any source, not only through the “chosen channels”. There can be hard scrutiny, but it will be fair, and rejections will be reasonably based in facts.

Without Respect, a “funny, relaxed atmosphere” can be easily transformed into harassment and abuse. Jokes will actually hurt. Closed groups,   extremely aggressive with everyone external with them, will be formed. That can include groups outside the company, like mocking customers or partners. Some groups will be appointed as intrinsically “better” (engineers, executives…) as others (secretaries, workers…) and generate asymmetrical relationships, with one part dominating the other.

When there is Respect, jokes are played just for the laugh, and are taken up to the correct limit for everyone, as there are people with thicker skin than others. If those limits happen to be crossed, the problem will be arisen and people will sincerely apologise and correct their behaviours in the future, without external influence. Occasionally the customers or partners can be make fun of, but the quality of the delivered software will be took extremely seriously (the highest form of Respect for customers) and their requests or suggestions will be taken into account when making new features.

Without Respect within the company and the different groups, no particular measures will be enforced to protect anyone or anything. Therefore, it will be easy for someone to take advantage of that, ranging from lower the quality of the work to be a moron and degrade the working environment. Code will devolve into an unreadable mess, and technical debt will grow uncontrollably. Hiring standards will get lower, and not-that-great people will be part of the team (technically, but also in a more personal sense). Also, the expectations will be to work overtime regularly, without any contingency plans or treating it as a bad sign.

When there is Respect, the organisation truly cares about the people, and not just as an empty statement. This includes understanding when overtime is unavoidable evil and work as a team to avoid it as much as possible. And when it happens, everyone do as much as they can to make it as short and enjoyable as possible. There will be understanding when someone wants to leave because they have a genuine different interest, leaving the door open if things don’t turn out for the good. Learning and personal growth will be encouraged with actions, not only with words.

Trust, a extremely important value, can only arise if there is Respect. Without Respect, fear and uncertainty will replace real trust. Being honest needs trust and confidence in the other part, as real honesty can be, and sometimes should be, uncomfortable to hear. Formality and defensiveness take control over honest feedback and team work when respect is not present. Any long-term relationship also needs Respect to stay healthy.

What have I ever done to make you treat me so disrespectfully?

What have I ever done to make you treat me so disrespectfully?

Being imperfect human beings, we cannot probably achieve perfect respectful relationships  at all times. But we should try to be as respectful  as possible, identifying our mistakes and the ones of the organisation, and move up towards the Respect ladder. That makes a much healthier (and happier) environment for all. We should recognise the Real Respect, as the word is often abused.

It is great to aim for having a great organisation or startup, with a thrilling culture. But, in order to get to establish a funny, exciting, learning, diverse and passionate place to work, we should lay strong foundations with Respect. Identify it, and not tolerate the lack of it.

Compendium of Wondrous Links vol I


wondrous_linksAs a way of collecting interesting reads across the Internet, I plan to keep a relatively regular posts with some articles and posts that I’ve read, mostly related to development, software and tech world in general.

Here it goes the first edition.

Hope you enjoy it!

Online community biases


There are a lot of discussion online about a huge number of different topics. That’s fantastic news, I’d love to had a learning tool that powerful when I was in school. To share some of my interests, and have other people to talk about “cool stuff” and learn from them. Online communities have speed up personal and technological growth intensely, allowing people from around the world to share knowledge and to feel close. But, on the other hand, these kind of communities get naturally and subtlety biased. While this is normal, and probably unavoidable, anyone participating should be aware that the so-called “real world”, or even the community as a whole, is not a perfect extrapolation of it.

Totally scientific data, properly labelled

Totally scientific data, properly labelled

It is quite spread the idea of the “1% rule” over the Internet. A1% of the community will be the most active, driving the discussion, generating the subjects that will be provoke discussion, etc. ~10% of the people will collaborate, comment, retweet, add their impressions… And the rest will just consume it and learn from it. This distribution seems to be present in any community big enough. It makes sense, there’s only a very limited number of people that can be creators (I’ll call them leaders), there is a bigger group of people willing to spend time and effort collaborating (I’ll call them participants), and then the rest that are interested, but not willing to spend a lot of time (I’ll call them consumers).

But, here is the interesting part. The 1% is not a perfect representation of the whole.In fact, it can (and normally will) be pretty biased. That’s something quite natural. After all, leaders are different from the majority of the community, or they won’t be leaders. But other than their tendency to stand up, to speak up, they can have a lot of significative biases.

For example, a clear example of that are so-called “hardcore gamers”. While the statistical profile of a “gamer” (someone that enjoys video games from time to time) is very very broad, the “hardcore gamer community” is the most vocal. The discussion about games is centred into big AAA games (GTAs, CoDs…), and, to a lesser degree, to big casual games (FarmVille, Candy Crush…) and interesting indie experiments (Gone Home). The main idea someone will get is that “gamers” are mainly young, male and like to play for hours, when that’s not a good statistical representation of the community. Keep in mind that 45% of players are female, and a third have over 35 years. There are discussions about “what is a game and what is not” (meaning, “I’ve decided that you’re not playing games, OK?”), entire genres that are often ignored by everyone, and a general perception on what “real gaming” should be. A very good indication of that are the recent rants against microtransactions[1]. Sure, they feel wrong for a lot of people that is used to get a whole game for a price, and play it all. But I’m afraid that a lot of people right now spend a small amount of time playing and they just don’t feel like committing to a game, and Free to Play model present advantages to that kind of player.

I really don't see the point denying that this a game. It may be a BAD game, though.

I really don’t see the point denying that this a game, even if is a BAD one.

I am not arguing that biases are good or bad. Some will be good, because will bring focus to a chaotic community, some will be bad because will represent a minority that think they are the only “real” members of the community. Probably each of us will have a different opinion about which ones are positive or negative. What I am trying to say is that they are unavoidable.

Let me focus in development, as is the one community that I am most interested in. In the general online developers community, there are some biases that I think are quite strong, and probably not perceived from leaders and participants (after all, it mostly resembles them).

The community is young. This is clearer in the participants group than in the leaders one, after all, wisdom and insight are a good qualities for being a leader, and those comes mostly with age. With youth comes new views to change the world, but also naïveté and inexperience.

It is driven mostly by Americans (and foreigners living in the US, to a certain degree), not only by the strong position US has in tech, but also because the online lingua franca is currently English. In particular, it is very centred into Silicon Valley because is where the most discussion-driven companies of the world are based. Both well established companies and start-ups.

The most talked technologies are web tech (both front-end and back-end), with mobile apps in a second place. There is comparatively few discussion about desktop applications (which are the basis of everyday work), and even less on areas like embedded systems or commerce backends (including banks).

All those biases (there are more, of course, but just to limit to these three) work together in ways that some times are curious. Like assuming that most people are able to earn a Silicon-Valley-level salary, or that access to a computer (or even worse, Internet) in your teens is granted. Also, grammar errors are unforgivable mistakes a lot of times that should be pointed (and forget about things like transcript conference talks). Products are only relevant when they’re launched in the US, and everyone went to an american High School (which, as depicted on media and comments seems to be the Worst.Place.Ever.). That hardware come, out of the blue, from time to time, so we can run software faster. Of course, I’m exaggerating, but not by much.

I may have a biased idea on how US High School is.

I may have a biased idea on how US High School is.

I don’t know, from my point of view, given that I don’t share a lot of those biases (I can’t honestly consider myself “young” anymore, I am a Spaniard living in Ireland, and I spent half of my career working on non web technologies[2]), sometimes I get baffled by online discussion, especially the ones that talk about the community (as opposed to the tech, which is a different issue). My main concern with all the system is that everyone (participants and consumers in particular) will assume that every single issue raised by leaders can be translated directly into the general community.

Just to show an example, there is a lot of discussion about what makes a great developer and the proper strategies to hire them. Some ideas that could work for hiring a young front-end developer in San Francisco may not work as well on other places, for different technologies. There is always discussion about being a founder in different countries, and, as you can imagine, the experiences are quite different. Different legal system, different business cultures, etc…

Being in contact with communities where you’re talking to what in many aspects are your peers is absolutely fantastic, You can relate to them in a lot of things. That’s why you’re part of the community. Heck, I learn a lot everyday. But we also need to take some distance some times, be a little critic on some subjects and try to adapt what we learn to our particularities. Because  chances are you’re  biased in a different way than the leaders and participants of the community.

1.I don’t like the microtransactions thing, but I just think that there is a business case for it.

2. Embedded software related to satellites and industrial control systems.

Some characteristics of the best developers I worked with


I had a conversation last November on the PyConEs, when I was on a conversation stating that I am working with truly brilliant people in DemonWare, and then someone asked me: “Do you have problems agreeing in  what to do? Normally great developers have problems reaching consensus on tech discussions”. My answer something like: “Well, in my experience, truly awesome developers know when to have a strong argument and they usually are ok reaching an agreement in a reasonable time”.

So, I wanted to, as sort of follow-up, summarise what are the characteristics that I’ve seen in the best developers I’ve been lucky to work with. This is not a list I am making on “what’s my ideal developer”, but more a reflexion on the common traits I’ve seen on my experience…

    • Awesome developers are obviously smart, but that’s not typically shown as bursts of brilliance, solving really difficult issues with “aha!” moments. In my experience, genius ideas are rarely required nor expressed (though they surely happen once in a blue moon). Instead, great developers are consistently smart. They present solutions to problems that are reasonable all the time. They find and fix typical bugs with ease. They struggle with very difficult problems, but are able to deal with them. They are able to quickly present something that will make you say “Actually that’s a nice point. Why didn’t I think about this?”. They do not typically present something ingenious and never heard of, but deliver perfectly fine working ideas over and over, one day after another.  Their code is not full of mind blowing concepts, but it is logical, clean and easy to follow most the time (and when’s not, there is a good reason). They are able to remove complexity and simplify stuff, to a degree that it almost look easy (but it’s not)
Normally brilliant people on real life do not come with crazy great ideas out of nowhere

Brilliant people on real life do not come with insanely great ideas out of nowhere

  • They keep a lot of relevant information on their minds. They are able to relate something that is in discussion with something that happened three months ago. They seem to have the extraordinary ability of getting out of the hat some weird knowledge that is applicable to the current problem.
  • While they have a passion for coding, it is not the only thing in their lives. They have hobbies and interests, and they don’t usually go home in the weekends to keep working on open source all day, though they may occasionally do.
  • They love to do things “the right way”, but even more than that, they love to make things work. This means that they will use tools they consider inferior to achieve something if it’s the best/most convenient way. They’ll complain and will try to change it, but deliver will be more important that being right. They have strong opinions about what language/framework/way of doing stuff is best, being that Python, Ruby, Haskell, PostgreSQL, Riak or COBOL, but that won’t stop them knowing when it’s important to just stop arguing and do it.
  • They are humble. They are confident most of the times, but far from arrogant. My impression is that they don’t think that they are as awesome as they truly are. They will want to learn from everyone else, and ask when they have questions. They will also catch new ideas very fast. They are also friendly and nice.
  • Communication is among their best skills. They are very good communications, especially, but not limited, about tech issues. They may be a little social awkward sometimes (though this is not as common as stereotypes portrait), but when they have the motivation to express some idea, they’ll do it very clearly.
  • In some of the truly remarkable cases, they’ll be able to fulfil different roles, when needed. I mean different roles in the most broad sense, basically being able to be what’s needed for that particular moment. Sometimes they’ll have to be leaders, sometimes they’ll be ok being led. They’ll know when a joke is the proper thing to do and when to remain formal. They’ll be the person that helps you with a difficult technical question, or the one that will tell you “you’re tired, just go home and tomorrow it will be another day”
  • And they’ll have a great sense of humour. I know that almost everyone thinks that they have a good sense of humour. That’s not totally true.

Again, this is sort of a personal collection of traits based in my experience and on what I consider the best developers I’ve been honoured to work with. Any ideas?

Agile important bits


There is a lot of Agile talking and I think it has reached a point where it is, if not standard, at least a common way of doing software. But, even if there is a lot talking about Agile methodologies, and companies telling that the are doing Agile, are they really doing it? I’m not so sure. When relating to Agile, I always come back to the source, which is the Agile manifesto. I really like its simplicity. Let me copy it here

We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The first time I read it, I must say I wasn’t impressed. Yeah, sure… Great values, dude. But after spending more time, I come to see that as a really good set of values that, in mi opinion, work really well for software development. In practice, I think there are some of those values that are somehow “forgotten” over the day to day operations. I’ve been thinking about what are the ideas that, again in my opinion, are the ones I consider the best way of implementing those values. Consider them my personal “Agile highlighted parts”

Never-ending learn

Well, maybe not in 21 days, but that's the spirit...

Well, maybe not in 21 days, but that’s the spirit…

In my opinion, the single word that is capital in software development is “LEARN”. The same thing applies to Agile. Agile is about being constantly learning. Change (which is also a very important word) is just a consequence of this learning process, the outcome. Because we learn how to do things better, we change our way to work. Because we truly understand the problems of the customer, we can develop what the customer needs (which may not be what the customer has in mind in the first place). This learning process should not view restricted to the developers. It is also applicable to the rest of the people involved, including the customer. If the customer is not willing to learn in the process and refuses to accept feedback, then the process is much more difficult. That could be the single most important risk in Agile, as that will make the collaboration difficult and adds a lot of friction. Even in products aimed for mass consumption, this process can be present one way or another. For example, recently there has been a lot of discussion about iOS 7, and how consumers have learned how to use a touch screen and elements that were present on previous versions to help usage are no longer needed as average consumer know now what it is about. Refusal of learning can also be a problem in Agile. There are people that do not like the constant effort and the change in mindset that it implies.

Team centric view.

The team in Agile is king. When I say “a team” I am not referring to a list of people put together on the same building working on the same product. A team is much more than that. It is people working towards the same goal, but also effectively working close together and helping each other. Just as a soccer team needs players with different abilities, so does software teams. The people working on the same product will have to be, with high probability, multidisciplinary. That has not been usually the case on software companies, where you have the testing department in one side, the design department in another, and the R&D department detached from the rest of teams, communicating through big documents and formal meetings. That creates the need of strict interfaces, and negotiation between the parts to agree how to exchange information.

Some development talk is full of wibbly-wobbly... timey-wimey... stuff

Most development talk is full of wibbly-wobbly… timey-wimey… stuff

Instead, a team will try to learn and improve how to work and exchange information. Asking constantly, “how can I make the work of X easier?”. To be able to do that, you have to know and understand what are the problems that X will face, and the only way of knowing that is to work closely with them. That is more difficult that it looks. We developers are usually very “machine centric”, tending to try to fix everything with a script, or adding a new feature that complicates the system. It is not simple to learn about how and why other “non-techies” people (sales, designers, etc) are doing the things they are doing the way they are doing them. We prefer to keep running out scripts and our UNIX commands. We talk our techie talk of threads, classes, recursion and functional programming. But the learning of the”domain knowledge” is really what makes the difference between a good team and a great one. And that knowledge can only be achieved constantly learning from one another. Both the developers understanding the real problems of the customer, but also, in some cases, the customer understanding how the team works and what is possible on a certain amount of time. Creating a good team is very important and challenging. But also accepting that it is formed by different individuals, with different capabilities, strong and weak points, is probably one of the most difficult parts in any organisation. I always think that the most challenging task is to deal with people, which, no matter how “good cultural fit” is achieved, will be individuals different from any other one. Acknowledging it and being able to make everyone on the same page is difficult, but capital for highly successful teams.

Interact in a constant, but structured fashion

While interaction is really important, some balance need to be achieved with interrupting ongoing work. Agile is not about “hey, we can change all at any point”. I know, the name is a little misleading. It about knowing that you are going to change stuff, and deciding what at certain points. One of the details that I found out more efficient in that are sprints and stand up meetings. Both are tools to structure the conversation while providing constant feedback.

Stand up meetings

Doing stand up meetings in the best way is more difficult that it looks. It needs to be kept very simple, fast, and with as little noise as possible. Basically each participant need to say, keeping it simple: What did I do yesterday? What I am going to do today? Are there any problems in the way? And listen carefully to the rest of the people to be aware of the work being done on the team, and to see if you can give support to anyone (during the meeting or later, if more than a few minutes are necessary). Being actually standing up and in a different room helps, as you tend to keep things up to the point, eliminating distractions. One interesting part is not the meeting itself, but the time that previously is used to structure your mind into what you’re going to say. That helps a lot in planning and in keeping you focused, as everyday you’ll have to explain what have you done. Focus is paramount in software development. Another important thing is to keep that as a strong habit. There are always moments when it looks like no one is saying something new, and it feel as redundant. If the meeting is all about the same things for a long time, then is clearly a problem (your tasks are not as small as they should). But the benefits in terms of constant feedback and focus are not achieved until some time. I also think that managers/product owners should be present on the meeting, and probably participate actively. Remember, it is part of the learning process and it’s a very good opportunity to show how the team is working and what are the management tasks. A proper star up meeting reduces the need to interrupt the work of the day with typical “what are you working on?” questions, and detects very fast problems and blockers. It structures communication to channel it.

Sprints

Well, it does not scream "sustainable pace", but still...

Well, it does not scream “sustainable pace”, but still…

While the standup meetings structures the communication between the team, Sprints structure the communication between the team and “the external world”. The idea of the sprint is to produce something that can be shown, and ideally works, even if it’s small and not complete. That gives feedback and then the goal for the next sprint can be decided. While having a simple objective for a sprint can be good, I don’t think is necessary. A simple grouping of tasks with no particular meaning together may well be the objective. I don’t like the word “Sprint”. I think is not fortunate, as it will not give the idea a long term race, but a strong burst in effort. Software projects are long, and teams should find a comfortable development speed, or the quality of the result will suffer. I’d prefer something like “stage” (using bicycle race metaphor), because the main idea is that they should have a sustainable pace. The sprint objective is not a contract signed by blood of your firstborn. It is a reasonable objective that the team honestly thinks can be achieved.  Let me get back to  couple of ideas there. What can be achieved on a sprint is something that can only be decided by the team. They are the only ones with the knowledge of what is possible and what is not. Estimations are that, assumptions. A typical problem in software development is unrealistic deadlines by management, that will be used as weapons against the developers, and the natural response from developers is to produce “safe” estimations, much bigger that they should, so they can be protected. This is not a good thing, and it is a reflection of distrust. The way to overcome that is to treat estimations as that, and try to improve them, without punishment for  mistakes. Let me rephrase it: Estimations will be wrong. Often. The objective should be to improve them, and to not be wrong by a huge margin. Dividing work in small tasks will help, but that’s an inherent problem.

Make it work

I consider myself a pragmatist. At the end, everything should be done not for the sake of it, but because it helps towards an end. As with a lot of good ideas, people has fallen too often in “Agile cargo cult”, just following processes without thinking why, or without analysing who are the people on charge of doing it. Again, analysing and learning what’s going on is important, to enable the best concepts applied to a particular team.

In defense of resting


I have been watching recently some documentaries about software development, including the classic Triumph of the nerds (available in YouTube in three episodes, 1, 2 and 3) and Indie Game: The Movie. They are both very good  and I’d recommend them not only to developers, but to people interested in technology and/or entrepreneurship in general.

But they are very good exponents into something very present on the software scene, which is presenting crunch mode, working insane hours, in some sort of glamourised way. It is part of the usual storytelling and, and probably, part of the hard work -> ??? -> profit logic.

Let me told you something. When I was starting my career, on my first long term job, we once had a very strong deadline. This made us work in crunch mode for a long time (around 2 months). That meant working around 12 hours or more per day, 6-7 days a week. The very last day (a Sunday), I started working at 9:00 AM and went home the Monday at 6:00 PM, only stopping for eating something quick and going to the toilet. The rest of the team did similarly.

Continue reading

Magical thinking in Software Development


I guess we all Python developers heard this kind of argument from time to time:

Python is slower than C++/Java/C# because is not compiled.

Other than the usual “blame the others” when working with other companies (usually big corporations than thinks than using anything except C# or Java is laughable), you can also see a lot of comments in technical blogs or places like Hacker News or Reddit with similar, simplistic arguments. You can recognise them on the usual rants about how technology X is The Worst Thing That Ever Happened™ and Should Never Be Used™

That’s a form of Software Development Magical Thinking. This can be really harmful for software development, specially when the opposite, positive form is used. Let me define Software Development Magical Thinking in this context:

Software Development Magical Thinking noun Assuming that a technology will magically avoid a complex problem just by itself.

Probably that will become clearer after a couple of examples:

Java is a static type language and it is safer than dynamic type languages like Ruby.

We program in C++ so our code is very fast.

MongoDB / NodeJS / Riak is web-scale.

Please note that those are not completely, utterly wrong statements. C++ can be very fast. Static typed languages can avoid some bugs related with input parameters type. But there is no guarantee that creating a system in C++ is going to act like a magic wand against slow code. Or that Erlang will avoid having a single point of failure. And you’ll get as sick of bugs and security issues both on static type language and dynamic type languages. *

Those are all complex problems that need careful design and possibly measurements to deal with them. Deep analysis of the problem, which usually is more complicated that looks on the first place. Or even worst, the problem is not as bad as it looked and the designed system is more complex that it should, trying to catch a problem that never arises. Not to exclude having previous experience to avoid subtle errors.

Let me say it again. There are problems that are HARD. In software systems they are confronted almost daily. And no single thing will make you forget them. Even if you use a very good tool for what you’re doing (like Erlang for concurrency), which usually implies paying a price (in development time, etc), doesn’t replace vigilance and issues could eventually appear. Unfortunately, making software is tough.

The problem with Software Development Magical Thinking is that it is very easy and it is also very natural. Seductive. We know that “general Magical Thinking”, simple solutions to very complex problems, is quite common. Hey, a lot of times, it even seems to work, because the Feared Problem will only present after certain size that is never attained, or after the designer leave the company and left a latent problem behind. Most of the time, making a totally informed decision is unrealistic, or simply not possible, and some risks must be taken.

But as software developers we should know that things are not that easy, even if we have to compromise. Each bug that takes time methodically eliminating causes. Every measurement that makes you wonder what is the best metric to reflect a value. Every time you realise that there was a back-of-the-envelope calculation that shows something that will have an impact on some design aspects. Those are all reminders that should makes us think that there are no silver bullets and we shouldn’t take lightly all those difficult problems.

Make decisions. Design systems. Choose a tool over others. Take risks. But don’t be delusional and careless. Be conscious that software can bite you back. Be vigilant. Be skeptic. Avoid Magical Thinking.

PD: And please, don’t say “Python is slow”. Just don’t. It is not for most of the jobs. It is not going to make you win a discussion unless you carefully measure and proof it. And, perhaps most importantly, raises my urge to kill.

* No, I am not going to comment anything the Mythical Web Scale property.

EDIT: Wow, it has been submitted to Hacker News here. Just in case any one whats to add to the discussion there.