Aku akan di sini saja

Sudah tujuh puluh tujuh hari sejak pertama kali Afi tinggal rumah kontrakan bedeng dempet empat di pojok Jakarta Barat. Rumah itu masuk ke dalam gang kecil, yang tetap saja terlihat muram walaupun di depannya terdapat masjid yang cukup ramai. Gang itu kecil kurang lebih sekitar satu meter, itu pun harus berbagi dengan saluran air di sebelah kiri yang senantiasa menawarkan suka ria tikus berlari kejar-kejaran. Tak akan ada orang sudi lewat jalanan itu kalau tidak karena terpaksa saja, paling juga satu dua motor yang tersasar masuk terjebak di tengah labirin gang kecil nan lembab itu.

Sudah pula Afi hapal dengan suara-suara yang di sekitar rumah itu, suara tetangganya yang pulang kerja setiap jam 1 malam; Bayi yang menangis 3 kali semalam setiap hari; Ataupun saat tetangga sebelah kirinya, si keparat botak bercinta dengan istri mudanya. Setiap malam dia berpikir, apa lebih baik dia pindah saja dari rumah itu. Tetapi selalu saja saat pikirannya melaju kencang mencari pilihan, akhir-akhirnya dia menyimpulkan untuk tetap tinggal. Apalagi…

Apalagi di rumah ini dia bisa selalu bisa melihatnya, tipikal lelaki jawa yang tidak terlalu tinggi, sawo matang dan berambut hitam kelam. Selalu terkesima Afi melihatnya mondar-mandir setiap pagi mencari kunci rumah, atau saat malam berguling kanan dan kiri di atas ranjang karena tidak bisa tidur. Oh sudahlah, aku akan di sini saja, tekadnya.

Being Engineering Manager

no it’s not me

Like many other software engineers out there, I used to think that I’m not a “people” people (at least not a good one)

At last I found time to write about me as Engineering Manager, a very unique role which I still can’t comprehend what it really is. But hey that’s the beauty right! When we don’t know, trying to understand and then tinker that out.

It began a year and half ago, second semester of 2017. The first batch of so-called Engineering Manager at my company, what we did back then? Honestly I didn’t know! In the first month I still code, one big and important feature. At the same time I was the squad lead, scrum master, technical architect, coach, entertaining all stakeholder and -you know- doing that random management stuffs. It was real chaos, things needed to change.

Let Go, about being easy to yourself

Let go, may be that’s the keyword I learnt through out this journey. One by one I put all that roles to others, the equation is not how much we can help team but how many people we can empower and build the bridge together. By doing that I could have more time to find what that Engineering Manager really is. In first semester I did a lot of experimentation (I still do), what’s the proper way to approach a project, communication pattern with product and business team and how we do agile development.

There was time that I tried to bring all the team for scrum ceremony. As predicted the team is too large for single scrum ceremony, daily will last for 30 mins more.

On pressure, failures and all “that’s too much for me” moments

Unfortunately even when I let go many of that roles, my team was still too big -It was too big that we had to split this into 4 tribes throughout the year. There was time that burnt out is understatement to describe my physical and emotional being, and even worse when the outcome of that suffering was failure.

Did you ever hear that being a good leader, no matter what kind of leader you are, your mental state is your team mental state. When you’re sad, your team are. When you’re so optimistic, your team are. And when you’re frustrated, your team are! It was months of crunch time and I had too many timeout moment to counts, but that helped me. In every timeout I prayed, doing warrior breathing or throwing some random yoga pose. Then I would be ready to face my team with all the positivity needed.

I think it’s very important to have another interest outside our day job. At that time I happened to have yoga class every week, so it helped. Naturally yoga poses are very difficult, it needs focus, physical strength and high pain tolerant (coincident?), all of that helped me to empty my brain from all other things. So Refreshing.

Another thing I learnt on that period was comrades are important, people whom we go to battlefield together. I had a lot of discussion about architectural design, problem solving or even debate with them, it was up and down situation. But In that kind of situation your hearth would say that people will always be here to charge the storm together. Your comrades would understand what’s that smirk means, or will shed tears together on many emotional moments. -Yeah I shed many (happy) tears-

Oh man after you passed that, anything will look like a piece of cake for you

It’s people not users. it’s people not resource

No no, I will not talking about UI/UX, product research or anything. The adage means that when we say user we will detach the beingness of human from the word. It’s similar with when we say our team member as resource, they are human being not a resource like rocks or oils.

My second moment of chaos was on how I underestimate people’s disappointment, I was too naïve back then. The way I brought news to people is almost the same to every person, how I motivate them was with the same treatment. That was big mistake, even Harper Lee wrote about this more than 50 years ago “all men are not created equal”.

Like many other software engineers out there, I used to think that I’m not a “people” people (at least not a good one). No it’s not, from many feedbacks actually I’m quite good people people -apparently that’s just an unnecessary mental block-. After this realization, all possibility comes to my mind. I eagerly add my time to hear, trust and coach people in my team. Yes it is not perfect, but I’m trying.

Helicopter is not destined to be exploded

My last semester as Engineering Manager was easier, I had more time to think more broadly – some might say big picture or Helicopter view. On this mode many problems become more clear to me, very exciting right! I had several big contributions to my employer on this time period, when I have more time to think and identify what no one have time to think. This is also the uniqueness of this role, that I also have authority to drive and empower people to solve and respond to problem. But man it was not for granted.

These moments shaped my definition of Engineering Manager even further they defined me as human being. In this era I believe the most important is not exact definition and understanding but the ability to identify, respond and adapt quickly. At the end of the day if you ask me what’s Engineering Manager I would not be able to give that kind of definition you found on wikipedia. Instead I can tell stories and then let’s distill together what’s this.

It’s quite long story already and don’t forget to take it with a grain of salt. There are 34 `I` in this story, it can be just narcissistic article, but you made it to the end.

Good luck

Tego microservice framework

Spent several hours on my Ied Holiday to continue Tego , it’s heavily inspired by go kit. Now I’m convinced that go kit has good balance of flexibility even though it’s far from echo on the easy to use side. However I can say that this structure allows code with 100% test coverage easy to achieve.

On Tego I was literally copied go kit endpoint’s code and adding set for ergonomic. Other than that there are several simplifying here and there. Lot’s of time spent on creating the sample apps to dogfood the tego itself, you can definitely create a complete by following the autocomplete example.

Basic Software Process Nature

About software process :

The special nature of SPs can be defined as follows:

a) They are complex.

b) They are not typical production processes, since they are exception driven, are strongly affected by highly unpredictable circumstances, and each process has peculiarities that distinguishes it from all others.

c) They are not ‘pure’ engineering processes either, since we do not know the appropriate abstractions, (there is no experimental science behind them), they depend too much on too many people, their design and production are not clearly differentiated, and their budgets, schedules and quality cannot be programmed reliably enough.

d) They are not (entirely) creative processes because some parts can be described in detail while some procedures are previously enforced.

e) They are finding-based and depend on communication, coordination and cooperation within predefined frameworks. Their delivery generates new requirements, the cost of changing software is not usually recognised, and their success depends on user involvement and the coordination of many different roles (sales, technical development, customer, etc.).

Ruiz-González,Francisco; Canfora, Gerardo; “Software Process: Characteristics, Technology and Environments” (PDF), European Journal for the Informatics Professional, 5 (5): 6–10

Hujan di bulan april

Kontradiksi selalu berawal dari keberadaan
Yang akhirnya berbelit lincah dengan pertemuan
Bertali-temali layaknya benang kusut
Berjungkir-balik bagai ayam aduan yang dipertemukan di tengah sorakan

Seperti sore tadi saat matahari masih hangat
Saat mata-mata masih awas memunguti remah remah rejeki
Saat buruh-buruh waktu masih sibuk menanti
Lewat sela-sela dedaunan akasia dan dahlia
Rinai-rinai hujan berjatuhan membaluri jalanan
Mencipta paduan ganjil kontradiksi terik matahari dan dingin tepias air hujan

Kita adalah kontradiksi di mana si aku berada di sisi sana dan si kamu berada di sini
Saling memandang lekat namun hanya dalam pandang
Yang kisahnya akan berhenti saat jalanan telah lengang dan waktu berhenti beradu
Tak cukup berharga untuk dikejar, tak bijak pula untuk ditinggalkan

Karena pada akhirnya
Kita akan berhenti seperti hujan di bulan april