Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell. Today I'm going to be answering a fantastic question from listener Janus. He is asking about becoming a better programmer. He has a background in design and I think that is highly applicable to a large number of people who listen to this show. I'm really excited about this question because it's actually going to open up quite a few topics that we're going to talk about in the future on Developer Tea. Make sure you subscribe to Developer Tea. If you don't want to miss out on those episodes, you can subscribe in pretty much any podcasting app that you have. Of course at developertea.com there's an RSS feed over there. You can also find Developer Teaon spec that's spec.fm. Spec is a network that I teamed up with the guys from design details to create. It's a really cool thing. Make sure you keep your eye out over there. If you are a designer by the way, you should go and check out design details. You can find that of course at spec.fm or at designdetails.fm. So let's jump into Janus' question. I've been working on creating websites for more than 10 years. I started out mostly as a designer with enough knowledge to manage the content on the site I was designing and building with Dreamweaver. And that tells you how long ago 10 years was in the web design world, doesn't it? However, he says times have changed. Now I'm probably mostly a front-end developer. I love taming HTML and CSS while trying to build semantic and responsive websites. But I find myself in a situation where it seems that I need to know programming better. And it's just really difficult for me. I've looked into Ruby on Rails, Meteor, Polymer and Node, and I find it all very interesting. So I'm not being forced into learning more about programming. But as soon as it goes beyond simple JavaScript, I'm quite lost. Whenever I read Ruby that's supposedly beautiful or code that's obviously bad, I just don't get it. I'm pretty sure that I can never become a great programmer, but I definitely can get better. I just don't know if it's going to take too much effort. If I'm more naturally talented at UX and design, should I let others do the heavy lifting? How do you figure something like that out? Y'all news? The answer just isn't that simple, is it? You kind of have to make a decision based on what you want to spend your time doing, and what kind of work you want to end up doing. Obviously, if you truly enjoy UX and if you truly enjoy design, then put all of your effort into those, and that is a highly rewarding career, most definitely. But I don't think you'd be asking this question if you weren't interested in programming. So I'm going to approach this as if you are interested in programming and you want to get past this block, this place where you feel like you can't progress any further. So I want to dive into how you might evaluate this situation. I'm going to go back and read different parts of your message, Y'all news, and address each of these things head on. So you said that you find yourself in the situation where you need to know programming better. And that you feel like it's a little bit difficult for you. You've tried all these different frameworks and that you're still interested. You're not being forced into this. But as soon as it goes beyond what you call simple JavaScript, you feel like you're lost. And then whenever you read Ruby that's supposed to be beautiful or code that's obviously bad, you just don't get it. And then the next thing you say is that you think that you can't become a great programmer, but you can definitely get better. Now first of all, I think you can become a great programmer. Call me an optimist, but I think the opportunity for becoming a great programmer is available to just about anybody who tries hard enough. I believe in that hard work ethic and that is such a big part of learning to be a great programmer. Now, I don't think that everyone is going to become great. I think that's unrealistic. But I certainly think that the opportunity is there, you know, for you to become great. Now with that said, programming isn't easy. Certainly there are some concepts in programming that may be considered easy, but there are people who spend their entire lives on very small sub topics inside of the overall topic of programming. It takes significant effort and energy to get to the place where any of these technologies you mentioned, Ruby on Rails, Node, whatever, becomes fluid in second nature where you feel like a master of a given technology. So you mentioned something here that I'd like to kind of dissect for a second a bit further. You said that as soon as it goes beyond simple JavaScript, you're quite lost. Whenever you read Ruby, that's supposed to be beautiful or code that's obviously bad. You just don't understand that. And this is a really common situation for many developers actually. We hear that one framework or another is really awful or hacky. Early on in my career, we made it a habit of making fun of Internet Explorer, for example. Even though a lot of us didn't even know the problems that Internet Explorer actually has, we just heard somebody else say that Internet Explorer was bad. So we just kind of hopped onto that train. We all adopted each other's opinions and perspectives. And so I think that this is a large portion of what programmers think about different languages or different frameworks is that they're really awful or hacky based on what another programmer has said or what they read in a blog. Now a lot of programmers just don't actually have the context to know why that's the case. It actually makes the code great, what actually makes the code terrible, what makes a piece of Ruby beautiful and what makes people cringe when they see Pearl. Even though Ruby actually has a lot to do with Pearl, there's a lot of Pearl in Ruby's development history. Sorry to any Pearl developers out there who actually still love the language, but the truth is a bit of this is subjective too, right? Because somebody may still love writing Pearl. And there's nothing particularly wrong with that. So I want to break this down a little bit further because I think it's important for us to understand the different aspects of code quality, both the subjective ones and the objective ones. There's still a lot of debate about frameworks and about languages. So there's definitely still some subjectivity. There's not a perfect system for what makes code good and beautiful and what makes code bad and ugly. But I am going to kind of help define some of these ideas for you, Yannis. And I'm going to go deeper into these in future episodes. So if you're listening to this and these sound interesting to you, make sure you subscribe to Developer Tea. You'll hear more about these in the future. But number one, so it's going to be like a comparison thing here. Number one, in beautiful code, the intention of the programmer is explicitly apparent to the reader. In bad code, the intention is implied and difficult to determine. The idea here is that you can read the code and understand what the programmer was intending to do in good code. Down in bad code, you have to actually maybe talk to that programmer to figure out what they were trying to do. Number two, good code works. Bad code is broken. This is perhaps the most important one, obviously. Good code works and bad code is broken. It doesn't matter how beautiful the code looks, how aesthetically pleasing it is or how easy it is to write. If it's broken, then it's pretty much useless. Steve McConnell, the guy who wrote code complete, he has a quote that says, a brute-force solution that works is better than an elegant solution that doesn't work. So definitely one of the most important pieces for code to be good is that it works. As an addition to this point, it's important to note that good code, also works well. This means that there is a minimum amount of efficiency that your code should have in order to be considered good code. This is where we start talking about different languages that are faster or slower. And the truth of the matter is, a particular language may be good for one scenario and quite bad for another scenario based on the performance characteristics of that particular language. There's definitely trade-offs here that's kind of an economy. If you were to learn assembly, for example, it's going to be much faster because you're writing directly to memory. Whereas if you're learning Ruby, you can get things done more quickly because you aren't having to write directly to memory. Ruby is an abstraction far away from assembly code. So it's important to keep in mind that any abstraction at all is going to be a trade-off of performance. So going on to number three, good code handles unexpected situations well. Bad code may fail without warning or explanation. This is handling errors that occur that you might not have expected. For example, if someone visits a page on your site that doesn't exist, does your code handle that? Does your server handle that? What do you show to the given user? That is a particular part of code quality that is important to consider. It overlaps, Janus, with your experience, with user experience and design. So certainly those things are they go hand in hand, user experience and good code go hand in hand. But it's not just about handling errors when you're showing them to the user. It's also about handling errors internally and doing something to respond to that error properly. Number four, good code is easy to change in the future, whereas bad code is difficult to change in the future. Now, there's a lot that goes into this as well. It's definitely quite a few books on this subject. So I'm not going to go into deep detail, but making code flexible and easy to change, easy to extend, easy to reuse. All of these things go into this category of changing in the future, making good code means making code that is easily changed in the future. I'm going to take a quick sponsor break, and then I'm going to come back with a few more comparisons about what good code is versus what bad code is. And then I'm going to finish out the episode by continuing to answer Janus' question about how to determine if he should let someone else do what he calls the heavy lifting. We'll be right back after this quick sponsor break. I'm excited to tell you guys about today's sponsor because I think it is a huge opportunity for so many people, and it's something that everyone needs. And that is a job hired.com will help you find a job, and it's totally free to use. Now, on hired software engineers and designers can get five or more job offers in a given week. These offers have salary and equity in them up front, and there's offers in both full time and contract opportunities. So users can view the offers from over 2,500 companies of all sizes, startups and public companies, etc. Users can also accept or reject offers before talking to any company. So there's never an obligation, and it's totally free, like I said before. So normally, if you get a job through hire, they'll give you a $2,000 thank you bonus. That's just if you go to hired.com. But if you go to hired.com slash Developer Tea, you can double that bonus to $4,000. That special link will be in the show notes as well. So go to hired.com slash Developer Tea, and if you get a job after visiting that link, you can get a $4,000 bonus. Now, if you're not looking for a job, but you know someone who is, you can refer them to hired, and you will get a $1,337 bonus if they accept a job. So again, it's a huge win, and there's no reason why you shouldn't be using hired. If you or a friend are looking for a job, hire.com slash Developer Tea. So I've been answering listener Yanouse's question about whether or not he should continue trying to learn programming in a deeper way than he currently knows, or if he should let other people handle that and just focus on being a designer and a user experience engineer. So I'm going to continue giving you the comparisons between good code and bad code. I've got four more, and then I'm going to close out the episode with a few more thoughts directly for Yanouse and making a decision between these two career paths. So number five in our comparisons here, number five is good code holds truth in one place. So it can be updated in that one place. Now bad code requires that truth is held either in the programmer's brain or in multiple places. Think about that for a second, basically what this means is that your code should never have a duplicated information that represents a single idea. For example, imagine a page of products, an index page of products where you have, I don't know, five or ten different things, and then you go to the single page for that product. If you had the pricing information for that product held on both the index page and on the single page for that given product, then whenever the price changes, you have to change that into places. Good code avoids this situation altogether by having a separate source of truth, a single source of truth, where the price is held for that given item. So you change it at that source and it propagates to all the locations where the items price is presented. A lot of the time this is handled by a database, but sometimes configuration options, arguments that you pass into a given function or method, these are things that can be duplicated in multiple places, which makes the code harder to maintain. So good code holds all of that truth, all of those things that are static in a single place. Number six, good code is compact enough that powerful operations can happen with fewer keystrokes for the programmer, but it's also verbose enough that there's little ambiguity as to what that code does. Conversely, bag code is too verbose to be comprehended and too clever to be clear. All this means is that you've chosen to write your code in such a way that is easy to understand, but you're also taking advantage of language features or framework features that allow you to be concise when necessary. Number seven, good code respects the systems and the conventions that it operates in, while bag code feels out of place and requires that the system conforms around it. Good code, for example, for somebody who's coming in and working as a freelancer on a given project that has already started, good code would follow the structure in the syntax that is already present in the code that exists for that project beforehand. Now, bag code would come in and try to introduce something entirely new that affects the rest of the system and causes the rest of the system to need to adapt to the new code. Again, there are books on this subject of dealing with legacy systems and working within other systems, writing code that follows conventions for a given language. So those are the types of resources that you would want to read. The next one is number eight. Good code is well documented, and that means at a minimum, there are comments in that code. And bag code has a little or out of date documentation. Now, this is very simple. If you or another programmer revisits the code that you wrote today in three months or six months or a year from today, would you be able to understand it and would you be able to read a summary document or some kind of comments in the code that describe what that code does? This is the essence of what documentation is. You could consider it something sort of like cliff notes for your project. You don't have to read every line of code to understand what that project does. You don't have to read every line of code to be able to work on that project. There's a bonus item at the end of this list that I feel very strongly about. I left it to the end because I feel so strongly about it. And that is good code is tested while bag code is not tested. Good code is tested. And that typically means that you write programmatic tests for your code. You can go back and listen to my interview with Russ Taylor. Russ works at Etsy where he does a lot of work with integration and tests for the Etsy platform. So go and check out that interview to learn a little bit more about testing, about the difficult parts and the fun parts. There's a lot of information available about testing and why testing is so important. But at the very minimum, you should at least be testing that all parts of your code work, even if you test it by hand. So that wraps up the items that I want to cover in today's episode. Of course, like I said, there's going to be future episodes diving a bit deeper into these subjects. But I wanted to give you that framework, you know, so that you know how to think about code when you approach it. And also to say that a lot of us don't know how to think about code, about quality of code. There are so many people who just jump on bam wagons. And a lot of the time, we just listen to people that we know have taken the time to evaluate these things. Now, you definitely should listen to the experts when you, when you possibly can. The people who are taking the time to evaluate these frameworks and languages line by line, there are people out there that you can take their word for it and definitely worth listening to experts and people who are ahead of you who you might consider them mentors, even if you don't have a personal relationship with them, you can read and follow the things that they say and gain a lot of insight without having to go and actually evaluate those things for yourself. But this gives you a framework for evaluating code and whether or not that code is good. And it also gives you a framework for writing your own code. You can start thinking, is this code going to be easy to change in the future? Am I duplicating content? Am I making truth exist in multiple places? Am I handling unexpected situations well in this code? All of these things that kind of add up to quote, good code. So the final question that Yanus asked is whether or not it is worth it. Is it worth it to learn this code if you feel like you are more talented naturally with user experience? And I would say personally that it is. I do think that it is worth it. And the reason I think it's worth it is because you are interested enough Yanus to send me this email. You're interested in code enough that you have the motivation to learn. You have the motivation to become better at what you do. And code is empowering. Learning how to do this stuff. Learning how to be a programmer is empowering. I would also encourage you to not get frustrated because it takes a long time to become a master. For some people, it takes years on years. So is it going to be easy? Absolutely not. But if you actually are dedicated to becoming a better programmer, being a programmer is incredibly powerful and empowering. Is it easy? No. But is it worth it? I think it is. Thank you so much, Yanus, for your question. If you all have questions, other people who are listening to this show, please send them in. You can always send them directly to me at developerateatgmail.com. There's a contact form on developerateatgmail.com. That's also where you will find the show notes for today's episode. Thank you so much for listening to today's episode of developerate. I appreciate each and every moment that you spend listening to this podcast. Of course, if you want to automatically receive updates about developerate, you can always just subscribe to the show in whatever podcasting application you use. That way you automatically get the show three times a week. Thanks again to today's sponsor, hire.com. If you are a software engineer or a designer where you know someone who is and you or they are looking for a job, hire to such an awesome option for the job search because they bring together all of these offers from 2500 different companies in 12 major tech hub cities. You can go through those offers and decide which ones you like and accept or deny them without ever even talking to the company. There's salary and equity and there's full time and contract opportunities. The best part is that it's free and you get a signing bonus if you accept a job of $2,000. If you use the special code again in the show notes, it will be hire.com slash developerate. If you use that special code, that $2,000 signing bonus goes to $4,000. Go check it out hire.com slash developerate. Thank you again for listening to today's episode and until next time, enjoy your tea.