Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be answering a few questions from people in the community who have emailed me. It's been really cool to see you guys talking to me on Twitter and also through Developer Tea and Gmail.com. One day I might actually get a real person's email address at developertea.com but for now I'm just really enjoying using Gmail so I'm going to keep on doing it until somebody complains that I'm not professional enough or something. Speaking of professional, this episode is going to be a little more laid back. My wife is in the room with me Lauren say hi. So I'm just kind of hanging out reading these emails that you guys have sent me. The first one actually is a couple of emails long. It's from a guy named Brett and I'm not going to say anybody's last name for the sake of anonymity but his name is Brett. He said the first thing that he emailed me was that he's a sophomore and he's studying computer science and basically he's wanting to know how to become more than just an intermediate developer. So he wants to become an advanced developer. So I actually responded to Brett in the email. I'm going to share with you all what I said to him. Becoming an advanced developer, it's kind of hard to know what that even means because you have to decide what advanced developer actually is. So what I decided was that advanced developer actually kind of assumes two things. One is that you have a certain level of intuition as a developer and the second is that you have a certain level of quality to your code. So to understand both of these things, I gave Brett some advice. I said study the work of other programmers, number one. Old young doesn't matter. Just study what they did and why they did it. Study why some people broke the mold. Study why developers of new languages, why they decided to develop those new languages. This will help you understand the way that they think, right? These advanced Developer That you are aspiring to be like. It will, if you study the work that they've done, it will help you understand the way that they think, the way they respond to a given circumstance. The second thing is to begin studying, study, begin to study programming paradigms as a subject. So learn the language agnostic patterns that can be used in a classifiable problem situation. Most likely Brett is probably going to learn about some of these things in his CES program. But a lot of you may not know this. You may not even have ever heard of programming paradigms. There's a ton of free material out there. There's some on iTunes University. I think there's like a Stanford course on it. But basically, there's just a number of these different programming paradigms essentially just ways of looking at problems through the lens of a particular way of solving those problems. So there's the functional paradigm, there's the object-oriented paradigm, and then there's a myriad of sub-paradigms, like ways of doing functional programming. So the third piece of advice that I gave Brett was just to build a lot of stuff. So this is probably the most important one. That is just get into the code, start actually building things that you want to build. Brett responded, and his response, I think, is probably equivalent to what a lot of you are in the situation of. That is that you just don't know what to build, right? You've decided that you want to become an advanced developer, but now what? You've gotten a couple of books. You've started reading about what these other programmers have done, and maybe you've read all of Paul Graham's essays about Lisp. Who knows where you are in that journey, but you don't know what to build. Brett asked me what I built, and I can't tell you much more than what my personal experience is, because I think everybody has a different approach to this. For instance, Steve Jobs, he built something just for the sake of money in the very beginning. There's just a myriad of things that you might would build for your first project. I personally had started to take up the hobby of photography, and even previous to that, I was a musician, and I wanted to share the music that I was creating, and I wanted to share the photos that I was creating in a way that the world could see them in some sort of portfolio online. That's actually why I started learning about building things for the web. As it turns out, I got really interested in design, and so I learned enough jQuery to be able to move my site around and do some animation, and then I got really interested in jQuery. I got an internship, and from there, I just started building things because I was assigned them to build. I started building a lot of front-end type things, and then I got interested in some Python, and the Django framework, and then I moved past that. I went on into a lot of WordPress-based development because I started actually getting paid to do development, and I did it with an agency, and now that agency eventually became whiteboard. That's kind of the long history of my development background. Who knows where you're coming from and where you're going, but what I would say is start with something that you really actually want to build. Don't try to come up with something that is going to, you know, don't try to make a bunch of money right out of the gate. Chances are the very first thing that you build won't make you a ton of money. It's unfortunate that that's the case, but that is the case. The first thing that you build probably isn't going to make you a bunch of money, but the knowledge that you gain in that first thing is going to provide you with long-term positive return. Don't write it off just because you aren't immediately making money with it. Go ahead and continue to learn by developing things that you actually really want to exist in the world. All right. Hopefully, that has helped Brett. I know that answer was kind of, unfortunately, a dead end road. But I think that, you know, when you find something that you want to develop, you start actually choosing, you start actually developing things in your free time and you actually want to solve the problem. Rather than saying, well, what is the fastest way for me to solve this problem, you start actually wanting to solve the problem so you don't really care so much about the efficiency of solving the problem. You just actually want to do it. Having that desire, that drive is essential to the learning process. All right. Daniel writes, and it says, writing tests are boring. Writing it to the end means it wouldn't get done and doing it at the very beginning can kill the joy of writing the code or the project. When should you write tests and how do you motivate yourself to write them? That's a good question, Daniel. You know, it kind of depends on what you're motivated by, right? I actually have a good friend and coworker who is actually motivated by seeing the green dots show up for passing tests in his terminal. So for him, writing tests is the thing that he's excited about. And he writes the code for the project along with the test, but he really does start test-driven development. I'll tell you the honest truth. I've had a very difficult time doing test first test-driven development. It's not very easy to do if you started out not writing tests. If you started out, for instance, maybe with WordPress, and then eventually you found out about test-driven development and everybody told you that you should be writing tests first, and it's a little bit difficult to do because you're used to seeing the product of your work quicker. I will say that the answer to this is on a personal basis, but I will encourage you to write tests earlier rather than later. Some wise recently said that where you begin is actually the UI. So go ahead, create the design if you are a designer or go ahead and start creating some of the wireframe of the interactions on the front end and then go back and then you can start to create the code to integrate that front end into the back end processes. So unless you're doing really heavy back end work that doesn't really have a UI, I think that's a pretty good way of approaching this problem because you immediately start seeing the outcome of the work that you're doing. Another potential solution to this problem is to actually change the way that you think about what is joyful. I know that sounds kind of disconnected from reality, but if you actually get a little bit of joy out of writing tests, maybe it's a toolset problem, maybe you need to find a testing framework that you actually enjoy writing tests and find a way that writing tests doesn't kill the joy of writing the code. And if you can shift your mindset into believing and feeling like tests are actually a enjoyable part of the project process, I think that that is another good solution to this particular problem. That's all the questions we have time for today, but before we go, I wanted to let you know about a brand new way that you can support this show. If you go to developertea.com, front slash donate, you'll find a picture of my lovely wife and I, but you'll also see a way that you can support this show by simply donating a monthly 99 cents or 399. It's about the cost of a cup of tea or a box of tea, but it helps us tremendously to be able to keep this show going. As always, you can connect with me on Twitter at Developer Tea or you can email me your questions at Developer Tea at gmail.com and of course you can find the show at developertea.com where there's also a contact link in the header. And until next time, as always, enjoy your tea.