The Moderate Programmer
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 24 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46556 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 202015 / 24
2
5
8
10
11
13
15
16
17
19
20
23
24
00:00
Linker (computing)RhombusMusical ensembleComputer animation
00:12
Shape (magazine)CodeProgrammer (hardware)Bit rateMultiplication signFront and back endsInclusion mapTheory of relativityAnalytic setSinc functionBitProgrammer (hardware)JSONComputer animationMeeting/Interview
01:12
Extreme programmingProgrammer (hardware)Computer programmingSoftware developerMathematicsField (computer science)Front and back endsExtreme programmingMeeting/Interview
01:57
Computer programmingNetwork topologyExtreme programmingExtreme programmingProgrammer (hardware)Computer programmingInternet forumProgramming paradigmComputer animation
02:36
Programmer (hardware)Programmer (hardware)Internet forumVideo gameComputer programmingComputer animationMeeting/Interview
03:31
Programmer (hardware)CodeCountingInformationHidden Markov modelObject (grammar)Greatest elementBitCode
04:20
Programmer (hardware)Boolean algebraFunction (mathematics)Functional (mathematics)Boolean algebraCodeWordSocial classSystem administratorFactory (trading post)Object (grammar)CASE <Informatik>Array data structureMappingCAN busMeeting/Interview
05:25
Programmer (hardware)Function (mathematics)Programmer (hardware)NumberFunctional (mathematics)CodeMessage passingBitFlagControl flowLine (geometry)Meeting/InterviewComputer animation
05:52
Programmer (hardware)Function (mathematics)CodeFunctional (mathematics)Multiplication signCode
06:21
Programmer (hardware)Function (mathematics)FlagCodeFunctional (mathematics)Continuum hypothesis
06:48
Function (mathematics)FlagProgrammer (hardware)Software testingComponent-based software engineeringConnectivity (graph theory)Price indexFunctional (mathematics)FlagCASE <Informatik>NumberProgrammer (hardware)Rule of inferenceSign (mathematics)Parameter (computer programming)Right angleCategory of beingComputer programmingInternet forumSoftware testingMeeting/Interview
08:00
Programmer (hardware)Software testingChemical equationSoftware testingComputer programmingINTEGRALParallel portLinear regressionMathematicsMeeting/Interview
08:55
Programmer (hardware)Software testingDisintegrationImplementationExecution unitCodeSoftware testingRight angleImplementationLinear regressionSubsetComputer programmingCodeProjective planeSoftware bugInternet forumUnit testingINTEGRALRule of inferencePerfect groupTest-driven developmentProgrammer (hardware)DivisorMeeting/Interview
10:23
Programmer (hardware)Software developerCode refactoringComputer animationMeeting/Interview
10:38
Programmer (hardware)AbstractionCodeProgrammschleifeStatement (computer science)AbstractionCodeBlogMeeting/Interview
11:32
Programmer (hardware)CodeCodeRule of inferenceMeeting/Interview
11:51
AbstractionRule of inferenceProgrammer (hardware)Online helpDisk read-and-write headRule of inferencePower (physics)AbstractionCode refactoringControl flowCodeSineMultiplication signRevision controlStack (abstract data type)Buffer overflowDivisorFunctional (mathematics)Key (cryptography)Software testingComputer programmingNumberType theoryProgrammer (hardware)SummierbarkeitWritingPoint (geometry)Arithmetic meanInternet forumSoftware bugComputer animationMeeting/Interview
Transcript: English(auto-generated)
00:23
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
00:41
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
01:05
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 behavior. I'm just
01:22
been a programmer now professionally for over 20 years and I've been through a lot of changes in the field, especially in 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
01:41
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 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
02:00
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 behaviors seem to be endemic around programmers and we have to work harder than others at actually
02:21
curbing that behavior. 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 behaviors. So this quote, moderation in all things including moderation. For everything I'm going to tell you today, there's of
02:47
course a lot of advice. And sometimes we do have to go all in on something and do an extreme behavior 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
03:03
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
03:26
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
03:41
of Canada, which I guess is a country, although it just says name, so I'm not sure. Code is CA. 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,
04:03
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
04:22
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, and it's probably two verbals. We should avoid jargon and metaphors. Try not using the words factory or object or class. All of those things
04:40
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 Booleans, prefix with is, has, can.
05:05
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, then noun, like get users, find admin, things like that.
05:27
Number two, the moderate programmer writes small functions, but not too many. 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,
05:40
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 is doing, conceptually, too many things. Let's break it up. Oh, we've broken up far too much. Look at this. We got now four functions where we had one before, so now we got a get user, get ISO code, save user, get country,
06:04
and then the main function, start save user. Well, this isn't quite right. It's going to be really difficult to, because every time we get to it, const user equals this user. Okay, what does this get user get? Now we jump up, have to look at it. This becomes a lot more difficult to understand.
06:22
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.
06:44
So much more easy to understand this code than the last two examples. So again, some rules. A function should conceptually do one thing. Beware of how many flags you have in arguments. Any flags, even one, is probably a sign that your
07:00
function is doing too many things, and you may want to reconsider that. Beware 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 too, and this is really important.
07:21
Everything I said here also applies to your component creation, because conceptually, components are functions as well. 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. Number three, the moderate programmer
07:44
writes tests, but only enough. You've probably seen this before. Eat food, not too much, mostly plants. This is a nice moderate take on eating by Michael Pollan, and in programming, we have this.
08:03
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.
08:24
Not too many, because too many, and our program's 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
08:41
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 in regression tests. So again, some rules. Write your tests, and write them immediately,
09:00
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. Ember integration tests are your best bet. Again, they're the perfect middle ground, or the perfect moderate ground, in where you're going the best bang for your buck
09:23
when it comes to testing. 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.
09:40
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.
10:01
So don't forget you have diminishing returns after whatever percent of code coverage. This is different for every team and every project. I'd consider talking to your team about this to see just how many tests do you need to catch those regressions, to catch any bugs that you might introduce. So the moderate program refactors, but only eventually. This talk by Sandy Metz in 2014
10:27
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
10:42
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 write 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
11:04
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
11:22
those four loops instead of a filter. It's okay to write the if statements. It's okay to 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
11:41
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
12:04
to do it up to your third time. At that point you should be considering what the right abstraction should be. Will 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 under slept, and who is now stressed
12:24
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. Weigh 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
12:45
maybe the most important key is you should be erring 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
13:04
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
13:22
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've 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
13:45
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
14:03
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
14:25
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.
14:47
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.