Blog

leadership is a lot of things, some complicated, but most important and one I believe in, is to be yourself and to respect and treat others with respect. Bringing up the best in others doesn’t come naturally for a lot of people, and that’s what distinguishes good leaders from not so good. Leaders expect and demand best from others, but they can only accomplish that if they have integrity, and a true innate desire to help and serve others. Simple as that.

leadership is serving others. leadership is being authentic and having trust in those that you are serving. that’s in essence the definition of leadership. I believe I am that leader. I lead with a purpose to help others grow. I want to see everyone succeed. 

I am still strugglnig with k8. I know pods is the lowest level, then there is replication set, then nodes, so a given node can run up to X pods, and there’s deployment, which describes which containers need to serve as pods

K8 pods are meant to represent a class of images, which can then be applied with a replica set. 

I also learned that in agile development, addressing risk is important, especially early in the project development. It adds value by removing project risk. This book 50 ideas is giving me a lot of useful value, to be honest.

I had a tough day today, but learned something valuable. Integrity is being able to admit to mistakes, to come forward, and not be afraid to be laughed at, scolded or even yelled at. 

In terms of learning, I am still trying to become more of an expert in k8, and also keep researching how to make agile work. 

Learning docker, learning docker compose!

I have made a great progress in learning docker! The tool has come a long way and it is just amazing that we have not adopted it more widely in the companies I worked with.

I also started reading Essential Scrum, which appears to be a decent book on scrum. I know a lot, so this should be a good refresher.

Things fly! But I am starting to get into the zone a bit more, which is a good sign. Starting to get the hang of the vitrification process and the domain. 

In terms of user stories, I learned a few things. It’s fine to create technical user stories if they have some values, even if it’s indirect to some extent. 

When can we call something complete? It’s complete if it’s well written, has tests, is code reviewed and it’s ready to be merged and/or deployed. Definition of done!

Boys did great yesterday. I really had a blast with them, helping them at least to some extent, to win the trophy! A 1st one for the boys. We came up 1st in the sofive tournament and the boys totally deserved it!

User stories, agile. I’m learning how to best create them. Should they be created for one person, or multiple people? It appears it’s best if it’s a story that “cuts through,” but sometimes that requires multiple people working on it, making it potentially difficult. It’s something I have to learn more about.

I had a good day learning about user stories. I wrote a wiki page summarizing it and hopefully we can implement it on a day/day basis. 

User stories should be made fit to size, so they can get completed in a sprint. There are approaches in how we can split the user stories, by data, by operation, by concerns, and by functiona/non-functional requirements.

I looked over a few career-changing books. The Pragmatic Programmers were at the top of the list. I will keep reading it as time allows. In fact, I can read a little bit of it every day on a way home. Not a bad idea. I should charge my ipad so I’m ready.

I am also learning the overview of DDD. It’s time I get a closer look at it. Lot of people have it as a must have skill to make sure the full architecture stays “in shape.” I am doing that now, so it’s a good time to brush up on it.

Another good book to read is Continous Delivery. I want to make sure that the way we build the infrastrustrure, is that we have it in such a way that it is easy to build, easy to deploy, and easy to run.

I learned about agile today. Agile can be adopted by several approaches, each requiring a different company mindset and support. It’s very true. You can’t just adopt a methodology and expect magic to happen. To be able to move fast, yeah, some basic methodology needs to be adopted. But that’s not enough. Technical expertise and practices have be adopted as well. Decision making process has to be streamlined. Anything else? I do have to re-read the excellent article by James shore. Well worth it.

I also learned about story points. I can use 1, 2, 3, 5, 8 (fibonnaci) or a simple, 1, 2, 4, 8. Key point here is that a story should be compleatable in a sprint. If it can’t, it should be split, and perhaps assigned 13, 20, 40, 100 as the number. Pretty good suggestions!