In this article, I’ll explain what leading with curiosity means and provide examples of what has worked for me over the years.

Battling imposter syndrome

I’ve often experienced imposter syndrome, especially when I join a new company. More specifically, this was true when I joined Stripe and GitHub. Of course, being surrounded by exceptionally talented people does not help and makes you wonder if you deserve your spot.

When joining a new company, there’s a ton of new information to assimilate: a different technology stack, new processes, learning about a new industry (e.g. fintech), different customer base, etc.

You’re essentially drinking from the firehose for the first few months. It’s a perfect recipe for feeling like an imposter and like you don’t know what you’re talking about. Of course, it’s not the only situation where folks can experience imposter syndrome but it is one of the most recent experience I can relate to.

On top of this advice for new hires that I have shared in the past, I over index on being curious. Being curious not only helps me push through imposter syndrome but also to come out of it stronger.

More concretely, what this means for me is that I have a living document to keep track of 3 main buckets:

1. Questions and unknowns that I want to dig into further

2. Notes and thoughts I had but haven’t looked into yet

3. People I should reach out to next

As I go about my day-to-day tasks, I add things into the 3 buckets above.

The first bucket, Questions and unknowns, is essentially the questions that I have for folks and what seeds the basis of my curiosity. I use items from this bucket to learn from others and approach my work with curiosity. For instance, I could frame questions as follow: “Can you help me better understand what X is?” or “For my own education, can you tell me more about why we do Y this way?”.

The second bucket, Notes and thoughts, represents items that I want to dig deeper into and may end up surfacing more questions that I have for others. It can also result into me writing a short-form blog post, proposal, or a list of notes that I share with others and ask for their feedback on an area that I’m currently thinking about (i.e. What’s top of mind for Wissam). I have found that writing a draft and sharing it with others for feedback is a good way to request input and learn from others.

The third bucket, People, is a collection of folks that I want to connect with based on suggestions from peers or from proposals / initiatives I was intrigued by and want to learn more about. In my experience, colleagues appreciate when I reach out to ask and learn more about a specific initiative they’re leading. It also creates a good opportunity to connect around a mutual interest and build my network within the organization.

Leading a new team

In my experience, managers who lead with curiosity tend to be empathetic, compassionate, and humble leaders. Curious leaders have a growth mindset rather than a fixed mindset. They’re aware that they don’t have all the answers, they are open to learning more, and are willing to challenge their own beliefs.

I found this to be especially true for leaders who join a new organization. One of the biggest mistake a new leader can do is to make changes immediately after joining a team. Instead, they should approach this opportunity with curiosity and spend time better understanding how things currently work. There is a reason why things are built or done a specific way (for better or worse), but leaders will never get a chance to understand the history of things if they make sweeping changes based on previously held beliefs or experiences.

My suggestion to leaders who join a new company or team would be to make it explicitly clear that they are approaching this new challenge with curiosity and willingness to learn. For instance, a statement like this can go a long way to set a good tone right off the bat:

For a brief while, my goal is to listen and ask questions so that I can learn more about our past decisions, better understand where we are today, dig into what good looks like for our team, and how we are going to achieve our goal of XYZ.

Being a better listener

A critical part of being a manager is being a good listener, but more specifically, to listen with a curious and open mind. This means learning to ask good questions and to dig further into what your team is saying.

Leaders should prioritize coaching over solutionizing.

A leader’s job is not to have all the answers but to help their team come up with the answers. And to achieve that, leaders need to actively listen and repeat back what others saying, and to ask questions to dig deeper into what they’re saying.

Here are questions you can use to dig deeper into topics and to lead with curiosity:

• “What are you optimizing for in this context?”

• “What led you to this conclusion?”

• “What are the different options that you’ve considered?”

• “If we were to do your recommended approach, what are the tradeoffs that we are looking at?”

• “What would be the best case scenario for you? What would be the worst case scenario?”

• “Is my understanding correct that…”

Conclusion

Being a good leader requires curiosity because it helps cultivate an environment where people feel valued and really believe that you have a true interest in their success. This leads to more functional and successful teams that operate with a high sense of trust and psychological safety.

Furthermore, leading with curiosity and asking thoughtful questions has personally helped me battle through imposter syndrome and to come out of it as a better leader.

Finally, it’s important to keep in mind that:

• You don’t know everything and no one expects you to know everything.

• Yours peers should generally appreciate answering questions and helping out (especially with new hires).

• You can promote a healthy team culture when you lead by example.

Don’t be the hero

One negative trait that I’ve seen from leaders is the idea that they need to work in hero mode where everything depends on them. This is detrimental to a team’s culture and creates an environment where engineers are less happy and less creative. Leaders who work in hero mode tend to suck up all the air (and fun) in the room. This, of course, has a direct impact on attracting top talent, retaining talent, and team culture.

As Simon Sinek calls out in Start with Why: How Great Leaders Inspire Everyone to Take Action:

The role of a leader is not to come up with all the great ideas. The role of a leader is to create an environment in which great ideas can happen.

Your goal as a leader should be to focus on what you do best and how you can have the most positive impact on the company. In other words, this would be to not do the work of engineers. You should delegate the work you do in hero mode to engineers so that they feel trusted and valued.

Trust and empower others

Engineering leaders are responsible for their team’s outcome. Their success is linked to their team’ success. The more they multiply the impact of others, the more successful the engineers will be. This, in turn, will lead to the leaders being more successful.

Leadership is about making sure that the people who work with you feel valued and feel like they are also getting opportunities to grow.

Empowering and trusting your team more will result in happier, more energized, and more creative engineers. They will be more successful and more impactful. And, you will be more successful because of that.

What about Elon?

What does this have to do with Elon, you ask?

Elon is very hands-on, according to everything I’ve read and learned about him. He is supposedly very hands-on at SpaceX and at Tesla. When his text messages were recently revealed as part of the Twitter dispute, a particular exchange with Twitter’s CEO, Parag Agrawal, was fascinating to read. Elon had lots of concerns about Twitter’s bot ratio and did not trust the information given to him and other stakeholders. To dive deeper into this problem and find a solution himself, Elon said to Agarwal:

I would like to understand the technical details of the Twitter codebase.

As I mentioned earlier, this is apparently something that Elon often does. It’s a bad trait that many engineering leaders do. They like to play the hero. Instead of empowering engineers to make decisions and to support them along the way, they want to be involved in every detail of the solution. This slows down progress and is less fun for the engineers. It promotes a culture that relies on the boss and where all decisions need to be thoroughly vetted by the boss.

Instead, as mentioned earlier, leaders should look at pushing these responsibilities to engineers. Leaders should focus on building a culture of ownership and accountability.

One approach that I enjoy using to enable a culture of ownership and accountability is the Directly Responsible Individual (DRI) model. This model was first coined by Apple but I’ve personally used it at Stripe, GitHub, and InVision with lots of success.

By having engineers act as DRIs, leaders create the type of environment described earlier in this article: a place where engineers feel valued, trusted, empowered, creative, and accountable.

And, as Camille Fournier points out, leaders who want to remain involved have other ways of making an impact. They should ask engineers to bring proposed solutions as well as a recommended path forward based on the tradeoffs that they’ve considered. Leaders should then use this opportunity to ask hard questions, try to poke holes in the solution, better understand the scope and timelines proposed, help align on priorities, and much more!

While doing all of this, leaders should remember to speak last.

Last week, I was sharing some thoughts with a colleague about building diverse teams. I figured I should spend some time trying to better articulate my ideas.

Throughout my engineering career, I've been part of hundreds of interviews ranging from software engineers to engineering managers and directors. One feedback that I often see from interviewers that I try to push folks away from is: "this candidate is a culture fit" or "this candidate is not a culture fit".  Let me explain why.

First of all, the term culture fit is overloaded. No one really knows what it means when an interviewer gives that feedback after an interview. Are they referring to team fit or company fit? Are they referring to a specific behavioural trait? Are they referring to someone's background? Are they referring to the programming languages that the candidate knows? Are they referring to a candidate's accent?

Culture can mean a lot of different things. When an interviewer uses culture fit as part of the candidate's interview feedback, it does not provide any meaningful signal to the hiring manager.

Second of all, if we want to build diverse teams (shouldn't we all?), then we should be looking for candidates that do not necessarily fit our current culture. We should not be looking for culture fits but rather for culture additions. More concretely, instead of asking yourself if the candidate is a good fit with our current culture, you should ask yourself if the candidate can add to our culture.

This is especially important as part of a company's DI&B efforts. If you have a team of graduates from Stanford, what does a culture fit look like in this scenario? Is it another graduate from Stanford or an Ivy League school? That's not necessarily great for diversity! A culture add would be someone from a different background and that brings a different professional outlook. A culture add is someone that can bring in a different point of view, represent more users, and level-up the team's overall culture.

Hiring for culture fit is another way of signaling that we have a fixed mindset as opposed to a growth mindset. Said another way, we prefer to prioritize our comfort zone and familiarity over challenging our beliefs by bringing in diverse people.

A team should be greater than the sum of its parts. I aim to hire based on a team's gaps: diversity, technical, seniority, etc. Every new hire should add to a team's culture and technical expertise. And with every addition, the team will be better for it.

I initially intended to only share this post internally at Stripe. I have since tweaked it a bit in order to share it externally in the spirit of learning and growing in public.

Having recently reached my 90-day mark at Stripe, I wanted to take a moment to reflect back on this period and, on the flip side, to also reflect on what I want to dig deeper into in the upcoming weeks.

Feedback is critical

One thing I’ve struggled with so far is understanding how well I am onboarding to Stripe and how I am doing as a new hire in my role. With so many moving pieces, I’ve found it difficult to gauge how successful or not I have been in my role thus far. Because of this, I started asking for a lot of feedback over the last few weeks. I’m a big advocate for 360 feedback. I’ve asked for feedback from my boss, my peers, and my direct reports. Thank you to everyone who took the time to provide feedback. I know that providing good and actionable feedback is a time-consuming process and I truly appreciate everyone’s time. If anyone has more feedback to provide, please feel free to share it with me (anonymously or not).

Move with urgency

Stripes (this is how we call Stripe employees) have a high sense of urgency and it’s contagious. It’s very exciting to be surrounded by motivated people that are at the top of their game and move fast. It gives me more energy and drive. Things at Stripe also move very fast: decisions are made quickly, feedback on proposals is given quickly, initiatives and scope change quickly, etc. Folks had advised me about this value during my interview process and I was somewhat prepared for it, but Stripe’s high sense of urgency exceeded my expectations.

Meeting people IRL

In my short time at Stripe, I’ve had the privilege of attending 2 offsites: a team offsite in NYC and a manager summit in SF. These offsites provided an incredible opportunity to meet my team and peers early in my tenure here. They helped accelerate my rapport with these folks and created a faster culture of trust in my opinion. They also provided key opportunities to have deep-dive conversations on important topics both at the team offsite and within my organization’s leadership group at the manager summit. I look forward to the next offsite and the great conversations that will come out of it (in Montreal, anyone?)!

What I want to dig deeper into

As I reflect back, I’m pleasantly surprised by the amount of knowledge I’ve gained in my first 3 months. It’s easy to lose track of what I’ve learned so far or how much I’ve grown without taking time to reflect back on my tenure at Stripe. That said, I know there’s a ton more that I want to dig deeper into and learn. Here’s a non-exclusive and non-prioritized list of what’s top of mind for me at the moment:

• I want to write more. This blog post is my first attempt at writing regularly and stemmed from feedback that I recently received (did I mention that I love feedback?). I’ve found that Stripes who excel at their work tend to write a lot and are very good at distilling their thoughts into posts. It’s a skill that I want to spend more time building over the next few months.

• I want to spend more time playing with queries from our data warehouse. I’ve consumed a lot of powerful dashboards that folks have built but I haven’t spent enough time building my own queries and dashboards. I know there’s a lot of value from an API perspective that can be gained from this data and so I want to carve out the time to do that.

• I want to learn more about the different ways our deployments can fail. [The rest of this item is redacted for confidentiality reasons]

• [The rest of this list is redacted for confidentiality reasons]

Photo by Saulo Mohana on Unsplash

I recently hired four new engineers for the API team at GitHub. Starting a new job is never easy, and I feel like it is especially harder when you land at one of your dream jobs.

As part of their interview process and onboarding, I've been thinking a lot about how to help our new teammates be as successful as possible and what advice I can give without overwhelming them with information. It ended up boiling down to this:

Do not rush to show value.

What does that even mean?

I can't speak for everyone, but I and many other new comers had pretty big imposter syndrome when we joined GitHub.

These questions were always top of mind for me: How did I earn this job? Will I live up to expectations? Will they figure out that I'm a fraud? How can I prove myself as fast as possible?

This mentality is more harmful than anything. Rushing to show value is not helpful, and most people tend to do mistakes when they feel rushed.

Furthermore, they do not have to prove themselves. The fact that they successfully went through our interview process and that we extended an offer out to them is proof in and of itself that they deserve it.

In fact, they should trust our decision-making process that led to their hiring, and hopefully remove some pressure off of their shoulders.

Learn to walk before you run

Every step in the onboarding process is important, and the goal is not to skip them in the spirit of moving fast. New hires should focus on learning to walk before they can run. I understand that it is challenging to not be as productive as you know you can be, but the onboarding process is a great opportunity to solidify your foundation and understanding of your new "company's system and architecture.

These steps will serve you well in the future:

• Taking the time to digest all the information you're reading.

• Asking questions.

• Digging deeper into the code to better understand how the system works.

• Thinking about the big picture, and how the different parts of the system interact with each other.

• Bookmarking important links that you'll want to refer back to in the future.

• Pairing with other engineers.

• Listening and participating in meetings.

• Taking notes.

The goal is to set yourself up for future success. If you skip a bunch of important steps, you (and others) will quickly notice the gaps in your understanding.

Conclusion

Imposter syndrome is real, and a big topic on its own, but ultimately it is important to acknowledge that it exists and to also understand that reacting to it by rushing your onboarding is not the key to success.

Instead, take a more steady approach by solidifying your foundation and understanding of your new company, and you will be better set up to show all the value that you can bring to them.

Photo by Bonneval Sebastien on Unsplash

As a follow-up to my story about Introducing Engineering Design, I share the step-by-step guide I put together for my team when I first introduced this concept to them.

Feel free to use it and modify it as needed for your own team and use cases. I'd love to hear feedback about what worked and what did not work for you!

Updates to our development process

1. A new "In Design" step that tickets go through.

• If a ticket is simple and does not need a design, feel free to skip that step. The goal is for the assignee to consciously make that decision based on common sense.

2. A 30-minute meeting reserved from 10:30-11am EST every day for engineers that need to talk with other engineers, EM, PM, or designer about their ticket under "In Design".

• Not all tickets will require a conversation or this meeting.

• The goal of this meeting is to ensure that we are available to chat with the assignee if they need us, and that the conversation is time-boxed to 30 minutes, which means that some work and thought were put into it.

• I do not expect us to have to attend this meeting every single day, but the idea is to have that time reserved for when we do need it.

Benefits of this design approach

1. Align on the implementation prior to any development so that there are no surprises during PR reviews.

• We should not be presenting code in these meetings — this is not a review meeting. Instead, we should be presenting documentation, engineering specs, diagrams or pseudocode.

2. Make the end-to-end development cycle faster (shorter) by investing time up front so that PR reviews are more efficient.

3. Identify estimate discrepancies early in the development cycle.

4. Opportunity to do knowledge transfer when talking about different implementation approaches.

5. Empower other engineers on the team and bring them along on the ride.

If a design exercise is needed

How to run efficient design meetings

There are 3 approaches that should be used by the proposer to ensure everyone's time is respected and that the meetings are beneficial:

1. The proposer comes to the meeting with a proposal, and asks for thoughts / opinions / breakdown of their idea.

2. The proposer comes to the meeting with multiple options (a la DACI): "I am debating between options A, B, and C, any suggestions?"

3. The proposer is struggling to come up with good implementation ideas and uses the 30-minute meeting as a brainstorming session with their fellow engineers. Even though this is a brainstorming session, the proposer has done some initial homework on the requirements and understands the problem to solve.

Responsibilities of the proposer

1. At the start of the meeting, state the end goals for the change.

• Be as specific as possible

• Provide pseudocode examples of final implementation if it makes sense

• Enumerate all affected packages/services/systems
  

2. Can the change be performed incrementally?

• If they cannot, why not?

• The change is insoluble and can only function properly as a whole (should be avoided).

• The change is so small that it does not make sense to break it down
  

3. Break the change into discrete increments.

• Be specific about each increment.

• Eliminate ambiguity where at all possible.

• If the next increment depends on findings from a predecessor, state that up front, so that everyone is on the same page. This should be avoided whenever possible as it introduces uncertainty for anything downstream.
  

4. Quantify and capture all increments in the issue tracker.

Responsibilities of the team

The team (defined in this section as everyone involved in the design decision process except the proposer) is responsible for the following:

1. Provide timely feedback and a definitive 👍 / 👎 decision on the proposed design by the end of the meeting.

• If the design is not fully understood, or if it is only understood up to a certain incremental stage, then this should be explicitly stated and agreed upon by all team members. The proposer should work on reducing risk and unknowns to make it clearer, clarify the proposal based on the feedback received, and present it again when ready.

2. Consolidate opinions.

• The focus of each design step should be the most immediate subject matter. Peripheral concerns should be addressed in other design meetings, unless the impact is unavoidable.

• There's really no way to quantify this. We all know bikeshedding when we see it.

• If there are competing ways to handle the issue, then the team and proposer should reach consensus on the best way to go forward.

Disagree and commit

Once a decision has been made, I expect that everyone gets onboard. We will reopen the discussion only if there is significant new information.

Photo by İrfan Simsar on Unsplash

I recently published 2 new stories about Engineering Leadership on Plato. These stories cover different challenges I had to overcome as an Engineering Manager.

In the first article, When Words Bear More Weight , I discuss my transition from an individual contributor to a manager and how that impacted my participation in technical discussions.

In the second article, Introducing Engineering Design , I discuss the constant need to improve team processes, how I introduced an Engineering Design process, and what were its most immediate benefits.

I hope you enjoy the articles and that they'll be helpful in your own journey.

PS: If you found these articles helpful, please share it with an engineer or manager that could use help boosting their career.

Photo by Element5 Digital on Unsplash

I often talk to engineers who feel stuck in their current position and struggle to get much progress on getting promoted. They believe they have what is needed to get to the next step. The problem is that their leadership team doesn't see all the value that they bring and aren't aware of all their accomplishments.

If you want to grow your career, then you have to be your own biggest advocate and show your value to folks.

You may have written a new library or service scaffolding that will save the engineering organization a ton of money and time, but no one knows that you were the one to build it so it doesn’t help you grow your career. You may have fixed a critical bug in the middle of the night that eliminated customer impact, but the right people didn’t hear about it.

The same concept also applies for freelancers — your customers need to understand the value that you bring to them. They're investing in you, and they expect a bigger return than their investment.

Getting out of your comfort zone

I usually get push back from engineers when I tell them they should advocate for themselves more. They don’t want to sell their value, they’re afraid of sounding too self-centred by doing so, and they aren't used to showing off.

I understand that concern, and showing off isn't the goal here. There are good ways of sharing your accomplishments where people will appreciate it. Here are some examples:

• Talk about your accomplishments to your manager more often (e.g. in 1:1s, tag them in status updates, etc)

• Give presentations to the team or organization about what you’ve learned and built

• Write a company blog post to share your knowledge more broadly (internally or externally)

• Hold office hours to help people use your new library or service

• Be more active in different Slack channels and help your colleagues out

There are many ways to increase your visibility and people’s awareness of your work without sounding cheesy. Most of the suggestions above help you achieve that while also helping others by sharing your knowledge! It's a win-win situation.

I would also suggest keeping a list of your accomplishments in a living document (Google Doc, etc) that you share with your manager. The two of you can continuously add to it as you accomplish things, and can refer to it during performance reviews or when thinking about future promotions. It's a good way to keep track of your accomplishments over an extended period of time. Another critical upside of writing these down is that it keeps a history of things in case your manager changes. You'll appreciate having that trail when you get a new manager a couple weeks before a performance review is due!

Final thoughts

The most important part is not to lie about your achievements and not to steal other people’s credit. For instance, if multiple engineers participated in an important bug fix, then give credit to all of them. No one likes having a colleague that actively steals the spotlight and doesn't give credit where it's due. People will catch on to this fairly quick.

It'll hurt your growth, network, and reputation more than it can help. It's also about being a decent human being and doing the right thing.

The infamous red dot associated with notifications makes us reactive. We see a notification and we tend to drop what we are doing to look at it.

In a creative job like software development or knowledge work in general, this is very disruptive because getting back “in the zone” or “in flow” takes a while. The impact of a single notification is huge and we should try to mitigate it.

Be proactive by controlling your notifications, rather than being reactive to them.

How I Handle Notifications

I’ve been toying with my notifications for a while now, trying to find the balance that works best for me. I’ve tweaked notifications on all my devices and adjusted them to what works best for me.

Only the upmost important ones make it to my watch: phone calls, important messages, Nest, etc.

My iPad is tweaked so that I barely have any notifications that can pull me out of flow. I mainly use my iPad for creative work such as reading, drawing, brainstorming ideas, and even coding so I need to protect my mental space as much as possible when I'm working on this device.

Group notifications in iMessage and Whatsapp are all muted across all my devices. I personally find group notifications very disturbing because they occur very often when a group is active, but are rarely important enough to require your immediate attention.

Overall, my system is still not perfect, but I feel like I’ve made good progress on taking back control and not being as reactive. This is an evolving process that I will keep iterating over, especially as I install new applications. For instance, I've recently been using the GitHub mobile app and I get important work notifications through it. However, I have not yet figured out in which bucket this app should go. Is it important enough to warrant a watch notification? Time will tell (no pun intended).

Have you felt the need to tweak your notifications? How do you handle the constant flow of notifications? Let me know below — I'd love to hear about your experience and learn from it.

I often talk to engineers who are interested in making the big jump to management and becoming engineering managers, but they're not sure if it's the right fit for them. They are (understandably so) concerned if they will like it or not, and what their day to day will look like. Here a few points you should consider before making the big jump into management.

It is not a promotion

Switching to management is not a promotion. Rather, it is a career transition and you'll be starting at the bottom of the career ladder where you'll feel like a novice at the beginning. Depending on your previous position as an Individual Contributor (IC), this might not even come with a raise. However, you'll have an opportunity to increase your impact on the company and business. You'll be learning something new every day. You'll help people grow in their career and as individuals. There are a lot of pros to being a manager, but don't make the switch if your main motivator is to climb the career ladder and make more money. In this case, you might want to stay on the technical track and grow there.

Get ready to code much less

As a manager, you'll be coding a lot less (read: almost not at all), and you have to be okay with that. I personally work on side projects a few hours per week to get my coding fix and keep learning new technologies, but I do not contribute meaningful code at my day job and that's 100% fine with me because my focus is on delivering more impact to the team and business by focusing on higher-leverage areas. A key concept you should also aspire to is to stay involved with code, but stay out of critical paths such as being a required reviewer or a blocker for shipping a feature. Instead, you could work on a bug fix or internal tooling to help improve the team's velocity.

Pictured above are my GitHub contributions as an engineer VS manager

Your definition of success will change

As a manager, your definition of success will change. Successes are far more spread apart than as an Individual Contributor, and you will not be getting the same adrenaline rush. As an engineer, you might be getting multiple successes per day when you ship a fix or merge a PR — that adrenaline rush that feels good. As a manager, your successes might be helping the team re-align on a project, hitting a quarterly objective, helping an engineer get promoted, or writing a proposal that gets approved by the VP. As you can imagine, these successes take longer to build and are more spread out, and the adrenaline rush you get will also be different.

Meetings, meetings, meetings

Your days will mostly be spent in meetings, despite how much you try to reduce the number of hours spent in meetings. I've found certain tricks to help me take better control of my calendar — and it helps a lot — but the bottom line is that you have to attend and even run a lot of important meetings. These meetings include (ideally weekly) 1:1s with your direct reports, team planning meetings, leadership and organization meetings, etc. Because of that, you'll also have less uninterrupted chunks of time so you will be less likely to "be in the zone" unless you are very defensive with your calendar. For instance, I block out large chunks of time on my calendar to ensure that I get regular focus work done and don't jump from a meeting to another.

Finally, this is not a one-way door

It's important to note that making the switch to management should not be a one-way door. I suggest trying it out for 1-2 years to gain experience, a different perspective, and gain insights into how your manager thinks, and then deciding if you want to pursue it further or would prefer switching back to being an engineer. On average, it takes about 2-3 years before your skills erode so you should still be in a relatively good place to jump back to engineering after 1-2 years.

If these do not sound like blockers to you and are motivating instead, then you should be well prepared for making the switch to management. I hope I was able to provide more insight into what a manager's role entails and that I brought up some good points for you to consider if this is the right fit for you or not.

An important part of your work in software engineering is to provide estimates or level of effort to your stakeholders: your boss, your peers, and your customers. It can be a stressful part of your job since you are held accountable for your estimates, and let's face it, no one likes to be late on a deadline that they've provided.

A critical part of every Engineering Leader's job, including your manager's, is to challenge the estimates they receive. It's their job to question you on the estimates, ensure that you are building the right thing, that you looked at it from different angles, that you are taking the simple approach to building it, and to push you on shipping it sooner.

This might induce some fear into you. You might feel pressured to reduce the estimate and over-promise on the timeline. This is normal. It's important to take a breath, and not commit on the spot to a new date. Instead, go back to the drawing board and re-visit your plan with a clear head. You might come to the same conclusion and the same date after all, and that's also okay.

Now is the time to be firm with your estimates. You've done your homework, and you and your team know your project best. If you're still getting pushed on the timeline, make sure to explain how you've come up with the estimate but remain firm.

You should also provide different options. For instance, new estimates with a reduced scope or new estimates with more engineers working on the project (if you can add more engineers). Ultimately, it is important to provide options rather than excuses.

It’s important to note that at this stage, the disappointment of hearing a higher than expected estimate will be a lot easier to swallow than the future disappointment had you reduced the timeline and not met it. In my experience, the disappointment of over-promising and under-delivering is very unappreciated, and erodes trust quickly, so you should avoid this path.

In fact, your stakeholders will appreciate a well-thought out plan and explanation on the estimates, and their trust in you will grow if you meet that estimate. They will respect the fact that you know your project enough to make well-educated decisions, and that you deliver on your promises.

This is why — if done right — estimates can help build trust with your stakeholders. The more you deliver on your estimates, the more trust they'll have in you.

The same concept applies to building trust through your commitments and how well you follow through with them, but I'll keep that for another time.

I hope you enjoyed this article, and do not hesitate to reach out if you have any questions or comments. I'd love to connect!

I recently listened to a Tim Ferriss podcast interview with Safi Bahcall, a physicist turned biotech entrepreneur, where Bahcall was talking about system mindsets and it really resonated with me.

I’ve often focused on analyzing why something fails — why I didn’t get the result I expected — and trying to learn from the failure so that I can improve and avoid repeating the same mistakes. This mindset has proven valuable to me so far, and I’ve definitely learned a lot from my many failures. I also know that this is a mindset that is often pushed for at companies (“move fast and break things”, anyone?). This is called analyzing the outcome.

However, Bahcall was talking about elevating our point of view and looking at this from a higher perspective. Instead of analyzing the failures (or the outcome), companies and individuals should analyze the decision process. Why did we decide to do this specific move, what context did we have at that time, and what did the outcome look like?

This system mindset has a couple strong benefits in my opinion that I’d love to dig into further.

Avoid Repeating the Same Failures

The first benefit is that, when analyzing failures, we are looking past the outcome and spending more time analyzing the process that got us to make that decision. For instance, if the new hire on your team turned out to be a bad fit after a couple months and you decided to let them go, it would be easy to chalk this off on the candidate missing some key skills or because they were a bad culture fit. However, this would not prevent you from repeating the same mistake in the future. Instead, you need to analyze the process that got you to hire this candidate. What can you improve in your hiring process to better vet candidates? If this new hire did not have the required skills, how can you improve your process to specifically vet for these skills?

By shifting your focus to the process rather than the outcome, you are addressing the concerns at their root and setting yourself up for success by avoiding the same mistakes over and over again.

Analyzing the Successes

All too often we are focused on analyzing our failures but not successes, and understandably so. Why would we invest our time and effort analyzing successes when we got the result we desired? By shifting our focus and prioritizing a system mindset, we start to realize that analyzing successes is important, too.

“There’s one more crucial aspect of system mindset that great companies do and average companies almost never do: analyze successes as critically — if not more so — than failures.” — Safi Bahcall

In fact, a successful result does not mean that your decision making process was not flawed or wrong. Maybe you were lucky and got the desired result despite making some wrong decisions along the way. For instance, if your team was able to successfully meet a deadline, does that mean that you accurately estimated the level of effort required to complete the project and gave an accurate ETA? Maybe, but maybe not, and the only way to know is to analyze the process and the success. Some questions you could ask yourself here are:

• Did your team members work overtime to meet your optimistic deadline?

• Did you have to change the scope to stay within your ETA?

• Were you simply lucky enough that you did not run into any major unknowns despite the fact that you had not done enough research to identify the risks at the start of the project?

There is obviously a lot more that goes into breaking down a project and trying to identify an ETA, which makes even more of a case that you should analyze both successes and failures so that you can keep improving your decision process.

There is a saying in sports that “a win is a win” and that teams will take the ugly win and move on (e.g, a 7-6 hockey game). However, that’s a cliche and not entirely true. Coaches will dig into these ugly wins just as much as the losses. They will review the game, take notes, and give their feedback to the players so that they can improve before the next game, despite the fact that they won.

To quote Bahcall, “the [system] mindset means carefully examining the quality of decisions, not just the quality of outcomes.”

The Decision Process Is Key

I've mentioned this already but I cannot stress it enough: the decision process is key. A successful project does not always correlate with a good decision process, and vice-versa, a failed project does not mean that the decision process was necessarily wrong.

The outcome does not correlate 1-1 with the decision process.

For instance, if you use your cellphone while driving but do not get caught by the police or get into an accident, does this mean that the successful outcome was related to a good decision process? The answer is obviously no, and if you do this enough times, you will end up getting in trouble, or worse.

On the flip side, if you invest time getting better, and making the best possible decisions with the available information you have, the result will be a success more often than not. You might get unlucky sometimes and fail, or you might not have had access at the time to all the information you needed to realize that this was going to fail, but you will be successful in the long run if you stick to a good decision process. Failures will happen, but you are increasing your odds of achieving success.

Imagine that there are 99 other parallel universes that exist our there. If you stick to a system mindset and keep making good decisions, I’d like to believe that the outcome will be successful on a very large percentage of these universes.

The odd failure will occur every now and then, but you would be setting yourself up for success.

Having transitioned to an Engineering Management role 6 months ago, one of the biggest challenges I had to overcome was learning not to immediately share my opinion or thoughts. I had previously read articles and listened to podcasts on how leaders should speak last, or how the leader’s opinion is often taken as a directive rather than what it really is: simply another opinion. To be honest, I did not fully buy-in or relate to this concept as an individual contributor. However, this hit me hard in my new management role.

The first time I realized that this was a challenge was during a team meeting. We were all brainstorming solutions on a technical problem we were trying to solve. When it was my turn to speak up, I remember starting my sentence with “this is just my opinion, but I believe we should do XYZ.” When I was done, an engineer responded to me with “what I am hearing you say is that we should do XYZ, but I do not agree with that.”

After the meeting concluded, I took some time to reflect on what had just happened. How could I have been clearer or expressed my opinion differently, without having it seem as if I was pushing a decision onto my team members? I legitimately wanted to share my opinion and see what the engineers thought of it. I was not pushing for my proposed solution to be the right one.

I then remembered listening to an interview with Katie Womersley where she said that brainstorming as a leader without your team knowing that your brainstorming is really dangerous. She also went on to say that you have to be explicitly clear that you are brainstorming — or in creative mode — and that what you are saying does not necessarily mean that it will be implemented.

So, the first lesson I learned is that simply saying this is my opinion does not work, and that I should have been clearer that I was in brainstorming mode and that I do not intend us to implement what I say.

Another podcast that resonated with me on this topic was Adam Grant’s interview with former U.S. Attorney Preet Bharara (available on iTunes). This episode had nothing to do with technology or engineering, but had some very interesting leadership lessons in it. The one that really caught my attention was Preet suggesting that leaders should speak last. In his experience through many different leadership roles, people will often lean towards the boss’ opinion. They might disagree with it or have different opinions, but they will most likely lean towards their boss’ opinion and not share their own. For that reason, leaders should always speak last.

Our mandate should be to listen first, and speak last.

Let your team members go first. Give everyone a chance to speak up. Let them share their opinion and concerns. Then, when everybody else had a chance to speak up, you — as a leader — should speak and share your opinion.

The benefit of this approach is that you will not bias anyone else’s opinion. You will hear what they truly want to say and think. You will have more information at your disposal to make an informed decision. You will have the chance to hear more opinions than if you had went first and everyone agreed with you.

This should be our objective as leaders. We should allow everyone to speak up, listen to their feedback, and use that knowledge to make the best possible decision.

As an Engineering Manager, I adapted this mantra to fit my technical field. Now, when I’m talking with my team members or when we are brainstorming solutions, I listen to the conversations and speak last. But, I also focus on asking a lot of questions instead of proposing solutions. I try to poke holes into the team’s proposed solutions to see what will remain standing at the end. I ask questions that will push the engineers to think through different edge cases that they may not have thought of. I want them to realize that the solution may not be viable because of a question that I asked, or because a question I asked made them think of another potential loophole. This will help them grow, make them practice thinking through different use cases, and learn to poke holes into solutions when discussing among each others.

To summarize, the way I have overcame my biggest challenge as a manager so far has been to speak last and let my team members go first. Furthermore, I also ask lots of questions about the proposed solutions rather than proposing a solution myself. This has worked great for me so far and has helped me improve a valuable skill: the art of listening.

If you use Redux, you’ve most likely used redux middleware before through - for example - redux-thunk, redux-promise-middleware, redux-saga or redux-logger. These are important middleware in most apps but yet some of us (including me) take this concept for granted without digging any further.

With that said, I recently had to implement a caching solution in a large application and, after doing some research and poking one of my colleague’s brain (thank you Rec!), decided that implementing a custom middleware was the best approach for this, mainly because:

• It makes for cleaner code

• It makes for more maintainable code (think separation of concerns)

• It groups all the caching logic in one location

In this article, I’d like to explain what a Redux middleware is, and how I implemented a custom middleware.

What is a Middleware?

For backend developers, a Redux middleware is similar to a middleware in Express or in ASP.NET. Although it is not exactly the same thing, it’s similar and represents a good way of thinking of this concept.

In Redux, a middleware is used to intercept dispatched actions before they make it to the reducer. This means that when you call dispatch on an action, the action goes through a (or many) middleware before hitting the reducer - if it even makes it that far, but more on that later.

You can apply multiple middleware to a Redux store, which means that the action will have to go through all the middleware before making it to the reducer. The order of execution is actually the order in which you pass the middleware to the store. Also, at any point in a middleware, you can chose to stop forwarding the action, which will end the cycle.

For instance, in my caching middleware, I first check if the same action is already in progress. If it is, I cache the latest payload and interrupt the flow by returning out of the middleware. Since I’m not calling next or dispatch, the action flow will not continue.

Why Use a Middleware?

As expressed above, actions go through middleware before getting to the reducers, which gives us a great way of applying logic or filters to all actions. This means that the logic is grouped in one place instead of being spread across reducers, that we can easily identify where to investigate if a bug occurs, and we can swap that code out if we ever need to.

Some use-cases that benefit from using middleware:

• Logging: every action goes through this middleware, so we can log its type and payload for debugging or tracking purposes.

• Error tracking: if any asynchronous action returned an error, this middleware can display a notification.

• Caching: Only call your API for the same action once, and cache the result for future calls.

• Auth requests: For API calls, apply an authentication token before sending out the request.

• So much more :)

Writing a Middleware

To define your own middleware, you need to write a function with the following signature:
store => next => action => result

This looks very confusing at first glance - I hear you - so let’s break it down a little bit:

• store is the Redux store instance that will be passed to your middleware.

• next is a function that you need to call with an action when you want to continue the flow execution, which means passing the action to the next in line: either the following middleware or a reducer.

• action is the action that was originally dispatched so that you can access it, apply logic based on the action, and eventually pass it on using next.

• result is the value used as the result of the dispatch call.

Finally, to apply this middleware to the Redux store, you need to call applyMiddleware when creating the store through createStore(). Here’s a nice example from the official Redux documentation:

import { createStore, combineReducers, applyMiddleware } from 'redux'

let todoApp = combineReducers(reducers)
let store = createStore(
  todoApp,
  // applyMiddleware() tells createStore() how to handle middleware
  applyMiddleware(logger, crashReporter)
)

In the example above, the middleware logger will be called first, followed by the crashReporter middleware since this is the order in which they were passed to applyMiddleware.

The Caching Middleware

As mentioned in this article’s outline, I implemented a caching middleware recently to solve a very specific issue. I know that there are existing caching middleware out there, but I needed something small and specific to the issue at hand, so I wrote a few lines of code instead of using an existing library.

For this issue, I had to make sure that a WYSIWYG editor only called the backend sequentially when saving the content. For instance, if auto-save kicked in while a save was already occurring, I did not want to send the text to the backend until the previous call completed. The same concept also applies if the user hit the Save button multiple times.

Here’s what my middleware looks like:

export default function textUpdatesMiddleware () {
  return store => next => action => {
    if (action.type === UPDATE_TEXT) {
  	// Check if the new text in the payload is different from what we already have in the store
      if (!shouldSaveText(action.payload, store)) return

	  // Are we currently saving?
	  // isUpdatingText is set to `true` in a reducer
	  // A reducer listens to CACHE_TEXT_UPDATE and will store the payload into `pendingTextUpdate`
	  // We only cache the latest content, not all of them
      if (store.getState().isUpdatingText) {
        return store.dispatch({
          type: CACHE_TEXT_UPDATE,
          payload: action.payload
        })
      } else {
  	  // This uses `redux-promise-middleware`
        return store.dispatch({
  		type: UPDATE_TEXT,
		  payload: {
      	  promise: http.patch(apiEndpoint, content)
    	  }
  	  })
      }
    }
	// This uses the `redux-promise-middleware` convention of _PENDING, _FULFILLED, _REJECTED
    if (action.type === UPDATE_TEXT_FULFILLED) {
      const pendingTextUpdate = store.getState().pendingTextUpdate
      // If we had a pending update
      if (pendingTextUpdate) {
		// A reducer listens to UNCACHE_TEXT_UPDATE and will clear `pendingTextUpdate`
        store.dispatch({ type: UNCACHE_TEXT_UPDATE })
		// Allow the fulfilled action to continue on to the reducers
        next(action)
        // Dispatch the update with the cached content
		return store.dispatch({
          type: UPDATE_TEXT,
          payload: pendingTextUpdate
        })
      }
    }
    // Nothing to do here - keep calm and carry on
	next(action)
  }
}

Based on the code above, it’s worth noting that Redux applies some magic when you call store.dispatch from within a middleware and the action will travel through all the middleware again, including the current middleware that dispatched it. However, when you call next, the action moves on to the next middleware in the flow.

Conclusion

This middleware solves a specific issue I was experiencing, but we could just as well make it more generic so that it applies the same concept to all (or a subset of) actions. At this point, I don’t have any need to make it generic so I did not want to over-engineer it, but it’s worth noting that it’s definitely doable.

If I hadn’t applied this logic in a middleware, I would have had to validate that an API call is not currently in-progress from a reducer, then dispatch calls from the reducer to cache the content, and also listen for the FULFILLED action from the reducer or the then on the http call, and then re-dispatch the action. This gets messy real quick and doesn’t scale well if we need to make it more generic.

I hope this was a good introduction to middleware and that it covered enough of the basics to get you started if you ever need to write your own custom one.

My final piece of advice is that research and discussions are very valuable. I am very glad I decided to not go with my original (bad) approach because something felt wrong and that I did more research, discussed it with a colleague, and ended up settling on using a middleware because the final result is a better solution.

Credit

• The official Redux documentation section on Middleware.

• You Aren’t Using Redux Middleware Enough.

What Are Business Rules

Before jumping in to the technical stuff, let me clarify what I mean by business rules so that we are all on the same page.

Business rules, sometimes referred to as business logic or application logic, are what governs how your app should function and what validations to apply. For instance, a business rule at Twitter is that tweets cannot contain more than 140 characters (if we dumb it down for the sake of this example and remove logic such as URL shorteners, replying to someone, etc). This means that before sending a tweet, Twitter needs to ensure that it respects the character limit.

I'm over the character limit 👆.

Where this validation should be made is exactly the topic of this article. Let's dive in!

Client-Side Validations

Client-side validations are useful in order to provide immediate feedback to the user, which makes for better user experience. For instance, when writing a tweet, we can instantly see if we went over the 140-character limit or not.

However, client-side validations are not enough on their own since they are easily bypassed. Browsers (and mobile apps for that matter) can be "hacked" or toyed with in order to bypass certain restrictions put in by the application's developers. In fact, browsers allow you to inspect and modify the html and JavaScript quite easily, so it's a bad idea to count only on frontend validations.

For instance, it's easy to re-enable the Tweet button in the browser even if we went over the 140-character limit. By doing so, we are bypassing the client-side validation and sending the longer tweet to the backend, as so:

• Re-enabling the Tweet button:
  

• Sending the long tweet to the backend, as seen in this POST request:
  

• This is gracefully handled on the server and a friendly error message is displayed to the user:

To protect the integrity of your data and app, it is essential to enforce your business rules on the backend as well.

Backend Validations

Backend validations allow you to take another look at the data - now that it's made its way from the client to the server - and ensure that it respects the business rules. In our previous example, this is where you would ensure that the tweet being sent is indeed 140 characters or less. If not, the server should return an appropriate error to the client so that it is handled gracefully and the user knows what to do next.

The backend is also where you can ensure data integrity by validating the information being saved to the database, making sure it does not contain any ill-intented information, that the types are good, etc. This should also be done at a lower level than the API, such as an ORM or even the database, but I include those in the big backend bubble. Separating concerns and where exactly to apply these validations is a discussion for another article.

One of the reasons why validations on the backend are better suited for business logic is that you have control over your server and the code executed on it, as opposed to client-side code. This is not being run in a browser or on a mobile device and is not being manipulated by a user. It is code that you wrote and know how it will behave.

Conclusion

One important thing I'd like to clarify here is that both frontend and backend validations are important but their main goal is different.

Frontend validations are great for giving feedback to the user. Imagine having a user filling up a long form and submitting it, only for it to be rejected by the server because of an empty input, and prompting the user to re-fill the form. This would obviously be frustrating to users and is avoidable by using frontend validations.

Backend validations, on the other hand, are meant to ensure that the business rules are indeed applied and respected, and for data integrity.

I hope this was helpful and clarified the differences between the two parties. Let me know if you have any questions, and please share this article if you found it helpful 🙏. Thank you for reading.

How does Facebook Live scale? Let's dig in and analyze!

The Challenges

Before analyzing the architecture and how Facebook Live can scale to that extent, let's look at some of the challenges that building such a product comes with.

Chris Cox, the company's Chief Product Officer, had an interview with Wired[1] back in April of 2016, where he enumerated the following challenges, considering that there were over 1.86 billion monthly active users on Facebook by the end of 2016:

• Needs to be able to serve up millions of simultaneous streams

• Needs to be able to support millions of users on the same stream

To quote Chris Cox, this "turns out it’s a really hard infrastructure problem", which makes it even more exciting to deconstruct and analyze.

Another unique challenge with live video is that traffic comes in spikes, and your infrastructure must be able to handle huge traffic spikes. For instance, when a celebrity starts a live video stream, there will be a huge traffic spike when users join and while the video is still streaming live, and then it'll slow down drastically when the video ends but it will still by viewable by users, even if it is no longer streaming live. The main challenge will be to gracefully handle the spikes while it's streaming live.

The Architecture

For the purpose of this article, I'll be exclusively focusing on the high traffic spikes that occur when a user with millions of followers (e.g. a celebrity) starts a live broadcast. In cases like this, more than a million people could be watching the broadcast at the same time, and when they all join around the same time, this causes major stress on the servers and infrastructure.

When all these requests come in at once - which is called the thundering herd problem[2] - it can cause streaming issues such as lag, dropped packets, or even preventing users from joining the broadcast.

When there's a possibility you may run into such a problem, the first thing you should do is prevent all the requests from hitting your streaming server directly, which could be fatal and drop the server all together. Instead, you should aim at adding multiple layers that will filter these requests and ensure that only the necessary requests make it to the streaming server.

This can be achieved in many different ways, depending on the size of your product and the number of users. In Facebook's case, they chose the following architecture:

It's important to note here that Edge Cache servers are spread out across the globe to support Facebook's global reach. There's also a one-to-many relationship between the Origin Server and the Edge Cache, where multiple Edge Cache servers can send requests to the same Origin Server.

The flow works as follow:

1- The requests first hit the Edge Cache server closest to the user in order to reduce the latency between the user and the server. The Edge Cache servers are essentially a cache layer and do not do much processing.
2- If the requested packets are in the Edge Cache, then they are returned to the user.
3- If they are not in the Edge Cache, then the request is forwarded to the Origin Server, which is another cache server and has a similar architecture to the Edge Cache server.
4- If the requested packets are in the Origin Server, then they are returned to the Edge Cache who caches them before returning them to the user.
5- If they are not in the Origin Server, then the request is forwarded to the specific Streaming Server handling that live broadcast. The Streaming Server then returns the packets to the Origin Server, who caches them before returning them to the Edge Cache. The Edge Cache caches the response and returns the packets to the user.
6- Future requests for the same packets will then simply be handled by the Edge Cache and will not travel further than that layer, which speeds up the process incredibly and reduces the load on the Streaming Server.

As we can see, this architecture greatly reduces the number of requests that make it to the Streaming Server. For instance, if 5 requests make it to the Edge Cache sequentially, only the first one will go all the way to the Streaming Server and back, while the 4 others will immediately get a response from Edge Cache since it'll have cached it already.

However, this is still not enough for Facebook's reach. In fact, according to an article released by Facebook[3], this architecture still leaks about 1.8% of requests to the Streaming Server. At their scale, with millions of requests, 1.8% is a huge amount to leak and puts a lot of stress on the Streaming Server.

Facebook's Global Reach: Edge Cache servers are in pink, and Origin Servers are in yellow. Source: http://cs.unc.edu/xcms/wpfiles/50th-symp/Moorthy.pdf

Why is it Leaking so many Requests?

The first flaw in the architecture above is that simultaneous requests to the same Edge Cache will make it through to the Origin Server. Since the Edge Cache forwards all requests for missing packets to the next layer, if simultaneous requests ask for packet A and it is not in the cache, all those requests will be forwarded. Extrapolating this at Facebook's scale, we can quickly see how so many requests are leaked.

The second flaw in the architecture is that multiple Edge Cache boxes can send the same packet request to the Origin Server, which will in turn forward all those simultaneous requests to the Streaming Server since the packet is not in its cache. This is similar to the first flaw but it's happening at the Origin Server level.

Again, 1.8% may not seem like a lot for normal products, but at Facebook's scale, it is indeed an important issue that needs to be resolved.

Adjusting the Architecture for High Scaling

Facebook's solution to this problem is creative, yet simple to understand. When multiple requests for the same packet hit the Edge Cache, they are grouped together in a request queue and only one goes through to the Origin Server. This is called request coalescing. Once the response comes from the server, it is stored in the cache and then the requests in the queue are responded from the cache.

For instance, when 10 simultaneous requests make it to the Edge Cache, they are all added to the same request queue and only one goes through, which helps reduce the leaking of requests. If we compare this scenario to the original setup, where all 10 simultaneous requests would have made it through, we see a huge increase in performance.

The same concept was also applied at the Origin Server level, where all requests for the same packet - coming from one or many Edge Cache endpoints - are grouped together and only one of them makes it through to the Streaming Server. Needless to say that this greatly reduces the overhead on the Streaming Server, especially consider the amount of requests a live broadcast may receive.

Load Balancing

Another important tweak that Facebook implemented was load balancing for the Edge Cache servers. In some cases, with huge traffic spikes, Edge Cache servers can get overloaded and no longer perform consistently, despite the use of request coalescing. To avoid such situations, the load balancer redirects requests to the closest Edge Cache with availability for the request. For instance, if the Edge Cache closest to you is already serving 200 000 requests, then the load balancer might forward you to an Edge Cache a little further but that is serving half the number of requests, which would mean you would still be getting a response much faster.

Facebook determines which Edge Cache is available by constantly measuring the load on these servers and keeping track of its performance. It goes even further than that and uses an algorithm to predict the load before it happens, which is incredible. The basis of the algorithm is complex enough that it would require its own article so I will not be getting into that at the moment, but it is a very interesting topic that I may cover in the near future.

Request Coalescing Using Nginx

For those of you using Nginx, request coalescing can be enabled by setting the proxy_cache_lock config to on (default value is off), as explained in the docs here:

When enabled, only one request at a time will be allowed to populate a new cache element identified according to the proxy_cache_key directive by passing a request to a proxied server. Other requests of the same cache element will either wait for a response to appear in the cache or the cache lock for this element to be released, up to the time set by the proxy_cache_lock_timeout directive.

Conclusion

I had a lot of fun researching and dissecting Facebook Live's architecture and how the engineers were able to make the product scale to millions of users. Although we may never build products that reach such a high amount of users, there are great lessons here that we can use in our own products, such as how adding multiple layers in the architecture helps filtering the number of requests that make it through to the processing server. This, in turn, improves the performance and availability of the server, which provides a better product to users and helps scaling it.

CREDITS

1. Scaling Facebook Live at @Scale Conference

2. Scaling Facebook Live (2) at @Scale Conference

FOOTNOTES

1. Zuckerberg Really Wants You to Stream Live Video on Facebook ↩︎

2. Wikipedia: Thundering herd problem ↩︎

3. Under the hood: Broadcasting live video to millions ↩︎

I've wanted to contribute to Open Source Software (OSS) for a while now but always had excuses. What if they don't like my changes? How can I get started if I don't know the code base? What if I'm not good enough? This is also known as Imposter Syndrome and happens to a lot of people. I am not the only one going through this, and you're not either.

However, I just conquered my fears. This past week, I contributed to Open Source Software (OSS) for the first time. I enjoyed it so much that I contributed to a second project only a couple days later. You read that right. I went from being too worried to contribute at all to contributing to two big projects: The open source version of Facebook's Parse, and Microsoft's Visual Studio Code.

Here's what I learned from this experience and how I did it.

Finding the Right Project

Finding the right project is key to having a pleasant and fun experience. I wanted to make sure I contributed to a project I love and use daily. I wrote down a list of some of the Open Source software and tools I often use and the first names on my list were Parse and Visual Studio Code.

Picking an Issue

With that in mind, I decided to take a look at Parse's issues and filtered them by the Good First Task label. Personally, I wanted to start by fixing a bug instead of writing a new feature as I believe it's the best path to a first contribution.

The first bug I decided to grab was just recently submitted and no one had claimed it yet, so I commented on the issue that I'll be looking into it. This is important as you do not want to work on an issue someone else is already looking into, and vice-versa. Make sure to always comment on the issues you are looking into so that the other developers are aware.

Once you're ready to contribute, you should always read the project's Contributing Guide. This is a guideline of what the maintainers expect when you submit a Pull Request. This varies for each project so make sure to always read it.

Getting Started

The first step in fixing a bug, in my opinion, is to be able to reproduce it. It's extremely harder to assert that you fixed an issue when you cannot even reproduce it in the first place. Therefore, after you pick an issue to work on, you need to clone the project and run it locally in order to reproduce the bug. Also take some time for familiarize yourself with the codebase, the project's structure, etc. A great starting point is the project's documentation and Wiki.

Working on the Issue

Once you can reproduce the bug, you can get started on writing a fix for it. Here's what you need to keep in mind when working on an issue:

• Create a new branch for your changes.

• Make sure to always test thoroughly and write automated tests. This improves the chances of having your Pull Request merged and will always be appreciated by the maintainers.

• Make sure your code respects the project's code style and syntax. Most projects will have linters (e.g. eslint), so ensure that your code respects the linter's rules.

• When creating a PR, make sure to write a good description of what the issue was and how it's fixed. This can be in the form of a before / after description.

• Be ready to answer questions on your PR. The maintainers may have some questions regarding your code, which is totally normal. Do not feel offended by it but take it as an opportunity to learn and improve. They will not criticize or make fun of you. They are there to help you succeed, as it's also in their best interest if you continue to contribute to their project. Always keep in mind that they want to help you.

My Second Contribution

After my first contribution, I was hooked. I loved the feeling of seeing my work merged in Parse, and wanted to contribute more. I started looking at Visual Studio Code's beginner issues and found an issue I wanted to work on. I went through the same process as described above (claiming the issue, reading the Contribution Guide, etc.) and my PR got merged on the same day!

Update: VS Code's March release that contains my PR: https://code.visualstudio.com/updates/v1_11#_thank-you

Conclusion

It's an honour and a great feeling to contribute to such awesome projects. I will continue looking for different ways to contribute to these two projects, and possibly many more in the near future. I am also looking forward to writing a new feature for an Open Source project.

I hope this article helps you get over your fears of contributing to OSS. I am very curious to learn about your future contributions or issues you faced while trying to contribute to, so please feel free to let me know in the comments below.

You know JavaScript, but do you really know JavaScript? It's a great language, even though some may argue otherwise. Sure, it's got some bad parts, but it has improved a lot in past years and developers are getting much better at using JavaScript correctly and at following best practices. Strict mode is also getting better at preventing newer developers from making some bad JavaScript mistakes and unfortunately running into unwanted behaviours.

However, not everyone has heard of the term Hoisting or knows what it means. In this article, I'll explain what hoisting is and show different examples so that you can better understand what it's all about.

The JavaScript Interpreter

When you execute your JavaScript code, the interpreter goes through the code twice.

The first run through the code is where it does a safety check and small optimizations of your code. Safety checks such as making sure that the syntax is right, if there are any calls to eval or with, etc. Then, it optimizes the code as best as it can to ensure better performance when it is executed. This is also where hoisting occurs (more on this soon). This is also referred to as the compile run.

The second run is where it actually executes your code by going through it line by line, doing the assignments, calling the functions, and so on.

What is Hoisting?

Hoisting is when the JavaScript interpreter moves all variable and function declarations to the top of the current scope. It's important to keep in mind that only the actual declarations are hoisted, and that assignments are left where they are.

Hoisting is done during the interpreter's first run through the code.

Variable Declarations

Let's start with a basic example and look at the following code:

'use strict';

console.log(bar); // undefined
var bar = 'bar';
console.log(bar); // 'bar'

At first, you may think that the sample code would throw a ReferenceError on line 3 (console.log(bar);) because bar has not been declared yet. However, with the magic of hoisting, it won't throw a ReferenceError but the value of bar will be undefined at that point. This is because the JavaScript interpreter does a first run through the whole code and declares all variables and functions at the top of the current scope, and then, on the second run, will execute the code.

Here's what the same code would look like after the interpreter's first run:

'use strict';
var bar;
console.log(bar); // undefined
bar = 'bar';
console.log(bar); // 'bar'

Notice how bar is now declared at the top (var bar) but is not yet assigned at that point? It's a subtle but important difference, and this is why bar is logged as undefined instead of throwing a ReferenceError.

Function Declarations

Hoisting also applies to function declarations (not function expressions). Let's analyze the following sample code:

'use strict';

foo();
function foo() {
    console.log(bam); // undefined
    var bam = 'bam';
}

console.log(bam); // ReferenceError: bam is not defined

In this sample code, we are able to successfully call the function foo since it's a function declaration and therefore it is hoisted as-is to the top of the current scope. Then, foo will output undefined when calling it since, as in the previous example, bam is hoisted to the top of its current scope, which is function foo(). This means that bam was declared before calling console.log(bam) but it has not yet been assigned a value (bam = 'bam').

However, the important thing to note here is that bam was hoisted at the top of its current scope. This means that it was not declared in the global scope but in the function's scope instead.

Here's what the same code would look like after the interpreter's first run:

'use strict';

function foo() {
    var bam;
    console.log(bam); // undefined
    bam = 'bam';
}

foo();
console.log(bam); // ReferenceError: bam is not defined

Notice how foo() was moved to the top, and bam is declared in foo()? This means that, when you call console.log(bam) on line 10, it will not find the variable bam in the general scope and will throw a ReferenceError.

Function Expressions

Next, the third use case I'd like to cover is how function expressions are not hoisted as opposed to function declarations. Instead, it's their variable declarations that are hoisted. Here's some sample code to demonstrate my point:

'use strict';

foo();
var foo = function () {
    console.log(bam); // undefined
    var bam = 'bam';
}

This code throws a TypeError: foo is not a function error since only the variable declaration var foo is hoisted to the top of the file, and the assignment of the function to foo is done on the interpreter's second run only.

Here's what the same code would look like after the interpreter's first run:

'use strict';

var foo;
foo(); // `foo` has not been assigned the function yet
foo = function () {
    console.log(bam);
    var bam = 'bam';
}

What Takes Precedence?

Finally, the last use case I'd like to cover is that function declarations are hoisted before variables. Let's look at the following code:

'use strict';

console.log(typeof foo); // 'function'

var foo = 'foo';

function foo () {
    var bam = 'bam';
    console.log(bam);
}

In this example, typeof foo returns function instead of string, even though the function foo() is declared after the variable. This is because function declarations are hoisted before variable declarations, so foo = 'foo' is executed on the second run, after we call typeof foo.

On the first run, the interpreter will hoist foo() at the top of the current scope, and then will get to the var foo = 'foo' line. At that point, it realizes that foo was already declared so it doesn't need to do anything and will continue its first run through the code.

Then, on the second run (which basically executes the code), it'll call typeof foo before it gets to the assignment foo = 'foo'.

Here's what the same code would look like after the interpreter's first run:

'use strict';

function foo () {
    var bam = 'bam';
    console.log(bam);
}

console.log(typeof foo); // 'function'
foo = 'foo';

ES6

ES6 is the future and is what most developers will be using moving forward, so let's see how hoisting applies for ES6 code.

Hoisting doesn't apply the same way for let and const variables compared to var variables, as we saw above. However, let and const variables are still hoisted, the difference being that they cannot be accessed until the assignment is done at runtime.

From ES6's documentation:

The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated.

At the end of the day, it's a small technicality where the interpreter applies hoisting to these variables on the compile run but they'll throw reference errors when accessed before the assignment happens, essentially preventing us from accessing these variables before their assignment.

Conclusion

I hope this clarifies how hoisting works in JavaScript. It's definitely not as tricky or complicated as it sounds, but it does require us to breakdown the different use cases and trying different scenarios to understand how things work under the hood.

Do not hesitate to leave me comments or questions if you have any - I'd love to hear your feedback.