 I'm presenting to you today from the comfort of my home in rural Alberta Canada where yet another winter storm seems to be rolling in. Today I'm going to chat to you about what it is to be a moderate programmer. Why becoming one will make you a better programmer and maybe more importantly a better teammate. First a little bit about me. I'm the front end lead at inclusive where we do public relations analytics for large brands such as Lyft, Airbnb, etc. I've been using Ember for over six plus years since pre 1.0, since pre Ember CLI, and still using it for work and for pleasure today. This is my fourth time at Ember conference and my first time speaking at it. My first time attending virtually as well as it is for all of you too. So first off what do I mean by moderate? I mean avoiding extremes of behaviour. I'm just going to tell you a little story about why this matters to me. I've been a programmer now professionally for over 20 years and I've been through a lot of changes in the field especially front end programming. And I've done almost every single one of the things I'm telling you to avoid today. And I think it's really important to share this story because especially junior developers and other developers who are coming up, you're likely to make a lot of these. And I'm hoping that that I can shed some light on my path to what I hope anyway is becoming a better programmer. First off this is not moderate. I do not recommend jumping into your tub. So I don't know if it's in our DNA or if it's in our culture, but extreme behaviours seem to be endemic around programmers. And we have to work harder than others at actually curbing that behaviour. It's so much in our culture, we even have extreme programming as a programming paradigm that's been used by a lot of people over the years. So yeah, like I said, we have to work a little harder at curbing those behaviours. So this quote moderation and all things including moderation for everything I'm going to tell you today, there's of course reasons to ignore my advice. And sometimes we do have to go all in on something and do an extreme behaviour depending on the thing. However, I do think that we should be fighting for the middle ground, not only in programming, but really in life itself. So this quote was brought to you by my mother. Well, actually it was Oscar Wilde or before that apparently this quote can be attributed to Socrates. So the idea of moderation in society and as human has been around for as long as we've had society. So first item is the moderate programmer names things appropriately, but with enough detail. So let's dive into some examples of that. Here at the top we have a not specifically enough named array. So we have an array of items that contains a name of Canada, which I guess is a country, although it just says name, so I'm not sure. Code is, yeah, well, what kind of code? Well, let's go into a two specifically named example. Now we have country ISO code objects, which is better, but that's pretty long. And oh, look, we're repeating country ISO twice. So that's a lot to read a lot to look at that's going to make it more difficult for someone looking at it after. In the moderate way on the bottom, we have all countries name is Canada, and the ISO code is CA. So now we have a little bit more information about that that's going to be easier for someone to read. Let's go through some rules about naming things. You should name things three words or less, whether that's a variable or a function or a class, any more than that is probably two verbose. We should avoid jargon and metaphors. Try not using the words factory or object or class. All of those things are repetitive and do cause problems in the code. You should also use plurals where appropriate. This would be in the case of arrays or collections or maps. It signals to your teammates or for you looking at your code in the future that this in fact is multiple items makes it easier to understand. Also for Boolean's prefix with is has can. Again, this is another trigger when we're looking at it at the code later. It's much more clear that this is in fact a Boolean if it has those words in front of it. For functions use a verb the noun like get users find admin things like that. Number two, the moderate programmer writes small functions but not too many. So again, here's another example. This function is doing far too much. We got set country for user and we're passing in an ISO code and a save user, which I think is a flag. It's a little bit hard to understand though, not that this function has too many lines. It's only about 10. But that's is doing conceptually too many things. So let's break it up. Oh, we've broken out far too much. Look at this. We got now four functions where we have one before. So now we got to get user get ISO code, save user get country. And then the main functions start save user. Well, this isn't quite right. It's going to be really difficult to because every time we get to a console user equals this user. Okay, what does this get user get? So now we jump up have to look at it just becomes a lot more difficult to understand. Here's a nice moderate example of writing small functions. We have now two functions, both do one thing conceptually. The first one gets the country code or gets the country name from the ISO code. The second saves the user we check if the user is valid. We see if we get the country set it to the user save the user and set a user flag. So much more easy to understand this code than the last two examples. So again, some rules, a function should conceptually do one thing. Be aware of how many flags you have in arguments. Any flags, even one is probably a sign that your function is doing too many things. And you may want to reconsider that. Be aware of how many arguments you're passing to a function. Again, too many arguments, I'd say even more than three. And that's probably again, a good indicator that it likely should be refactored. Components are functions to and this is really important. So everything I said here also applies to your component creation. Because conceptually, components are functions as well. So your component should do one thing. You should be aware of how many flags you're passing to your component, as well as how many arguments or in the case of components properties, you're passing to it. So the number three, the moderate programmer writes tests, but only enough. So you've probably seen this before, eat food, not too much, mostly plants. This is a nice moderate take on eating by Michael Poland. And in programming, we have this. So Guillermo wrote this a while ago, write tests not too many, mostly integration. Now, if you take the idea that writing tests is like a nutritional balance for your program, they have some similar parallels. So writing tests, because if we don't write tests, we're starving our program, not too many, because too many and our program is going to become bloated. And we mostly want to do integration. Now, why do we want to mostly do integration? Because integration gives you the best balance of knowing enough about the program to find regressions and not enough that it's going to become tripped up over changes that aren't important, that don't need to be caught, integration test. So again, some rules, write your tests and write them immediately, or you probably won't write them. So I'm not saying that you need to do test driven development. I'm saying that you should make sure that you have tests in your own PR right away. Embraer integration tests are your best bet. Again, they're the perfect middle ground or the perfect moderate ground in where you're going in the best bang for your buck when it comes to testing. The unit tests know too much about the implementation. I'm not saying don't do unit tests, they're important, just as important. However, you should be using them sparingly and only when it's important for a regression to be caught. Acceptance tests can also become too fragile, and they don't really know enough about your program. So they're often catching things where they shouldn't be. And it becomes that you're fixing tests more than you're fixing problems. So don't forget, you have diminishing turns after whatever percent of code coverage. This is different for every team and every project. I consider talking to your team about this. See just how many tests do you need to catch those regressions to catch any bugs that you might introduce. So the moderate programmer refactors, but only eventually. This talk by Sandy Metz in 2014 at Rails Conference was really great. And she talked about refactoring. You don't need to be a Ruby developer or even a Rails developer to understand this talk. I highly recommend it. She says one thing in that that really resonated with me. And she says duplication is far cheaper than the wrong abstraction. She even has a blog post specifically about that. And I think it's really important. But above that, I've written right ugly code. And that's the one thing, if you're only going to take one thing from my talk today, I want you to take that. I want you to have permission to yourself to write ugly code. Because unless you write ugly code, you're not going to know what beautiful code is. You're not going to know what the right abstraction is going to be. You also might make it harder for your teammates to read the code. So it's really important that at least at first you write ugly code. It's okay to write those for loops instead of a filter. It's okay to write the if statements. It's okay to write the ugly code. So this came up the other day, Jeff Atwood tweeted, the older I get, the more I enjoy dumb verbose code over fancy concise code. And I thought this kind of summed up what I was talking about fairly well. So you can see at the top, it's a much more complicated thing to understand than below. So again, some rules rule of three abstract on your third duplication. If you're going to refactor, it's okay. If you leave some duplication in your code, that's not a sin. You absolutely can do it. In fact, you probably want to do it up to your third time. At that point, you should be considering what the right abstraction should be. Well, future me or my teammates understand this better. And when I say future me, I don't mean future me that has been working on this code for three days and knows it inside out, but future me who's been tired, who is underslapped and who is now stressed because they have to figure out that code. That's a different person than you are when you're writing it. So you really want to consider that way the costs of the refactor. Is this going to be better for the program? Or is it just clever? Like, is it going to stop bugs from coming up? Is it going to be easier for my teammates to read? And I think that that's maybe the most important key is you should be airing towards easier to read rather than easier to write. So the moderate program gives up, but not forever. So there's a number of examples about this. Let's go through each type of giving up. First off, give up and ask someone for help. And this is probably the most important versions of the giving up. If you're struggling with trying to get some code written, if you're not sure and you banged your head against your monitor for three hours, it's definitely time to give up and ask someone for help. That could be a teammate. It could be online. It could be in Discord. It could be just a Stack Overflow search, but it's really important to stop and do that. Also, I found that while asking for someone for help, within minutes of trying to explain the problem, I've already solved it in my head and I don't even need to talk to someone anymore. So it's more important that we need to do this and not just power through when we're struggling. Also, give up and take a break. Take a walk, play a guitar, do some yoga, whatever it is that takes you away from programming, even if that's just for 15 minutes, that will clear your mind and make it easier to solve your problems. And finally, give up and throw out your code. It's okay. You can write your code two, three times. And sometimes you have to struggle through it once or twice before you find the right way to do it. So I'd say it's okay to throw out your code. You probably want to get stashed at first. You'd be surprised at how many times you might need it. So let's sum up what we've been through today. We talked about the moderate programmer names things, but with enough detail, writes small functions, but not too many, writes only enough tests, refactors their code eventually, and the moderate programmer knows when to temporarily give up. Thank you, everyone. I really appreciate you listening to my talk and please reach out to me on Discord or wherever you can find me, and I would love to chat to you more about this. Thank you again.