Last week, I wrote about how the way I perceived developers radically improved for the better during the past few years. This was partly due to a better understand of the law of supply and demand, showing that the value on anything on the market is based on the power balance between what’s needed and what’s provided. In other words, the more I need you (your service or your product), the more you can charge for it, and vice-versa. Today, I want to discuss my current perspective on the way developers are recruited, based on my experience. And as you’ll see, the law of supply and demand will again play a big part.
Continue reading “Beware of companies hiring too easily”
Last week, I shared how I reached a very low view of software development (and thus developers) even though I studied computer science at university. I ended my post saying that things started to change when I saw how some of my friends who were passionate about development got great jobs at prestigious companies, with amazing salaries and work conditions.
In this post, I want to share how my perception of software switched from being a commodity to being one of the most valuable assets for today’s companies, and then how this new perception started influencing my career decisions.
Continue reading “The value of (good) developers”
Last week, I shared how I ended up in a management role after studying computer science at university. This was mainly due to my perception of development and developers. My goal for this article is to explain why this was the case.
Continue reading “Why I perceived code as being a commodity”
After my introductory article, some readers told me that the reasons behind my transition from a management-related job to a development job were not clear. But before explaining why I transitioned, you need to understand how I ended up in a management position after my Master’s degree in software engineering.
Continue reading “Why did I work in management in the first place?”
As I’ve explained in my introductory post, I’m going to blog mainly on the topic of clean coding practices.
Now, you may be wondering what is meant by “clean code”. What exactly does it mean for code to be “clean”?
Well, the answer is tricky. It’s as if you were to ask an architect what makes an architecture “good”. I guess that if we were to ask the top 20 architects in the world to answer the question: “What is good architecture?”, we’d pretty much get 20 different answers.
However, by listening to their answers, we may start to get a feel as to what the important criteria are, and also find recurrent and common themes emerging.
In the classic book on the subject I’m currently reading called Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin (called “Uncle Bob” in the industry), the author shares the answer to the question: “What is clean code?” by five of the most respected software engineers in the industry.
To help you get a feel for what clean code is, I’ve reproduced their answers below.
Continue reading “So… what is clean code? Let’s ask some giants!”