In today's episode, I interview Una Kravets, developer at IBM and prolific open source advocate. Today's episode is sponsored by Digital Ocean! Use the code "DeveloperTea" at checkout to get one month of a 1GB droplet, completely free!
In today's episode, I interview Una Kravets, developer at IBM and prolific open source advocate.
Today's episode is sponsored by Digital Ocean! Use the code DeveloperTea at checkout to get one month of a 1GB droplet, completely free!
Please take a moment and subscribe and review the show! Click here to review Developer Tea in iTunes.
Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell, and in today's episode, I continue my interview with Yuna Kravitz. Yuna is a developer at IBM. She works on the Bluemix project. She is also a proponent for Sass, the fantastically awesome style sheets. We've talked about Sass many times before. If you missed the first part of the interview, make sure you go and check it out. You can find it at spec.fm, and of course, it will be in the show notes for today's episode. Speaking of today's episode, thank you to DigitalOcean for being the sponsor of today's episode. If you are looking for a cloud hosting provider, DigitalOcean is the fastest-growing cloud hosting service provider on the market. So we'll talk more about what DigitalOcean has to offer to Developer Tea listeners later on in today's episode. But first, I want to jump straight into the interview with Yuna. So. You know, you have decided to attack some really major, big goals this year. And not only that, but you're not keeping them a secret. You've open-sourced your goals, and they're on GitHub. In fact, anybody who's listening to this can go and visit Yuna's GitHub and see what she's doing this week, and also her kind of big goals for this year. I'd love to hear a couple of those goals. I know, for example, one of your goals is to write a book this year. But I'd also... I'd like to know a little bit more about how you are going about doing this, this weekly thing that you're doing by updating your GitHub, and why you're doing it in the open-source environment. Oh, those are great questions. So this is something that I started doing in October of 2014, and I found it to be so helpful. I started it because I, like a lot of people, I'm sure, felt like there were so many things going on in the developer community. How do I keep... I'm not sure how many things I'm going to be doing, but how do I make the time? Like, you can't just find time in your day. You have to make the time. So by keeping this list, I was able to break those down, write them down. That helped me figure out exactly what I wanted to do, and then figure out the steps to get there. And then putting it out there in open-source sort of kept me accountable. It's this really great transparent system that has versioning. It's just all out there. So I figured, why not? I used GitHub for it. Yeah, it's crazy now to look at this list because I have this accomplishments folder where I just do this week in review. And I could tell you exactly what I did every week since October 3rd, 2014. Wow. That takes a lot of diligence and commitment. And I'm really interested about the mechanics of this. So do you have a specific day, a specific time that you sit down and kind of keep this list? Do you have a specific time that you sit down and kind of keep this stuff up to date? Yeah, so every Sunday night, I try to do it Sunday nights, maybe a few times, probably four or five times in the past couple of weeks. I've had to move it to maybe Saturday or Monday morning. But what I do is, as I am accomplishing these tasks for the week, I made a couple of terminal aliases where I'll just go in and check off that thing in the markdown file that is the readme of this repository. So I'll kind of just go in and check off that thing in the markdown file that is the readme of this repository. So I'll kind of just go in and check off that thing in the markdown file that is the readme of this repository. And then at the end of the week, I will look at all the things I planned for the week, make a list of things I did, things I didn't do, and things I'll do next week. I think it's really key to make a list for next week, the week before, so that you have an idea of things that you want to be doing. But it's also important not to overload yourself that week. So if I come up with an idea, I'll add it to next week's list. So after I've done that, what I do is I sort of write a little write-up of how my week went. And I try to reflect positively and think about the good things that happened. Maybe I didn't accomplish all the goals I set out for that week, but that's okay. Every week is different. Some weeks are more productive than others. But it definitely helps me be able to break down these big ideas. Like writing a book is huge. So one of my goals was to start looking for publishers, just emailing publishers as a step. Starting to write it, I'm going to start breaking that up into chapters when I get through that. But it's important. It's a really good way to start to accomplish big tasks with little ones. You know, this sounds like the agile approach, right? Which I assume somebody has said that to you at some point. That's the first time anybody's called it agile. And I kind of shudder at that word. Of course. Well, so let me back up and say, you know, the idea of maybe some of the original agile people was to have, you know, a short work period that was, you know, relatively defined that you decide pretty close to that work period, what you're going to do in that work period. You attempt to accomplish everything that you set out to do. And then you have a retrospect, a week in review, in your case, to determine, you know, how did this go? And then you plan the next week after you have that retrospective. So maybe it's not like agile in terms of the heavy agile processes or whatever that you've, that you've. Read about, but at its fundamental level, this idea of, you know, test, repeat, or test, evaluate, repeat is really a powerful idea, I think, at its core. Yeah. I've never thought about that way before, but that is a good point. There's no Kanban, but it does. There are a lot of similarities there. Yeah. So, you know, one, one question I have as a result of that, though, is do you find that you are able to kind of approximate how much you can do better now than you did, you know, before? Uh, 2014? I think it depends on how much time I have. I've gotten a lot better at realizing what tasks I can just sit down and do in a night and what tasks I'm going to put off. So you know yourself better, at least. I think I do know myself better. And I think I've come to terms a lot better about not accomplishing all the tasks that I write for the week. That's, that's okay. They're there. There's more than I can do in a week on purpose because it gives me options. And it's fine. Don't stress out about it. That's sort of something I've learned, um, not to get hung up on trying to just go through my life, checking off boxes. Yeah. Yeah. I think that's, I think that's powerful. Do you intentionally put more on your week list than, than you know you can do? Absolutely. There's never been a week that I've checked off every single thing. And that's because a lot of things are sort of ongoing and rolling. One of the things like I'm doing is I'm doing a lot of things that I'm doing. One of the things I'm doing right now is I, I currently own, you might not need js.com. Kind of like you might not need dayquery.com, but you might not need JavaScript at all. And it's been on my to-do list for like two months now because I just keep putting it off. It's not like high priority. Um, but every week or so I'll be like, add one or two items to this website and I just keep it on my radar that way. So I don't forget about it completely. And that definitely helps with the side projects with getting the side projects done is just keeping it on my radar. Yeah. That's interesting. I, you know, I've been told so many times to, you know, limit my work in progress. If you want to go back to Kanban, I think that, you know, limiting your work in progress is important. Sure. But you also need to have the things that you want to do visible, right? You need to be able to see all of that stuff because if you can't see all that stuff, then it's going to be kind of weighing on your brain and your, you know, I, I practice this regularly. I sit down and I just write out everything. That I can think of that I could possibly want to do in the next like three weeks, three months up to a year, right? The things that, that are way outliers that, you know, I know I'm not going to do them this week at all. There's no way I'm going to even touch it this week, but it's like a, you know, maybe it's something at my house that I need to do. Like maybe it's a project that I've wanted to do for years at my home. Uh, I'll write it down and that gets it out of my mind. It gets it out of that cognitive. Load position and into something tangible that I can look at. Also, one of the reasons why I did this in the format that I did, um, just through text files, um, and using my terminal for the most part is because that's my, that's my radar. That's where I work and where I live for most of the time that I spend my day. Oh my God, that sounds so sad. But especially when it comes to most of these goals, they're mostly code related or work related. Um, so it's really what is. Easiest for you. What's in your peripheral. If writing them down in a notebook is better for you do that. Um, I think there's so much there, there is a lot of psychology behind list making and the benefits of it. So as long as you have some method of writing down your goals, checking them off and holding yourself accountable that you can go back and reference as often as possible. That's key. And you know, this is a good practice for projects too. Like not, not just your personal projects, but you know, at your whatever type of company you are working at, if you're doing a web based project or if you're doing a programming project, uh, write out everything that you can think like this is, this is the traditional kind of brainstorming method, I guess. But right out everything that you could possibly think should be done for that project. Now there's probably some things that you know should be done for that project and you know, use checklists for those, keep those things like repeatable and reference those things in the future. But. There may be some things that are really specific to that project. And when you think about them, don't just make a mental note because mental notes disappear all the time. Like it's really hard to find the mental note. Instead. It feels so good to check things off too. It really does. That's the interesting thing about your approach though, you know, is that you know, you're writing enough stuff on that list that you're not going to be able to check it all off. But I do want to check it off. Like when I was, I've been in a sprint all week at work and um, what you will constantly see on my computer is a sticky note. On the left hand side of my mouse. Um, with a to do list, like a little, just at work to do list. And on Monday I felt so good about this because I had eight items for the morning, like at work and eight items for the evening. Um, but I wanted to do, and I think I crossed off. 12 out of 16 of those items and doing that many. I just, I wanted to dance and take a picture and share on Twitter, but I couldn't cause it was work related. Oh, that's great. This is my. Show. Show. Show. Show. Show. Show. Show. Show. Show. Show. Show. Show. Show. Show. Show. Show. Oh, that's great. This is my sharing of that. Well, now we know. Now we know that you got at least three-fourths of it done. So to take away from that, I think, you know, the important thing is that not everybody is going to do the same stuff, right? Like not everybody has the same methods. Obviously, Yuna's has a particular kind of cadence that she's set up for herself. And, you know, you enjoy this like weekly review. It's not so strict that it's confining and you have a text-based process. There's not like a particular tool. You know, if you're listening to this now and you have trouble feeling bogged down, my first recommendation, I would say Yuna's first recommendation as well coming out of this conversation, is to get that stuff out of your brain to begin with, right? That's, you know, step number one is get it out of your brain. And step number two, create these kind of incremental progress goals. You can't look at that goal. I've read a book, Yuna, and assume that, well, you're going to be able to cross that one off today, right? Like that is a series of small things. That is a series of small things that lead to ultimately accomplishing that goal. Yeah. I would even say step one is think about what you want to learn or what you want to do. Because it could be anything. It could be learn how to sew. I should probably put that on my to-do list. And then step one is look up classes. Step two is send them an email. Just breaking it down as small as possible and then doing them. If you've never done a to-do list, which would be surprising. I assume everybody has done at least one to-do list in their life. But if you've never actually taken the time to, you know, really, truly invest in this kind of process, don't be surprised when things take way longer or perhaps even way shorter than you expect them to. Don't let that break your brain because it's very easy to get thrown off track by, you know, your inability to figure out the amount of time that it should take to estimate that amount of time. We're really bad at estimation, notoriously bad at estimation. And it takes a lot of practice to get better at it. It actually takes a lot of intentional compensation for those issues as well, right? Like if you think it's going to take you five hours, add two hours or whatever, right? Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. thing that many of these researchers have said is get as granular as possible so that there's no question about what a particular task is. Get as granular as you can, practically get. You go through this process similar to what Yuna is going through, where you kind of use the things that you've done in the past to inform the things that you're going to do in the future. Do some kind of review, look at your history and see, you know, if I get five tasks done on average every day, then it would be kind of silly for me to assume that today I'm going to get 10 done, right? Because historically that hasn't been true. It doesn't matter how much coffee I drink, I'm probably not going to make that much of a productivity jump in one day. Well, it also depends on what kind of day you have. Because for instance, work days, I won't check off as many things as maybe if I set out like on Saturday of this week, I'm going to spend five hours in the coffee shop. Those five hours are going to be way more productive. Just a random weeknight. Oh, yeah. Yeah. Well, this is really interesting information and the kind of stuff that I could just talk about this stuff all the time. I love the soft skills side of development. And I really appreciate you sharing that with the listeners. No, I appreciate you asking about it. It's something that I don't think people talk about enough because people are always talking about how do I improve my coding skills when if you improve your ability to learn, that is going to make you a multiplier when you're trying to improve those coding skills. And that's something that we've talked about on developer team many, many times. The importance of the skill of learning, the kind of the meta learning, right? Learning how to learn. Yes. Incredibly important. It's something that I wish that I did more when I was in school, because I feel like I learned how to learn when it became something I wasn't doing for somebody else. Yeah. Yeah. I agree with that. I did well in school. But I did it because I could understand the system, right? My engineering kind of brain took over and it figured out the different variables to manipulate to get the right grade. Yeah. The only reason I did well in school is because I somehow happened to find this mix of design and development. And I really loved it. So I just got really lucky in being able to find a field that I loved and take classes in that. Yeah. Which didn't even exist 10 years ago. Yeah. I'm going to be honest. Yeah, that's true. This field is brand new, especially if you're in the web. Now, software development is slightly older than the average kind of web development career would be. But it's all the same, right? We are software developers. It is weird to think about it that way as a web developer. I definitely have a lot of imposter syndrome kind of baked into my bones about that still. I don't feel like a software engineer as much as I feel like a web designer sometimes. Yeah. I mean, we could probably get into this for a long time, but those lines are also constantly blurring as web apps become more and more prevalent. Today's episode is sponsored by DigitalOcean, the fastest growing cloud infrastructure provider. They are laser focused on their mission to provide simple and elegant solutions for developers and teams. You know, I talk to a lot of people in the spec Slack community and specifically in the developer T channel on the spec Slack community, which, by the way, you can join at spec.fm slash Slack. And we've recently had a lot of people asking questions about DigitalOcean. And what's really awesome is we have some people from DigitalOcean in the spec Slack community. It's really cool because we can talk to them directly about their products. The DigitalOcean products are easy to deploy. You can spin up a droplet that's pre-configured with your popular open source platforms like Node.js or Magento or Docker. You can scale your application using the DigitalOcean API. They have floating IPs. And as you grow, you can manage your apps with team accounts. So if your team scales up, then your team can all log into the same account. Of course, all of these nodes are reliable and available. You can select from data center regions around the world based on the latency or deploy across regions for redundancy. And of course, DigitalOcean has straightforward pricing. So you only pay for the resources that you actually use by the hour. There's no setup fee, no minimum spend. I think we talked about it the other day. It was like 16 cents to try it out for one day. But if you use the promo code developer T, you can get one month for free on a one gigabyte droplet. That's a whole month for free on a gigabyte worth of RAM, a cloud SSD server, which is an incredible deal. So go to the show notes at spec.fm to find that code. And when you check out, use the code developer T. Thanks so much to DigitalOcean for being a sponsor of developer T. Speaking of web apps, you are learning a lot more advanced JavaScript this year. That was one of my big goals for the year. I am trying to learn by doing. So one of the things that I've been working at is building this React app that I've had in my head for a long time. Building it in React for a few reasons. One of the big reasons. Being that I want to kind of explore just what all the fuss is about. So that doesn't make sense. But there is a lot of sort of like screen changes that React really helps with with the virtual DOM. So I have a reason for it. But one of the big reasons is that I just want to learn it. And it's a side project. So who cares? It's my choice. Yeah. Do what you want to do if it's a side project. I mean, by all means. Yeah. It's been really fascinating because when I first started working and learning it, I thought, oh, everyone really understands it well and everyone's so good at it. And then I started tweeting out about how there aren't very many good beginner resources. And so many people agreed with me and people that have been building React and Redux kind of like trying to get that viewpoint and understand it. It's been really cool to see that a lot of people are there with you. You're not alone in this. It might seem like everyone is so much more advanced than you. But it's because you're so good at it. You see their final product. You don't see the struggle and what they're going through. Yeah. You don't see them struggling to get the right NPM stuff installed. Oh, my gosh. Like dependencies, peer dependencies are never in sync. And then Babel 6 breaks everything from Babel 5. And these are things that I thought was my fault and my problem. But it turns out that a lot of people are sharing these frustrations. So it's been good. The tools are definitely... In flux. No pun intended. Yeah. I mean, you have so many tools to learn. I mean, if you sit down as a web developer, especially a front-end web developer, but also, I mean, really any software developer, write out the number of tools that you use and your mind will be absolutely blown. The number of languages that you use, the number of plugins, the specific things that you use for your work. All of your environment setup. All of that stuff goes into this craft. And you're kind of balancing it as a marionette in many ways. You're like orchestrating all of these tools together. And it's not easy. Like we can all have this kind of support group moment here. This isn't an easy thing to accomplish, to learn these things and then to wield them in such a way that you create a compelling and useful environment. Usable and highly performant and error-free thing. Like that is, in many ways, it's like a miracle that that comes out on the other end. You know, I do want to shout out to Rebecca Murphy for a lot of this sort of... I'm not going to say courage to speak out about not knowing what I'm doing, but just the push to do that. Because I turn to her for a lot of JavaScript advice, since that's not the world that I run in. Right. It's not the circles that I have a lot of experience in. She just sort of lets me know that a lot of people will get value out of sharing this experience of learning with somebody else. And to not be afraid of that, to not try to pretend like you know what you're talking about when you don't. Yeah. Because there is so much value in having that viewpoint of a beginner that people who have been working at it are missing. Because they don't remember that it's not a common term or a common concept to understand flux architecture. So I'm just trying to be as open and honest about it as I can. Well, I mean, another common example is how little I know about Bash. I'm just really not good at Bash. And so I'm constantly copying and pasting little snippets of code to do the simplest stuff with Bash, like iterate over a folder of files. And rename them. Like, I have to go to Google to figure that stuff out still. And I realize that there are other ways of doing that. But, you know, I just haven't had a good, you know, a good amount of time and the demand to learn that. Yeah, the demand is a big part of it. It's not present enough. It's the peripheral thing. You have to make it a part of your peripheral if it's important to you. I mean, I commit my code many, many, many times a day. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. I need to learn that. Right. But I, like, I'm not writing Bash scripts every five minutes. Yeah. It's not a common thing for me. I mean, I wrote aliases for the terminals and for a few other things. And I just have to reference the internet. It's fine. I think everyone does. Oh, definitely. I mean, I reference it for so many things. Even the most common things that you can imagine, every once in a while my brain just gives up. And it's like, nope, just go to the internet. and remind yourself. That can be a healthy thing sometimes because it keeps the perspective that, hey, this is not about memorization and you're not gonna be quizzed on this, right? Sometimes it's also unhealthy that I reach for the internet so quickly because at some point, that becomes a little bit of a hurdle, right? It becomes a little bit of a productivity negative. You know, the thing is, everybody does this to some extent at some level, right? Like about something, you're still Googling. And so if you're still like learning about these things, at some level, we should all come together and say, hey, look, you don't have to remember every single command. You don't have to remember how to write an alias because you aren't doing that, but like four times and then you've written all the aliases that you need. It's not- And then you can reference your aliases that you just wrote. Yeah, I mean, just copy paste, you're good. It's an amazing thing that we expect more out of ourselves than what is really feasible. I like to set high expectations. You know, I hope that I am not always Googling how to iterate over files in a folder, right? Hopefully at some point, I will start Googling more sophisticated things. You'll learn what's useful to you when it is useful to you, so. And that's what it comes down to. And I think, you know, if you're listening to this and you feel like you have not been able to catch on, again, you're not alone in that. Everyone has some level of abstraction away from the things that they would like to know. Well, this has been a fantastic discussion. You know, I really appreciate your time tonight. Thank you for having me on the show. I feel like it was really cool to go from talking about these abstract concepts and technology to really technical, specific things like CSS. And JavaScript. It's been a fun conversation. Yeah, I've enjoyed it very much so. Oh, by the way, if you are listening to the show and you don't know much about Rebecca Murphy, of course, we'll include links in the show notes to her site and other things related to Rebecca. But there was an interview that I did with Rebecca as well on Developer Tea, so I will include a link to that. She talked about a chicken coop on that episode. She talked about a chicken coop that she was... She was making smart with JavaScript. It was a really fun interview that I did with Rebecca. Yeah, I have had eggs from her, so I can attest. Wow, it's a real thing. They are great. She's succeeded in her chicken coop creation. She has chickens, yep. Wow, that's impressive. Well, you know, I have two questions that I like to ask all of the guests that I remember to ask them. The first one is, if there's one thing that you could tell all developers from whatever background, whatever experience level, if you had 30 seconds to talk to them, what would you tell them? I would just say, keep working at it. If you think you know what you're doing, you don't know what you're doing yet. So when you reach that point of yelling in your head, oh my gosh, there's so much more out there that I don't know, that's when you know you are in the right place. Welcome, welcome to the chaos. The Dunning-Kruger effect, right? Yeah. And I agree with that wholeheartedly. And you did that in less than 30 seconds. So there you go. It was a challenge. Challenge accepted. Efficiency. Damn, mic drop. The second question is the harder of the two, I think. What is one thing that you wish more people would ask you about? Oh gosh, that is a good question. What do I want people to know about me? Oh man, I don't even know how to answer this question. Because I feel like I'm just so transparent about a lot of things. I think I just want people to ask me questions that I don't get to talk about on a daily basis. I really like theorizing with people and just talking about sort of the future and state of tech. We got a little bit into that. That was fun. Those are really fun conversations to have. I don't know. Don't ask me about movies. I don't watch movies. I feel like I talk a lot about CSS. Sometimes JavaScript stuff. I'm not answering this question very well. No, it's fine. It is a difficult question and it really reveals a lot about the way that we think. Because I think it's important for us all to be thinking about that. You actually said a really good thing that reveals what I think is the best answer for you to this question, which is you're already pretty transparent about stuff. And you value that. It's an interesting question that definitely transcends tech and definitely transcends work. What do you want people to talk to you about and ask you about? I've never thought about what I would want to have a conversation about. I guess I always like talking about travel. That's a fun topic. Travel is great. Yeah, I agree. I agree with that. I'll always talk to you about travel. Suggestions, tips, tricks. Tell me where I should go. Are you responsible for any of the things on your blog? Are you responsible for any of the things on your blog? Are you on the stuff in Austin site, I believe it is? I'm in the big Slack chat, but I haven't made a thing on it. I'm a member of the community in support of the community that I'm always traveling away from. Love you all. And you're going to Brooklyn JS this week, correct? Yeah, so I happen to be in New York, which has made this interview really fun in a way that... We keep breaking up the audio with each other. But yeah, I'm sitting in a hotel room. I'm here for an IBM event. So since I'm in town, I'm going to do some of the programming tomorrow and just work with the JavaScripters of Brooklyn. I'm excited to hang out with them. It's really cool that you can just go to any city and find a web event and meet new people. I'm excited for that. Well, Yuna, thank you so much for coming on the show. And thank you for opening up and talking about all of these... all of these things that you're involved with. If people want to find you online, what's the best way that they can do that? Twitter, I think, is the best way. You can find my blog from there. So my Twitter handle is Yuna, just U-N-A. So twitter.com slash Yuna. My blog is Yuna.im, so U-N-A dot I-M. And all of the links are there. I'm Yuna on GitHub. Just search Yuna Kravitz or just Yuna. It's weird. I'm on Google search results on the first page for my first name. Learned that recently. That was creepy. Wow, that's great. But yeah. Well, of course, all of those links will be in the show notes as well. And we'll include all the links to the specific things that we talked about in today's episode. And I really hope that you all will go and visit Yuna's site and look through all of the amazing stuff that she is putting out. Thank you so much again, Yuna. Thank you. Thanks so much for listening to Developer Tea today. And thank you to... Thank you, Yuna, for joining me on the show for this two-part interview. If you missed the first part, make sure you check the show notes. Of course, all of the links from today's episode will be found in the show notes at spec.fm as well. Thank you so much for listening to the show. If you are enjoying Developer Tea, make sure you subscribe and also go to iTunes and give us a rating. This is the best way that you can help Developer Tea grow and reach new developers just like you who would love to listen to the show. Thank you. Thank you so much for listening. And until next time, enjoy your tea.