Internationalization and Connection
Published on
A few years ago I came across a text by Gabs Ferreira talking about the need for content production in Portuguese, not only in the IT area, but especially in it.
(go read the whole thing. It’s a good text)
I know I’m not a big content producer, a famous blogger, or a relevant figure in any way in the community, but that post resonated with me. While one of the goals of maintaining a blog in English is to keep the language sharp and actually learn to build ideas directly in another language, how much do I limit the reach of ideas (which are the main objective of this “communication” thing) by making the decision to ONLY write in English?
Sometimes I miss the adrenaline of decompiling a jar file (because the source was lost ages ago), adding a feature and putting it back in production. But, believe me, those days sucked.
In the bad old days, people pushed to production without any kind of automated testing. We would just build the features needed, tested locally and copied the files manually to a server, usually after midnight, accompained by pizzas and fear.
After many years working in your system, building, tinkering, improving, breaking and reassembling, you decide that what is really needed is a full software rewrite. After all, what can go wrong?
If you were ever involved in a full rewrite project, you know the answer. Absolutely everything can go wrong.
Why you think you want it There’s plenty of reasons for developers to advocate for a full software rewrite, but the most common is the software complexity and cost of maintenance.
Let’s get more technical. ‘Know your Language’ is a new category in my blog, about Programming Languages and their most common problems in enterprise environments
According to Tiobe Java is the most used backend programming language of the world. According to StackOverflow, this title goes to Javascript, but Java gets third place. Java and the JVM are also almost omnipresent in mobile, with Android using it as a platform.
There are hundreds of interview techniques, thousand of tools, each with a corresponding required knowledge to work with, countless “classic” algorithms and a myriad of different types of projects to try to evaluate a Software Developer. Yet, it is not easy to, nor formally or mathematically, separate a good Developer from a bad one. Why?
As always, there’s no easy answer to this question. The main reason for this is, perhaps, that we don’t know what a Software Developer actually does.