Collaboration and open source

- People are not open to somehow taking advantage of these types of enablers and the technologies available to us just because of the time differences. Just because of inconveniences you have to go through or deal with when you're trying to use these types of technologies. So I think being open-minded and being somehow willing to work together with anybody out there in the world. I mean, that kind of mindset I think is even more important than the tools you have, you know, available to you. I mean we are lucky that we have these capabilities, but we will be even more productive if we are able to somehow leverage those tools by being more open-minded and by being willing to reach out to the many people out there in the world as your collaborators. - So for me, you know, coming from a design background and becoming a developer, it's an interesting perspective. I've noticed that developers tend to kind of work in a very progressive, linear pattern, whereas designers tend to work across the project, or in a more organic way. And they're just two totally different ways of thinking. And even in my own head when I'm working on a project, it's like, oh, why can't the developer just get it the way I want it? And the developer side of my brain is like, you know, why is the designer making this so difficult? And so, it's this ongoing battle. But you know, even things like with test-driven development where you know, you're supposed to start with these kind of procedural of ideas in mind. It's very difficult for me, because I know my brain starts with design first. And so I really have to slow down, reverse the way I think and go step-by-step. I think there are days when I'll work on a team, and I'll sit, it's like I feel like I'm sitting on top of a wall, and you know, I'm watching the designers and I'm watching the developers and it's like, you guys are doing the same thing, and if you would just talk it would be so much easier! - In a learning environment you have this perfect setup. When you're starting a new project, it's brand new. You're using maybe the latest tools. You're using your own computer. You're maybe even working by yourself. Everything is sort of these perfect scenario situations. And then when you actually work in "real life", most of the times it's not often that you get to start in these perfect scenarios. You're starting a project that has already been started by someone else. Or maybe you're restricted in certain tools that you normally like to use because the rest of your team doesn't use that. Or maybe you have to use a Mac computer and you usually use a PC. So, a lot of times what you learn in school gives you the general background of what it is that you're learning. But those real-world scenarios are generally less perfect when you are actually working. In addition to just learning the syntax or the language or how it works or how to actually write code, when you're actually working, you now have to think about more of the soft skill side of things. So how to actually work with team members, how to ask questions when there's something that you don't understand instead of struggling by yourself. How to effectively communicate when there's issues. And so there's a lot of soft skill things that you need to learn. - I evaluate the superior contributor in three areas. The first is trustworthiness. What that means is can I count on this person to produce quality code? Will I have to worry about this person's code at all? And the next area I evaluate them on is teamwork. You know, how will this person react to code review feedback? How easy is it to collaborate with this person? Will I be able to brainstorm solutions and ideas with this person without encountering any issues? And the last area is domain knowledge. In the particular area of tech that I'm interested in. You know, is there anything I can learn from this person? You know, is he the go-to person for any technical issues that I can't solve myself or other developers can't solve themselves? So these are the three areas that I would consider when evaluating a person. - There's obviously a very big difference between doing something solitary, like writing a book, or having a job where you work in a office and collaborate with people all day long. So sometimes it's just being able to switch between the two. You know, and if you're used to working by yourself, it can be a hard adaption to all of a sudden have people talking to you all day, when you just want to kind of do your thing. But if you're in that environment, it's because working together is a better way to work. So you just have to kind of get used to that and move into that, but then if you go back to doing something solitary, again you're like, well, where are the people? Where am I getting my ideas? So I think that's the biggest difference between things is switching back and forth between those modes.