Last night I was at one of the Jakarta thousand islands. I rode the bike slowly, letting my face tickled by seashore breeze. Parked the bike near a small pier, left unused by most fishermen here.
The water was turquoise at day, but it was sparkling so beautiful that night. Mesmerizing was understated, together with the wind they could blaze my anger, sadness and loneliness away.
I looked up to the sky, wondering why the water was sparkling beautifully. Enchanted once again, I saw a bright and dazzling moon framed by thin night clouds.
I think I’m longing for a home
Not a home where my family reside
The place where I was born and raised
I’m longing for my home
A place where I can relish my loneliness
Enjoying night with a cup of warm tea while watching TV
Or reading a book with swinging music at the background
Having conversation with night skyline while doing nothing
Such pleasure such home
DDD or Deadline Driven Development, a term popularized in a well written article by Joshua Partogi (1) is real yet interesting problem to solve. It is not easy to tackle but nothing impossible right?
For me as software developer having enough experience of DDD is understatement, I’m fed up with it. No MVP, impossible deadline, no clear long term product and bussines vision, Long crunch time and everything in between. Don’t blame developers who think they’re a victim of vicious process.
Fortunately that article comes with good solution by prioritizing, slicing by the amount of cost of delay then doing continuous improvement afterwards. I will not try to explain that points, but I will add my own here.
The main point is to stop thinking as a bunch of victims and realize that we are also part of that vicious cycle. Get the position and speak up, present your concerns and ideas with clear reasoning and back it with good data. It is our job to be a good break for them, and giving options for each concerns.
Crying about how bussines or products people never understand engineer is useless, they will never fully understand us. Always improve team’s confidence for the next wave of impossibility in terms of technical efficiency and ability.
I said that full mutual understanding is not possible but at the end of the day we must agree that our goal is the same.
Too much will make us overwhelmed which eventually lower our alertness to alerts that are important.
Too little makes us do not aware of the state of our system and may miss a problem.
Determining key metrics is the most important step to good alerting, then formulate any form of alert for those metrics. Then divide it into four important quadrants, make sure exposure for critical alert are greater than others or not buried by alerts that are in lower quadrants.
After all that division, now we can determine who should get each alert.
Oh and making sure alert recipient to understand key metric and urgency of each alert is also important.