One dream many of us share, is to get the chance to work for Good. To have a meaning behind what we do. To feel we are contributing to making the world a better place.
I had that chance when I operated as a GDPR auditor for one year, here is my story.
Let’s agree from the start, the road to be a good software engineer never ends, it is a continuous learning process for various reasons.
What are those reasons? What should one do to enhance his skill level and then keep it high enough?
Many questions that I, you should think about.
First things first, the passion. The fuel for achieving great things in life is to have passion and love for what we do.
A couple of years ago, I was thinking about learning a new concept in a field that I have no real experience in.
I started a Machine learning course. During my learning journey, the idea of getting a certification for “validating” what I was acquiring was tempting me. But in the end, I was still skeptical regarding the certification system.
Let’s think about it, together …
I have acquired some certifications in the old days, mainly professional-level IT certifications. I can tell you that it required dedication and hard work, even for the ones that were in my ‘comfort zone’…
During the covid-19 pandemic, my favorite sport started living a crisis. I decided to dedicate this article to Football aka Soccer for some of us.
I try to follow the lives/replays as much as possible, and I am always mesmerized by some of the reports I see on sports TV channels.
So here I am, sharing with you my passion for Football and Technology.
As I mentioned earlier, beautiful reporting in sports channels is one of the candidates for consuming data ‘big time’.
To have added value and captivate the attention of the viewers, the media uses statistics in commentaries…
When we talk about technical debt, we use an analogy with the world of finance to designate the weight that a project or a software product drags during its lifetime. This debt is often known or at least simple to detect, but there is another type of debt called “Dark debt” which is more complex and undetectable by the various techniques of code analysis. That is the dark side of the technical debt.
The term “technical debt” was mentioned by Ward Cunningham (known for the concept of wiki) during the 1992 OOPSLA “Object-Oriented Programming, Systems, and Languages & Applications” conference.
In a number of situations, many developers mix-up the terms “design pattern” and “architecture”.
It is true that they share the “pattern” aspect, as a way of thinking and designing software and to be clearer by the way, we should say “software architecture patterns” and “software design patterns”.
They also have in common the definitive product which is the information system or at least a part of it.
But the differences are fundamental at many levels, that is what we will see together in this article.
The most commonly known fact about design patterns is that they are Object oriented…
One day, I was having a discussion about safety in the software development cycle of our project with a colleague. Then I remembered a subject I worked on in the old days, which was really interesting for me. As I am a huge mathematics fan, I remembered it very well, it was about creating a predicate evaluator for a tool used in the B-method.
Then, to B or not to B ? Let’s dive into the B-method, together.
The B-method, is not about extracting nectar from flowers for making honey. It is rather: