Transcript
Stefan Tilkov: Welcome, listeners, to a new episode of The CaSE Podcast, a new conversation about software engineering. My guest today, I'm very happy to say, is Steve Vinoski. Hi, Steve.
Steve Vinoski: Hello!
Stefan Tilkov: Steve is someone I've admired for a long, long time, and I've known him for a long time... I'm really happy to have him on the show, and our topic today is going to be things a mentor can tell their mentee. Steve, great to have you here, and welcome to the show.
Steve Vinoski: Thank you for having me.
Stefan Tilkov: Steve, please introduce yourself first.
Steve Vinoski: Sure. I work for a company called Arista Networks, but I've got a fairly long history of being in software, and even hardware development... I guess about 34 years or so. I started working at Texas Instruments in the mid-eighties, working on hardware, working on chips, and they needed someone to write tests for one of the chips that I was working on, and they pointed to me because I was the youngest person on the team.
Steve Vinoski: I didn't know much about software, so I started studying it and I found that it was pretty cool. I taught myself a few languages... As I learned more and more, I just kept moving farther away from hardware, and more into software.
Steve Vinoski: I went to Apollo Computer in the Boston area in 1987, started using C++, worked in a group that did kind of half-hardware, half-software for a few years, and then came CORBA (Common Object Request Broker Architecture). There was a team in Apollo - what was then Hewlett Packard, because in 1989 HP bought Apollo - that was working on one of the first object request brokers, and I was looking around the company for anybody using C++, and that team was using C++. So I joined that team -- not because of CORBA, but because of C++, and I spent quite a bit of time working with CORBA, working on the object management group standards, working in teams and leading teams that developed object request brokers both for Hewlett Packard, and then later for IONA Technologies, which was one of the most successful Irish software companies in history.
Steve Vinoski: Along the way, I kind of learned a lot more about distributed systems, which is a lifelong thing - you can never learn everything about distributed systems... That kept me quite busy, and it still does, in some ways.
Steve Vinoski: Then I was looking at web development technologies, as the web got stronger and more powerful and more popular and everything... I was looking at the web and found Roy Fielding's thesis on REST; I started looking at that, and I said "Wow, that's different than what CORBA preaches", and I could see a lot of ways that it made a big difference, especially for large-scale systems like the web... So I worked with REST for quite a while.
Steve Vinoski: In 2006 or so I found the Erlang programming language, and saw that it had a lot of things built into it that we had spent quite a bit of effort developing in C++; it was already there in Erlang, so I started working with Erlang. I worked for a couple companies, including Basho Technologies, the makers of Riak, who used Erlang.
Steve Vinoski: Then about three-and-a-half years ago I switched gears again and joined Arista Networks. They make networks switches, and primarily target the data center and the cloud technologies, cloud systems.
Steve Vinoski: The interesting thing about Arista is they have a mentoring program. Every engineer, it doesn't matter how many years of experience they have, when they join, they get a mentor for three months, and they're under the guidance of that mentor. The whole idea there is that we have - as any company does - our particular engineering process, we have lots of tools that we both get from outside or develop ourselves, we have processes in place for all kinds of different things that we have to do, and rather than just kind of casting someone into the mix and saying "Figure it out", we take the time for a mentor to teach the person where to look, who to talk to, what to do, all that kind of stuff... And it really saves time in the end, because it prevents questionable practices from creeping in, and it just gives that person kind of a comfortable feeling when they're coming to work those initial days. They know who to turn to when they have questions. Anyway, that's who I am.
Stefan Tilkov: Great. When we started out planning for this conversation, I actually wanted to talk about distributed systems for a while, but you said "Um, we've done that...", and I said "Okay, let's think about other interesting things to talk about." Then I finally noticed that a very interesting thing would be to draw from your experience of 30+ years and talk to you about this mentoring thing and about the kinds of things that you'd be able to share with somebody who's starting out their career as an engineer. That's gonna be what we're talking about, and maybe we can start with one of the things that people (I think), including myself, fall victim to, or I used to when I was younger, a long time ago, which was to be unable to decide what is an over-hyped fad and what's something that's really worth learning... So how do you make that decision?
Steve Vinoski: That's a good question, and a hard question. I think everyone - you said you did, I certainly did - has experienced the case where you see something that's hyped, and you take a look at it and it looks like "Hey, this looks great. I'm gonna jump onboard, and drink the Kool-Aid. This is gonna solve all my problems." As you know, it's not always the case.
Steve Vinoski: I guess one way -- well, I guess there are a couple ways to do it. You could be an early adopter or a late adopter. If you're an early adopter, you jump in and I think you can get in and start seeing the thing for what it is. You have to grab it and try to make actual use of it. It's kind of like programming languages - you can look at them, you can say "Oh, this looks like this one I know... I kind of know it because of that", but you don't really learn a programming language until you actually use it for real development, not just an example; something that solves an actual problem you have. I think that can be applied more broadly to any new technology.
Steve Vinoski: If you see something that's hyped and people are saying that it's going to solve a particular problem or class of problems, try it. Jump in on the early train and give it a try. You might find that yeah, there's some promise there, but it's got a lot of things missing. If you're early enough and if you want to put in the time, you might be able to actually influence the technology to go the way you want it to by not only being an adopter, but joining in with the development of the system, if that's allowed. So many systems today are open source, so that's generally possible. That's one way to do it.
Steve Vinoski: Of course, being a late adopter means kind of being skeptical and saying "No, I don't believe a word of it, and I'm not gonna even try it until everyone's proven it and it's already solved a number of problems that people have that are like the ones I have. Then I will make use of it."
Steve Vinoski: I think what's interesting about those two positions is it kind of goes back to one of my favorite topics, which is the innovator's dilemma, and the adoption of technology. If you look at the work of Clayton Christensen and others who have also worked on this area, you have this kind of bell curve which is early adopters jumping in and finding that this new technology doesn't quite do what they want, but it's good enough and it's better than what came before, and they kind of coax it along and get it from good enough to better. Then more people see that it's better and they jump in, and they kind of help push it even farther and better, and it reaches a peak where the average developer has adopted it, and then it starts to decline somewhat, and that's when the skeptics start to adopt it, and late adopters then pick it up, because by then it's proven itself and it's slowed down its rate of change. Some people fear change, so they tend to wait until the rate of change has slowed, and that's what happens as the technology kind of wanes, and then the late adopters pick it up.
Stefan Tilkov: I would guess that probably in your youth you were definitely somebody to adopt things early, right? Which is why you ended up using C++ in CORBA at the time when those were very new things still...
Steve Vinoski: Yes, I would say that's true.
Stefan Tilkov: Has that changed over the course of your career? Have you become more skeptical, more and more skeptical?
Steve Vinoski: I wouldn't call it skeptical. I think it's more practical. As you know, you tend to see cycles in things, and you see similar things happen over and over again, so it's almost like being on Groundhog Day or whatever, where you see a technology and say "Oh, that's a lot like this thing that happened a few years ago. I'll take a look, but it's probably not any different than that thing, and that thing had the following problems, and that's why I didn't use it." We do have cycles like that, and sure, each iteration does have some improvement, but it's really about "Is it good enough to make you want to switch to it?"
Steve Vinoski: I think also as you have more experience, you do become kind of comfortable with the tools you have, and tend to lean on them more. It takes a bit more to get you to switch, so maybe there is a bit of skepticism involved in that.
Stefan Tilkov: Actually, one of the things that I remember - I don't know which year it was, but we did an interview at a conference (I think it was QCon San Francisco) a long time ago, it must have been about a decade ago, and that was when you first talked to me about your newfound love of Erlang... And I actually found that quite amazing - something that you said two minutes ago, that you noticed that a lot of the things that you had tried to solve or that had taken you a lot of effort to solve using C++ in the CORBA ecosystem were actually a lot easier with Erlang... Was that a hard thing to do? Because it sounded to me like you were this absolute expert in this CORBA thing, and then you sort of said "Well, yeah, maybe I shouldn't have done that."
Steve Vinoski: I don't think it's a hard thing... I think everyone has to look at what they've worked on, and you have to know that it's not going to last forever. There's a saying in business that if you really want to succeed, you kind of put yourself out of business before somebody else does, and I think you can apply that to what we work on, as well. If you want to just get stuck with a technology and ride it out, you can certainly do that. There's been technologies that have lasted for decades and decades, and people have stuck with them. There's a lot of C++ gurus that were C++ gurus back when I started looking at C++, 30 years ago, and they're still considered gurus today. So they rode that along, and they've done well with it.
Steve Vinoski: But I think it's usually better to kind of look at things, and like I said earlier, you want to look at new things that come along - don't shield yourself from them, but honestly evaluate them. If you're truly an expert in something like CORBA, that means you not only know what it's good at, you know what it's bad at. Looking at things like Erlang, looking at what it's got in it, how it works, what are the underlying architectural principles, how do those differ from CORBA or other languages... I think you have to be able to do that if you're truly an expert. And if something's better, hey, it's better. There's no point in pretending it's not.
Stefan Tilkov: Related to that, have you seen people become a victim of vendor marketing, and if so, what is your advice against that?
Steve Vinoski: We've all seen that, I think... That's a tough one. Vendor marketing can certainly oversell things. I always wonder what the programming language world would be like today if Sun hadn't massively pushed Java 25 years ago, or whatever it was... I think it would be a lot different. I think for a long time, Java kind of put almost a clamp on language development, language innovation. So many people flocked to it... And I think that's another example of where people have been able to just kind of adopt the technology, sit on it for decades and ride it out, and it's done well for them. But would it have succeeded like it did if Sun hadn't had such a massive investment from a marketing perspective? Who knows...?
Steve Vinoski: CORBA - kind of the same thing. Object Management Group is a group composed of hundreds of companies, all of those companies pushing things like CORBA and the services around it and the products that came from it. Was it good? Yeah, it was good for some things, maybe not so good for other things.
Steve Vinoski: I think it really does come back to that kind of pilot program notion that I mentioned earlier. You've gotta use it, you've gotta try it. The marketing stuff is what it is; of course, they're gonna spin it a certain way, they're going have examples that work well for the spin they're putting on it, but does that mean it's going work well for you? You don't know until you absolutely sit down with it, work through it... You have to compare it against other things, whether they're popular or not. That's really the only way to get around it.
Steve Vinoski: You do get to the point where you start to recognize vendor (over)selling, if you wanna call it that... Just pushing and pushing and pushing. It does kind of wear you down and makes you think "Well, if they're willing to put that much time into it, it must be worth my time as well", and you tend to jump on... But at the end of the day, you just have to resist and give it a try for yourself.
Stefan Tilkov: Let's get away from products and hype... What are, in your view, some of the foundational things that people should look at? What's sort of a prerequisite for being a good engineer?
Steve Vinoski: Interesting question... I think there are technical and non-technical aspects. One thing I would say - all the good engineers I can remember working with always had a curiosity; they weren't satisfied with what they had... Not in the sense that they wanted to throw everything away and start over, but in the sense of knowing that something could be improved, even a small improvement. Always looking for ways to make their systems better.
Steve Vinoski: What goes along with that is study. There's a constant learning that has to happen. Some people say "The company should be training you", and stuff like that, and I think that's a different issue. It's really about your curiosity and what technical things interest you. They're not always the same as what the company who pays you are interested in, right? So finding papers, finding books, finding articles that describe certain issues, tear them down, kind of come to conclusions about what works well with that approach, what doesn't, comparisons against similar approaches - those are always good things to read for an engineer.
Steve Vinoski: Back when I started, I remember having to go to the library at Apollo computer and look for papers in these big binders, and if I couldn't find it, I'd have to ask a librarian, and they'd say "Well, we don't have that, but maybe I could request it from another library", and it would take days or weeks to get things. Of course, today we just search it, find it, read it... So given the technology we have today, there's really no excuse for not keeping up with things, not keeping up with your interests and your curiosity.
Steve Vinoski: I know, Stefan, that you like similar music to the music I like, and you have this way of finding bands. You listen to a band, and you look at all the members of the band and say "Who played drums? Who played bass?" and you kind of go and say "Do they have any solo work? Do they have work with other bands?" and you find other bands or other solo artists that way... And of course, you also have music recommendation technology and stuff like that today that helps. You can do that with papers, too; you look at the authors of a paper and say "What other things do they do?" and search their name, or the topic, and generally you will find things, not only things that you know about, but things that you probably didn't know about that might even be more interesting than what you think you're interested in. I'd say that's something that's fairly fundamental to the work we do.
Steve Vinoski: What else...? You know, there's this thing as a non-technical issue - you have to be able to work with people. If you're going to be a lone developer and have your own business and write all the code yourself and do all the testing, that's doable, but very rarely. Generally, you have to be able to work with people, communicate with people, be able to take other people's points of view, be able to put aside your own -- you might have strong feelings about a particular approach or technology, but you have to kind of set that aside, listen to the counter-arguments for different approaches or different technologies, and kind of separate the emotional binding that you might have to something from the technical side... You've gotta get along. I think that's an important aspect, as well.
Stefan Tilkov: How much do you think, as an engineer, you have to look at the other surrounding aspects and disciplines in your company or in your context? Maybe the economic side of things, the business side of things, or maybe politics these days...? How much do you have to be aware of those?
Steve Vinoski: That's a tough one... Well, it fits with what I've just said in some ways; that's kind of the people side of things. You have to be able to participate in that. I think looking at the business is important. I've certainly been in places where the project is cruising along and you think you're on top of the world, and all of a sudden the business decides that that's not something that they want to be involved in anymore, or they have to make cuts and that's kind of below the bar, or whatever it is... If you're able to keep up with your own business - maybe not the entire ecosystem that your employer is in, but at least your own employer's business, keep up with what they're looking at, keep up with their direction, those kinds of things will be less likely to bite you.
Steve Vinoski: On the flipside, if you're working on something that's very important to the business, it's good to know that as well, and have some kind of contact with customers, knowing what customers want, being able to provide what they want... That's critical, of course, because if you're just developing stuff that you want, it may not be what the customer wants and it might drive the system in a direction that's undesirable.
Steve Vinoski: In terms of politics, a lot of companies do have a lot of internal politics, that's for sure... And I've generally found it's better to stay out of those, because you tend to wind up either in a place you don't wanna be, or getting burned somehow. It's sometimes hard to stay out of, because if you feel strongly about a particular direction or a particular product, you want to jump in the fray and defend it and help push it, you're going to get involved in politics; that's just human nature. Where there are people, there's politics.
Steve Vinoski: But it comes back to being honest, being open, trying to, again, be open to evaluating different ideas, different approaches, different viewpoints. I think that helps, not only you, but it helps the people around you, but it helps the people around see that you're a person to be respected and a person who's thoughtful enough to have considered many viewpoints. I think that gets you to a position where people start to seek your advice, and then you do have more influence than you might otherwise, if you're always shutting down others' ideas, or just ignoring them, or saying "My way is the only way." That's going to bite you, too; you're going to get isolated and you're going to find that you have less influence than you might otherwise wish, or might otherwise have.
Stefan Tilkov: Have you ever been in an ethical dilemma, and if so, what's your advice on those kinds of things, where maybe somebody wants you to do something that you really feel bad about?
Steve Vinoski: Yes... For me, and I know this is important to you as well, software patents - I've worked in a number of places that have patented software. Because in the past I've been technical vice-president, I've been a chief architect, senior architect - when you're in those positions, this idea of patenting does come along. People want to protect the company's assets, and IP and everything... So you get in a situation where you're kind of forced to look at the technologies you have and see if there's anything patentable, and I fundamentally don't believe in software patents, so it's kind of like "Well, what do I do?"
Steve Vinoski: In those cases, if I could, I would decline to participate, and just say "I don't believe in this and I don't think it's right", and I've managed to do that a few times. In other cases, I was still kind of asked to put together a list of things that might be patentable, and then they would just go find somebody else to evaluate them.
Steve Vinoski: I knew of one case where there was some technology where I knew of prior art, and I showed the lawyers the prior art written in published papers, and they just said "Oh, that doesn't matter. We can still get a patent", and somehow they did. In that case, I felt like I did everything I could to do the right thing, but the wrong thing still happened.
Steve Vinoski: I think you just have to stick to what you know to be right. Sometimes I've even looked at the ethics that have been written up by groups like the ACM or the IEEE (I'm a member of both of those groups), and I've actually at times gone through/read through those things where I was stuck in some ethical dilemma, and I find them helpful. They do provide general guidance. You might also find a more experienced person that yourself and ask for their advice if you're stuck in those situations. Hopefully, not too many people get stuck in those, though.
Stefan Tilkov: Let's get a bit back to the mentoring thing and the career path... Something that people might ask - is it a good idea to stick to coding throughout your career, or should you try to transcend that as early as possible and do something else, whatever that is? ...architecture, or management, or something that may not be as much related to coding as when you start out.
Steve Vinoski: Well, I've always wanted to be coding, and I still do. I've found that even those times when I had those lofty positions of technical VP or chief architect, I was not effective unless I was coding at the same time. The reason for that is at the end of the day the code is the truth; it's what the system is, it defines everything the system does, and you can have all the diagrams about what the system is, or slides, or whitepapers, or whatever, that somehow are alternative descriptions of the system, but the code is what the system is. So if you don't know the code, then you don't truly know the system.
Steve Vinoski: I'd say for me it kind of boils down to two choices - you're either going to stay on the technical side, or move into management. Some people like managing people; there's lots of challenges with that. If you're good at that, that's to be commended. And if that interests you, then you should go that way. You should also know that if you think you're going to be a people manager and also write lots of code, it's probably not going to happen. I know of people who have done it, and I could count them on one hand, literally, over all these years... So it's kind of rare. If you don't want to be a manager, then yes, keep coding. Always keep coding. And that's what I've done.
Stefan Tilkov: You've worked at a number of different companies in your career... What was the most fun? Was it small companies, or big companies? Was it while you were maybe in consulting, or product development, or doing project work? Was it maintenance, or greenfield development? What were the most interesting times in your career?
Steve Vinoski: That's a tough one. I think the most fun times I've had is just working with people that I like being around, people with certain talents in the technical arena, but also their interest in people, as well. I've been fortunate to have met quite a few characters along the way, and I've had some very good times. I've met very few people that I wish I hadn't met, fewer than five, I would say. So that's been good.
Steve Vinoski: I think to try to isolate it down to greenfield versus maintenance, or small versus big - I don't enjoy big companies. Apollo had a few thousand people, and then HP bought them, and of course, HP then was pretty big and just kept getting bigger and bigger. HP back then (28 years ago, or something), they were still on top of things; they were still around and had an influence on the company, and the thing that made HP great was still part of HP... "The HP way", you've probably heard of that... So it was an interesting place to work as a big company.
Steve Vinoski: But then that started to wane and fade away, and it became this -- I don't know... It was like a collection of smaller companies, all competing with each other, within a big company. It was hard to get anything done, and you saw these middle managers trying to build empires, and battling with each other as if they were separate companies competing with each other. That got to be a drag, so once I left there, I just said "You know, I don't think I'll ever go back to a big company", and I never did.
Steve Vinoski: I think working at smaller companies is better. You get to know the people who are there, you get to have better visibility, not only into the system(s) you're building, but who works on what, what their strengths are, how different people can apply their talents to different areas... You get to kind of see the business side as well, maybe be directly in touch with customers, be on sales calls, be on support calls, where the customer is quite angry with you and you have to figure out what the problem is and fix it; that's always a good thing to experience, as painful as it might be. I tend to like companies where you have the ability to see across the business, not only engineering, but business as well.
Steve Vinoski: In terms of new development versus maintenance, this might sound crazy, but I think it takes a better engineer to be a maintenance developer than it does to be someone cranking out new code.
Stefan Tilkov: How so?
Steve Vinoski: I think when you have something that's there in front of you, it has a certain structure, you have to be able to kind of respect that structure and fit whatever it is you're doing into that structure. Now, sure, you could change the structure and maybe tweak it a bit, but you're kind of like taking something that's working and leaving it in a better place.
Steve Vinoski: When you have new development, I think you're cranking stuff out and it's got a lot of holes in it; you might think it's the best thing you ever wrote, but it's going to have holes in it, it's going to have bugs in it, it's going to have sometimes holes big enough to drive trains through or whatever, and you're going to be kind of oblivious to it.
Steve Vinoski: The mentality I really don't like related to that is "I'm gonna write all this new code, and then it's gonna be someone else's problem to fix..." That's very bad, don't do that. A company that I've worked for, that had been the most successful in terms of what they've produced and in terms of keeping people there and keeping people interested in what they're doing are companies where engineers develop code and they maintain that code, they write tests for that code. That doesn't mean you can't move on to different things, that you're always stuck with your own code and everything you've written in the past; that's not true. What I'm really talking about is kind of a lifecycle... Write it, test it, maintain it, fix it.
Steve Vinoski: Fortunately, today the notion of continuous integration, continuous development is fairly widespread, and I think that approach uses this lifecycle thing I'm talking about. It's not foreign to a lot of developers today, which is good, but it's certainly something I've seen in the past that is to be avoided. But I'd say most of what developers work on, the majority tends to be more maintenance-related than new code development. That's why it's good to be strong in that area.
Stefan Tilkov: From the mentoring side of things, as well as from imagining you're just a regular co-worker, how do you deal with that young, talented, ambitious, but still pretty clueless colleague who just doesn't know that he/she doesn't know everything? ...on the contrary, they actually believe they do know everything. How do you actually help them to appreciate things and actually become better at their job?
Steve Vinoski: Well, I'd say one thing that we try to do -- where I currently work, we have a way of hiring that I think doesn't always bring in people that are so blind to themselves, shall we say... So that's good. We do get people who have that curiosity I mentioned earlier, that aren't afraid to work on fixing bugs instead of writing new code, that have a more rounded approach to things, so I think I'm fortunate in that regard. That doesn't mean that they don't need mentoring and they can't learn, or anything like that... That's definitely not true, and I'd say that's definitely true of anybody.
Steve Vinoski: I think the main approach is to really focus on that whole notion of lifecycle. If they write some bug fix, review it, take a look at it... Where I work now, all code is reviewed. It goes up in a browser and you can look at it, you can comment on individual lines, just like things you can do with GitHub, or similar to that. You can put comments in, you can raise issues, you can actually block the thing from getting merged, if it came to that... Fortunately, it doesn't really ever come to that.
Steve Vinoski: The main thing is to ask questions about "You did this, but have you considered the following issues?", and it requires you as a mentor to have kind of a bigger picture in mind. They might be thinking of the very particular fix they're putting in, or the very particular change they're putting in, but they are going to be effects of whatever it is they're doing. Maybe they change the API to some class or something and it might affect systems in other areas that they didn't know existed, so you have to be able to point things like that out.
Steve Vinoski: They might be using the programming language in a certain way that isn't idiomatic, that maybe there are better ways of doing it, that are more normally done with that language. Things like that have to be pointed out. You have to evaluate the change to make sure that it's doing what the customer needs it to do, that it fits the architecture, that there isn't some code that already does what they've done that they could have just reused... All that kind of stuff is the job of a mentor, and you have to do it in a way that isn't kind of squashing that person's notion of contribution.
Steve Vinoski: If they put something in and they're kind of happy with it, you have to kind of gently ask questions, like "Did you consider this?" or "Hey, have you seen this part?" "Oh, your code reminds me... I've totally forgot there's this piece over here that we could reuse... Did you look at that?" And kind of think of the human side of the equation. You have a person there who's doing their best, and you want to keep them doing their best, and be gentle. Ultimately, it's the job of the mentor to have that bigger picture in mind and be able to get that picture across to the person they're mentoring.
Stefan Tilkov: Let's turn this around and say you're the new person; maybe not directly from college or university... Maybe you have a few years experience, but there's this wise, experienced person, well-known possibly even, with lots of experience, and they're really smart, but they're also completely disillusioned and stubborn in their own ways. How do you go about changing a person's mind if they're like that?
Steve Vinoski: That's a good question. I remember once when I was a very young developer at Apollo, I was working on a boot ROM for some system... So you had your code, and you had to burn that onto a EEPROM and then you'd plug it in and hope that it booted the system, and if it didn't, well, back to the drawing board and figure it out... And because of my lack of I guess formal software training (or whatever), I was kind of struck one day by this notion of that thing that burned the PROM this machine you'd load your code into, and it would write it all into the ROM. I was like "I wonder how this actually works inside." I asked somebody and they said "Oh, you should go ask this one particular senior developer."
Steve Vinoski: I remember that guy had -- they all had offices back then, with doors and everything... This guy had had like several bookcases arranged around the door of his office, so once you went in the door, you had to navigate through this maze of bookcases to even find the guy. That was a signal, like "Don't bother me." But being young and naive, I navigated through and asked "Hey, how does this thing work?" You could also smoke in your offices back then; he was smoking a cigarette, staring at his screen, and he stopped and turned and looked at me and just told me to get the hell out of his office. He didn't ever answer the question.
Steve Vinoski: Don't be like that... If you're the kind of person that you described in your question, at least don't take it that far. I never did get the answer to that question, but... I'd say the thing about when you have experienced people, you do have to respect the fact that they know things. They didn't get to where they are by not knowing things. They have strengths, and you kind of have to figure out what those strengths are and start to pick up on the things that are important to them, and why are those things important.
Steve Vinoski: I think if you were to ask somebody "I've noticed that you prefer this way of doing this particular thing... Why is that? Is there something hidden in there? Is it just based on experience that that works out best? What are the alternatives, why aren't they as good?
Steve Vinoski: Most people will tend to sit back and say "Well, here's why", and you gain some insight into their thinking. I think you can then start -- it's almost like you're joining their team; you start to see why they do certain things a certain way, and if you're showing them that you understand why things are the way they are, once you have that understanding and they see that you have it, it's a lot easier to change their mind about things, because then they know that you have studied the system, you know why it's done the way it is, but here's some alternatives that you think they might want to look at.
Steve Vinoski: The alternative, of course, is to kind of charge in and say "Well, that's the past, here's the future" or "Here's why this has to be done", and you're sort of setting yourself up for this battle that you probably don't want. So it's just better, I'd say, to take time and at least get to understand the system and the person or people behind it, why they do certain things a certain way, and you'll have a better time influencing that system afterwards.
Stefan Tilkov: One of the things that you did throughout your career was to write a lot of papers and magazine articles, and do a lot of conference presentations... I don't know how many -- did you keep track of how many of those you did, actually?
Steve Vinoski: No... In terms of articles, I know there were over 100. Not greatly over 100, but over 100. Conference presentations I would say hundreds...
Stefan Tilkov: Is that something that you recommend doing, and would you advise people to consider doing that? Under what circumstances would you suggest that people do that?
Steve Vinoski: That's a tough one as well... I think the reason I got into it was because of -- you know, I mentioned early on in this podcast the notion of being curious and looking for approaches that might solve problems you're working on, reading papers... I was doing that - I was reading books, I was reading papers, and kind of voraciously absorbing and absorbing, and some of the authors of those papers I contacted and I would get to know them, and they were the ones who started encouraging me to publish my own articles, or write my own books, or give conference talks, or whatever... It's certainly not an easy thing to do, because it takes quite a bit of time.
Steve Vinoski: I was lucky in that I had -- my wife was very supportive of my work, even if it meant spending night times working on papers, or books, or traveling to conferences... My employers generally were supportive of that as well, taking time off to go give a talk. So I understand that some people don't necessarily have that opportunity, and that makes it difficult... So that's something you have to be aware of, that it's going to impact your work and your personal life... And if you're lucky enough to have a system around you that does support it, then I definitely recommend it. It's going to open your eyes to a lot of things, a lot of work of other people; it's going to kind of make you think about things that you thought were just kind of hard truths all of a sudden are revealed not to be, when you see some of the work of other people... Or even you get like a question at a talk, someone asks a question about the talk you just gave, and you might think "Oh, that's interesting...", and go off and kind of research their question and find this whole door opens to another world that you were unaware of. So if you're that curious type of person and you do have that support system that allows you to do this, then publishing and speaking are definitely good things to do.
Stefan Tilkov: Okay. Did we cover most of what we wanted to cover? Is there something you wanted that you wanted to add, a piece of advice for the young engineer?
Steve Vinoski: Yes, I kind of hinted at it earlier... Don't wrap yourself up emotionally in what you're working on. It's not always the easiest thing to do. Once you spend a lot of time on something, it's your work and you want to protect it... But everything we do changes so much, changes so rapidly that you just can't get attached. There's business behind this, it's not just a pure coding exercise most of the time; there's business choices that have to be made, and sometimes they are made in a way that isn't favorable to your technical choices.
Steve Vinoski: So try to avoid not only emotionally wrapping yourself up with what you work on, but don't be that technology. For a while, I was the CORBA guy. Then I became the REST guy. Then I was the Erlang guy... And then I don't know what I am now. Just the old guy, I think...
Steve Vinoski: That's good, if you become that sort of person where you're identified with a particular technology - that's fine, but don't just hang out there forever. Reinvent yourself. Look at the alternatives and say "You know, we did that work, it was good for what it was, but here's a different way now", and don't be afraid to take that next step.
Stefan Tilkov: Very good. Steve, thanks for all the advice and all the wise words. I really enjoyed the conversation. We'll put in a bunch of links in the show notes to your other work... Is there anything that we should add related to mentoring? Any book you can recommend or resource you can recommend on this particular topic?
Steve Vinoski: Not really... I don't tend to look to books for the mentoring side of things. I think it's just more the feel that I have for having done this for so long, and what people need to know, and that sort of thing. I do recommend that developers become familiar with the innovator's dilemma, and not just the word "disruption", because that's overused now, but the actual science behind it... It will help you see things in a way that helps guide what you do on a daily basis, so there's that.
Steve Vinoski: In terms of mentoring, don't forget it's people, it comes down to people. You're on a team, you're working with people, you have to be someone who people want to work with and conduct yourself in a way that makes you somebody that people do want to help and be around.
Steve Vinoski: The only other thing I would want to say is if people hear this podcast and they have questions, they can certainly e-mail me. My address is my last name @IEEE.org. E-mail me, and I'm sure to answer you.
Stefan Tilkov: Excellent. Thanks again, Steve, for a very inspiring conversation.
Steve Vinoski: Thanks for having me.