Config files > Github

I’ve been at my new job for two weeks now. Im learning a ton and really enjoying it. But this post isn’t about that. I’m going to give it a few more weeks until I write the to-be-expected My First Weeks as a Developer post. Instead, this post is a quicky about how to setup all your dev application config files with Github so that they are never lost, always updated, and able to be pulled down onto a new machine from anywhere.

The philosophy with all my personal electronics is that everything should live somewhere other than the device. It was more work a few years ago to make that happen, but with high speed internet just about everywhere and cloud storage dirt cheap its really not that big of a deal. Right now I could drop all my devices into a river, walk into an electronics store, buy new ones, and in about 10 minutes be back up and running as if nothing happened. Its nice peace of mind to have.

Before I started my new gig, I completely wiped my laptop and installed a fresh OS. After that process I started wondering what the most efficient way was to keep all my developing application (iTerm, Atom, VIM, etc) config files backed up so that I never had to worry about losing all their respective customization. Initially, I just found the corresponding files and pulled them up to my Google Drive. It wasn’t efficient, but at least they were up in the almighty cloud.

After a few iterations of manually pusing individual config files to my Google Drive I figured that there had to be a better way. I mean, at that point I had pulled down three different repos for work and made more than a few branches and commits on each. Surely if I could pull down and push up that kind of info I could do the same for my config files. It took all of 30 seconds of searching to find the right article:

https://www.digitalocean.com/community/tutorials/how-to-use-git-to-manage-your-user-configuration-files-on-a-linux-vps

Definitely take a look at the article, but the gist of it is that you git init your entire root folder, then add all the files to .gitignore, the pull out the ones you want, the config files, then push them up to a new Github repo. Easy peezy. And, when its all done, you can rest assured that all the sweet customization you’ve done to your workflow will never be lost. Along with the above link, Ive also created a Github Gist outlining the process and highlighting which config files I backup, that can be found here: https://goo.gl/pV2Wdc

The Hustle

Oh man, it’s been awhile, longest lapse in posts I’ve had yet! Well, I have a pretty good excuse because I GOT A WEBDEV JOB! The ball started rolling shortly after the last post about being a ‘Yes Person’ and I thought it would be worth holding off on a new post because the lead I had was pretty promising and this would be a great follow-up post. I’ll give a rundown of the series of events that lead up to me receiving the job offer, not for any horn tooting purposes, but to show how my approach to school, extra-curriculars, and being a ‘Yes Person’ all lined up to get me a job before I finished the Bloc program. I’m not implying that this is the only way to go about it, but it did work for me.

The initial job posting was pretty unofficial. It was a posting for a Junior Full Stack Engineer on a jobs whiteboard at a the Denver Full Stack meetup. I hadn’t even attended this meetup yet, but it was on my radar. I had the meetup in my calendar, and was following it on Twitter. They posted a photo of the jobs whiteboard and I picked out the open Junior position pretty quick. You don’t see those very often, so I pounced on it and started putting together an email.

I started off with the questions I had about the company. It was based in NYC, so I was curious if they were looking for a remote dev or starting a shop in Denver? I also asked things like what tech stack they use and if they’ve ever brought on a Junior before? I feel like opening with questions is important. Its starting a conversation, not just asking for a job. I sent that email before the Thanksgiving holiday, so it took a bit to get some back and forth going, but pretty quickly he offered to meet with me if I had the time. This was the best case scenario, to be able to meet with a potential employer in person and not have to sell myself with emails and resumes alone. The meeting came with one caveat, by this time an offer had been made to another developer for the position, so there was a good chance that the position may not be available anymore. It was a no brainer to meet with him anyway (this goes back to being a ‘Yes Person’; only good things could come from meeting with someone in the tech industry).

The meeting went well, and the next day I was on a Google Hangout with the NYC-based CTO. At the end of that meeting we were scheduling a time to have a technical interview the next day. Three rounds of interviews in three days. I don’t know very much about that part of the industry, but I know that’s not common. I was obviously a bit nervous about the technical interview, but I was told that there would be no code challenges, only me talking about the projects I’ve been working on. Again, absolute best case scenario.

I don’t think I necessarily knocked their socks off with my projects, they are pretty boilerplate code school stuff. But where I do think I was able to shine a bit was with my personal project, which I talked about a few posts ago (http://noelworden.com/2016/09/18/bloc-week-28/). I explained that the goal of AdventureSearch was to give the user the most information with the least amount of effort. I talked about my U/I choices of a simple interface and gathering the user location with the GET request and not through the gps functionality of the browser. I also spoke about how I leaned heavily on ruby gems and APIs to make a powerful app with minimal written code. I was trying to convey that I could think like a developer outside of the school structure.

Well, it all worked. I got the job offer, accepted it, and have completed my first week of work. I had some theories about what I would have to do above and beyond Bloc to get a job, and in this case I was successful. I’m not sure if someone following in a similar path would have the same results, I’m also not sure even I would have the exact same outcome if I were to do it over again. But, in this case it worked, and for the time being that’s all that counts.

There were three particular things that all added up to get me to this point, I’ve touched on all of them at one point or another, but for the sake of thoroughness I’ll list them off again:

Pushing job postings to me
I had every source I could find pushing jobs to me. Slack channel alerts, twitter, builtincolorado, meetups, all pushing info to me to then filter through. It was a much more manageable process than digging through pages of classified postings

Networking
I cannot emphasize this enough. In a roundabout way is was my network that got me this job. And in a very direct way is was my network that helped walk me through the interview and job offer process when I had no idea what I was doing.

Personal code project
I can’t say with absolute certainty, but I am pretty confident that my personal project (of which I only wrote a total of 200 lines of original code maximum) is what got me this job. Start a personal project. It doesn’t have to be complex. Just find something you are passionate about and start tinkering.