Commit #9: Mastering macOS keyboard for better efficiency

In the past few years, I have seen a rise in MacBook Pro usage in tech companies, including in Jakarta. Although pricy, MBPs are one of the primary go-to machines for tech folks around to world. The well-known butterfly-switch issues since 2016 don’t seem to prevent people from buying MBPs, which thankfully fixed for good in the recent new 16″ model. In my opinion, one of the main reasons for this rise is the productivity value it brings along with the macOS.

In the software engineering field, macOS has many things to love. It’s UNIX-based, which is almost similar to the Linux environment used for most server-side services. For mobile app engineers like me, macOS allows us to develop applications for both iOS and Android. Not to mention the OS integration with the trackpads, which unrivaled in the laptop realm – its buttery-smooth experience convinced several designer friends of mine to work mostly using them. Nevertheless, I found that the senior engineers I worked with use their keyboard more than their trackpads. They seemed to be able to do things way faster than others due to mastering their keyboards.

Throughout the years, I’ve tried to reduce my trackpad usage and use more keyboard for work, which I find to be efficient. I wrote this based on my experience, so you might find this post to be opinionated. Still, I hope you could draw some benefits that could increase your work efficiency.

1. Use macOS’ Spotlight

Most Indonesians (including me) grew up using a Windows machine as our daily driver. So on our first time we got our hands on a Mac, we’ll be looking for the “Programs” folder using our mouse and click the application icon to run them.

start_win1

Windows XP’s Start Menu. I grew up seeing this menu a lot of times. Image taken from OpenDNS.

 

While we can run applications the same way in macOS, there’s a quicker way to do it: using macOS’ Spotlight. All we need to do is press the Command + Space key, type the application name, and then press the Return key (or Enter in other keyboard layouts).

Screen Shot 2020-01-06 at 20.27.33

A sample screenshot on how to open applications using Spotlight in macOS.

On the screenshot above, I only typed “xc” in the Spotlight, and it shows the most-used application with a matching prefix: Xcode. All I need to do next is pressing the Return key to open the Xcode.

Besides opening applications, macOS’ Spotlight also provides a lot of nifty features, e.g.:

  1. Opening a file based on filename,
  2. Calculating a simple conversion, e.g., “1000 USD to IDR” or “70 F to C”, or
  3. Searching a word definition in the thesaurus or dictionary, e.g., “hitherto.”

2. Use a third-party window manager

Coming from the Windows environment, I missed the Windows Aero’s Windows + Arrow keys combination to tidy up my application windows (pun intended). When I started using OSX Maverick, my friend suggested me to use SizeUp. The site page says that its the “missing window manager” for macOS, and it’s not an exaggeration.

With a simple combo of Control + Option + Command + Arrow keys, you could arrange your windows with ease! I find this approach is way more efficient than macOS Split View feature. For multi-monitor users, SizeUp could move the currently active window to another monitor using the Control + Option + Left or Right arrow keys. What’s not to love?

You can use SizeUp for free due to its unlimited demo. Still, it shows a pop-up periodically until you bought their license. If you wanted a free open source alternative, check out Spectacle. Be warned, though; the source code is not maintained anymore.

3. Use generic keyboard shortcuts for navigation

Most of us know that we can replace the Control key in Windows’ keyboard combo with macOS’ Command key. The classic Control + C for copying and Control + V for pasting in Windows are Command + C and Command + V in macOS, respectively. While this is a good start, there’s plenty of other combos to help for navigation, e.g.:

  1. Command + T creates a new tab in your window, if available (e.g., Finder, Safari).
  2. Command + Shift + ] focuses the app to the next available tab, and Command + Shift + [ to go to the previous tab.
  3. Command + W closes the current tab in the app.
  4. Command + N creates a new window for your application.
  5. Command + ` (tick) focuses the app to the next available window.
  6. Command + → or Control + E moves your cursor to the end of the line in a text editor, and Command + ← or Control + A move it to the beginning of the line.
  7. Control + → moves the cursor to the next word in a text editor, and Control + ← moves it to the previous word.
  8. Command + Tab opens the next available app, while Command + Shift + Tab opens the previous one.
  9. Command + Q quits the current application.
  10. You could combine #8 and #9. After pressing the Command + Tab then releasing the Tab key, you could quit the currently highlighted application in the navigation popover by pressing the Q key.

Combined with the SizeUp, I usually create one window of Safari for a particular context. For example, one window to display the web page I’m currently working on, another window to contain tabs of StackOverflow pages, and another window to play YouTube’s Lo-Fi tracks in the background. I think this is way superior compared to having dozens of tab opened in one browser window.

If you want to check the full list of keyboard shortcuts in macOS, check out this link.

4. Use ClipMenu to manage clipboard

Have you ever find yourself opening a StackOverflow page and code editor back and forth to paste several sample codes? Instead of this, I prefer copying multiple texts at once and choose which one I want to paste later, thanks to ClipMenu. ClipMenu allows you to choose what to paste throughout your recent clipboard history. By using Command + Shift + V instead of the Command + V, it shows your recently copied and pasted items. And yes, it’s available for free!

Screen Shot 2020-01-06 at 21.47.19

Sample of ClipMenu usage in a text editor.

5. Master your most-used applications’ keyboard shortcut

Last but not least, everyone has a different workflow and uses different applications. However, I believe there’s a chance that the application you use has keyboard shortcuts for your usual mouse-based operations. I started looking for shortcuts when I found myself clicking Xcode’s buttons to hide and show the debugger over-and-over again. When I searched for the shortcuts in Google, I stumbled upon this RayWenderlich’s blog post and saw this GIF in awe:

Combined with window management tips above, I ended up saving a lot of time instead of repetitive click-based tasks in Xcode. It also makes me feel comfortable working with my own machine. It’s a good feeling, and I think others will love it too!

It became a habit for me to search the keyboard shortcuts for the new applications I’m using. These days, I mostly use Visual Studio Code to work on my grad school projects and iTerm to navigate between the projects and executing Git operations. These applications have different keyboard shortcuts compared to Xcode, but they’re always a Google search away!

That’s the list of easy ways to master macOS’ keyboard for better work efficiency! I hope you gained some benefit after reading this post – whether you’re a software engineer or not! 😉

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? Are you 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… our brain has different wirings on how to recharge ourselves. Due to my introversion, I tend to evade unnecessary social interactions since young, which inhibited my social skills. Growing up, I realized their importance and ended up analyzing my extroverted friends to catch up. (Yeah, that sounds nerdy, I know.)

I learned that social interaction takes different forms and contexts. In the professional setup, these interactions come in various kinds – discussing in a meeting, writing technical documentation, listening to a person, and giving proper response. Out of all of them, I took an interest in a particular interaction: mentoring. And I want to share what I learned about it as an introvert in this post.

Why mentoring?

As humans, I believe most of us learn from experiences. A mistake from the past, for example, provides reasons and steps to prevent a similar outcome in the future. Thankfully, we don’t always need to learn these lessons from firsthand experience. Reading one’s experience through books is a great example. Another alternative for reading is (surprise, surprise) mentoring!

A proper mentoring could significantly accelerate the mentee’s growth. In the process, a mentor tailors lessons based on the mentee’s needs. In addition to the lessons, they also provide a living example for the mentees – an advantage which reading lacks. In my opinion, nothing increases confidence more than someone who models on how to do something properly.

In addition to the mentee’s growth, the mentoring process forces the mentor to grow, too. Besides the required accountability from “practicing what you preach,” the mentees could also drive the mentors out of their comfort zones through their questions. I experienced these on my career growth, and I’m thankful for it.

From a 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, which will multiply the given effort as a result. Mentoring is one of them since it will help the mentees to grow and take part in the mentor’s responsibilities. Following the mentees’ growth, the mentors could delegate their tasks and tackle more challenging responsibilities.

Last but not least, I have seen the impact on both being a mentee and a mentor to career and personal growth. My personal growth is the main reason why an introvert like me bother writing a post about mentoring. It also helped me to push my comfort zone a little bit wider every time I get demotivated as a mentor.

Make a one-on-one routine

As an introvert, I reluctantly start social interaction with others. My comfort zone as a junior engineer was working on my code while listening to music or reading through technical blogs. Sure, I could speak in front of the public or explaining in-depth technical details in a one-on-one setting, but those events require enough preparation and happen infrequently. This comfort zone was blasted when I got promoted and requested by my manager to mentor junior engineers two years ago.

Based on my mentoring experience 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 still need to deliver my day-to-day job! Left alone, I might ignore my mentees due to my introversion and use my workload as an excuse.

To battle my comfort zone, I decided to schedule my mentoring sessions. I sent a periodical schedule for each mentee in my work calendar. Having it on the calendar helps me to plan my day, leaving me with no room for an excuse. It also helps to remind the mentees to allocate time for the sessions, too! On top of that, it prevents others from disturbing us during the allotted time.

When having a one-on-one session, it’s important to remember that your mentee is human. Your mentee has a personal life, and it affects their performance in the workplace. This fact has driven me to ask for their well-being at 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 typical “everything’s fine,” a passionately-told story, or an in-depth discussion. Your mentee might be reluctant to open up on the first few sessions, which is normal. Try to open up to them first. Share your experience or thoughts when they share theirs, and deliver it in a positive language. Offer help when possible.

After discussing their concerns outside of work, ask for the work-related ones. Should they raise technical questions, try your best to ask their thought process first before giving the answers. If it’s outside of your forte, refer to others who might be able to help them. Don’t hesitate to ask them to explain the solution when they solved it – and appreciate them when you learned something new!

There are times when your mentee’s concerns related to the workplace. Listen to them well, since you are their go-to person to raise their 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 since the previous session? You could improve this by assigning a specific material or book to be discussed, which is even better if it applies 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 in each session.

Remember to take notes on every session, based on the date. Writing down their concerns and learned lessons will help you to track their growth. It will also help you to follow them up on future sessions. Those notes could also serve as evidence to the management during their 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 a presentation about Clean Code’s first chapter in the first session. At 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 my mentees a chance to know each other better. Thanks to our constructive communication culture, we covered each others’ missing material and offered feedback on how to deliver them 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 a 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 hold our group session in an open space or see-through meeting room in the office. There are some occasions where our coworkers dropped in to join us. Besides listening to the material, they also happily give inputs or share their knowledge!

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 leadership skills by letting them take the wheel.

I tried to instill a sense of ownership by asking the speaker for the group session to send an invitation through the calendar. They get to decide the date, time, and location! I’m thankful that other team members were also quick to respond, so the speaker knew when the session needs to be rescheduled.

There are occasions where my mentees gave brilliant ideas, too! In 2017’s third quarter, we were thinking about our quarterly team-building event. We usually hang out for dinner, and I was thinking about something new. Sadly, I don’t have a good idea (damn introversion). When I shared the question to the team, Yoga suggested us to take an escape room game. We ended up going to Pandora Experience on Puri Indah on the next Saturday, and we had a lot 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 new discussion material. Last year, we read the Gang of Four’s Design Patterns book and discussed one or two patterns on each group session. In the last two sessions, I pointed out that we need new materials and requested them to look for a new one. Iqbal offered to go through Wayne Bishop’s “Algorithm and Data Structures with Swift.” All of us agreed to do it. We enjoyed the book!

(A glance at 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 from this post:

  1. Schedule one-on-one sessions with your mentees.
    1. It will help you get out of your comfort zone.
    2. Ask their well-being first, be it from their personal life or work-related concerns.
    3. Listen and take note of their concerns.
    4. Share your experience. Show your mentees that you’re a human, too.
    5. Last, but not least, ask what did they learn since the previous 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. Schedule group sessions.
    1. Decide on a topic to discuss. It would be better if you could divide it into several parts, e.g., a book with several chapters.
    2. Encourage them to deliver several parts of the topic.
    3. Build a culture of appreciation. A small “thank you” at 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. The speaker for the next group session should decide the date, time, and place. Make sure they’re the one who sends the invitation, too.
    2. Ask them what materials they want to have for future sessions.
  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.

Acknowledgments

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

I want to thank the mentors I had in the workplace up until this point: 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 other engineers out, and you might make this world a slightly better place.

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