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!

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: 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!

TDD with JavaScript

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!

A book written by Christian Johansen
Time for some fun!

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.)

I’ve been a developer for six weeks. Here are the code school skills I actually use.

In December 2016 I finished the Front-End Engineering program at The Iron Yard in Salt Lake City. In January I was offered a job and in February I started that job. So what did I learn in bootcamp that’s helped me daily?

How to read code

I used to beat myself up constantly for being able to read code and understand what it’s doing, but not being able to write it myself. And then I got a job at a place with multiple giant codebases and it turns out that reading code and understanding it is the more important thing (at least right now – I was here four weeks before I needed to write anything from scratch). Every week I’m introduced to a new thing at work, and lo and behold, all that practice I got reading code during school comes in handy again.

How to focus among a gazillion distractions

Write/read/test code while groups chat and laugh five feet away and there are Nerf gun torpedoes being shot at my head and some delicious smell is coming from the nearby kitchen? Yes, yes I can. In school we were encouraged to spend our afternoon lab time together, so I quickly developed the ability to be in a small area with a bunch of people and a lot of talking and interruptions, and still stay on task. At my previous job, I often had to use earbuds and brown noise to block everything out – now I don’t even notice it.

How to learn

I’ve always been a capable student and never had a problem learning things. But with bootcamps, it’s a firehose of information, and this job has been no different – learning in this kind of environment is a beast. The brain has to quickly filter through the hundreds of things being thrown at it, decide what’s most important and useful, grab onto those varying pieces of information, and then plug them in where needed hours or days or weeks later. I was able to practice this at The Iron Yard for twelve straight weeks and it has paid off immensely.

How to ask questions

Part of our pre-bootcamp coursework was to watch this talk on getting technical help. You should definitely check it out. Asking for help is complicated in our field. Knowing what information I need to convey to my team and how to communicate it succinctly, quickly, and in a way that gets the most helpful answer is something I work on daily – if I hadn’t spent so much time practicing it at The Iron Yard, my first weeks here would have been much worse.

How to ride the emotional rollercoaster of dev work

You caught that, right? What I said about it being worse? It implies those first weeks on the job were bad, and they were. If you’ve read my posts, you know that I almost quit in week 3 of bootcamp. Every week was so full of ups and downs that I could oscillate between wanting to quit and knowing I’d made the right career change decision four times a day! And so when I wanted to walk out of this job in week three and never return, I knew enough to ride it out. When I’m feeling especially stupid (happens often), I know that I just need to give it time and I’ll get it.

How to talk to complete strangers

Not only were we encouraged to go to meetups all over Salt Lake City, we were often thrown into on-campus networking events with little notice, or required to pair with people we didn’t know at all. The result? I can approach anyone at my job or at meetups, and I can successfully pair with any teammate. I know this isn’t a big deal to plenty of folks, but this was a skill I did not have before The Iron Yard, and it’s been huge for me.

* * * * *

I can’t be the only bootcamp grad whose first job uses a different language than the one studied in school, and I’m so glad I can still get some ROI for my $25,000 (tuition plus three months of not working). So, my advice to anyone attending or considering code school — spend as much time focusing on the soft skills as you do on the actual code. It’ll pay off.

From accountant to developer

Career changes. How do we come to the conclusion that we need to upend our entire life? To risk safety, routines, and having an idea of what the future will bring to take on the completely unknown? And what makes some people willing to do it, and others refuse? I’ve recently made a career change, and I’ve discovered that my feelings about it are not very cut-and-dried. I’m so happy I did it, and full of regret that I did it, and so unsure of how it’s going to turn out, and so cavalier about if it turns out well or not.

In the summer of 2015, I found myself in a cardiologist’s office listening to him say, “You need to find a way to reduce the stress in your life.” I was way too young to be having that conversation but all the same, it was true. For a decade I had made my career the first priority, and years of being in executive management of a company with constant growth and change had finally taken its toll. My Type A behavior didn’t help.

As I thought about what I could do to make my career less stressful (how in the world could I ask for a demotion now?), I spotted a bigger set of problems. I realized I wasn’t coming up with fresh ideas anymore. I had become accepting of problems because I no longer had the energy to tackle them. I was burnt out, and I felt stagnant. These things gnawed at me, but I couldn’t see a way out.

I had just received my BS in Accounting – four very long years of full-time credits, full-time employment, freelancing on the side, and raising two kids – and it wasn’t the most optimal time to be thinking, “Eh, I don’t really want to do this anymore.” So I persisted down the path I’d set for myself long ago: get my MBA, then sit for the CPA exams. I started looking at grad school and settled on two prospects. I had the transcripts sent, the recommendations written, and I filled out the applications. But when it came time to write the essays – that most simple of questions, why do you want an MBA? – I struggled mightily. Writing has never been difficult for me, and I can bullshit my way through plenty of things, but the only honest answer I could come up with was, “To make more money.” I realized I didn’t really want to be a CPA – it was just the next logical step and the way I could provide more for my family. When I weighed going $60-$80k in debt for something I felt only lukewarm about, I knew I couldn’t do it. And there was no more denying the truth – I had zero interest in being an accountant anymore.

Turns out that deciding to change careers wasn’t the hardest part for me – it was figuring out what else I’d like. It took months of exploration, and several bouts of frustration, yelling at myself, “WHAT KIND OF IDIOT DOESN’T KNOW THE THINGS THEY’D LIKE TO DO?!” I finally resorted to thinking about myself as a kid and the things I’d liked then. Two things bubbled to the surface: writing and programming. Writing was immediately slapped away as a too-frivolous dream, but programming…maybe there was something there. In middle school I’d had a BASIC class and adored it. In high school (think “You’ve got mail!” era), we had the chance to create our school’s first website, which I also loved. More recently, I’d taught myself Access, then designed and built a database for my employer – a hefty project I’d enjoyed immensely. Looking back on my career, I could see what I really liked doing was solving problems. And helping people. And that I needed to have an unending well of knowledge to keep drinking from.

I turned to Google. I found this amazing piece by Paul Ford and I read it through immediately, fascinated. I tried every little tutorial I could find to see if I was right, to see if this coding stuff would hold my interest. It did. But how to go about actually learning to program? I figured I could use self-guided online study, but I didn’t really want to – I’d earned my bachelor’s that way, and I wanted to be with people this time. Plus, my job as a financial controller was stressful and draining, leaving me with no brainpower at the end of the day to devote to learning. One day my husband told me his colleague’s brother had gone to something called a coding bootcamp; I googled it right then and there. After a couple of weeks of research, I decided on a school and a language, gave a three-month notice at my job, and traded one stack of books for another:

Sometimes, you’ve just got to make the leap, safety net or not.