I’ve been on an algorithm kick for a couple of months and while I’ve failed at this goal of completing five algos a week, I haven’t felt too bad about it because I’ve been learning about big O and refreshing my memory on logarithms. Not a bad tangent to pursue! Since I’m super nerdy, it’s been super fun.
I got this book for Christmas and it’s terrific. After a couple of false starts trying to grasp big O, this author’s explanation of it made complete sense.
This baseCS post tackles the explanation of logarithms with lots of visuals and by getting into the nitty-gritty of the math.
This is a great week for our family – Dustin and I often go on vacation for Christmas and then have our family Christmas celebration on New Year’s Day. So we just returned from a week in Las Vegas – sometimes ya just gotta get out of the Salt Lake City cold – and will spend the rest of this year eating, watching movies, and playing lots of Overwatch. Happy Holidays!
This is usually where I try to write a decent intro paragraph but man, I am exhausted. It’s the start of the holiday season and for us that means two Thanksgivings, two Christmases, two company parties, and plenty of travel. Ain’t nobody got time to write an intro paragraph right now.
I really enjoyed this article about the very human trait of not acting on what we know we need to do. The part about breaks in momentum not being the end of the world is something I need to be reminded of often. Give it a read and see if any of the root causes connect with you!
I’ve been on a TDD kick lately. But can TDD replace human testing? DHH says no, and I agree. When I QA my colleagues’ code, I love acting like a brand new user and seeing what I can break. Because of that, I’ve been called ‘the goalie’ – nothing gets past me. TDD is useful (and wonderful for developers) but it is not the only testing we need.
This is part one of a three-part series on unit testing. In it, mpj explains how he uses unit tests “to keep complexity from overwhelming” him while he writes code. This has been of huge benefit to me in my journey as a developer and I encourage you to watch the video (11 minutes) and see what you think!
It’s terribly easy to get distracted by the shiny new thing in programming. I thought I would be better at not being drawn in because I’m that person who maps out annual and quarterly goals and checks in on the progress weekly but no – turns out, I’m only human! So this is me recommitting, in public view so I feel held accountable, to studying vanilla JS, to finishing these algorithms, and to learning TDD at the same time. You can check up on my progress here. I’m going to try my damnedest to not let anything get in my way, and soon it will be a year since I said I wanted something and we’ll see if I’ve accomplished it. BOOM.
I’ve been on a TDD kick lately and have found some cool resources:
Sometimes, a difficulty about learning TDD is understanding how to construct those test functions and how they interact with the code you’re writing. Check out this tutorial to get a basic understanding of how it all works.
I’ve been exposed to mocha, jasmine, chai, and selenium during my first year as a developer, and here’s what I discovered: I’d start thinking about an app I wanted to make, then I’d start telling myself I should obviously do TDD with it, then I’d get overwhelmed by all the ins and outs of those testing frameworks and stay stuck in that decision-making limbo for far too long. Then I discovered tape, thanks to a mentor. Use this tutorial to see how simple tape is.
While you’re working through those tutorials, you’ll notice a code coverage tool called istanbul. I turned to my local Software Craftsmanship group and asked them what their preferred code coverage tool is, and the conversation turned to whether code coverage is even necessary. Here are a couple of excellent opinions to give you some food for thought:
“It’s useful to have coverage when you’re just starting out with TDD as you’ll often not realize you’ve written more code than necessary or you should have and will miss conditions. Once you can consistently do quality TDD, only writing the code required by the tests, coverage becomes less useful.”
“I tend to avoid those coverage tools as well. While I can see the allure, I think it is the wrong metric to track. Covering a function with a test does not guarantee that the function is fully tested. I prefer to track bug counts that I discover after shipping — I feel that this metric is more telling of code quality.”
So check out how istanbul works, too! Give TDD a shot, and chances are you’ll find it makes you a better developer. It’s only partly about testing your code automatically – I’d argue it’s mostly about getting into the habit of really thinking about your code before you start writing it, which saves everyone, including you, so much time in the long run. Cheers!
Back when I started getting into development, I read this blog post by Vaidehi Joshi. In it, she explains that one of the great benefits of technical blogging is having posts to refer to when inevitably forgetting how to do something previously learned. Unfortunately, I didn’t follow Vaidehi’s advice very well and I recently found myself needing to use git, with no recollection as to how (judge all you want, but my employer uses an in-house version control system, so I did not keep up on my git skillz). Luckily my muscle memory eventually kicked in, but it still took longer than it should have to do a simple edit and pull request – and ain’t nobody got time for that, so here you go, future self:
Step 1: Navigate to the repo you want to edit, and fork it. This copies the repo to your GitHub profile, so you can make the changes you want.
Step 2: If GitHub doesn’t take you there automatically, navigate to your profile and then to your copy of the repo. Click the clone/download button, and copy the SSH url that pops up.
Step 3: In your terminal, navigate to the directory you want to place this project into. Type git clone, paste the copied SSH url into your terminal, and press enter. Go ahead and cd into your newly created project.
Step 4: You want your copy of the repo to have the original repo location as a remote, so you can fetch and pull from there and always have the most current code. Navigate back to the original repo location on GitHub and copy the SSH url.
Step 5: Use the command git remote add upstream followed by the URL from the original repo, then use git remote -v to check your fetch and push locations.
Step 6: Use the command git fetch upstream to get information on the upstream remote.
Step 7: You want your local master branch to point to the upstream master branch. Use the command git branch --set-upstream-to=upstream/master master (or whatever their master branch is called).
Step 8: Create a branch for whatever feature/change/bug you’re working on, using the command git checkout -b followed by what you’d like to call your branch. Using this command will simultaneously create the branch and check it out for you – meaning, move you to that branch.
Step 9: Open up the project in your code editor and make your changes, yay!! When you’re done, you can use git status to recap what files you’ve changed and what you need to add and commit.
Step 10: Add those changed files! Use git add followed by the name of the file(s) you want to add, or git add . to add everything at once.
Step 11: After adding, you’re ready to commit the changes you’ve just staged. Use the command git commit -m, followed by your commit message enclosed in quotes.
Step 12: Now it’s time to push the changes to your local copy of the repo. Using the command git push origin pr/update-forwardjs-link means you are pushing these changes to origin, branch pr/update-forwardjs-link.
Step 13: Navigate to your copy of the repo on Github. Notice that it displays a recently pushed branch and a ‘compare & pull request’ button. Click that button.
Step 14: Select the correct base and head forks and branches. Add a comment if you need to, then select ‘create pull request.’
Step 15: You’re all done! Now it’s just a matter of waiting for your pull request to be merged/rejected/ignored. Move on to the next project in the meantime!
This blog post by Trevor D. Miller covers running a Node server on a Pi with a physical button. I’d really like to try this with my son, for whom I recently bought a Pi.
These fantastic slides on the “tremendous social pressure to constantly learn and migrate to new technologies.” Great stuff from Brandon Hays – it will make you think!
Um, can you tell it’s hard for me to find time to write? My last List was over a month ago, and on vacation to boot. At the time I had grand aspirations of doing these once a week, because I consume A LOT of content and there’s no reason it shouldn’t be easy to share the best of it with all of you, and yet here we are. Maybe once a month is a more realistic goal?
I enjoyed this piece about being a better male ally. A particular line really hit home:
“A boss has season tickets to see a baseball team. He generally invites men from work to join him — not because of discrimination, but because he’s worried about how the invitation would be perceived if he extended it to a woman.”
How many times have you seen that happen? And it’s pretty understandable! As a woman, I can attest that this happens from our side, too: Countless times, I’ve held back from connecting with male colleagues outside of work because I’m worried about the perception. What steps can we all take to fix this?
Utah’s very own Tyler McGinnis has some great podcast episodes, and you should give them a listen! The two up now feature Kent C. Dodds (also Utah’s own), who is active in the OS community, and Dan Abramov, who helped create Redux. I love how the topics include burnout and work/life balance.
Last week I had the opportunity to attend React Rally, and it was fantastic. When I told Brian Holt it was my first tech conf, he insisted that it would be all downhill from now on. So many great speakers, so many ‘online idols’ I was able to learn from and meet! I’ll have to write a detailed post about it later, but in the meantime, keep an eye on their website for next year’s tix, because they sell out QUICKLY.
This weekend we enjoyed Snowbird’s Oktoberfest with some of our favorite people, and when my mother-in-law asked us to send her the picture with the mountain, well….we couldn’t resist sending her this:
Fascinating blog post title, right? Well, it’s 5:30am on the kids’ first day of school and it’s all I can come up with. And it’s the truth.
I’m seven months into my first developer job and I haven’t had time to write about any of it, which is very disheartening. Every day is an adventure of learning and I want to document it all, but when the workday is over, there’s just enough time to hit the gym, bury my eyes in icepacks, hang out with my family, and hit the sack. Which means mornings and weekends are generally reserved for the extra studying I’m doing on my own. Which means writing falls by the wayside. And I hate it. But priorities are priorities.
This week I drove down to Vegas for some quality poolside time and you know what road trips mean – time to catch up on ALL THE PODCASTS! Today’s picks are:
Front End Happy Hour’s episode #32, “Imposter Syndrome – These are not the drinks you’re looking for.” Join some of my fave Twitter follows for a discussion that proves maybe Imposter Syndrome isn’t 100% awful after all. You’ll come away feeling a little less stressed out, I promise. Listen here!
Patrick Wyman’s “The Fall of Rome” podcast, 23 episodes. History is fascinating and the rise and fall of Rome has captivated me for some time – I’ve been trying to find the perfect way to learn more about it. This just might be it! Give it a couple episodes before you quit 🙂
Do you love books? I LOVE BOOKS. I just got this one in the mail and I can’t wait to spend my evenings with it for the next few months!
Do I sound nerdy to you? (It’s because I am.) I can never get enough of learning. This has been a really difficult part of being a developer for me, because I’m interested in so many things, plus I have zero patience, so I try to study multiple things at once. You can imagine how this works out for someone with unmedicated ADD. After months of trying to balance learning a new language at work with studying other things in my ‘spare’ time (hardee har har), I decided to take a couple of weeks off and see if there was one thing that would rise to the top – one thing I wanted to learn more than the others.
Now, take note of that word, ‘wanted.’ This is another difficult thing for me, because I like to make the practical decision, the responsible decision, the decision that will lead to better employment/more money/good stability for my family. Often this does not correlate with what I actually want to do. All you adults out there feel me. But over the last few months I’ve realized that if I’m going to find the motivation or energy for extra learning after a full day of work, it’s got to be something I actually want to know more about. Enter this book.
Here’s what I know about TDD:
1) TDD is something that needs to be done, should be done, and often isn’t done.
2) Every time I’ve paired with someone on it, I’ve felt so clueless I wanted to cry.
3) Every time I’ve paired with someone on it, I’ve thought, “This stuff makes me a better developer.”
That’s about it. So TDD it is. I’d like to commit myself to a post a week about what I learn, but I’m already overextended so nah. (But maybe.)