#213 Wynn Netherland is a man of APIs and wrappers

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Wynn Netherland 0:00
You're in charge of your choosing your own adventure here, right? It's not your manager, it's not the reporting to to sort of shape that its trajectory of your career, I think you've got to have some self awareness to, to understand what you're passionate about, like if you want to go deeper in certain aspects or you're more prone to, to want to go wide. But look for opportunities and get explicit with the folks you report to. And look, try to make your own opportunities to grow. I think grow is the the key word there, right? You if you feel like you have a handle on the job you're currently doing, you probably have been doing it too long and need to find whether it's the same company somewhere else find other opportunities, they're going to stretch it a little bit, I think there's a certain degree of healthy discomfort that should come with, with growth.

Tim Bourguignon 0:50
Hello, and welcome to developer's journey, the podcast bringing you the making up stories of successful software developers. To help you on your upcoming journey. I'm your host, Tim bourguignon. out this episode 213 I received when little Wayne is a director of engineering at Adobe Creative Cloud on his technical leadership journey, he has text back and forth between roles as a hands on individual contributor, manager and executive when co created the change log podcast back in Wow. 2009 as an outlet to discover projects and share ideas around the creative explosion happening on GitHub. And with an interest in well designed API's and a love of Ruby, he created or contributed to many popular Ruby API wrappers for Twitter, LinkedIn, and GitHub. And if you don't know him from the changelog, and you should, you might have seen his work The obligate Gemini created and which to date, and I checked, has had over 130 million downloads, which is huge when welcomed afternoon. Thanks for having me. It's my very pleasure. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew, and help me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guests. So when, as you know, the show exists to help listeners understand what your story looked like, and imagine how to shape their own future. So as as usual on the show, let's go back to your beginnings. Where would you place the start of your journey?

Wynn Netherland 2:50
Started by the dev journey, probably having an Atari computer back in the 80s. Being a child of the 80s. I was big into video games. And it was the first time I realized you could tell them what to do via programming instructions. My older brother was taking a basic course in high school. And so I would rework his homework to see if I could get the same answers and put something on the screen. Simple things like 10 print when 20 Go to 10 sort of thing, probably where I would grounded I think seriously though, as far as getting into what I would call programming, I don't have a computer science background. In college, I was studying pre law, my brother was a medical doctor and I didn't like blood or pain. So I thought, well, you know, law would probably pay just as well at the time. So I thought I was gonna go into pre law. A friend of mine in ROTC handed me a printed out spec of the HTML three spec, I think it was at the time and in a binder form and said, check this out. So I start making websites. And he and I went into business together in college and started making websites for businesses around town. Our college is located just up the road from Walmart's corporate headquarters. And so at the time, a lot of brands were moving into the Bentonville, Arkansas area, because they needed a presence there for Walmart. And so there was this influx of companies coming into the area right at the time that public internet was kind of taking off in the mid 90s. And so we were just in the right place at the right time to start making static websites for folks that needed a web presence. And it was an interesting time to be in web development because you would have designers that were coming from a print background, asking for a particular Pantone shade of blue and you'd have to explain to them that you know, the Venn intersection between Netscape and Internet Explorer gave you two under 16 colors max. So which of these 10 boys do you want that sort of thing? So that's where I really discovered that there was a paying future for me in development, but at the same time, I was had just barely dipped my toe into I would even call it engineering at the time it was development

Tim Bourguignon 5:00
Did you remove them the moment in time where this site activity eclipsed the preload? And they said, Oh, this is gone. I'm going on the road. Now,

Wynn Netherland 5:08
it was right about the time, I've wrapped up my fourth year of school that I just knew that my immediate goal was just to get a paying job in the industry, right? It was not, you know, climbing the corporate ladder or anything like that. It was just like, I can't believe there are people that get paid to tell a computer what to do all day, I have since found out there's much more to the job than that, right? People are the actual problems. But as far as like doing hands on creative work on a computer, that was kind of the turning point, probably the last year of school. So that led to I got a job at the local paper as an assistant webmaster. And so I it sounded big at the time I, I found out that the difference between a webmaster and assistant webmaster, the webmaster is responsible for the layout of the site, the HTML, the CSS is as wrong as it was back in the day, we probably still using table based layouts for everything. The assistant webmaster had the the job of copying and pasting out of quark and into Adobe go live every night. So I got into server side programming to really automate that work. Because like this is a lot of mundane, just tedious copy paste work. So it was an all Mac print shop. And I smuggled in my own NAC mini tower, PC, and learned ASP while I was waiting for the print deadlines, because we had like a 3pm to midnight shift every night waiting for the paper due to go to print. So there's some downtime while you're waiting on the editorial desk to get done. And so I was using that downtime to learn the trade.

Tim Bourguignon 6:47
The good old days, I remember exactly that time, the TruMotion, the time went out and he came out of high school. And I visited a couple of companies and to try and see what do you do as a webmaster? What's What's the job, I really saw people playing around with playing around. That's it that's really playing around with, with computers with, as you say, table layouts of graphics, etc. It was who I want to do that I didn't learn this. And the guys look at me and say there is no school to teach you to learn it on your own. I said, Okay, now it's getting funny. So did you have at some point in this timeframe, the the question in your mind, do I need to go study for that was you had enough baggage ready to say, Okay, I'll wing it, I'll go for it.

Wynn Netherland 7:34
You know, I was considering it, I was looking at switching gears and school, the disconnect for me at the time. And I think it took a while for you mentioned, there's nowhere to study for this. And it took some time before the curriculum is caught up right at the time, I'm looking at the computer engineering and computer science courses that I could take at the university. And they just they were I could tell even as a newbie, they were outdated. Right, there was nothing that was going to prepare me for a job other than just basic data structures, and, you know, the computer science side of things. But as far as hands on skills to be immediately productive, in a in an environment where development was the, you know, the main discipline, it was going to take some time to acquire those skills in school probably was not going to be the best route for me, I fortunately got caught up in sort of the.com, boom, right? In the late 90s. Anyone that you know, could run Excel was getting a job in the field, I was working at the paper when I think I was watching probably a live stream of a ballgame on broadcast.com or something back in the day. And so I had a job ad for a job in Texas for ASP developers. And so I applied online and ended up doing a phone screen. And I still remember having, I don't know if you remember the brand, the rocks, technical brand. That was I think they're still around, there's a red cover with yellow letters. And usually as the author's pictures in black and white, there's a whole series of these technical books. And I had the ASP 3.0 book in my lap during the phone screen answering some of these questions. So sort of like, actually faking it till I made it. So that was fine. I got the job that ended up being a contract job in another state and so moved to Houston, and was the only developer attached to a networking tech group that was basically they were running cable and setting up networks and just a lot of MCSE I think was the the four letter acronym back in the day. So they thought I had was wielding dark arts by being able to script a lot of the things that they were doing manually and I just was still learning on the job.

Tim Bourguignon 9:46
Cool. And this was ASP was an

Wynn Netherland 9:50
ASP script. Yeah. This was before ASP dotnet it was the ASP classic that

Tim Bourguignon 9:55
I think yeah. Cool. Cool. Cool. Cool. And how long did that keep You challenged and energized

Wynn Netherland 10:03
I don't know that it was I don't know early in my career I was probably just soaking up anything tech related that I could I was still in the Microsoft platform for probably the first three or four years of my career shifting gears from that company that I worked for to Compaq if you remember combat computer

Tim Bourguignon 10:24
old enough to remember Yes.

Wynn Netherland 10:27
I have co workers now that don't know the name so so is it Compaq and later HP when HP acquired Compaq. So that was a fun job. It was as far as kind of pioneering ecommerce at the time we take it for granted now with Amazon and anything that you want to buy is like two clicks away now on your phone. But back then, I mean, it was it was sort of the Wild West and taking credit card numbers, and how do you secure all that and, and take someone's money and send them a physical product was was not a guaranteed thing back then. So we were trying to pioneer how we sold and configured computer hardware online. So that was it was an interesting challenge. Because a lot of what we would stitch together with SAS these days, or open source wasn't the case, back then it was a very proprietary world. The breadth of information that I think is available at anyone's fingertips these days to approach a problem and come in a number of solutions just didn't exist back then it was very team oriented and localized.

Tim Bourguignon 11:27
So you were not alone anymore doing dark arts scripting?

Wynn Netherland 11:32
No, I guess I found my tribe on a team of folks to work together. I think that's maybe the takeaway of that part of my career is instead of being kind of the the lone wolf trying to figure out things on my own, I now found Oh, there's other folks that are interested in this. And I'm not the black sheep of my family. That's the narrative of computer all the time. Right?

Tim Bourguignon 11:50
Was it was the first time you're working really with the team? And you you mentioned this, this student you work with the beginning and then this this first job? Yeah, it was I guess,

Wynn Netherland 11:59
I'm just now reflecting on it. It's probably the first time that I've worked together in a team solving problems together and trying to break things down and considering other viewpoints instead of someone asking me how I would solve it and going off and doing my best to to hack together a solution. So yeah, that was probably the inflection point for looking back where I started developing an interest in not only the technical content of the work, but also how do you what's a high performing team look like? Because there was a lot of dysfunction in that team as well. You know, we did some really cool things. But there's a lot of any of the anti patterns that you would see on the office or Silicon Valley or other TV shows existed in that that team as well.

Tim Bourguignon 12:43
Where it doesn't look, as these shows, y'all are so dumb, and thank God, we're doing half of this, did you have an idea of what your future might look like, back then or dream of how it should look like?

Wynn Netherland 12:57
You know, it was a different time I there was still this? This is too good to be true. type of, I guess, mindset. I don't know if it was for me personally, no, it permeated a lot of folks that I was on the team with because back in the early 2000s, I mentioned, I caught up in the draft of the.com Boom, but then it was followed by the.com Bust. And there was this nagging feeling as a as a well paid engineer in the states that your job may go overseas. Right? There was especially if you work for a multinational company like I did at the time. And my job became less and less about the hands on creative work more about architecture and drawing pictures of how things should work and more and more of my time was spent talking to folks and other timezones trying to get feedback on on the design and how they were building it. So I felt more and more separated from what got me into the field to begin with, which was that instant feedback loop of hitting Save and hitting refresh and seeing something change on the screen. That was the exciting part for me. And, you know, as the job became more and more grounded in Microsoft Office, drawing pictures of things that is I kind of lost my the thrill was gone in some some ways. It ebbed and flowed. I mean, dotnet was exciting when it came out. And they had some interesting takes on how to do UI design. I wrote a couple of books during that time, just as a way to kind of catalog what I was learning on the platform at the same time, but a lot of what dotnet was doing, at least on the web was sort of against the grain of how the web works with how they were doing ViewState and some other things. It was about that time that a coworker of mine had introduced me to the Ruby and Rails how to build a blog in 15 minutes podcast that DHH did way back in the day and I it was one of those things where I kind of got tired of hearing about it because I was perfectly happy my dotnet world at the time. had the time Excuse me. And on a weekend I decided to dig into it. The more I dug, the more I was intrigued and decided to rebuild one of the apps that we had in dotnet. Just to kind of like, give it a problem domain that I knew how, how can I learn the tech without having to also learn the problem domain the same time and I was just blown away by how quickly I could recreate the website, and Ruby on Rails and sort of drunk the Ruby and Rails Kool Aid and kind of made this shift to, to Linux and Open Source and kind of changed my entire posture as an engineer from preparing proprietary dotnet to open source and Ruby on Rails. And so sort of got disenchanted with my day job at the time and just really wanted the opportunity to, you know, early my career, I just wanted to get paid to do computing for a living, right. And now I really wanted to get paid to do the sorts of projects I wanted to work on which were less than less about Big E commerce websites and more about just pulling compelling things for startups. And so a side hustle turned into another business, I ended up leaving my employer and founding a company with the same college buddy that we got into web development back in college with and another co worker, and we did rails consulting for a few years and during kind of the web 2.0 Boom, and kind of rode that wave. And that was fun. And I enjoyed the consulting aspect of there was always a new problem domain for every customer. I mean, the toolkit was the same as far as Ruby and Rails and what it provided. But the problems we're solving were different. And I felt that was exciting in some ways.

Tim Bourguignon 16:45
How did you how did you, I want to see cope. But that's probably not the right word adapt to the this, this being a founder. So you basically, you still have your job coding, but there's a whole new can of worms that falls in your lap, and you have to tackle that one as well.

Wynn Netherland 17:03
Absolutely, you're especially if you're in consulting, it's a little different if you're in a startup, and you've got a product that you're trying to get to market and find product market fit. But as a, as a consultant, there's this, this constant, you're hunting the next project while you're building the current project, and it can get exhausting, especially if you're, in my case, I was leading the tech side of the business, but at the same time, you have to be in sales calls to, you know, to close those deals to convey that you the company has the wherewithal to, to be able to solve the problems that folks are bringing to you. And so yeah, it can get exhausting, you're wearing a lot of hats. And I think there's this smaller the company, regardless of your role in the company, the more hats folks have to wear. And the more I think a generalist you have to be. And that's, I guess that's sort of been my specialization across 25 years of doing this has been as a generalist, right, I would describe myself as T shaped, there's certain aspects of my skill set that go deeper, but for the most part, I understand a little about a lot of things and so I can talk bridge communities and talk to folks and connect dots, I think is a skill that I've learned and honed that yeah, and in the consulting phase of my career

Tim Bourguignon 18:20
as a specialized generalist will say yeah, I think that's

Wynn Netherland 18:23
and I've come to accept that I think I would have probably bristled at that description 15 years ago, but now I kind of wear it proudly is like yeah, you know, I'm, I'm not as deep and technical as a lot of the folks that I work with or even lead, but that's okay, because I can connect the dots and the sum is greater than the whole.

Tim Bourguignon 18:43
I don't shy away from the description. I mean, if if you use the term generalized to say you're not a specialist, then then there's a negative connotation but you can wear it proudly and really go go really really wide and really can connect dots and in very different field silos aspects there's a bonus added to that so that's coming back to you said before you were drifting toward more architecture more drawing boxes and less coding and this affected your your interest your energy and your your your happiness was your job this my words, not yours, but that's what I understood. How did this being more entrepreneur and having a part time business had in effect, this part of your of your happiness was the same? Was it different?

Wynn Netherland 19:26
I think I found a certain satisfaction and I think my goals in starting a company like I said, previously, were to create an outlet that I could work within the framework of the business to approach this, the stack that I wanted to work on and the problems that I wanted to work on and do the projects I want to work on. So in that in some regards it you know, I was able to create space for that and I felt a certain satisfaction and working on the business as much as working in the business. I don't know that you know it at the same time, like we all age, we're not the same people we were last year 10 years ago. And so part of that was just I think maturing and finding, there is a certain level of satisfaction and doing different types of tasks that aren't the same, what once brought you joy is probably not going to bring you joy, forever, there's got to be some sort of like Wonder and, and going a level deeper and growth and trying to discover what what there is to be learned as far as part of that process. So I don't know that it was maybe a sideways move in some ways. In that sort of role, you really can't give all of yourself to either technical direction or to growing the business, right. And that's a tension that's always there. And at some point, you've got to step out of one of those roles and delegate the other one if you're going to do it well. And that's that's really the struggle for I've known. I've met a lot of friends that have done software consulting, and in burned out for that very reason, right? It's, there's really, it's hard to reach that exit velocity to to grow a sizable consultant company that can stick around because it really is dependent upon next month's billables.

Tim Bourguignon 21:16
Absolutely, absolutely. And so you kept at it for nine years, if I recall correctly,

Wynn Netherland 21:22
we may think it's been 25 years in the industry and better than remember all the time. So I guess we were, I still have, you know, a couple of companies that I use just for book writing and publishing and that sort of thing. But as far as the the consultancy here that I'm referring, it was about a three year run that we had from I guess 2007 to probably around 2010, I remember the timeline correctly. And things sort of dried, dried up, you can probably catch the business cycle, sort of undertones of of my story, things started drying up after the big financial meltdown of the late 2000s. And I was getting burned out and I got a job call from my previous boss at Hewlett Packard. And when I had left, I mean, I thought it was done with like very large corporations, especially multinational corporations, where you're fighting the bureaucracy as much as your your tools. And he said, Hey, you know, we're booting up a brand new business unit. It's sort of an incubated business within a business, and we're gonna be doing Ruby on Rails, it's already decided you can recruit your own team, and you can work remotely. And that was the other big driver for me, leaving heel back at first I was I wanted to work remotely, it made no sense for me to commute to sit in a cube to talk to another continent all day long, just like a whole lot of sense. And so the remote aspect of it was a big driver. And I think now as we're coming out of the pandemic, everyone's got a different appreciation for remote work, because we all did it for for so long. But for those of us that I've done it for a while, back then I mean, it was a big, big draw, because provided flexibility for me and my family to to not waste two hours a day commuting into the city to work. So that was fun. I worked there for about a year until the new technical CEO or CTO rather decided to completely change the stack from Ruby on Rails to try to remember the Python based Cloud project at the time. It's been so long ago, but completely changed the technology. And it was just a good time to pursue other opportunities about that time, I got the offer to join a small startup that had a charitable flavor to it. And that we were building sort of Kickstarter before Kickstarter was what we know is as it is today, but Kickstarter for charitable projects where folks can charities could post their projects and patrons could back those projects. And that was called Pure charity was there for about a year and was happy there until I got to been doing open source over this time. And even when I guess the reason I got into open avidly as I did. When I was doing consulting work, we were using a ton of web 2.0 API's at the time, everything from Twitter and the Twitter ecosystem. Seemed, I guess, to be from a developer standpoint, it seemed to be bigger back then than it is today. The result of this there's a whole cottage industry of one off, like Twitter, adjacent API's, like clout and some of these others that were in that same space. And I remember one was a Friday afternoon, towards the end of the business day, and I just, I was on Twitter, and I found my congressman on Twitter. And, you know, I just I tweeted out, hey, my Congressman Michael Burgess is on Twitter as yours and just had this kind of like aha moment. Maybe we could build a website that that allowed folks to find their congressional representation on Twitter. I mean, Twitter was still this was pre Oprah Twitter and it was pretty. It wasn't the Twitter today, right? I mean, back then we were talking to friends and family about Twitter. They were like, what? They didn't understand it right? To the extent they do now. And so I had that idea. We were still using, I think campfire at the time for our company, chat. And so I just remember putting into in campfire, hey, I have this idea for a website where you know, if you put in your zip code, you could come up with if your congress, folks are on Twitter, and if not, then you could recruit them to join. And I had a screenshot because I gave this talk once where I showed the screenshot, like all this chatter going around my comment from other folks working on projects, like totally ignoring the idea. And I still remember writing something like, since this is obviously a bad idea, I'm gonna go help my wife with with dinner, right and signed off for the day. And but it couldn't let the idea ago, I found an open API, where if you put in your zip code, it did tell you what your representation was. So that part was done. So just kind of mash together a website and I found some stock art, like Capitol dome, and made it look like the kind of the parks paper constitution aesthetic, and called it tweet Congress. And we put it up and it started getting more and more popular. There was a Yes, folks were discovering what Twitter was. And then there were politics, politicians were starting to join. And this was a site that kind of was a clearinghouse for tweets from Congress, because we would show tweets from, from congressional folks on there. And then the State of the Union, I believe, I'm trying to remember what year this was. There were folks live tweeting during the State of the Union. And right, this just came like a cultural moment where your media start picking up, hey, what's up with this, this Twitter thing? And you know, I guess we were easily easily Google Mobile. And I remember getting off a plane coming back from a comments online and our analytics had just gone off the charts, like CBS News had featured us in passing on covering that story and highlighting to us from their their website. So like, traffic started to increment up and ended up we went to a web award at South by Southwest that year for tweet Congress, which is pretty cool. So I've got, I don't know, mixed emotions about it. Because it was, it was a cool idea. I think it was, you know, for where we were in the cultural moment, it was a cool thing to bring together. At the same time I lament like, how many politicians are on Twitter these days, I sort of miss the, the the pre, I don't know, pre Oprah Twitter when it felt more like CB radio, right? Where it's where you connected with people in your tribe around like esoteric, technical topics. And it felt better and a little bit more like IRC back in the day then, than what it is now, which is kind of a feed of brands and updates.

Tim Bourguignon 28:02
Yeah, I'm disengaging more and more with Twitter. It's not what it used to be. It's really too much too slick, too polished. Yeah. We're just getting old.

Unknown Speaker 28:13
That's what it is.

Tim Bourguignon 28:14
That might be. Get off my lawn. It was better before. Okay, so you were saying this is what took you also more toward working in open and working open source?

Tim Bourguignon 28:26
Yeah. So I wanting to do things with the Twitter API, there were things in the Twitter gem that the API supported that weren't yet in the gym. So I started open pull requests. And John Newton maker who's created the gym graciously started allowing me to contribute. And so I learned a lot about what makes a good API wrapper doing that, like, learn more and more about rest, kind of from the outside consuming it. And then, like, I was just fascinated by the different approaches that different Twitter gems took to solving the problem. And what I liked about John's approach was the idiomatic way that he wrapped rest concepts. idiomatically in Ruby, where if I'm gonna Rubeus, I can walk up and understand this. And I really don't have to understand all the concepts of rest. I just want to do the workflow that I want to do. And I don't have to think through this put or a patch or post or any of that, right. And so they just got me thinking about how different engineers solve that same problem. I wrote a blog post once comparing like three different Twitter related gems and how they solved it, which were fascinating. Some like, the rest semantics came right through the syntax. Others you never knew you were calling an API at the same at that time. And I remember going home Thanksgiving one year I was on the drive home when I was checking Twitter or something and saw the LinkedIn and come out with their REST API. And I went like that very night pretty much took what I knew from John in the Twitter Gemin, wrote a LinkedIn gem that I maintained for a couple years before handing that off. And then I guess what really makes accelerated my open source career was as we started the changelog podcast, we were wanting to feature the projects directly on the blog. And was we moved from just a static website. We're doing all this in JavaScript, we were making JavaScript calls back to the GitHub API and pulling back like the number of stars and the metadata about the projects. When we went from that to a more dynamic website, it opened up the opportunities to us Ruby, and I looked at the landscape of Ruby wrappers for the GitHub API. And they just didn't feel like Ruby, and just didn't, I liked the semantics that we had in the Twitter gem. So I created my own project and just started whittling on it, it became the Octocat gem. And I guess that's what a couple of years later, I'm CTO at this small nonprofit and leading a team with probably 10 folks or so working on something totally unrelated to the open source that I think I'm spending a lot of joy in. And I get a call or get an email that says I've never had a subject I won't forget, because it's too funny. It says, Would you like to chat with some good hitters? And I was like, this is a little strange. And so I opened up, and it's from someone I don't recognize, and I knew a lot of the folks that GitHub at the time, and I'm going to name names because I don't want to out anyone but this was if you knew this person, you totally get why this is funny. But the subject line said, Would you like to chat with some good hubbers? And I opened it up and said, we're interested in are you interested in interviewing at GitHub? Well, they just had a security incident, probably in our three or four days earlier, some rails vulnerability that allowed folks to get admin access and repositories, this is early, get up days. And so I just assumed like they got hacked. And like, everybody got this. So I'm in like, my work channel, go. Anybody else get this? You want to come work and get an email? And they're like, no. Okay, why don't you This is legit. So I remember replying. Oh, and I, I looked up this is back when get ahead, everyone on their blog, and if so, and so was it GitHub, or once you joined, everyone got through a blog post. And so I looked at this person on GitHub, and sure enough that had that post. And it's them sitting on a rock like in a Zen pose. Right. And so this is what made me think that like, I got hacked, because like, this is like, that's connect here. So anyway, I wrote I replied back. Sure, I would like to and I wrote it as a regex. Like with the optional in there sure. Like to chant chat with some GitHub errs. Right? It's anyway, it was a legit offer to come interview. And so I flew out to San Francisco and an interview and what blew me away. When I was doing my technical peering session, I got to you open a pull request on GitHub, GitHub, which is the main monolith. And as the bootstrapping script is running, I see gem install Octo kit, and they were using it I just couldn't believe that someone was using my project to that degree. So that was kind of a another turning point in my career, to say the least.

Tim Bourguignon 34:14
Wow, it's nice story as well. That is really cool. You digital a bit on the why this this rapper conceptual interest you in and how it matches in language in the NBA if you let the REST API bleed into the language or not, but it's interest you for years. What's what's so fascinating that it takes 10 years of your life and then that you find a new API and you want to you want to rapid it again and again and again.

Wynn Netherland 34:40
Yeah, I think I was fascinated by just the boom of interconnectivity that came about with web two, you know, and this kind of API economy that was so popular at the time, I remember early in, in my career, like communicating between systems was almost impossible. I mean, just all the failed attempts of CORBA. And just calm, calm plus, and all of this like graveyard of projects past where we, as an industry couldn't get our act together to cooperate in a well defined manner. And then we get things like JSON. It's not perfect, but we have a minimal set of types that we can parse and share. And whenever you have HTTP, and it's got some nouns that are verbs, rather than that work, and we can create our own nouns, and if you just lean into it, that's there's a dial tone there that just suddenly we can start connecting dots between websites, we can design an economy around that which we take for granted now, right. But it was new at the time. And I think that is one of the draws for me. And I, I've always enjoyed learning something and then going one level deeper, you know, what, just removing the abstraction and try to understand that technology to magic continuum, right, just continue to go down deeper in the stack. And for me, it was coming from consuming rest on one end. And then kind of jumping behind the curtain and understanding. When I took the job at GitHub, I was the second API engineer on the team of like, I think there were 70, folks that get up at the time, and only two of us really cranking on the API full time. And you had to think in every, every time there's a new feature, and you're exposing it to consumers, you have to think through what are the nouns here? And I think so many engineers typically look at their database structure, the data structure, and those are the nouns and they just expose crud API's, create, read, update, delete, and what what was the challenge, I think, was trying to make it workflow driven and not now driven, or just data access driven, right. And so, I don't know, countless threads on GitHub discussions where an engineer that was building a feature would come and say, Hey, we need to add this into the API. So we can allow third parties to call it what are the semantics here? And you'd have to think through, like, what should the error code be? In this case, right? Is it a 422 is, you know, 404, that sort of thing. That's tricky. Things like there's good, I've always had this thing where they would not disclose that something that you did not have access to existed. And so like, you've probably had this like, moment of terror on GitHub, if you've logged out and didn't know it, and you hit something, it says, 404, like, what happened to my stuff? And then you realize, Oh, I gotta log in, they'll tell me that, you know. And the same thing happens on the, on the API side of things, right, we'll return 404. If you're, if you don't have access to it, instead of before three, if it's not public, sorry, just little things like that. It just was an endless series of just design decisions that I've found interesting to, to design. And then also scale, right, that was the other thing, you know, GitHub scale, was the first time that I really was exposed to the possibilities of testing your code in production. Right? Well, I mean, that sounds funny, but I'm not I don't mean it as joke, I'm at a certain scale and a certain network effect, you have enough real time data to a B test things in production and get real instant feedback. So we had a project called science that was developed there that allowed us to test two code paths, a control group and experiment group for correctness and latency. And so it would, you could, with a Ruby block, describe like, here's one code that I want to run. And here's the other one, and it would mostly worked for read pads, of course, but you would run both of them log the results. And you would continue to tweak your code until you got 100% accuracy, also with performance rate that you wanted. So it was a really cool way to not have to do a lot of upfront stress testing of your code, you can just use US production. If it's not

Tim Bourguignon 39:16
truly critical enough, then right? Yeah, of course. Of course, you can get the chance to work during this time working on API's with people who didn't come from this extensive consumer perspective that you had, and and how you how you, you interacted with one another how you completed maybe one other a bro, two different pieces of the same puzzle, and collaborate on that. Yeah,

Wynn Netherland 39:39
I think there was a lot of folks that I work with that came from a very technical computer science background that would rightly consider the performance of what they're trying to expose, and just the robustness of the feature that they're trying to build. And really, not really think about the UX of an API. I think that's the other thing that always I've always been kind of played in my career at the intersection of development and design and said before user interfaces to me sometimes involve pixels. But a command line interface has also got a certain degree of UX. How approachable is it? Only? Do I have to run four sub commands to do this thing? Are you know, is it like? Is it deeper? Is abroad that sort of thing? Like, how approachable? Are you making your tool for a human walking up to it. And a REST API is one of the things why we like web 2.0. I think as an industry so much is it on the on the main, we went from fairly large, opaque, almost non human readable URL structures to these nice segmented, you know, predictable resources, right. And a REST API can can do the same thing. If you have a certain consistency across your API, instead of it'd be more RPC based, which is what a lot of API's were before rest, kind of took over. The RPC would, there would be one endpoint, and then you just have all these method calls that you could. And there's no like every websites, exposing its own set of verbs in that case, but if you lean into the verbs of rest, and expose your nouns, then it becomes a little bit more predictable. I know I'm going to lose something or fetch something, it's going to be a get, I'm going to update something or create something it's gonna be opposed to I'm going to update it's going to be a put or a patch.

Tim Bourguignon 41:28
Yeah, that's fascinating. Many of you probably have, what about Graph QL? It's, it's become more and more buffing. How do you approach it as as an interface as a rapper person?

Wynn Netherland 41:42
I was skeptical when it first came out. I wasn't the one that floated the idea. Our VP of Engineering at the time, floated the idea of GitHub rolling out a Graph QL API, because I think he'd worked to the NFL where they had done it, they were heavy react and Graph QL Graph QL sharp. And so I was skeptical. I was like, we have a fully functioning API. And there's one of those things. It's one of those things where the the marketing bullets for something sort of out pace, the actual content, and the marketing bullet that usually folks latch on to for Graph QL is that you don't no longer have to over fetch clients can fetch exactly what they want, which is a big selling point. But it neglects things like types, right, and neglects things like having a consistent interface, regardless of the implementation behind the graph. QL API. So having a consistent set of tooling that if you have a Graph QL API that meets the spec in a graph, QL playground, or our front end, can hook up to that API, and you can discover and, and, and interact with that API in a consistent manner. And you don't have to, I mean, we rest as counterparts to that swagger and some other things that you can do similar things. But in many ways, I've been in response to how Graph QL is gonna solve some of those problems? I think types are the biggest thing that I pure rest world without swagger, other Open API specs, you one of the reasons why wrappers are needed is because you need to marshal that data into a type system that can be consumed on on the other end. So Graph QL, obviates that. In some ways, I don't know what it is about Graph QL, that has been such a good fit for so many projects, I really, it's not a hammer that I picked up went around looking for graph girl shaped nails. But you know, I, I worked on it a little bit at GitHub was leading the teams that were rolling it out. And there's a lot a lot and a lot of work to expose that. That API. When I left GitHub, I didn't really expect to work with Graph QL again, but the next project that I went in to the small startup that I joined, we had effectively four Rails applications of different versions of rails of different versions of Ruby, all thought they owned the database that were kind of multiplex together with this reverse proxy. And I was looking at it going, Okay, I'm sure there's history here. Startup growing quickly, but like this is madness. And so, so why don't we just lean into like, one of these backends that provides a REST API built on a Graph QL interface and for new features, we start threading things through Graph QL and just see where it goes. And it just grew like we have a weed here in the southeastern United States called kudzu that was brought over after the the destruction of our civil war that was planted to green things up and it just looked, it took over the entire south like it's now just this pest of a weed. And, for better for worse, graph girl has grown and in projects that I've introduced it in much the same way just because you don't have to sit there and rewire In the HTTP interfaces, every time you're exposing a new type to consumers, you basically have that one dial down or no, in many ways that's gone to the other extreme, I was talking about the RPC world in many ways Graph QL is RPC with types and like, its provides a consistent interface over something like that. But as a meta point, I think that and I'm sure you've discovered this as well. That's the thing I've noticed in my career is just all these ebbs and flows between the pendulum swings back and forth, right. It's like, tapered, like jeans and bootcut, right? It's just, it's gonna go back and forth. Everything's gonna be in the server, and everything's got to be in the client, right? Everything's gotta be in rest. Everything's gotta be RPC. And the longer you stick around, the more you're just like, Okay, well, let's just hang around for the ride. Because like, save those ties, I'm going to need to wear them again in about 15 years, right? So

Tim Bourguignon 45:47
you see the pattern coming by say, Oh, we're in for one more time. Exactly. You said at the beginning, some of your your T shaped, I said something that's I find really hard to to grasp at the beginning of your career, you're torn between this going broad and really understanding more and more of the landscape, while at the same time going deep. And obviously, you cannot do both really at the same time. But you're torn in the business wants you to go deep, or sometimes the business wants you to go wide. And you're just you're just going into flow and can explode in in fly mid flight. Will you have an advice for for newcomers that are dealing with this and not really know where to

Wynn Netherland 46:29
start? Yeah, just I encourage folks that, especially early in your career, like you're in charge of your choosing your own adventure here, right. And it's not your manager, it's not the reporting to to sort of shape that its trajectory of your career, I think you've got to have some self awareness to understand what you're passionate about, like, if you want to go deeper in certain aspects or you're more prone to to want to go wide. But look for opportunities and get explicit with the folks you report to. And look, try to make your own opportunities to grow. I think grow is the the key word there, right? You if you feel like you have a handle on the job you're currently doing, you probably have been doing it too long and need to find whether it's the same company somewhere else find other opportunities, they're going to stretch a little bit, I think there's a certain degree of healthy discomfort that should come with what's gross

Tim Bourguignon 47:27
discomfort. I love that. That's very true. Thank you very much. We haven't covered a big part of your story, but that was fantastic. Nonetheless, thank you very much. Thanks for having me. Where would be the best place to find you online and talk about the rest of your career or the one covered? Oh, sure.

Wynn Netherland 47:43
Twitter's probably the best place my handle is penguin PE and GWI and then I go to the change log into our probably

Tim Bourguignon 47:56
anything on your plate anything you want to plug in for quality, quality?

Wynn Netherland 48:00
I don't think so I you know, I'm at this spot in my career where I'm, I'm probably digging more deeply into high performing teams and, and I'm in a consumption phase right now where I'm reading more than I'm producing. So nothing to plug at the moment, but I'm I'm liking the spot of

Tim Bourguignon 48:18
my career. whatton a new book coming out a

Wynn Netherland 48:22
lot. Yeah. And first of all, like, if you want to write a book, don't do it to get rich. You only write it if you have something to say.

Tim Bourguignon 48:29
But But I heard the yet in your sent in your answer. So I

Unknown Speaker 48:33
won't rule it out. I won't rule it out. Okay.

Tim Bourguignon 48:35
Duly noted. Thank you very much. It's been a blast. Thanks, Dan. And this has been another episode of the rich journey, and we see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week's story is shaping your future. You can find me on Twitter at @timothep ti m o t h e p or per email info at Dev journey dot info. Talk to you soon.