Software Estimation

You may be surprised that we are not able to give an estimation as well as we think, and you may be more surprised that not all of the software engineers are able to estimate (properly), most just guesstimate with rough intuition. Though it’s not completely wrong, we can actually learn how to estimate properly. If you are graduated from Computer Science major like me, you will remember that software estimation technique is one of the courses by itself.

Continue reading

Thoughts on Developer Productivity

Color Cycling in Pixel Art | by Stephen Schroeder | Prototypr

I used to have a dream to work at a consulting giant until a few years ago. I worked with a bunch of them, as my parent company decided to hire one of the consulting companies, and they gave me nothing but a mess (Duh! 🙄). A while back, I stumbled upon this “Yes, you can measure software developer productivity” article from the consulting giant, and it sparked debate in a lot of tech blogs/newsletters.

Continue reading

How to work with Panji

A while ago, I wrote this https://github.com/rhapsodixx/manager-readme, inspired by the other manager readme. Though it’s debatable whether the doc is useful, to me, writing this kind of doc is intended for ourselves – as managers – to force us to think about what kind of managers we want to be and what is our expectation to work with our directs, explicitly.

3 years afterward, I’m rethinking and came up with this…

Continue reading

Defect/Bug Management

who doesn’t love bugs? they are small yet beautiful…ly ruining our life 🙂. Bug is inevitable, choosing 0 Bug as your OKR/KPI is an insane choice, it’s not impossible but it will astronomically hit your productivity & cost, your best bet is to manage it properly. So how are you organizing and managing these bugs? Assigning the right priority(by assessing its severity) is the key, inspired by a couple of references, here is how I typically categorize them.

Continue reading

Software Fragmentation – The Golden Path

There is a direct correlation between teams that give their engineers autonomy to own their technical decisions and the team’s ability to hire and retain A-class or Senior talent. There is a tradeoff, but an acceptable level of chaos in exchange for a stronger sense of individual/team ownership is usually the right one and leads to higher performing teams in the long run – at least this is what I’ve been seeing if a couple of companies in Indonesia.

So, how to make sure these “chaotic” things are manageable and actually give the benefit to the team?

Continue reading