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?”

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!

Console.log is my friend (yours, too)

I don’t get to use a lot of JavaScript at this point in my new job, so to keep up on my JS skillz I spend some of my weekend time practicing old things or learning new things. Right now I’m learning Node. And while reading some code for a basic Express server, I was reminded of the lovely thing that is console.log.

Here’s the code:


var express = require('express')
var app = express()

var jsonData = {count: 12, message: 'hey'}

app.get('/', function(req, res){
  res.sendFile(__dirname + '/index.html', function(err) {
    if (err) {
      res.status(500).send(err)
    }
  })
})

app.get('/data', function(req, res) {
  res.json(jsonData)
});

var port = 3000
app.listen(port, function(){
  console.log('listening on http://localhost:', port)
})

I can see the code is pulling in Express, that it’s declaring a jsonData variable and assigning an object to it, that the get method will call one of two functions depending on the path that’s being requested, and that the listen method will show me what’s happening on my localhost:3000. And I can see those two get functions are going to use req and res, and I can see what happens with res…but what about req? I figure it’s the request coming in, but I have this need to know what all parts of all things look like, so how do I find out? Put a console.log in those functions, of course! It’s about a gazillion lines of data so I won’t repost it all here but at the very bottom, I see something like this for the first get function when I ask for the root path(‘/’):


route: Route { path: '/', stack: [ [Object] ], methods: { get: true } } }

And something like this for the second get function when I ask for the data path (‘/data’):


route: Route { path: '/data', stack: [ [Object] ], methods: { get: true } } }

Doing things like this helps the code make more sense in my brain. While I understood that the functions were taking in requests and returning responses, now I can see what the requests actually look like and I can see how the functions are seeing the path. Yay!

Flex-basis, flex-grow, & flex-shrink

Flex-basis, flex-grow, and flex-shrink are three Flexbox properties that can make things easier when dealing with responsive design. So what’s the difference between them? Let’s take a look at some code and find out!

Flex-basis is how much space we want our element taking up in an ideal world, before we start addressing extra space or less space. So in this instance, we want each of these divs to be 100px wide.

.div1 {
  flex-basis: 100px;
}

.div2 {
  flex-basis: 100px;
}

Now, when we’re viewing these two divs in any browser wider than 200px, there’s going to be some leftover whitespace. Flex-grow helps us decide how we want to divvy up any extra whitespace between our elements. So, as whitespace expands, div1 will take up twice as much of it as div2:

.div1 {
  flex-basis: 100px;
  flex-grow: 2;
}

.div2 {
  flex-basis: 100px;
  flex-grow: 1;
}

Flex-shrink helps us decide how we want our elements to behave as space decreases. In this case, we want div2 to shrink twice as much as div1:

.div1 {
  flex-basis: 100px;
  flex-grow: 2;
  flex-shrink: 1;
}

.div2 {
  flex-basis: 100px;
  flex-grow: 1;
  flex-shrink: 2;
}

To make it much more concise, we can re-write our code like this:

.div1 {
  flex: 2 1 100px;
}

.div2 {
  flex: 1 2 100px;
}

I hope that helps make sense of these three properties. If you want to learn more about Flexbox, you can’t go wrong with Wes Bos’ free series.

On object manipulation in JavaScript

Honesty is important to me, even when it means coming clean about things I struggle with. Today, I confess that I struggle with comprehending object manipulation in JavaScript. Earlier this morning I was pairing with a friend on some katas in Code Wars, and I was struggling to understand what was happening with this code:

let staff = {
  tim: 'finance',
  jim: 'accounts',
  randy: 'canteen'
}

function boredom(staff) {
  var map = {
    accounts: 1,
    finance: 2,
    canteen: 10
 }

  var score = Object.keys(staff).reduce((a, b) => {
    return a + map[staff[b]]
  }, 0)

  return score <= 13 ? 'kill me now' : 'party time!!'
}

As you can see, boredom is taking in the staff object, where it wants to match up the staff values with the corresponding numbers in the map object, then tally the numbers to produce a score and return that score’s relevant string. So theoretically I understood all that, but not this specific part:

map[staff[b]]

My brain was reading it like this…

map.staff.b

…which is sort of right, but also why I was getting confused.
I mean, map and staff are two separate objects, not connected in any way, so how is that working? Let’s walk through it! And by let’s I mean me, so I can solidify my understanding 🙂

Alright, so the first time through, a is 0 and b is ‘tim.’ Which means map[staff[b]] is basically map['tim']. And what’s Tim’s value? It’s finance. Since Tim’s value is ‘finance,’ map['tim'] is basically map.finance. And what is map.finance? That’s right, it’s 2! So the first time through, 2 gets added to 0, and on the next time through 2 becomes a, and b is now ‘jim,’ and on and on until the numbers are reduced down and boredom spits out how you feel about your office’s fun level.

Check out the reduce method on MDN.

Find out more about objects in Eloquent JavaScript.

And don’t forget, you can walk through code step-by-step on this site.

Let’s learn about objects and this

No really, let’s. Because I’ve learned this already, but I need all the reviewing I can get. This should take 6-8 hours.

First, watch these videos by one of my very favorite JS resources, Mattias P. Johansson. (And later on, find time to watch all his other videos – he’s highly entertaining, very human, and also super nice on social media.) No need to code along.

Then read chapters 1 and 2 of this book by another one of my favorites, Kyle Simpson. You may, like me, feel both dumber and smarter after reading Kyle’s material, but that’s okay – he knows his stuff and it’ll be worth it. I like to code along with the examples Kyle provides, but you don’t have to.

Now, code along with Mary while she makes a fun little game. She moves fast and you may have to stop the video every few minutes to catch up. After you’ve got all your code written and working, watch the video again while adding comments to your code about what every single thing is and what it’s doing. You’ll learn more in this second run-through than you could catch in the first, trust me.

There, now you’re an expert! Okay, not really – but you learned some stuff, right? BOOM.