Contributing to tech for beginners

Giving back to the tech community is important! Every time we use Slack/Twitter/Stack Overflow/Reddit to ask our fellow devs how to do something, I hope we think to ourselves, “Somewhere down the road, I need to help someone else the way I’ve just been helped.” It may be naive, but I feel that remaining a community of givers is so important to tech, and it should never go away. But if you’re new to coding, this concept of paying it forward can seem tough to implement. You may not yet know enough to answer others’ questions. You may be completely overwhelmed by the concept of contributing to OSS, or presenting at a meetup. I faced the same issues when I first became a developer. The good news is, there are things you can do to be involved and help the community. Here are the things I’ve done so far – maybe this list will help you brainstorm some ideas that work for you!

Help plan a conference

Conferences abound everywhere, and they need volunteers to help pull it off. Here in Salt Lake City we have the awesome UtahJS organization, and for six years now they’ve put on an annual conference for all of the amazing developers we have around here. A year ago, I noticed their website wasn’t updated with the newer location of one of the many JS meetups, so I found the code on GitHub, did a quick change and pull request, and then offered to help out in any other way they needed. Shortly after that I was on the planning committee for the conference, helping to pick speakers, voting on everything from venues to t-shirt designs to schedules, and doing everything possible to keep ticket costs low.
time commitment: 10-15 hours a month for the 8 months leading up to the conference, then 35 hours the week of

Transcribe a podcast

Think of your favorite developer podcast. Then think about making it more accessible – as in, available to people who need to read it instead of listen to it. Now think about how bad talk-to-text technology still is, and how in the world that podcast is going to get transcribed. You can provide this service! I volunteered to do this for an episode of CodeNewbie, and it’s not easy, but if you believe in what the podcast is trying to do, it’s worth it.
time commitment: 6 hours per 1 hour podcast

Help foster a community

On social media all the time anyway? There are Twitter accounts, Slack channels, and Facebook groups that could use your help! You could volunteer to post meetup schedules, take pictures or make videos of the meetups while you’re there and post those – anything at all to keep the community active and engaged. Sometimes it’s just a matter of welcoming new members, setting guidelines, and being available when someone has a question. I do this for UtahJS and our local FreeCodeCamp chapter and it’s by far the easiest way to be involved and give back.
time commitment: 1-2 hours a week

Co-host a study group

All around us, people are trying to learn to code. Can you help out by being present for a study group? Even if you feel you don’t know enough to answer questions, you can still be there to open the door, welcome attendees, and provide encouragement. Getting into this field can be intimidating and overwhelming, but if we can help others feel less alone on the journey, that’s worth a ton. Plus, chances are good you’ll come away feeling inspired – I know I do whenever I do this for the FreeCodeCamp meetups here in SLC!
time commitment: 4-8 hours a month

Smaller ways to help a conference

If the time commitment above is too much for your schedule, there are still other ways you can help out with a conference! This kind of event always needs usher-type attendants present in each room to help out the speakers, be available for code of conduct issues, help direct the audience in and out or answer general questions, or even help out at the registration desk in the morning.  Interacting with that many people not your cup of tea quite yet? What about volunteering to review and rate applications for the conference’s scholarships? I happened to be on vacation when I was asked to do this for ReactRally, and although there were 150 applications, it actually didn’t take that much time. (It did help that my vacation was nothing but laying by a pool, but still.)
time commitment: 2-12 hours

I hope you take these ideas and run with them! Find your niche of giving back to the tech community, until that day comes along when your knowledge reaches the point where you can answer someone’s question, and make them start thinking, “How am I going to pay this forward?”

The LaMarr List: December 29, 2017

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.

  • This blog post is a nice, easy intro to big O.
  • 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!

The LaMarr List: November 29, 2017

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!
An image of the author's Christmas tree
Happy December!

Getting back to basics

One of my biggest disappointments with coding bootcamp is the scant amount of time we spent with vanilla JavaScript – only one week! By week four we were into Webpack and then React and Angular came quickly after. And while I was glad to get experience in those technologies, I set a goal in January of 2017 to practice a lot of vanilla JS. I stuck with it for a month but then I got a job and it required learning SQL and then a couple months later that job got crazy and it required learning C# and then I realized hey that language is fun and I even asked for (and got!) this book for my birthday and that ended up being a three-month side trip and then I had an idea to build an app for work and I thought hey I should use all these things I want to know in it! – so then came postgreSQL, graphQL, node, express, and vue and then October showed up and I was asked to help out with the local FreeCodeCamp chapter and I looked at all those algorithms in the course which I had never finished and always wanted to and I was sad and I also looked back on the goals I had set at the beginning of the year because fall is a great time to evaluate one’s life and I saw the ‘get super comfy with vanilla JS’ goal and I was disappointed in myself as usual but I was also really enjoying getting familiar with TDD because I think it makes me a better developer and I didn’t want to stop doing that and then Eureka! I decided this was the perfect chance to combine vanilla JS and TDD and put everything else on the back-burner for three months.

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.

The LaMarr List: October 29, 2017

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!

Remembering git

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!

An image of a git repo
The repo you want to work on. Click ‘fork’ here.
An image of another git repo.
Your copy of the forked repo. Click ‘clone or download’ here.
An image of the author's terminal
All of the git commands in the terminal
An image of a new pull request
Creating a new pull request. Click the ‘compare & pull request’ button.
An image of a modified pull request
Add clarifying comments to the pull request, if needed.
An image of a finished pull request
The completed pull request. Now you wait for a maintainer to merge your work!

The LaMarr List: September 29, 2017

  • 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!
  • And one of my very favorite learning resources ever, Fun Fun Function on YouTube. Mattias makes learning about JavaScript fun AND real! Lately I’ve been using him for the GraphQL videos but he has so many great ones – check him out!

The LaMarr List: August 29, 2017

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:

An image of Ashly LaMarr at Snowbird Ski ResortAt Snowbird’s Oktoberfest

No time to write

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.

So yes, I’m still here and yes, I’m still loving being a developer. My team is amazing and makes every day a blast. I am realizing the appeal of a job where I’d get to use all the latest and greatest tools/frameworks/libs – then I wouldn’t have to spend tons of my time outside of work learning them. But I cannot believe the rate at which I’m learning JavaScript, SQL, and C# – sometimes I feel like that Matrix download thing is happening. It’s the learning that makes everything worth it!

The LaMarr List: July 21, 2017

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:

  • JavaScript Jabber’s episode #270, “The Complete Software Developer’s Career Guide with John Sonmez.” I’ve gone ahead and ordered the book ($.99 on Kindle, woot!) and will read it when I can, but I’m recommending this episode because of the discussion on computer science knowledge (algorithms, data structures, design patterns) and how necessary it is – or isn’t – for your career. Check it out!
  • 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 🙂

In the meantime, greetings from Las Vegas!

An image of a pool in Las Vegas
Did I mention quality poolside time? BOOM.