If you are not having fun doing your work, it could be one or more of the following (Ordered):
Get knowledge and learn from anyone, that's great, but be sure to take advice from only the people who practiced and/or witnessed situations relevant to your context. An advice from the wrong person may cost your goals.
Doing things for fun, and being highly paid for that, is one of the most blessing gifts in life. Don’t just work, have fun doing your work.
People don't like to read documentation, but they really enjoy read stories.
I believe that the best developers write code that is really enjoyable to be read by other fellow developers, they write it as stories.
Be student all the time, no matter what expertise you have or degrees you gained, this will make you a better person by being more knowledgeable, more valuable, and most importantly, more humble.
Being busy all the time is not a cool thing, and doesn't reflect how important is the person; in fact, it could be a critical sign that shows
issues in time and resources management.
Most of the successful people I know have a plenty of time to do a plenty of things without affecting their productivity.
Focus on results, not processes, be Result-Oriented.
I have been thinking a while for the true definition of “Expert”.
According to Cambridge dictionary: “Having or showing a LOT of knowledge or skill” However, "a lot" is relative, so I was looking for a criteria that could measure that, and I have concluded the following list that could be part of it :
Your employees are the most important factor in your business success, you should give them respect, coaching, support, and good pay (as much
as you can afford).
Without doing that, eventually you are out of business.
Before judging if a technology is old, ask yourself these questions:
Last week, I shared a question with my connections, if creativity could be taught? I face this question every day, with my students, my
employees, and my customers.
The responses to my question varied between, Yes, No, and something in the middle.
My personal opinion is:
if you get 4 years old children, and put them in a place with anything (papers, sand, water, tissues, .. ), they will start creating cool stuff in a very creative and innovative way, simply because we are all gifted with Creativity and Innovation in our DNA.
However, this gift will be either Enhanced or Constrained by the ecosystem surrounding us (home, school, culture, and environment), the thing that will affect our capabilities for ever.
So, back to the original question, can creativity be taught? The same question could be reflected on other questions: Can Intelligence be taught? Positivity ? Persistence ? and Consistency ?
In my personal opinion, the answer to all the above questions is: Yes. But, if it could be taught, why companies do not do it? Why big companies always pick innovative, creative, smart, and hardworker people?
The ultimate answer is: Because its Expensive and Risky process on the business.
Since 2005 until 2019, my network grew to around 5000 connections, from different domains, regions, and cultures.
The thing that turned my LinkedIn newsfeed to something that is irrelevant to my interests, in addition of showing personal news for people who I don’t know; also, it had a lot of dead connections of my friends’ old profiles.
So, in 2019, I decided to rebuild my network from scratch, so I removed all the old connections, and started to build my network.
Since that time, I have started to see relevant contents to my interests again, in addition to the news of my friends.
Everything requires refreshment from time to time, even your social media network.
In CICD, here are the Continuous Delivery pipeline options in real-life implementations:
If you keep running away from your technical issues, they will keep chasing you, and they will wait until you go live, then they will take you down; don’t wait until that moment.
Your code should be a story that is enjoyed to be read by your fellow developers.
During my professional career, I have witnessed, worked, and applied different management styles: the American style, the English style, and
the Centralized style.
In my opinion:
I always believed that my top three reasons of my passion of the software development are: Java, Object Oriented Programming, and UML. With this wonderful combination, sky is the limit in Software Engineering Reusability.
If you have all the available academic degrees, professional certificates, and/or many years of experience, good for you. But what really matters, that how you can utilize all these qualifications to deliver high-quality software systems that provides the values promised to internal or external customers.
I have been building end-to-end software applications for almost two decades now (almost daily), and I doubt that any software/system
architect could be able to make a good architectural decision without having a continuous hands-on experience on the various technologies and
Without having such experience, an architect wouldn’t be able to understand the pains and gains that could face the technical team, which may lead to projects/products failures, caused by the gap between the theoretical architecture and the practical implementation.
In the software development industry, adopting new technologies and trends without having a clear justification to solve current problems or reducing cost (time and resources), will most likely increase the overall overhead of software development projects and will definitely create a new level of challenges.
Trust me, most of the many successful people you have met in your life, had negative attitude and bad habits at some points in their lives, but because they are open-mind enough, they have been able to improve their personality and attitude and become what they are today. During my professional life, I have gotten the chance to work-with, interview, and hire hundreds of engineers in the software development industry. In the beginning, we were looking for people with good skillset. Then we started to look for positive energy and good attitude. But now, after almost 20 years, I would look for two main things: (1) being open-minded, and (2) passion of learning. Open-minded enough to improve in all aspects, such as starting to carry a notebook and pen to write all the notes, to focus on quality, deliver all your personal and professional tasks on time with minimum following up, and receive any criticism from your colleagues, customers, and stakeholders as hints to improve your tasks, and maybe improving some aspects of your personality. Being open-minded is a great gift, if you don’t have, start working on it
The secret is always in SIMPLICITY.
In the current trends of digital transformation and agility, it is all about what is "Enough" to proceed to the next step/action/phase, not what is "Complete". This includes: 1- Enough Features 2- Enough Design and Architecture 3- Enough Documentation 4- Enough Testing 4- Enough Security 5- and Enough Infrastructure However, the main challenge here, is defining "Enough", which could be part of the process itself.
Saying that your organization is Agile is not enough to be Agile, it has to apply Agile principals and practices in the right contexts to be so.
What if the distance in the picture is only 10 meters and this is a one lifetime task, would you invest in shaping the box to be faster!! In fact, trying to work smarter in this case makes it harder. The full advice should be: “Be smart on when to work smarter not harder”.
When you like or hate the organization your work for, think twice, because most likely you like or hate your direct manger, not the organization it self.
Last week, I asked one of the best managers I have ever knew: How do you deal with the employees who objects most of the time on the work process? His answer was: First, you need to know why he/she objects, is it because of his/her leadership skills and good ideas to implement, or to cover his/her weaknesses. If it is because of the first reason, then most likely, putting this person in the right place, could make a good difference for the person and the organization. But if it is because of the other reason, then I think you all know the answer.
Agility doesn't mean rushing things out, it means deliver values faster.
Working with smart-people is one of the priceless gifts in life, if you have it, enjoy it.
In Software Architecture, complexity doesn’t vanish, it could be only transformed from shape to another.
If you struggle with the technology, and you try to make it work, DON’T, it is the wrong technology for your team. And if you struggle with the process, and you try to make it work, DON’T, it is the wrong process for your culture.
Agile is not the Agile you think? When management or business people say Agile, they mean to be responsive faster to market as a part of their digital transformation move. On the other hand, When IT people say Agile, they mean implementing an Agile process in their software development, such as: XP, Scrum, or SAFe. So be sure to understand the context first before discussing Agility!
Again guys, the most important (and maybe the only) measure that can tell whether a software architecture is a monolithic or micro-services
based, is how it is deployed, not structured, period.
If you structured your application into a modular approach (as components or web-services), congratulations, that might make it cleaner, but if you still deploy once, it is a monolithic.
In this era of technology disruption, if an enterprise wants to stay in the market, it should know and respond to customer-needs quickly (Digital Transformation ) , and to do that, it should deliver values faster (Agile Culture) , and to deliver faster, it needs a new approach (Agile Process) and ownership (DevOps). Faster delivery and ownership requires teams parallelization and resources isolation (Microservices). Taking one part of all of the above is like buying car-wheels only (One Component), and not a full car (the Whole System) and expecting that you could reach your destination faster.
The traditional process of planning software delivery is:
1- Customers request vendors to deliver in 1-3 months claiming that business/operations will struggle if they didn't operate in this period.
2- Vendor commit to deliver in this period assuming that they will lose the contract if they didn't do that.
3- Management will push project managers to avoid penalties, project managers will push technical leads, technical leads will push the technical team to deliver.
At the end of the day, the project is delivered in 6-18 months, everybody is happy , and a new project is started.
Note: the funny thing that: customers, vendors, management, project managers, and technical leads are most likely aware of the actual delivery time from the beginning, but they like to have some action :)
Is open-source technologies and systems are less secure than closed-source? One of the worldwide trends in technology nowadays is to use open-source software technologies and systems (OSS). This trend is adopted because of many reasons, including: (i) cost reduction, (ii) maturity, (iii) and learning resources. However, the main criticism of OSS is security, but is it really justified? A research paper published by IBM in 2005 , shows that open source projects are not less secured than closed source projects, in fact, sometimes it can be better. For instance, the most secured operating systems on earth are Unix-based systems, which either open source (such as RedHat, Sun-Solaris, and Ubuntu) or use open-source kernels (such as IBM AIX and HP-UX). Another example is the hypervisor software used by Amazon for their cloud services virtualization, where they used to use Xen, and now moved to KVM, whichboth are open source (full story can be found at ). So, is it really less secure!!!