Commit #8: An introvert’s take on mentoring engineers

Do you prefer reading books or listening to music over partying for your “rest time”? Or planning deliberately instead of taking spontaneous ideas when speaking in the front of a crowd? Or feeling drained after interacting with a lot of new acquaintances, wanting to retreat? If your answer is yes, there’s a big chance you’re an introvert (or ambivert) like me.

Us introverts have to rest after a certain amount of social interaction. It doesn’t mean that we hate people, just… our brain has different wirings on how to recharge ourselves. I found myself lacking in this area, and I know I need to be better. I ended up learning communication and social interaction techniques from my extroverted friends. I took a fair amount of embarrassing moments on learning how to deliver my thoughts through different context and mediums, e.g. writing technical documentation, delivering a presentation, or giving proper response when mingling in a group.

Along with my social interaction learning process and career growth, I took an interest on a certain form of interaction: mentoring. In this post, I want to share the lessons I learned on mentoring other engineers… as an introvert.

Start with why

As a human, I believe that most of us learn from experience. A mistake from the past, for example, provides reasons and steps to prevent the similar outcome in the future. These lessons doesn’t have to be learned from a firsthand experience. Reading one’s experience through books is a great example. Mentoring is even better, since the mentor could provide tailored lessons for the mentee.

Mentoring also provides a living example for the mentees. It also works as a platform for keeping the mentors accountable. Through their questions, the mentees could also drive the mentors to grow out of their comfort zones. This allows both sides to grow together.

From the business perspective, mentoring provides a long-term value. On The Effective Engineer, Edmond Lau states that investing in your team’s growth is one of many high-leverage activities. Mentoring is one of them. Through mentoring, the mentees could rise up to take part of the mentor’s responsibilities. This allows the mentors to learn and take more challenging responsibilities.

Last, why do an introvert like me bother writing a post about mentoring? Because I’ve been on both position – as a mentee and a mentor, when I was in college and in Ice House. In the days where I found myself demotivated as a mentor, I remember these reasons and push that comfort zone’s border a little bit wider.

Make a one-on-one routine

As an introvert, it’s normal for me to reluctantly start a social interaction with other. My comfort zone as a junior engineer was working on my own code while listening to music or reading through technical blogs. Sure, I could speak in front of the public or explaining deep technical details in one-on-one setting, but those requires enough preparation, and normally happened intermittently. This comfort zone was blasted when I got promoted and requested by my manager to mentor junior engineers, two years ago.

Based on my experience as a mentor when I was in college, I know that I need to ensure my mentee’s growth by checking on them periodically. The context is slightly different, though – I need to deliver my day-to-day job, and I know that I will be inclined to ignore my mentees, using my workload as the reason. To battle my own comfort zone, I decided to make the sessions done once per two weeks. I created scheduled invitation to each mentee through the company’s calendar. Having it on the calendar definitely helps me to plan my day, and prevent others disturbing the allocated time.

When having the one-on-one session, it’s important to remember that your mentee is a human. Each of them have their own life outside of work, and it affects their performance in the workplace. This fact has driven me to ask their well-being on the start of a session. Is there something that they’re concerned about outside of work? Or perhaps a great experience from last weekend? The answer could be anything – A common “everything’s fine”, a passionately-told story, or a deep, serious-toned discussion. Your mentee might be reluctant to open up on the first few sessions, and it’s normal. Try to open up to them first. Share your experience or thoughts when they share theirs, and make sure it’s delivered in a positive language. Offer help when possible.

After discussing about their concerns outside of work, ask for the work-related ones. Most of the time it’s a technical question regarding their current project. Try your best to provide guidance. If it’s outside of your forte, refer to others who might be able to help them. Don’t hesitate to ask them the solution when they have solved it – and appreciate it when you learned something new!

There are times when your mentee’s concerns related to the workplace. Listen to them well, since we are their main person to raise the concerns to the management. If you’re not senior enough to offer a helping hand,  you could raise it to your higher ups, too. It’s also a good chance for you to impart cultural company values or lessons – e.g. how to tackle an over-promised feature.

Last but not least, ask for their technical growth. What have they learned from past two weeks? You could improve this by assigning a certain material or book to be discussed on each session. It’s even better if the material could be applied to their day-to-day work. For me, I always assign new hires to read the Clean Code book for starters, and discuss each chapter on each session.

Remember to take notes on every session, based on the date. Writing down their concerns and learned lessons would help us to track their growth. It will help us to follow up any concerns on future sessions. You could also use the notes to provide evidence to the management when they’re being reviewed in the periodical performance review.

Group them together

I was concerned about my team’s camaraderie, so I scheduled all of the one-on-one sessions to be done in a week, and added a group session in the following week. The group session has one rule: each session will be lead by one of us, sharing something to the group. I remember bringing presentation about Clean Code’s first chapter on the first session. In the end of that session, I asked Heri to deliver the second chapter for the next group session. The five of us took turns until it circles back to me. So the routine goes.

The group session gave chance for my mentees to know each other better. Thanks to our constructive communication culture, we covered each others’ missing material and gave feedbacks on how to deliver better. It’s not long until Sinta delivered her clever-and-dry jokes to light up the situation. I am glad that the friendliness that built in the group session extends to the day-to-day job, too!

Besides the camaraderie, the group session allows my mentees to refine their skills before speaking to larger audience, e.g. our company’s weekly demo. It also helped us to keep learning something new, especially when we’re too busy to learn due to a project’s deadline. Talk about hitting three birds with one stone, eh?

We usually held our group session in the office, usually in a open space or see-through meeting room. Due to the transparency, there are some occasions where our coworkers drop in to join us, driven by their interest of what is shown in the screen or scribbled in the whiteboard. What’s better, they also happily give inputs or share their knowledge regarding the material!

Lastly, this two-week session gave me a room to breathe on the alternating week, since I’m not always the one who delivers the material. I usually use this time to focus on my current project, learning something new, or maintaining a pet project.

Let them take the wheel

As a mentor, there’s an important goal for us besides helping out mentees grow – it’s to prepare them to lead and become a mentor someday, too. I tried to hone their skills in this certain area by letting them take the wheel.

When one of my group member became the speaker for the next session, I’ve always asked them to send the invitation to others. This was supposed to instill a sense of ownership to them – what day should it be, on what time in the day, and where. There are some rare cases where we need to reschedule, and on that occasion, I let them to decide the rescheduled the session, too. I am glad that our team is responsive and thoughtful should we have a reschedule – all of us quickly responds when are we available.

There are occasions where my mentees gave brilliant ideas, too! On 2017’s third quarter, we were thinking about our quarterly team building event. We usually hang out for dinner, and I was thinking for something new… but I don’t have a good idea (damn introversion). When I threw the question in one of the group session, Yoga suggested us to take an escape room game. After a few discussion, we decided to do it. We went to Pandora Experience on Puri Indah on the next Saturday, and we had a ton of fun!

Law of Demeter's Q4 team building event

The Law of Demeter! From left to right: Me, Yoga, Sinta, Iqbal, and Heri.

 

There’s another occasion where we’re looking for a new discussion material. Last year, we took Gang of Four’s Design Patterns book and discuss one or two patterns on each group session. On the last two session, I pointed out to that we need a new material, and requested them to look for a new one. One of the team member, Iqbal, offered Wayne Bishop’s “Algorithm and Data Structures with Swift”. I realised that not all of our team member came from computer science degree, and agreed that this material would benefit all of us. All of us agrees to do it, and we had fun!

(A quick glance of Iqbal’s presentation for self-balancing trees. Heri went to the toilet when I recorded this. 😔 We also got Fathureza dropping in!)

Recap

As a recap, these are the practical points that can be taken from this post:

  1. Set up scheduled one-on-one session with your mentees.
    1. This will help you get out from your comfort zone.
    2. Ask their well-being first, be it from their personal life or work-related concerns.
    3. Listen to them, write their concerns down if needed.
    4. Share your experiences too, however small. Show to them that you’re a human, too.
    5. Last, but not least, ask what did they learn since the last one-on-one session. When possible, share some relevant technical knowledge or work ethics.
    6. Don’t be shy to praise them or ask for further details when they’re sharing something you don’t know.
  2. Set up scheduled group session with your mentees.
    1. Decide a topic to discuss about. Make sure it could be divided into several parts, e.g. a book with several chapters.
    2. Encourage them to take part in delivering several parts of the topic, preferably in a certain sequence.
    3. Build a culture of appreciation. A small “thank you” on the end of the talk would go a long way.
  3. Instill a sense of ownership by encouraging them to take part in the group.
    1. If one of them become the speaker for the next session, let them decide the time and place. Make sure they’re the one who sends the invitation to others, too.
    2. Ask them what materials that should be brought into the group session.
  4. Remember to have fun!
    1. If needed, ask your extroverted mentees for ideas! 😉

Be reminded, though – this method works for my team and my company culture. Yours might be different, but I believe that mentoring could improve your workplace culture, if haven’t already.

Acknowledgements

I wanted to thank the mentors I had in the college, Arthur Lumolos and Sarah Awuy, for giving me the example on how to live in the Word of God. And for giving me the room to do mistakes and grow by leading others.

I want to thank the mentors I had in the workplace up until this point, whether from designated one-on-one sessions or giving me lessons through my mistakes: Fauzan Emmerling, Batista Harahap, Muhammad Taufik “Obet”, Pria Purnama, Abdul Haris Ilmawan, Darrick Rochili, and Lars Oleson.

I want to thank my Law of Demeter team for the great journey for these two years – Heri, Sinta, Iqbal, and Yoga. It’s been a joy to watch all of you grew in your career! Don’t forget to share what you have learned – and be a mentor! Help another engineers out, and you might make this world a slightly better place.

Advertisements

Commit #7: Useful practices for leading an Agile team

2016 has passed, and people had different opinion on it. The internet seemed to think that 2016 is a complete disaster, though. Political turmoils, wars, death of famous figures, and our personal miseries propagated through social medias and memes. This meme depicts the thought pretty well:

I got my share of miseries for 2016, but the old hymn reminded me to count my blessings. I realised that through the whole year, I learned important lessons from my workplace.  One of the most valuable lesson I had was more chances to lead iOS team in projects.

Moving from a single contributor to a team leader wasn’t easy. I need to deliver stories while facilitate my teammates to deliver theirs. Along with other leadership principles that commonly known, I found out that these practices helped me on leading my team, which were establish shared grounds, foster ownership, and schedule technical retrospectives.

Read More

Commit #6: Unwrapping Swift optionals

Update 12 Oct ’16: I’ve updated the code in this post and the Xcode Playground blog post version to Swift 3! Thank you for the wait 😁

As an iOS developer, handling empty value cases in Objective-C is never easy. Let’s suppose we’re making a function that return NSString instance out of a NSDictionary:

Everything seems fine, isn’t it? The method’s logic is pretty clear – it returns the value in user_token key of the JSON. If the key exists, it will return the string. If not, it will return a nil value… dead simple, right?

No.

I left out a sanity check there, but  let’s continue our example for now.

Suppose that the returned string will be encrypted and stored by C++ library. And for that, we need to cast our NSString to C string:

Where’s the problem, Do? Everything looks fine…

Right. The method above looks good – it stopped the process early if passed userToken is nil. Both of them will work correctly, until somebody from the server side single-handedly pass null value in response JSON’s user_token key, instead of omitting it.

Let’s run through the code once again. If the passed JSON is made from NSJSONSerialization process, the user_token key will store a NSNull  instance. Thus, the result from userTokenFromJSON: will be a NSNull instead of a nil or NSString – which will allow it to pass through storeUserToken:‘s early sanity check code (since it’s not a nil), and break the whole app, since NSNull doesn’t have UTF8String method.

Let’s hope this case will never happen in production servers. And yes – I’m looking at you, cowboys.

Due to this issue, nil-checking alone in Objective-C isn’t sufficient. We also need to ensure whether an instance is the right class using isKindOfClass: method. It doesn’t always work well either – for example, if the server on the example above returns a number for user_token value, there’s a chance that it’ll read as _NSCFString (Apple’s private API) instead of a NSNumber.

That’s why after a few month working with Swift,  I grew appreciating the Swift Team’s decision to include Optionals. I believe they made this as an answer to Objective-C’s tedious sanity check. The documentation clearly says that:

You use optionals in situations where a value may be absent. An optional says:

  • There is a value, and it equals x

or

  • There isn’t a value at all.

If I declare a variable to be a String? (read: String Optional), it would either be a String value or a nil. Not a NSNull, not other class type, and not another Apple’s private API. So, userTokenFromJSON: above could be rewritten in Swift into this:

And yes, this method will an Optional – either  String or a nil. 🙂 But the process isn’t ended here – we need to take the available String value out of the Optional. The term is usually called as unwrapping in Swift development – and there are several ways to do it!

Wait, it seems I had enough rant above… this post started to feel edgy. Let’s change the mood, shall we?

In this post, I’ll list the ways for unwrapping Swift’s Optionals that I have found so far. For the sake of the post, let’s assume we got a new function that needs a String input and an Optional variable:

Now, we need to unwrap the name (since it’s a String optional) to pass it to the createGreetings(sailorName:). There are several ways to do this:

Read More

Commit #5: On choosing learning materials

For us who work on the field of software engineering (and its neighbours), it is no secret that we constantly learn new things. Driven either by need or curiosity, it seems like learning is a never ending quest for us. Some of them have direct impact to our craft, like how using Xcode’s debugger could save us from headaches, or how side menu reduces user engagement with your app. Some of them are just for fun – like how TrumpScript is making Python great again (duh), or how a build engineer automates everything using bash scripts, ranging from scanning e-mails to ordering the coffee machine (!).

As a software engineering company, Ice House has a diverse learning scene. We have two main diets in our learning materials:

  1. Knowledge in our main craft, e.g. iOS or Android. To deliver the best quality, we always strive to know better about our own backyard.
  2. Specific knowledge which needed in client project’s domain,  such as geolocation or image processing. Sometimes, our client requests more than a simple mobile app to compete with current market.

Outside of that, each of us has our own preferences. Some of us love to venture outside of our comfort zone, such as playing with Arduinos, explore new programming languages / concepts, or tinkering with new game development tools. As for me, I found myself learning much more general topics, such as clean code, test-driven development, or design patterns. Sometimes I’m afraid a new platform-specific knowledge would quickly obsolete – especially on today’s tech pace.

Last week, I joined a design-and-define workshop for a new client. I had a chat with our software architect during a session’s coffee break. He has more than ten years of experience in software engineering, and had several years working as Senior Director of Engineering for Citrix’ mobile platforms. I always knew that he has a vast knowledge about a lot of things, but I witnessed it myself up close on the workshop sessions. Wondering if he’s still learning new things these days, I asked him straight away:

M (Me): So, what are you learning about these days? Got anything new?

H (Him): Hmm… nothing much. I currently playing around Kotlin and Swift.

M: Kotlin?

H: Yeah. You know, the new language from JetBrains – some people build Android app on top of it.

M: Whoa. Do you also planning to build Android app with that? Or perhaps using Swift for backend?

H: Maybe – as a software engineer, it’s always a good thing to keep up with today’s technologies. At least, I’ll learn new paradigms that might be useful later.

I found myself agreeing with his last statement, but I also start wondering how he picked his learning plan. He’s an architect, and it’s his job to keep being updated with general software growth. Why did he chose Kotlin and Swift? Why not Haskell, Node, or others? Curious, I continued our discussion with this:

How do you choose what to learn next?

Read More

Commit #4 : My top seven clean code practices


Hi there, fellow readers! It’s been more than a month from my latest commit, where I promised this post will be published a week after 😅 Sorry for the delay! I got my hands full for a month 😓

As I said before, the Clean Code book got tons of useful practices. In this post, I want to show you how I applied a few of them in my code – which mostly is Objective-C, hence the examples on this post 😉 I believe I don’t always get it right either, so I’d love to hear from you if I got something wrong on how I applied it! 😁

So, here’s the top seven clean code practices I mostly use! 😆

Read More

Commit #3 : Clean code matters

*dusting blog*

*coughs*

Hi there! It’s been months since my latest post commit here, work life sure can be tight 😅  After two tutorials, let’s try some different type of commit, shall we? This time, I want to share about a book that changed the way how I code.

It was on my early days in Ice House. Some of our higher-ups just came back from US and brought technical books for us. I was reading a copy of  The Pragmatic Programmer at that time, so I didn’t really looked at the new books. After a few days, Ridhwan handed a copy of Clean Code to me, and said this:

Check this book out, do. My code structure changed a lot, even only by reading a few chapter of it.

I took it with a so-so feeling. I was reading the Pragmatic Programmer, and that book made me feel worthless. It was full of best practices that I haven’t done (yet), so full of it that I was confused where should I begin with. I was unsure whether I can take something practical out of Clean Code. I was afraid (duh) that it will make me feel worthless again. Yet, I ended up reading it. It was recommended by the prodigy*, so… why not?

I read the introduction (it suggests amazing measurement for code quality) and the first chapter, and BAM – these paragraphs pops out:

Read More

Commit #2 : Export your *.xcarchive to *.ipa via terminal!

December last year, several Ice House clients asked for Christmas update on their app. There’s a strange case that occurred when our team tried to send old projects to the iTunesConnect using Xcode 6’s Organizer, just like this image :

Screen Shot 2015-01-09 at 17.12.22

Our supervisor, Didiet, said this issue might be caused by the project file. The project was built on Xcode 5.1 and we’re trying  to publish it from Xcode 6. Since we don’t have much time left, we ended up using xcodebuild‘s exportArchive command from terminal to export the *.xcarchive from Organizer to *.ipa :

Read More