SFELC Summit Recap

Credit: SFELC

On January 24th I had the opportunity to attend the San Francisco Engineering Leadership Community (SFELC) Summit. The summit consisted of over 40 speakers who are engineering leaders, authors and entrepreneurs.

Usually when I attend conferences I live tweet the sessions as they happen, but for this conference I thought a blog post would be a better way to share my reflections of what I learned from attending.

Here’s some quick takeaways from a few great sessions:

  • Managing for creativity is a different practice than managing for reliability. As a manager for creative teams you have to expand the definition of success, provide incentives like impact and visibility and trust your team to do the work. (The Quantum Theory of Managing Creative Teams, James Everingham)
  • If you want your ideas to take root, you have to spend time getting people to embody it like it’s their own idea. Telling someone to do something doesnt mean they will do it, you have to make the why and what explicit so they can form a personal investment in the vision/project. (Influence Without Authority, Maria Latushkin)
  • You have to educate people on how to spot impactful work. Knowing how to solve a problem is a separate skill from knowing which problems to choose to solve in the first place. (Engineering Your (Engineers’) Career(s): Balancing Impact With Personal Growth, Jean-Denis Greze)
  • Trust is not gained through team-building events, giving thanks or being transparent with information; trust is built through being vulnerable, making intentions clear and sticking to your commitments. (The Accidental Bad Manager, Claire Lew)

For more in depth thoughts on some of my favorite sessions I attended read below.

The Quantum Theory of Managing Creative Teams, James Everingham

I don’t know much about Quantum physics but I think James did well in making the theories understandable in a way that relates to management practices. He talked about classical management using Henry Ford as the prime example. Classical management works when the prime goal is quality and reliability, but in technology with the primary goal being creativity the same management style doesn’t work.

My favorite part of the talk he gave was about the Observer Effect. The Observer Effect states that by simply observing a situation the outcome is changed. For example if you put a cat in a box with a bottle of poison and close the box, it’s effectively in two states – alive and dead. If you open the box, the cat is forced into one state, but when the box is closed the possibility of life is greater. As a manager he posited that you have to hyper-aware of the observer effect and allow your team to keep as many possibilities open as long as you can. You can do this through avoiding prescribing paths and expanding the pathways to success.

Engineering Your (Engineers’) Career(s): Balancing Impact With Personal Growth, Jean-Denis Greze

Jean’s talk focused a lot on how they interview engineers to join Plaid and the signal they try to focus on. What stood out the most to me was a question he said they ask every engineering candidate: “What is the most tedious and boring work you’ve done in the last year?” The reason he said they ask that is because it shows what motivates the person to get up out of bed every morning and go to work despite the fact that they know they have to do that work. They’re trying to signal for candidates that not only understand that boring and tedious work is necessary, but they are willing to do because it what will help the team move forward towards whatever their overall goal is.

Another part of Jean’s talk that stood out to me was the immense focus on impact in their interview process. He emphasizes that it’s important to find engineers that know how to spot which projects/work will be most impactful, not just engineers who know how to solve those problems. That’s a skill they also teach to their engineers at Plaid. I think as engineers many of us focus so much on the problem solving and often leave understanding or determining the impact to other members of our teams (PMs, EMs, etc). I’m trying to work on spotting impact better myself, so it was really interesting to hear Jean hone in on that.

The Accidental Bad Manager, Claire Lew

I love how Claire started out her session, she asked everyone to think of their worst boss. Then after letting folks reflect she asked, is it possible you could be someone’s worst boss? Her talk showed the various ways in which managers could accidentally end up being a bad manager. All her points were backed up with data from surveys she’s done with managers and direct reports all over the world. The three ways she suggested avoiding being a bad boss are through trust, feedback and time.

Starting off with trust, she clarified that most managers misunderstand how to build trust. Lots of managers try to build trust through social outings, giving thanks or being transparent with information. Claire’s research showed that those are some of the lowest ranked methods on how to build trust. Instead she emphasized being vulnerable, making your intentions clear and keeping well-defined commitments as the best ways to build trust.

The last suggestion was around time. Claire talked about how often managers think that being busy equals good, but it’s opposite. She stressed that if a manager doesn’t have time to do the parts of their job that have serious impact like defining team vision, culture, hiring, and communicating the direction of the team then they’re not doing their job effectively. I really appreciated her adding the fact that if a manager is doing the work their directs are suppose to or capable of doing then they’re not providing the opportunity for their directs to grow from doing that work.

The Meaning Revolution in Work, Fred Kofman

Fred Kofman is the author of The Meaning Revolution and Conscious Business. The talk he gave at SFELC was similar to a talk he gave some years ago at LinkedIn which you can watch on YouTube. Fred’s talk was incredible and really made me think deeply about my own career and goals going forward. He started out challenging the audience that we didn’t know what our jobs were. He used soccer as an example; the job of the goalie is to defend and the job of the attacker is to score, but the goal of the team is to win. The goal of the team are the real jobs of every member of the team, but each member is incentivized to fulfill their own self-interest because that’s how their performance is rated. This problem of “parts vs whole” in an organization is unfortunately unsolvable.

Although that sounds demotivating, Fred brought us back by telling us about transcendent leadership. Even though we cannot solve the unsolvable problem, we can find meaning in the missions we’re trying to achieve. It’s human nature to want to transcend meaning to find a way to leave a lasting impact on the world that will be remembered when we’re gone. If we as leaders can inspire others through our missions and encourage them to work on problems that transcend, we can find deeper value in work.

Overall, I thought SFELC Summit was incredible. I learned a lot from all the sessions I attended and appreciated the insight all the speakers had to share. I am excited for next year and highly recommend attending to anyone who is interested in engineering leadership whether as an individual contributor or manager.

Getting Stuck

Where’s the first place you go to when you get stuck on a programming problem? Stack Overflow most likely, but what if there’s nothing there to help you? Do you go to Medium in hopes someone wrote a blog post about that very obscure thing you’re working on? Well, this happened to me recently when I was finishing the last part of refactoring We Read Too’s suggestion view.

Working full time as a developer is very different than working on a solo project. At work you have your team to bounce ideas off of and if you get stuck you often have several other people to help you figure out your issue. When you want to merge new code into the app, you’ll do a code review with one of your teammates which hopefully teaches you how to improve your approach. Being on a team of other programmers helps you grow as a programmer. Side projects on the other hand are sometimes done solo. How can you make sure you’re still growing while working alone?

You have to ask for help. It may sound simple, but asking for help can be daunting. Working alone does give you the flexibility to make whatever decisions you please but if you get stuck it can be very frustrating which is why a lot of side projects never get finished. Many folks in the development community who are passionate about their work on are willing to answer your questions if you just reach out, whether it’s by email or Twitter DM. If that doesn’t work there’s always Stack Overflow or publicly asking a question on Twitter or in a forum.

So here’s where I got stuck. I needed to create an Observable<String> that my view controller would subscribe to in order to display an alert that shows the user whether or not sending the suggestion form worked. I decided to use RxFirebase to write the form to my database, but RxFirebase returns an observable of a database reference.

As shown above, I created a class, FirebaseService, where I’m going to add all the methods that interact directly with my Firebase database. My point of confusion was related to the Observable<DatabaseReference>, I know that if the write transaction succeeds then the observable will trigger an onNext event and if it fails the onError event will trigger. The issue is, I don’t want my view controller to subscribe to the Observable<DatabaseReference>, I want that to be abstracted and only have my view model return the success or error string to the view controller.

Now I could get these events by subscribing to that observable in my view model, but my view model does not have a dispose bag (nor do I want it to, since I want my view model to just provide observables to a consumer, the view controller, which does the subscriptions). So how do I get my view model to consume the onNext and onError events without subscribing? I didn’t know. So I decided to ask Shai Mishali, a well-known iOS developer in the RxSwift community. He was incredibly helpful and provided me with suggestions on how I can use PublishSubjectflatMap, materialize and RxSwiftExt to solve my problem.

From his suggestions here’s what I came up with for my view model’s intializer:

Let’s break it down. Before the view model had an empty initializer but now we initialize it with my FirebaseService class as a parameter. The formData combines all inputs into one Observable<(String, String, String)> which will come from text fields and a picker view. Title, author and category are all PublishSubjects. A PublishSubject emits items to a subscriber only after they’ve subscribed. I was using BehaviorRelay subjects before, but because my text fields have no initial value, I can use PublishSubject.

We make the request by using sendButtonTapped which is a PublishSubject<Void>. The withLatestFrom operator gets the latest item emitted by a given Observable.  To ensure that we don’t make multiple request for the same data, I am using the distinctUntilChanged operator which suppresses duplicates. Then we use the flatMapLatest. Here’s a diagram from bacon.js that shows the difference between flatMap and flatMapLatest:



flatMap takes each emitted item and turns it into a new stream whereas flatMapLatest overwrites the previous stream so there is only one stream to subscribe to.

The data I’m passing into the processForm method is a simple Encodable struct I created so it can be turned into JSON and sent to the database. After the Observable<DatabaseReference> is returned from processForm I use the materialize operator which takes the emits items and turn them into events (onNext, onError, onCompleted). The last operator I use is share, which allows you to have multiple subscriptions to one observable.

This is where RxSwiftExt comes in handy. RxSwiftExt is a library that provides convenience operators separate RxSwift in order to avoid bloating the RxSwift library. The two operators we’re using are elements and errors. Defining my outputs, successMessage and errorMessage, you can see why the operators come in handy, now I am able to send the right message to my view controller according to the events emitted from the Observable the RxFirebase method returns.

What’s Next

That wraps up the suggestion view (for now!). Next up I have to pull the book data from Firebase and insert it into a collection view. I also want to connect these different views using a Tab Controller so you can tab from Books, Search and Suggestion.


CaseIterable in Action

Swift_logoIn my last post, I started off refactoring We Read Too into MVMM with RxSwift. In the “What’s Next” section I mentioned that I need to add another field to the suggestion form. So far, the suggestion form only has a two text fields, one for title and the other for author, and a button for submitting the form.

In the current version of the app, there is a third text field for the user to write in the genre of the book they are suggesting. Unfortunately having that third text field leads to a lot of book suggestions that are out of the scope of the app. We Read Too focuses on children’s and young adult books, so the third field should be a picker view instead of a text field so I can pre-populate the options for genre. This hopefully will lead to more relevant submissions.

In Swift 4.2, enums can now adhere to a CaseIterable protocol which allows us to easily get an array of all the enum cases and have access to the total count without having to implement that ourselves in a public variable on the enum. You can read the proposal for CaseIterable here.

The code snippet above shows my enum Category. Category will be used for the picker view in our suggestion and later as well when we populate the collection view of books which will be filtered by these particular categories. You may wonder why I just don’t make the cases equal to what’s in the description variable? Well we’re going to need the shorthand names (PB, CB, MG, YA) later for pulling the book data from Firebase.

Above is the enum in action, we use the just operator to create an Observable that emits the array of our all the cases that we can bind to the category picker view’s item titles. Then when any of the items are selected when can send it back to our view model and use the selected item to complete the suggestion form.

Simulator Screen Shot - iPhone X - 2018-06-26 at 22.26.50_iphonexspacegrey_portrait

What’s Next

Now that we’ve gotten our complete form, we can use this data to create a decodable Suggestion object and send it off to Firebase where we’re storing all the suggestions.

Refactoring to MVVM with RxSwift

Source: Manu Cornet

Every developer has that moment of realization when you look at your code and barely understand what it’s suppose to do or how it got to be so many lines long. This doesn’t mean you have to completely start from scratch, but it’s important to be open to refactoring parts of your code. The point of refactoring is to make your code more understandable, testable and/or modern.

This is the first post of many where I’m going to share the refactoring process for my app, We Read Too, along with the patterns, libraries & tools I learn along the way.

When I first started learning iOS development four years ago, the design pattern I learned was MVC which stands for Model View Controller. The following diagram shows the user interaction an MVC pattern:

Source: Wikipedia

If you’re learning iOS and rely on Apple’s documentation you’ll notice that they follow the MVC pattern. Over time as your app grows it’s easy to write all the logic for your app into the view controller which leads to extremely large classes that are hard to test and hard to understand (commonly known as the Massive View Controller).

A different design pattern that has grown in popularity recently is MVVM which stands for Model-View-ViewModel. The view model allows the business logic to be decoupled from the view controller. That way our view controllers stay small and focused on the UI. The view model usually doesn’t import UIKit and has no knowledge of the view or view controller. This allows the view model to be unit testable. The model is usually a struct or simple class that represents the data.

Source: icetime17

Following the MVVM pattern doesn’t mean your code will be perfect. Just as you can have massive view controllers, you can also have massive view models. You don’t have to use one design pattern throughout your whole app, it depends on what’s works best for the functionality you’re trying to implement.

Reactive programming

In the MVVM diagram above you there are terms like “data and user action binding”, “updates”, and “notifies”. How do you actually implement those relationships in MVVM?

Many developers model those relationships through reactive programming. Reactive programming is a paradigm that has existed in software development for decades that allows developers to write  declarative code focused on asynchronous data streams. Check out this great documentation written by Andre Staltz that goes into more explanation. Reactive extensions (Rx) are how reactive programming became popularized especially in mobile development.

Why am I learning Rx? Users expect modern apps to be responsive. Thinking of everything as streams with inputs and outputs makes sure there is always a reaction to any change that comes in whether it’s a user action or network request. Reactive programming uses an Observer design pattern where a subscriber “listens” to a stream (the observable). For more on reactive programming and RxSwift specifically, watch this great talk by Shai Mishali or read the documentation.

Red, green, refactor method for testing

I wrote earlier about how testable view models are, but how will we test them?

I’ve decided to use the Red green refactor method created by John Shore. This ensures I’m following a TDD mindset when writing my code. The tests are written before the logic is completed and you write the logic to conform to the tests. Once the tests are passing you find ways to improve your code without breaking the tests. Kickstarter follows this method in their codebase and you can watch this video to see how it works. They use ReactiveSwift and have written their own test helpers. I’m using RxSwift and found a Cocoapods library that has been very useful called RxExpect.

Implementing the refactor

Now that we’ve laid the ground work for understanding the basics of what MVVM and reactive programming are, let’s get into beginning implementation of refactoring my app We Read Too which is written all in Swift.

We Read Too is a book directory app with the following features:

  • a collection view that displays the books filtered by age category
  • search by author, title or description
  • a detail view that shows the specifics of a book with data pulled from Goodreads and allows the user to share the book or view it on Safari/Goodreads
  • a suggestion view that allows the user to send a suggestion of a title that should be added to the directory.

The database (recently moved to Firebase) contains all the books and can be updated at anytime with new data or changes on existing data.

For the refactor I started with the suggestion view because it is the least complex and will help me build my comfort level with writing code in MVVM reactively. In later posts I’m going to cover how I refactor the other parts of the app and how I improve the code over time.

View model inputs / outputs

I decided to adopt the functional input-output approach to view models inspired by Kickstarter. The inputs and outputs are protocols which make easier to test and very readable.

The SuggestionViewModel adopts all three of these protocols and is a final class so that it cannot be inherited. For each of the inputs there is an associated BehaviorRelay subject (formerly known as Variable) which is used to transform the observed inputs into outputs.


Before we implement the logic for the outputs, we write our tests.

The first three tests above are all testing the functionality of the submit button which is only enabled when there is text present in the title and author text fields in our view. The last test is for the alert message after the submit button is pressed.

Logic for the view model

Now that we’ve got our tests, we have to write the logic to get them passing. We do this in the init method of the view model.

First, we combine the streams from the title text field and the author text field using the combineLatest operator which makes a tuple of the emitted values. We use the sample operator which will emit the most recent events from a given Observable. In this case we need the alert message when the submit button is pressed. Using a helper method isPresent which checks the length of the given text, we filter so that we give the alert message only when the text is present. For more on Rx operators check out this post.

Lastly we need the observable for knowing when to enable the submit button. When the view loads the submit button should not be enabled and then we want to monitor the form data and if isPresent returns true then the button will be enabled. With these two values merged we’re listening for both values and you can see that in how our tests are implemented above. Now when we run our tests, they pass!

View controller binding

Now that we’ve got our logic passing our tests, it’s time to actually connect it to a view. We create our view controller with two UITextFields, a UIButton, and a reference to a view model. Then in viewDidLoad we add targets that are initialized with the following selectors:

This makes sure all the logic is abstracted from our view controller. We pass any user interaction in as inputs to our view model. Next we need to use the observables from our view model’s outputs.

For the alert message observable we create an alert controller for every value that’s emitted and display it. For the submit button we bind our view model output to Rx control property for UIButton, isEnabled.

Lastly, we trigger our view model input for viewDidLoad.

What’s next

This is only the start! We’re not finished with refactoring the suggestion view. The only functionality we have set up is ensuring that the user has inputted text into the the title and author fields so we can enable the button that would trigger sending their suggestion.

We need to add another field to the form. The user has to pick a category their book suggestion matches to; picture book, chapter book, middle grade or young adult. We’ll do this with an Swift enum and UIPickerView that’s connected using RxSwift.

You also may notice that the send button logic is not actually finished. We’re not actually sending anything! And where’s our model? Next we need to create the model object from the form data and send it off to Firebase.