Democratizing Frameworks Through Developer Experience
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Yu, Sarah
Improving the developer experience (DX) of frameworks is often something that is pushed aside for new features. The cost of not understanding how things work results in the misuse of frameworks, bugs and, most importantly, frustrated engineers. This talk will explore the concept of DX through the lens of a former journalist. We will go over why having the lowest barrier to entry is important by democratizing development and providing access to information. We will also talk about the consequences of having subpar DX which creates an imbalance of power in the open source/developer ecosystem.
 Music So today I'm going to talk about how improving developer experiences vital to making frameworks more accessible and also contributes to a healthy open source ecosystem. Good developer experience helps bring engineers together from all levels toward the common goal of learning. And my hope is by the end of this talk you'll be inspired to work on developer experience features or at least think about and appreciate the ones that you consume. So I don't have a traditional CS background. My training is actually in journalism and that's really shaped how I tackle and solve problems in the software engineering space. I actually started my career out in Alaska at a public radio station where I was a journalist and also a web administrator. So I was writing stories about shucking oysters and gardening while also making sure that the website didn't go down and that's how I learned how to code. And because of my past, one helpful system I use is the classic Who, What, When, Where and Why thought process which I'm going to use in this talk to describe developer experience. So who am I? Why am I talking to you about this? I'm a UI engineer on the economic graph team. One thing that my team does is release a quarterly workforce report that shows trends in the US labor market. And this research is used by policymakers, by academics, by journalists. So I feel like I've really kept a tie back to my original training by working on this team. And like I said previously, I started out as a journalist. I really didn't have that much experience starting off on the job at LinkedIn three years ago. I really ramped up on the job. And when I was starting out, Ember seemed really new and exciting, but also scary and not a lot has changed since then, to be honest. So because of my past, I'm really passionate about working with the Reach Apprenticeship program at LinkedIn. And this program helps engineers from non-traditional backgrounds start full-time software engineering roles. And I really have to tap into the feelings that I had starting out, all of my fears, everything that I struggled with in order to empathize and mentor the apprentices. And also now I have a lot of experience seeing people from very different backgrounds go into the industry and how they learn and how they process concepts. And this has really inspired me to work on developer experience. So my main focus is on Ember data and the related add-ons, particularly M3, which is an alternative to DS model. And when I started learning Ember, that was the area that I found to be the most intimidating, but also incredibly interesting. I distinctly remember when I had to hook up my first API endpoint at LinkedIn, I was actually pair programming with someone on my team because I was really stuck. And honestly, I was actually on the verge of tears because I was really feeling like I didn't understand how anything worked. I was really struggling. I kind of had this feeling in the back of my mind that LinkedIn had made a mistake by hiring me. It was one of those really terrifying moments early on in my career. But I was able to push through it, I got a lot of help from really supportive people, and I felt like this incredible joy when I actually got everything to work. And I realized that I was actually learning one of the most powerful aspects of the framework. And that was incredibly exciting to me. And so that experience really motivated me to learn Ember data deeper because I wanted to make it easier for me to understand what was going on and also for other people to understand what was going on. And one of the more recent features I was responsible for was for adding support for M3 models in Ember Inspector. And this was actually just basically solving a pain point that I personally had. So what is developer experience? Developer experience is how engineers interact with your framework. It's really at the boundary between people and code. This can include documentation, which is the entry point for most developers and probably the first impression that they'll make of your project. If I go to a repo and it has a missing, outdated, or blank read me, I really hesitate to use the project. This also includes debugging tools, which engineers really appreciate, and they definitely remember if they're frustrating. This can also include framework ergonomics, and developers may not be consciously aware of good ergonomics, but they definitely know if a framework has clunky or difficult syntax. So unfortunately, developer experience is often not prioritized. And I believe one of the reasons why is because it involves people. And people metrics are notoriously hard to measure. It's a lot easier to say that you reduce the build size by X amount or sped up the website by X milliseconds. It's a lot harder to say that you made developers work X times faster with your feature. And just to be clear, though, developer experience is important. It should not come at the expense of user experience. Ideally, it should be a symbiotic relationship. So I actually ran into this problem myself on a feature that I'm currently working on, the concept of people metrics. So I'm trying to add a button in the data pane to output the store into the console. And this is actually a feature that I wish existed when I started out, because I didn't know that you could grab the store off the container pane. I didn't even know what a container was. I wasted so much time putting breakpoints into my code to try to grab the store. It was very frustrating. But I didn't want to build a feature that I just only found useful. So what I did is I actually talked to a lot of developers from all different levels. I heard about their pain points with Ember data. I also pitched my idea to see if they actually would find it useful. And that enabled me to gain a little bit of consensus and traction. So that I felt confident that what I was working on was actually something that I was working on. What I was working on was actually something that people wanted and that they would use. And I'll be making a PR for that soon, so keep an eye out for that. So why is DX important? If a framework has great DX, it's a lot easier for people to adopt it, to contribute to it, to answer questions, open issues, etc. And this really encourages diversity and a healthy open source ecosystem. If the framework is a delight to use, it really makes for happier engineers. If a framework doesn't have good DX, that really limits the type and number of people who can adopt it, contribute to the project, etc. This really can create conformity in the types of people that use it and the problems being solved. And also, if only a small number of people understand it, when developers are building out applications, there's a greater risk of bugs being introduced into the code and framework misuse. If the beginner can only understand what is happening by looking at the source code, that is a failure of the framework. And they'll probably go and find something else that's a lot easier to use. They don't have to use what you've built. And luckily, I'm not the only one who thinks that this is a problem. So, when should you contribute to developer experience? One great thing is that newcomers bring new and very valuable opinions to developer experience. New engineers have fresh eyes and new insights into the framework. They know it's hard starting off. These insights are really lost the longer you work with a framework. And people can contribute to different facets of frameworks as they gain experience, and each of these ladders is vitally important. And as engineers grow, they should continue to contribute to all levels of developer experience and help new engineers level up. And this will create a self-perpetuating ecosystem. I also really encourage people from non-traditional backgrounds to contribute to developer experience. I feel like there's a lot of pressure for people from non-traditional backgrounds to conform to the expectations of how software engineers should learn and solve problems. But we should really be using our unique backgrounds to make frameworks and the open source ecosystem a more open and engaging place for everyone. So, where can you actually contribute? One suggestion I have is to work on features or missing documentation that bother you or hinder you in your day-to-day work. This will help motivate you to contribute, and you'll also directly benefit from it. And a lot of small one-line changes exist. I personally have a huge pet peeve when it comes to deadlinks. Whenever I see a deadlink in the code, I'll make a pull request from the repo to fix it, and this ensures the next person will have access to the information. I've done this for Ember data, for the octane guides, for Mirage, so on and so forth. Usually this PR gets merged within days, and it really helps build relationships with the maintainers at the very least and kind of give you ramped up onto the framework. You can also add examples of how to use add-ons. So, if you start consuming an add-on and you kind of struggle with a bit to figure out how to get it to work, you can create a pull request in the readme with an example. And I've also done this with Ember sign-on queue unit, because like a lot of people, I actually spend a lot of time figuring out how to test my code in addition to writing my application code. And as you work on the framework more, you can add comments into the source code, you can work on developer tools like Ember Inspector. There are just so many areas out there that are just waiting, and maintainers really appreciate you making these fixes, even if they seem trivial, because honestly, a lot of times they don't have time to take care of these themselves. So, hopefully now you understand why I'm so passionate about developer experience and how important it is. DX is a great opportunity to help you learn more about the framework and also to help others learn. And if you're inspired to work on developer experience tools, I'm more than happy to talk to you about them, just let me know. So, thank you.
 Music  So today I'm going to talk about how improving developer experiences vital to making frameworks  more accessible and also contributes to a healthy open source ecosystem.  Good developer experience helps bring engineers together from all levels toward the common goal of learning.  And my hope is by the end of this talk you'll be inspired to work on developer experience features  or at least think about and appreciate the ones that you consume.  So I don't have a traditional CS background. My training is actually in journalism  and that's really shaped how I tackle and solve problems in the software engineering space.  I actually started my career out in Alaska at a public radio station where I was a journalist and also a web administrator.  So I was writing stories about shucking oysters and gardening while also making sure that the website didn't go down  and that's how I learned how to code. And because of my past, one helpful system I use is the classic  Who, What, When, Where and Why thought process which I'm going to use in this talk to describe developer experience.  So who am I? Why am I talking to you about this? I'm a UI engineer on the economic graph team.  One thing that my team does is release a quarterly workforce report that shows trends in the US labor market.  And this research is used by policymakers, by academics, by journalists.  So I feel like I've really kept a tie back to my original training by working on this team.  And like I said previously, I started out as a journalist.  I really didn't have that much experience starting off on the job at LinkedIn three years ago.  I really ramped up on the job. And when I was starting out, Ember seemed really new and exciting,  but also scary and not a lot has changed since then, to be honest.  So because of my past, I'm really passionate about working with the Reach Apprenticeship program at LinkedIn.  And this program helps engineers from non-traditional backgrounds start full-time software engineering roles.  And I really have to tap into the feelings that I had starting out, all of my fears,  everything that I struggled with in order to empathize and mentor the apprentices.  And also now I have a lot of experience seeing people from very different backgrounds go into the industry  and how they learn and how they process concepts.  And this has really inspired me to work on developer experience.  So my main focus is on Ember data and the related add-ons, particularly M3, which is an alternative to DS model.  And when I started learning Ember, that was the area that I found to be the most intimidating,  but also incredibly interesting.  I distinctly remember when I had to hook up my first API endpoint at LinkedIn,  I was actually pair programming with someone on my team because I was really stuck.  And honestly, I was actually on the verge of tears because I was really feeling like I didn't understand how anything worked.  I was really struggling.  I kind of had this feeling in the back of my mind that LinkedIn had made a mistake by hiring me.  It was one of those really terrifying moments early on in my career.  But I was able to push through it, I got a lot of help from really supportive people,  and I felt like this incredible joy when I actually got everything to work.  And I realized that I was actually learning one of the most powerful aspects of the framework.  And that was incredibly exciting to me.  And so that experience really motivated me to learn Ember data deeper  because I wanted to make it easier for me to understand what was going on and also for other people to understand what was going on.  And one of the more recent features I was responsible for was for adding support for M3 models in Ember Inspector.  And this was actually just basically solving a pain point that I personally had.  So what is developer experience?  Developer experience is how engineers interact with your framework.  It's really at the boundary between people and code.  This can include documentation, which is the entry point for most developers  and probably the first impression that they'll make of your project.  If I go to a repo and it has a missing, outdated, or blank read me, I really hesitate to use the project.  This also includes debugging tools, which engineers really appreciate,  and they definitely remember if they're frustrating.  This can also include framework ergonomics, and developers may not be consciously aware of good ergonomics,  but they definitely know if a framework has clunky or difficult syntax.  So unfortunately, developer experience is often not prioritized.  And I believe one of the reasons why is because it involves people.  And people metrics are notoriously hard to measure.  It's a lot easier to say that you reduce the build size by X amount or sped up the website by X milliseconds.  It's a lot harder to say that you made developers work X times faster with your feature.  And just to be clear, though, developer experience is important.  It should not come at the expense of user experience.  Ideally, it should be a symbiotic relationship.  So I actually ran into this problem myself on a feature that I'm currently working on, the concept of people metrics.  So I'm trying to add a button in the data pane to output the store into the console.  And this is actually a feature that I wish existed when I started out,  because I didn't know that you could grab the store off the container pane.  I didn't even know what a container was.  I wasted so much time putting breakpoints into my code to try to grab the store.  It was very frustrating.  But I didn't want to build a feature that I just only found useful.  So what I did is I actually talked to a lot of developers from all different levels.  I heard about their pain points with Ember data.  I also pitched my idea to see if they actually would find it useful.  And that enabled me to gain a little bit of consensus and traction.  So that I felt confident that what I was working on was actually something that I was working on.  What I was working on was actually something that people wanted and that they would use.  And I'll be making a PR for that soon, so keep an eye out for that.  So why is DX important?  If a framework has great DX, it's a lot easier for people to adopt it,  to contribute to it, to answer questions, open issues, etc.  And this really encourages diversity and a healthy open source ecosystem.  If the framework is a delight to use, it really makes for happier engineers.  If a framework doesn't have good DX, that really limits the type and number of people who can adopt it,  contribute to the project, etc.  This really can create conformity in the types of people that use it and the problems being solved.  And also, if only a small number of people understand it,  when developers are building out applications,  there's a greater risk of bugs being introduced into the code and framework misuse.  If the beginner can only understand what is happening by looking at the source code,  that is a failure of the framework.  And they'll probably go and find something else that's a lot easier to use.  They don't have to use what you've built.  And luckily, I'm not the only one who thinks that this is a problem.  So, when should you contribute to developer experience?  One great thing is that newcomers bring new and very valuable opinions to developer experience.  New engineers have fresh eyes and new insights into the framework.  They know it's hard starting off.  These insights are really lost the longer you work with a framework.  And people can contribute to different facets of frameworks as they gain experience,  and each of these ladders is vitally important.  And as engineers grow, they should continue to contribute to all levels of developer experience  and help new engineers level up.  And this will create a self-perpetuating ecosystem.  I also really encourage people from non-traditional backgrounds to contribute to developer experience.  I feel like there's a lot of pressure for people from non-traditional backgrounds  to conform to the expectations of how software engineers should learn and solve problems.  But we should really be using our unique backgrounds to make frameworks and the open source ecosystem  a more open and engaging place for everyone.  So, where can you actually contribute?  One suggestion I have is to work on features or missing documentation  that bother you or hinder you in your day-to-day work.  This will help motivate you to contribute, and you'll also directly benefit from it.  And a lot of small one-line changes exist.  I personally have a huge pet peeve when it comes to deadlinks.  Whenever I see a deadlink in the code, I'll make a pull request from the repo to fix it,  and this ensures the next person will have access to the information.  I've done this for Ember data, for the octane guides, for Mirage, so on and so forth.  Usually this PR gets merged within days, and it really helps build relationships with the maintainers  at the very least and kind of give you ramped up onto the framework.  You can also add examples of how to use add-ons.  So, if you start consuming an add-on and you kind of struggle with a bit to figure out how to get it to work,  you can create a pull request in the readme with an example.  And I've also done this with Ember sign-on queue unit, because like a lot of people,  I actually spend a lot of time figuring out how to test my code in addition to writing my application code.  And as you work on the framework more, you can add comments into the source code,  you can work on developer tools like Ember Inspector.  There are just so many areas out there that are just waiting,  and maintainers really appreciate you making these fixes, even if they seem trivial,  because honestly, a lot of times they don't have time to take care of these themselves.  So, hopefully now you understand why I'm so passionate about developer experience and how important it is.  DX is a great opportunity to help you learn more about the framework and also to help others learn.  And if you're inspired to work on developer experience tools,  I'm more than happy to talk to you about them, just let me know.  So, thank you.
Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_0_131.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_132_227.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_228_299.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_300_359.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_360_407.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_408_527.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_528_1235.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_1236_2291.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_2292_3467.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_3468_4439.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_4440_6779.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_6780_7967.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_7968_8915.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_8916_10499.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_10500_11783.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_11784_12323.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_12324_14027.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_14028_16391.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_16392_17051.png Virtual_EmberConf_2020__Democratizing_Frameworks_T_FIP6hmekDkc_17052_17153.png