The popular story says that when you throw a frog into a pot of boiling water it will panic and jump out. Put it in lukewarm water however, and then start heating it up, and the frog won’t notice the danger and will happily boil itself to death. Well, it’s not really true (as we learned at the introduction speech), but it’s a great analogy that we can apply to our work. A developer who doesn’t care to spend time on self-development, catch up with the new trends, and follow changes in the industry, will slowly fall behind. In a few years he will find himself in a position where he can’t understand or create anything new. On the other hand, a guy spending his life chasing the newest trends, and constantly picking the trendiest technologies may not notice that he’s no longer providing any real value to the client. He may think he’s very busy refactoring the code again and again, but he doesn’t really produce anything and is therefore slowly boiling his client and himself.
That’s why last weekend we went to the conference taking place at Wrocław’s Centennial Hall, with the aim to listen to the great speakers and do some networking. Here are some things that we’ve learned that will save you from getting boiled ;).
Uncle Bob says that there is a new Moore’s law of our times. Every 5 years the number of the developers in the World doubles. That means that at any given point in time there are 50% of programmers that have less than 5 years of experience. And the rest has to work with them everyday ;). It lays in both sides’ interest, that the new half gets educated as fast and well as possible. So if you’re new in the industry – learn fast from your older peers. If you’re a veteran, train the new recruits.
And do it multiple times. Michał suggested at his great talk that about 5 times is enough [Michał Płachta – Deweloper na detoksie]. What it means, is that it’s okay to trust your intuition when you’re making a business or a technological decision, but always admit to yourself and the others that it IS just an intuition. Never say “it’s the best practice” or “that’s how it’s usually done”. You probably don’t really know that. Instead, be like a curious kid and keep asking yourself “why”. This way you will actually get to the root of the problem, and won’t create a fake sense of comfort.
Don’t punch your colleague at the next daily, that’s not what we mean, but we’ve learned and strongly agree that “meetings are boring because we don’t argue”. [Anita Przybył – Napraw swój zespół]. It’s super important that everybody taking part in a project cares about it. It includes client, project manager, programmers, testers and even this admin guy that sometimes leaves his basement for the meeting. You can only achieve great results if you want to achieve them, and that only happens if you feel responsible for all the decisions made in the project. And you will only feel responsible for them if you try to push your own ideas and debate loudly, not just wait for the meeting to end, so you can go eat lunch.
Ok, this one won’t boil you slowly. It will burn you pretty quickly. One of the presentations was pretty funny, but terrifying at the same time [Michał Pipa – Data i czas dla programistów]. We all know that year has 365 days. Until it doesn’t. Because it’s a leap year (and it doesn’t happen every 4 years as most people think, but the year has to be divisible by 4 but not 100, OR divisible by 400). Some of us know that a minute doesn’t always last 60 seconds, because we sometimes insert a leap second to adjust for Earth’s rotation speed constantly changing. Very few people know that some countries have their timezone shifted from UTC by half an hour or 45 minutes. And that daylight saving time in Morocco is suspended for the time of Ramadan. That’s just the tip of the iceberg, so watch out when you deal with time in your program the next time.
Wojciech Gawron showed us during his talk [Functional programming in the wild] how they develop and maintain a big application written in Erlang at Appliscale. Erlang is really different from what most programmers are used to. It’s a fully functional language which uses concurrency model based on actors. Thanks to using this technology, the company is able to maintain a gigantic application with millions of users with only a dozen of developers. Bugs are scarce and performance is amazing. We know it well, as in NetworkedAssets we’re using the same concepts, only transferred to the Java world in the form of Scala + Akka.