Kirsten Hunter

- Well, like a lot of developers, I have been interested in computers since I was quite small. My dad loves technology and he always was buying the newest thing, and so my first computer was an Apple Iic, and I remember using my Games magazine and typing in those programs to create stupid little games on my computer, and it was quite a bit of fun. I didn't do a lot with computers until a little bit later after I got out of college and I started doing desktop publishing and I sort of moved into system administration, but what I really discovered was that computers were a way that I could solve people's problems. I could make it so that if you had to do something repeatable, I could make it so that that didn't happen. I could make it easy and remove this frustration from the world, which is really what I want to do. So I don't have a formal degree in computer science. I'm all self-taught, and so there is quite a bit of challenge getting into the industry. I was really fortunate to interview at Silicon Graphics with somebody who was willing to take a chance on me. He said, "What I really want you to do "is I want you to be a system administrator "for VAX and UNIX," two operating systems I'd never used before. And he said, "So, how long do you think it will take you "to be really fantastic at that?" And I thought, "three weeks." (laughs) And for that answer, I got my start in computing. I was a system administrator at Silicon Graphics and then I went into making tools and automating things for our customers, but really, the biggest challenge was I had no right to be in this particular position but I knew I could do a great job and I could convince someone else that I could also. Most of the high technology companies, such as Google and Amazon, they tend to want to hire people who have PhD's in computer science. It's difficult to get past the recruiters to get to the hiring managers, so even if you have some special sauce that you're going to provide for the company, it never gets to the person who's going to make that decision. So, it's definitely challenging to break into a lot of the companies that people want to work for. The software engineering industry is an amazing opportunity for people to break into the field, and the way that people do that is through open source and by integrating with a platform. If you want to work at Amazon, you build the skill for the Alexa and all of a sudden, you have demonstrated that you can actually work with the technologies and a passion for doing the work. I mean, you're not doing it because someone's paying you for it. You're doing it 'cause it's what you want to do. Doing this is actually more meaningful to a manager that you're more likely to want to work for anyways. So one of the things that I'm most passionate about is the developer experience, and I can't talk about the developer experience for our products if I'm not really familiar with how it works for other products. One of the things I'm doing is I'm learning how it is to get setup and work with the API. When you're creating a platform that you want to be usable by people outside of your organization, whether those people are in your company or external to your company, it's critically important that that be a usable interface. One of the things that we tend to do when we're creating API's is we create what I call the lowest common denominator API, which is I'm exposing my database for you, now you can see my whole schema, but that's not usable. If you don't have use case based design for your APIs, what you're going to end up with is something that's not very usable. The documentation for APIs tends to be focused on the resource documentation that says what each endpoint is going to do, but people don't learn things well if you say this is what it does. What they learn is, this is how I do a thing, or this is what I can do, right. So these are actually guides and tutorials, and a lot of APIs don't provide this information for developers. So they come in and they look, and they can see what the endpoints can do, but they have no context for why that's interesting to them. Part of the developer experience is helping them to understand why they care about your product. We have a diagnostic tools endpoint for the Akamai API, and what you need to do in order to make that call is you need to make a call to another endpoint to get the locations that are available and then you pick one of those locations and you make the second call. So we walk them through that workflow. Again, it's very simple. We have other situations where there's 10 different calls that you need to make in order to get the data that you want. So walking through the process of working with that data as opposed to just saying, "Well, here's the endpoints, "you figure it out," which is what a lot of people tend to provide for developers.