Mans.hu

Of life and all its colors

About everything that amazes and confounds me.

About / Blog / Contact
  • 
  • 
  • 
  • 

Categories

  • Amazing
  • Books
  • Business and Technology
  • Chess
  • History
  • Mahabharata
  • Parenting

Search

Book Review: The Expectant Father

December 21, 2019 by manshu Leave a Comment

I read The Expectant Father about an year ago when I first learned that I was going to become a father. Knowing nothing about babies, fatherhood or pregnancy I googled the guy’s equivalent of What to Expect when You are Expecting, and landed upon this book.

Expectant Father

I think this is a great book for someone who was in my situation; someone who needs a quick read to get familiarized with what to expect during his wife’s pregnancy as a man. I felt that the book paid for itself when my wife told me she has seen something on one of her reports that says crown to rump height, and I knew what it was whereas she didn’t.

The section on Down’s Syndrome was terrifying to me because we are both relatively older parents, but this is definitely the kind of information you want from such a book.

I skimmed through the sections on college funds, an savings etc. because I felt that I didn’t need as much coaching on the financial aspects of parenthood. Also, I did feel that the book contained a lot of fluff in terms of ideas to make your wife comfortable, doing nice things for her etc. and at some point I realized that the meaty part of the book can probably be distilled in twenty five pages or so.

Regardless, I think this is a worthwhile read for any guy who is going to become a father and has never experienced parenthood before.

Filed Under: Books, Parenting

Story points should never vary based on the assignee

November 9, 2019 by manshu Leave a Comment

One of the most common errors I see in sprint planning is the tendency of people to try and come up with story points based on who is going to work on a story.

If the developer is somewhat inexperienced then the entire team leans towards assigning a higher number than they would have otherwise done.

This is a mistake because if you do this you will never be able to increase that part of your team’s velocity which accrues due to the team becoming better at the task.

If a story is truly worth eight points, and you assign it 13 points based on the fact that the person doing the story will take more time then sure this time it seems like the person contributed 13 points to the team, but in reality they delivered lesser business value. Two or three sprints forth if this person is now more efficient and does 13 points worth of work that will not show up in your team’s velocity because you will assign this story 13 points as well. So, while the person did more work from one sprint to the other – the team’s velocity remained the same.

You see this happen a lot, and I believe a big part of the reason is that people are just used to estimating based on the time it will take them, and not based on relative sizing. This is why it is often helpful to remind everyone what the team’s baseline is and that’s to be kept in mind while doing relative story point estimation.

Filed Under: Business and Technology

Book Review: How Google Tests Software

September 21, 2019 by manshu Leave a Comment

Personally, one of the most fascinating things that is currently taking place in the software industry is the speed and frequency at which companies like Google, Amazon, Netflix etc. ship their code to production.

These companies are long past the age where a production deployment was a major milestone, and required a whirlwind of activity by many different teams to accomplish.

However, the majority of other companies are still a few years behind these players, and production releases are still a big deal, and are a quarterly event at best.

I have always been curious about how companies such as Google manage testing because in almost every project that I have worked on testing has been this huge monolithic activity that has given everyone headaches. And given how much time testing takes I couldn’t imagine how someone ships their code multiple times a day to production?!

How Google Test Software is a very insightful book into the leading practices and philosophy behind Google’s testing. It is written by people who have been deeply involved in testing for Google, and I’ll paste a little snippet about the authors here to give you a sense of their background and expertise on this subject.

James Whittaker is an engineering director at Google and has been responsible for testing Chrome, maps, and Google web apps. He used to work for Microsoft and was a professor before that. James is one of the best-known names in testing the world over.

Jason Arbon is a test engineer at Google and has been responsible for testing Google Desktop, Chrome, and Chrome OS. He also served as development lead for an array of open-source test tools and personalization experiments. He worked at Microsoft prior to joining Google.

Jeff Carollo is a software engineer in test at Google and has been responsible for testing Google Voice, Toolbar, Chrome, and Chrome OS. He has consulted with dozens of internal Google development teams helping them improve initial code quality. He converted to a software engineer in 2010 and leads development of Google+ APIs. He also worked at Microsoft prior to joining Google.”

The biggest takeaway for me from this book was the focus on automating tests, and on treating testers and developers the same way. The idea that a tester and a developer should have the same skills because the tester will ultimately write code to automate tests was new to me, and one that made a lot of sense if you think about test automation as one of the key things that will enable consistent quality and speed to market for your product.

Another wow moment for me was reading that in Google people raise bugs in the automated tests, and treat automated tests just as they would treat the code itself!

I also really liked the last chapter on the role of test engineers and test managers in the future, and how the authors see this shaping up. It is a little bit of a dire forecast if you are in this role yourself, but I do the see the industry tending in the direction of wanting fewer specialist testers and therefore test managers, and instead the mindset is shifting towards quality being the responsibility of every developer, and quality being baked into the development process itself.

Overall, I quite liked the book; I would however say that there seems to be a lot of repetition in the book, and it could have been a lot shorter without losing any of its key messages.  That being said, there’s a lot to learn from this book, and was a definite worthwhile read for me.

Filed Under: Books

Happy teams are all alike; every unhappy team is unhappy in its own way

September 9, 2019 by manshu Leave a Comment

Happy families are all alike; every unhappy family is unhappy in its own way.

This is probably the most famous opening sentence in all of literature. This sentence is also behind what’s known as the Anna Karenina principle.

Tolstoy meant that for a marriage to succeed there should be several key ingredients present such as love, healthy children, financial comfort etc., and the absence of even one of these leads to an unhappy marriage. So, while all happy families look the same, each unhappy family is unhappy due to their own circumstances.

While Tolstoy’s original insight pertains to families – it can be extended to many different things, and I think a happy team is much like a happy family. At present, I’m very lucky to work in a team which is a happy team, but I’ve not always been as lucky in my career.

Image Source: Fanpop

When I look back at some of my unhappy teams I can see several things that made them unhappy, and all of those things are absent in my current environment.

Let me list down some things that I think contribute to an unhappy team.

A bad boss: This is an easy one. There’s a lot of research that shows people don’t quit their jobs, they quit their boss. Tomes have been written on what makes a good boss, and more importantly, you know one when you see one, so I won’t get into the gory details here.

The team is over-worked: I worked on a team that worked weekends for eight straight months. Needless to say we suffered from terrible morale. Our output wasn’t particularly impressive even with all the weekends, and we were much less productive than we would have been if we were working just five days a week. If you know that you have to work on a Saturday then you start slating work that you would normally do on a weekday for the Saturday, and then you whine about it as well. No team that is over-worked can remain cheerful.

The work is not commensurate with the skill: Everyone wants to contribute to the team and do well. But that is not possible if you are being asked to do something you aren’t skilled at. While everyone wants to continuously hone their skills, if your job and skills are at odds you won’t ever be happy in your job.

Being under appreciated: There is something deeply human about the need to be appreciated. Everyone wants to be recognized for the work they do, and even for people who really love what they are doing – the work maybe its own reward, but someone recognizing it surely makes it that much sweeter.

Far too often, people are asked for statuses ten times a day when something is going wrong, but when the obstacle is overcome — no one takes a moment to recognize the ones that made it happen.

Have a lot of this, and people begin to feel they are in a thankless environment, and all joy is sucked from their work. Another aspect of this is trust. Are you being trusted to deliver? If someone is constantly looking over your shoulder and micro-managing you then you can’t be very happy or productive. Most of us have a self image of being competent and skilled in what we do, and micro management causes dissonance, and erodes all the happiness at work.

Doing meaningful work: I’ve been in some projects where the team really doesn’t believe in what they are doing. This can happen for many reasons; once I was working on a project that was going to replace a legacy system that was over twenty years old. What I was working on didn’t even match the performance of the system that was two decades old, and I hated being associated with something that cost so much money, and performed so badly. All of us have an innate need to be part of something bigger than us, and this naturally extends to our work where we want to build something that we can be proud of. It is hard to see how you can have a happy team if they don’t respect the very thing they are building.

While there may certainly be other things influencing the happiness of a team, I think it is a useful way to think about all teams in the way Tolstoy thought about families in an effort to make them happier and more productive.

 

 

 

Filed Under: Business and Technology

How to find the id of a Sprint in JIRA?

September 6, 2019 by manshu Leave a Comment

Often times you need to write a query to list out all issues in a sprint, and the most efficient way to do this is to write a JQL that references the Sprint id.

I am not entirely sure why, but there are times when just typing the Sprint number in the JQL editor doesn’t prompt it to complete the sprint id for you.

In such cases you need another way to find out the id of your Sprint. I know only one way of doing this which is kind of a silly way, but it is effective.

You open the story, and hover over the Sprint Number, right click and “Inspect” as shown below:Right Click and Inspect

 

This will open up the page’s Elements in Chrome, and the Sprint id is visible right there like I have highlighted below.  Sprint Id

 

Not the most elegant way to look for this information, but is certainly effective and quick.

Filed Under: Business and Technology

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • …
  • 32
  • Next Page »