The Ringelmann Effect (a.k.a. social loafing) is basically about people experiencing decreasing productivity when working in groups. We're basically more productive when we work individually to achieve personal goals rather than being teamed up. That was discovered by Prof. Max Ringelmann a hundred years ago in 1913. Today, during my workshop in Berlin at DATFlock 2015, we tried to reproduce that experiment. It seems the French professor was right.
JSON or XML? Which one is better? Which one is faster? Which one should I use in my next project? Stop it! These things are not comparable. It's similar to comparing a bicycle and an AMG S65. Seriously, which one is better? They both can take you from home to the office, right? In some cases, a bicycle will do it better. But does that mean they can be compared to each other? The same applies here with JSON and XML. They are very different things with their own areas of applicability.
There is a great book called Software Requirements written by Karl Wiegers about, well, software requirements. It's a must read for every software engineer, in my opinion. There's no need for me to repeat what it says, but there are a few very simple and very typical mistakes we keep making in our specs. I see them in our documents again and again, which is why I've decided to summarize them. So here they are, the ten most critical and typical of them, from the point of view of a programmer reading a specification document.
A chatbot (or chatterbot, as Wikipedia says) is a piece of software that talks to you in chat format. We use chatbots in a few (micro)services, and they fully replace user interfaces. I don't think there is any innovation in this approach, but it has proved to be very effective over the last year or so. That's the impetus for this post. Here is how the Rultor chatbot works for us and what its benefits are.
I want to create an iPhone app for my web service, but I don't have programmers. Well, I don't have iOS programmers. And I don't have money. Sound familiar? What do I do? Right, I go to GoogleUpwork and find an awesome company in Bangalore that is excited to work with me for nothing reasonable money. In a few months and after a few thousand dollars, I realize this is not exactly what I expected. After yet another few months, I swear to God I'll never outsource any software development to anyone. Is it just me? Not really.
InterruptedException is a permanent source of pain in Java, for junior developers especially. But it shouldn't be. It's a rather simple and easy-to-understand idea. Let me try to describe and simplify it.
I saw The Martian this weekend, and it triggered a few thoughts. Of course, I didn't like the movie as a piece of art. It is total garbage, but this is not my point. There is something bigger to discuss, aside from the bad acting, primitive story-line, politically correct but absolutely unrealistic casting, and tons of logical inconsistencies. It's Hollywood; what should I expect, right? Not just that. I think the problem is bigger.
When your team has to choose which technical decision to make, who has the final say? When one of your colleagues asks for a raise, who decides, and what is his or her decision based on? When it's necessary to work overtime, how is it decided who will stay in the office? I'm expecting you to shrug your shoulders. You're right, these questions never have explicit answers in modern organizations. We are used to working in a more "democratic" way, where such decisions are made subjectively by managers or more senior employees. Is this how it should be?
This is a short manual for you, my friend. I assume you are sitting in the office right now, reading this blog post. Maybe you don't like your office job, or maybe you enjoy it and feel excited to be close to your office friends. It doesn't matter. What matters is that there is always an alternative to office slavery. I'm not talking about starting your own business. There are people in this world who work for someone without doing what is described below. They do exist, as well as companies that don't turn their employees into slaves. I really hope you will eventually find one. In the meantime, this manual is for you :)