Career Development
First it's a lot sort of lost in the midst of time to a degree.
I had a woman who took care of me when I was a kid, who had a Commodore 64, and it has BASIC.
When you boot up a Commodore 64, it's got BASIC built into it.
So some of the first code that I wrote was BASIC on the Commodore 64.
Probably much like screen time with kids today, like this was the way that this person got me to quit bugging them to read stories to me or something like that.
So that's the very first code that I remember.
But I didn't do a lot of coding until high school, where I tried to teach myself how to code fairly unsuccessfully honestly.
Then when I got to college, you get the course book and I looked through the course book, and not the only things, but more than that core set of courses that were really interesting to me were these computer programming courses.
So I guess that would be the moment when I thought about becoming a developer.
I think I didn't really know actually for a freshmen, what do you know about careers.
But then when I was a senior obviously looking for jobs, it was obvious that this was a good fit for me, and the industry was growing.
It was the late '90s and the industry was growing a lot.
So that was good opportunity.
첫째, 그것은 어느 정도 시간의 한가운데서 많은 종류의 잃어버린 것입니다.
어렸을 때 나를 돌봐 주던 여성이 있었는데, 코모도어 64를 가지고 있었고 BASIC이있었습니다.
Commodore 64를 부팅하면 BASIC이 내장되어 있습니다.
그래서 제가 작성한 첫 번째 코드 중 일부는 Commodore 64의 BASIC이었습니다.
아마도 오늘날 아이들과 함께하는 스크린 타임과 비슷할 것입니다.이 사람이 저에게 이야기를 읽어주기 위해 아이들을 괴롭히는 것을 그만두 게 한 것처럼 요.
이것이 제가 기억하는 첫 번째 코드입니다.
그러나 나는 고등학교 때까지 코딩을 많이하지 않았고, 그곳에서 나는 상당히 성공적이지 못한 정직하게 코딩하는 방법을 스스로 가르치려고했다.
그런 다음 내가 대학에 들어가면 여러분은 코스 북을 받고 코스 북을 훑어 보았습니다. 유일한 것이 아니라 저에게 정말 흥미로운 핵심 코스 세트보다 더 많은 것이 컴퓨터 프로그래밍 코스였습니다.
그래서 개발자가 되겠다는 생각을했던 순간 일 것 같아요.
신입생 으로서는 직업에 대해 무엇을 알고 있는지 잘 몰랐습니다.
하지만 제가 분명히 일자리를 찾는 선배 였을 때 이것이 저에게 잘 맞는다는 것이 분명했고 산업이 성장하고있었습니다.
90 년대 후반이었고 산업은 많이 성장했습니다.
좋은 기회였습니다.
Where did your career first start?
I started at GTE labs.
So GTE was a telephone company.
It's now part of Verizon I think.
I was in their labs, which is the old telephony labs sort of like AT&T labs, and they have a storied history in computer science.
But it was on the down swing in Boston.
I did that for a year, and then I went to a company called Thompson Financial, which is part of Thompson Reuters, the big financial information and just information in general company.
I worked on search engine, therefore, financial documents.
Then I got bored honestly with Web apps, and so I went back to graduate school, and I spent six years getting a PhD in robotics.
So I did humanoid motion planning.
So how do you move arms that look like human arms? I did that mostly because I wanted to be a professor I thought I wanted to teach.
I did want to teach and I then I was a professor for a couple of years at a small school called Union College in Schenectady, New York and enjoyed it.
It was really a lot of fun.
But I was ready to move back to Seattle, and when your professor, you don't really get to choose where you live.
So I came back to Seattle and I took a job at Google working on web search.
I spent four years working on web's core, web search, web search infrastructure.
The summary was, if you did a search and you got a result that was under about 12 hours old.
It's coming out of infrastructure that the teams that I was on built, which is a lot of fun, taught me a lot about scale, taught me a lot about impact, gave me that taste for like what it's like to write software that lots and lots of people use.
Then there was a big reshuffling of people and my team ended up moving to Cloud, and there was like a time machine.
I stepped out of doing development when I went into graduate school because I was focused on robotics and embedded systems, and step back in 10-15 years later and looking at how people were developing code, it seemed like there must be a better way, and that really inspired us to do the community's open source project, especially as Docker, do the hockey stick, and then obviously transitioned to Microsoft.
A lot of the reason for that is I see the next generation being the developer productivity.
How do we make it easier to build distributed systems? There is this incredible DNA in this place around developers and developer productivity.
That's the career.
I mean, I think Kubernetes is the longest I've ever done anything at about seven years.
So it's cool.
저는 GTE 연구소에서 시작했습니다.
그래서 GTE는 전화 회사였습니다.
이제 Verizon의 일부라고 생각합니다.
저는 그들의 연구실에있었습니다. AT & T 연구실과 같은 오래된 전화 연구실이었고, 그들은 컴퓨터 과학 분야에서 저명한 역사를 가지고 있습니다.
그러나 그것은 보스턴의 다운 스윙에있었습니다.
저는 1 년 동안 그렇게했고 그 후 Thompson Financial이라는 회사에갔습니다. Thompson Financial이라는 회사에갔습니다. Thompson Reuters의 일부입니다. 큰 재무 정보이자 일반 회사의 정보입니다.
나는 검색 엔진, 따라서 금융 문서 작업을했습니다.
그런 다음 솔직히 웹 앱이 지루 해져 대학원으로 돌아 갔고 6 년 동안 로봇 공학 박사 학위를 받았습니다.
그래서 휴머노이드 모션 플래닝을했습니다.
그렇다면 인간의 팔처럼 보이는 팔을 어떻게 움직일까요? 저는 가르치고 싶다고 생각한 교수가되고 싶었 기 때문에 그렇게했습니다.
저는 가르치고 싶었고 그때 저는 뉴욕의 Schenectady에있는 Union College라는 작은 학교에서 몇 년 동안 교수로 재직하면서 그것을 즐겼습니다.
정말 재미 있었어요.
하지만 저는 시애틀로 돌아갈 준비가되어 있었고 교수님이 살 곳을 선택할 수 없었습니다.
그래서 시애틀로 돌아와서 Google에서 웹 검색 작업을 시작했습니다.
저는 4 년 동안 웹의 핵심, 웹 검색, 웹 검색 인프라에서 일했습니다.
요약은 검색을했는데 결과가 약 12 시간 미만인 경우입니다.
제가 구축 한 팀이 저에게 규모에 대해 많은 것을 가르쳐주고 영향력에 대해 많은 것을 가르쳐 준 것은 인프라에서 나오고 있습니다. 소프트웨어를 작성하는 것과 같은 맛을주었습니다. 많은 사람들이 사용합니다.
그런 다음 사람들의 큰 전환이 있었고 우리 팀은 결국 클라우드로 옮겨 갔고 타임머신과 같았습니다.
저는 로봇 공학과 임베디드 시스템에 집중했기 때문에 대학원에 진학했을 때 개발을 그만두고 10-15 년 후 사람들이 어떻게 코드를 개발하는지 살펴 보았습니다. 더 나은 방법이있을 것 같았습니다. 그리고 그 덕분에 커뮤니티의 오픈 소스 프로젝트, 특히 Docker가 하키 스틱을 수행 한 다음 분명히 Microsoft로 전환하게되었습니다.
그 이유는 다음 세대가 개발자 생산성이라고 생각하기 때문입니다.
분산 시스템을 더 쉽게 구축하려면 어떻게해야합니까? 여기에는 개발자와 개발자 생산성에 대한 놀라운 DNA가 있습니다.
그것이 경력입니다.
내 말은, 쿠 버네 티스는 내가 약 7 년 동안 내가 해본 것 중 가장 긴 것 같다.
그래서 멋지다.
What advice would you give to a developer just starting their career?
The number one advice I tell everybody, especially when they're starting out, is focus on learning.
That's people say, should I switch jobs? Should I switch companies? Enrolls, and I say like, "Well, are you enjoying yourself and are you still learning?" Because obviously we want to be happy.
So you should be enjoying yourself.
But learning is a really great sign of whether you're in the right place or not.
If you're still feeling challenged, if you're still feeling learning, it doesn't matter if you're in the same place for 20 years.
As long as it changes, as long as you continue to develop and learn.
But on the flip side, if you've been someplace for two years and you feel like everything there is to know, it's probably a good sign you need some change.
So I would really focus on, and I think learning how to learn and being comfortable with being uncomfortable or being comfortable with not knowing, being comfortable with that process of going from knowing nothing to knowing a little bit to then really knowing nothing again to having some degree of mastery.
If you practice that a lot, it becomes a lot less scary.
It becomes a lot easier.
You like, "This is the part where I feel lost and hopeless," and you know that in two weeks, you'll feel really good and it carries with you.
If you don't do that very often, you forget what it was like.
I think we forget what I was like to learn.
So that's the advice that I would give to people just starting out, try lots of things.
특히 처음 시작할 때 모든 사람에게 가장 중요한 조언은 학습에 집중하는 것입니다.
사람들은 내가 직업을 바꿔야할까요? 회사를 바꿔야합니까? 등록하고 나는 "글쎄, 너 자신을 즐기고 있고 아직도 배우고 있니?"라고 말합니다. 분명히 우리는 행복하기를 원하기 때문입니다.
그래서 당신은 자신을 즐기고 있어야합니다.
그러나 학습은 당신이 올바른 위치에 있는지 여부를 나타내는 정말 좋은 신호입니다.
여전히 도전을 받고 있고, 여전히 배우는 느낌이 든다면, 20 년 동안 같은 장소에 있어도 상관 없습니다.
그것이 변하는 한, 당신이 계속 발전하고 배우는 한.
하지만 반대로 2 년 동안 어떤 곳에서 지냈고 알아야 할 모든 것이 있다고 느낀다면 약간의 변화가 필요한 좋은 징조 일 것입니다.
그래서 저는 정말 집중할 것입니다. 저는 배우는 방법을 배우고 불편 함을 느끼거나 알지 못하는 것에 편안함을 느끼고, 아무것도 모르는 상태에서 조금 아는 상태에서 다시 아무것도 알지 못하는 상태로 전환하는 과정에 편안함을 느낍니다. 어느 정도의 숙달.
많이 연습하면 덜 무섭게됩니다.
훨씬 쉬워집니다.
당신은 "이것이 내가 길을 잃고 절망적 인 느낌을받는 부분"을 좋아하고, 2 주 후에 당신은 정말 기분이 좋을 것이고 그것이 당신과 함께 할 것이라는 것을 알고 있습니다.
그렇게 자주하지 않으면 어땠는지 잊어 버립니다.
제가 배우고 싶었던 것을 잊은 것 같아요.
이것이 제가 처음 시작하는 사람들에게 줄 조언입니다. 많은 것을 시도해보세요.
What do you wish someone had told you?
I think early starting out, I got really lucky and I had some really good mentors.
So I got a lot of advice about how to build software.
I don't think that I stepped into the open source community quite as early as I could, and I think that might have been a little bit more.
I've had a really good time and I've really enjoyed my career in general, but I think maybe there was some opportunities there, but I found my way in anyway.
So I don't know.
I think I've been lucky.
일찍 시작해서 정말 운이 좋았고 정말 좋은 멘토도 몇 명 있었어요.
그래서 소프트웨어를 만드는 방법에 대한 많은 조언을 받았습니다.
가능한 한 빨리 오픈 소스 커뮤니티에 들어갔다고 생각하지 않습니다.
저는 정말 즐거운 시간을 보냈고 전반적으로 제 커리어를 정말 즐겼습니다.하지만 거기에 기회가있을 수도 있겠지만 어쨌든 제 길을 찾았습니다.
그래서 모르겠습니다.
운이 좋았던 것 같아요.
What are some of the biggest lessons that you learned?
One of the biggest lessons that I learned was to know when it's time to stop.
I've had projects where, and I've seen other people's projects where they got so attached to it because they'd put so much time into that when it was time to move on, it was really hard for them to do it.
They stuck with it and it became way more painful than it needed to be to move on because they stuck with it way past the time when everybody else realized that it was done.
I think that's an important lesson.
You can't be attached.
You can't get too attached.
I told someone the other day, the inevitable trajectory of all software is death.
Like every piece of software that you write is eventually going to be deleted.
Even Kubernetes is eventually going to be deleted.
So accepting that and being comfortable with that is really important because otherwise, you make bad decisions.
You make decisions that you may have to do with attachment rather than where the world is at.
I think the other thing that I learned was the importance of community and working together.
That's been a huge thing.
I was a little bit more of a solo person earlier in my career, and I think that's been something that I've learned a lot of is, how to delegate, how to let go, how to let other people do the work, and realize when it's time for you to move on and to let other people do the work.
제가 배운 가장 큰 교훈 중 하나는 언제 멈출 때인 지 아는 것입니다.
저는 다른 사람들의 프로젝트를 봤습니다. 다른 사람들의 프로젝트를 봤습니다. 다른 사람들의 프로젝트에 너무 많은 시간을 쏟았 기 때문입니다. 왜냐하면 그들은 앞으로 나아갈 때가되었을 때 그렇게하기가 정말 어려웠 기 때문입니다.
그들은 그것을 고수했고 다른 사람들이 그것이 끝났다는 것을 깨달은 시간을 지나서 고집했기 때문에 계속 나아가는 데 필요한 것보다 훨씬 더 고통스러워졌습니다.
그것은 중요한 교훈이라고 생각합니다.
당신은 붙일 수 없습니다.
너무 집착 할 수는 없습니다.
요 전에 누군가에게 모든 소프트웨어의 불가피한 궤도는 죽음이라고 말했습니다.
작성하는 모든 소프트웨어와 마찬가지로 결국 삭제 될 것입니다.
결국 Kubernetes도 삭제됩니다.
그러니 그것을 받아들이고 그것에 익숙해지는 것이 정말 중요합니다. 그렇지 않으면 나쁜 결정을 내리기 때문입니다.
당신은 세상이있는 곳보다는 애착으로해야 할 결정을 내립니다.
제가 배운 또 다른 것은 공동체와 함께 일하는 것의 중요성이었습니다.
그것은 엄청난 일이었습니다.
나는 커리어 초기에 조금 더 솔로 인 사람이었고, 그것이 내가 많이 배웠던 것, 위임하는 방법, 놓아주는 방법, 다른 사람이 일을하게하는 방법, 그리고 당신이 다른 사람이 일을하도록 내버려 둘 때가되었음을 깨달으십시오.
What sorts of goals have you set for yourself this year?
The goals for my for myself, they actually tend to span more than one year.
I mean obviously, of near term goals.
I want to make sure my teams are happy, I want to make sure my products keep growing, and things like that.
I think the biggest thing for me is when I look at the systems that people are struggling to build, when I look at the things that people are building on Azure or anywhere else, it's just too hard.
I feel like we're still people are banging rocks together, and I feel bad, I feel responsible.
I feel like we need to do a better job building tools for them so that they can focus on their business and they're on their product.
I love what's going on with no code, low code stuff.
But I think we need to figure out how we bridge it.
How do we take it from no code all the way through to really advanced code in a seamless way.
Right now, it's these siloed experiences.
So my goals, obviously I guess for this year, but for the years to come, have a lot to do with improving developer experience for distributed systems.
나 자신을위한 목표는 실제로 1 년 이상 지속되는 경향이 있습니다.
분명히 단기적인 목표를 의미합니다.
우리 팀이 행복하고 제품이 계속 성장하도록하고 싶습니다.
저에게 가장 큰 것은 사람들이 구축하기 위해 고군분투하는 시스템을 볼 때, 사람들이 Azure 또는 다른 곳에서 구축하는 것을 볼 때 너무 어렵습니다.
나는 우리가 여전히 사람들이 함께 바위를 두드리는 것처럼 느껴지고 기분이 나쁘고 책임감을 느낍니다.
그들이 사업에 집중하고 제품에 집중할 수 있도록 도구를 더 잘 구축해야한다고 생각합니다.
나는 코드없이, 낮은 코드로 진행되는 것을 좋아합니다.
하지만 우리가 어떻게 연결하는지 알아 내야한다고 생각합니다.
코드가없는 상태에서 고급 코드까지 매끄럽게 진행하는 방법은 무엇입니까?
지금은 이러한 사일로 경험입니다.
내 목표는 분명히 올해에 대한 것 같지만 앞으로 몇 년 동안 분산 시스템의 개발자 경험을 개선하는 것과 관련이 있습니다.