Hello Reader,

We all hear this - "do more hands on, do more hands on". But how much hands-on is needed? Let's dissect this, and I will also share the way I do hands-on.

What is hands-on used for?

• Understanding concepts - Hands-on definitely helps clarify certain things. Not every nuance is spelled out when you are reading a blog or watching a video. While actually implementing it, those areas become clear. It also helps you memorize the topic better, inspiring you to delve deeper into the subject.
• Helps showcase work—Whether you are working on a project or looking for a job, documenting the hands-on experience gives you extra credibility. When you show a demo at work, you garner more respect from peers and managers. Similarly, you get increased recruiter attention if you have a hands-on project documented in GitHub and LinkedIn.

However, on the flip side, what are some challenges of hands-on:

• Time-consuming - Rarely, any hands-on goes smoothly. If you are studying DevOps, Kubernetes, or Gen AI, you know that there is a high chance some commands will not work. Often, there are many variables - version of the OS, addons, configurations, and a small deviation can cause the hands-on to derail
• SO MANY HANDS ON - Literally, there are thousands of hands-on. Even for a single concept, there are numerous variations of labs, workshops, demos, githubs. It is as confusing to select the proper hands on, as it is to navigate through them

Now this is the well-kept secret that many talented SAs and cloud professionals follow:

• Less copy-paste - Understanding the concept is more important than command copy-paste. If you are just copy-pasting the commands and finishing the hands-on, but you didn't grasp the big picture, or the flow, then it is of no use.
• Partial hands-on - Working backward from the hands-on usefulness, do what is needed to fulfill it, and don't overdo it. This is controversial, so let me explain. Let's say your goal is to understand event-driven architecture with EventBridge. So, do a hands-on that integrates EventBridge with SQS, messages getting processed from SQS using Lambda. At this point, if you have been deliberately thinking about the flow, you understand how event-driven works with EventBridge. So, there is no need to keep doing more hands-on with EventBridge integration with SNS, Kinesis, etc. You have the concept grasped, and you can implement other patterns easily.
• Prioritize concepts over error messages - Error messages are frustrating. When you eventually get one, instead of immediately asking in all possible forums, try to search and troubleshoot yourself. The important part is to understand the troubleshooting process, not the error itself. Because the error messages will change, and over your career, you will get different errors, but once you have the mental model of how to attack those, you are set! Also, don't let go of the big picture - understanding the concept even when you get errors.
• Hands-on using console - Unless you are specifically going for DevOps jobs, it's okay to do hands-on using console. For example - if your goal is to understand Kubernetes autoscaling using Karpenter, then by all means, create the cluster from the console or run a single eksctl command. Creating infra as code with a DevOps pipeline will take way more time and, more importantly, deviate you from your main goal - understanding Kubernetes autoscaling!

As I am learning Gen AI, I am implementing the above techniques. I hope this helps in your cloud journey as well.

Keep learning and keep rocking 🚀,

Cloud With Raj