Remote Non-Senior Developers, Part 2: What You Should Consider

Part 1 of this post was all about what companies need to consider and think about when hiring a remote developer. It's just as important for folks considering being a remote developer to think about a few critical pieces as well. Real talk time... Not everyone is cut out to be a remote worker regardless of your level of expertise. Some days are great and some are really challenging. If you're a non-senior considering remote work you need to be BRUTALLY honest with yourself because if you're not and you actually wouldn't be a great remote developer then it'll actually be you who suffers the most. So what are those things you should think about? 

1.  Are you a self-sufficient worker? As a remote worker you need to set up a schedule for yourself and get into a routine. You need to push yourself through the days where you're tired and a little checked out. And you need to be filling in the gaps. Working on an issue and stuck but no one is free to pair? If you twiddle or thumbs or go watch tv, remote work is not for you but if you say to yourself, "ok, I can't figure out this problem but it has to do with ______. I'm going to read the docs, find some blog posts, or find a conference talk to watch until someone is available to pair" then you're on the right track. 


2. Can you boldly, bravely, and shamelessly ask question? This is the most difficult part. You can't be fearful and let imposter syndrome take over because you'll never get anything done. When you're stuck, no one can see that you're stuck or maybe frustrated. You can lean over and say "hey, can you check this out real quick?" You've gotta announce it in a slack channel. And sometimes that sucks but it's important! When I began, I made it a goal to ask 100 questions a week so that I could frame asking questions as a positive thing. It wasn't something I needed to do because I didn't know anything, it was something I had to do to learn and accomplish my goals. 

And finally, what structural pieces can you put in place to help you be successful.

1. Coworkers to work with. But you're remote you say? How would this happen? Well, there are lots of other remote workers as well! I generally try to cowork at least once a week preferably with a group of ruby developers. There's no doubt in my mind that you do miss some learning when you're not in an office. You miss overhearing snippets of technical conversations or jumping into a conversation because it sounds interesting so try to creat that for yourself.


2. Regularly scheduled pairing sessions. As I got more experienced and started working on more challenging tickets, I would get stuck (as everyone does). Additionally I try to take a "challenge ticket" every week. Challenge tickets are tickets that are just above my skill level. I know they're within reach but I can't quite wrap my head around how to start them or what an effective plan of action would be. They're tickets I have to pair on. We have a pretty small team so sometimes there wasn't anyone free to help. I decided to set up scheduled pairing times. I have one hour a week with two coworkers that is in the calendar to ensure the time is blocked. The time can be used to ask some quick questions and get a few tickets out the door, work on a challenge ticket, or pair on something they are working on. And sometimes we cancel it if it's not needed but the point is that it's there, blocked off. 


3. A regular way to evaluate yourself. I try to do weekly personal retros which is something I noticed a coworker doing. He just reviews 3 things; liked, learned, lacked. I keep these documented in Evernote and they're a great way to looks back and see all the things that have been going on. 

I hope you've enjoyed this short series and it's given you some good information to consider. Again, here are the slides from the original talk.

Remote Non-Senior Developers, Part 1: What Your Company Should Look For

When I tell developers I meet at conferences or elsewhere that I transitioned from a career in nonprofit management to becoming a software developer I usually get smiles. And then, when I add that since becoming a Dev I've only worked remotely, the smile changes to skepticism. I understand hat skepticism. People have views of what will help a junior Dev be successful, some companies have had bad experiences with non-senior remote developers, and there are lots more stories out there. But as remote work and distributed teams become more prevalent in the field, companies shouldn't feel like they can't hire, train, grow, and mentor less experienced developers as a result. Last month at the United Silver Spring Ruby meet up, I spoke about being a non-senior remote developer (note: non-senior does not explicitly mean junior although I was a remote junior developer). Folks of all experience levels were interested to hear what I had to say because many can't envision what a non-senior remote teammate might look like. Here's s little bit about my experience, what I think makes a successful remote non-senior Dev. Part 1 will cover what a company should look for when considering hiring someone and then part 2 (coming out next week) will go over what a less experienced developer should think critically about before deciding to go remote. 

I won’t lie to you. It does take a special type of person to be a remote worker regardless of their level. This is why some companies decide not to have remote employees at all. And it is a little riskier to hire a remote worker with less experience because do can have a higher risk of not being successful if they are not great (I say great because they do need to be better than good) at the things that make remote workers of any level good remote workers. Here are some characteristics you want to look for when hiring for a remote non-senior developer. 

1. Someone who takes initiative. There are going to be bumps and issues and as a non-senior dev. In order for the employee to learn and grow as much as they possibly can, they’re going to need to make some decisions, put improvements in place, and get the rest of the team on board with what they need. Make sure that as a company, you look for someone who has done this in the past or has the potential to do this.


2. Good communication skills. This is necessary for any developer but especially when remote. How can they articulate their thoughts, the research they've done, a problem they're facing, etc. 


3. Learn about their past. Are they a new professional or just new to development? When I became a developer I had about 7 years of prior professional experience and had already been working from home for 2 years in different industries successfully. I might not be a senior developer technically, but I’ve got all the other skills necessary to be successful.


4. Make sure the person understands what remote work is all about. Ask them about the best and worst parts of working remotely. I don't like working remotely because I can work in my pjs (which I don't do, for the record). I like it because I have a schedule, more work time without a commute, and a quiet distraction-free workspace. I also have opinions about the parts of working remotely I don't like. I’m aware of all the good parts and bad parts of remote work and I know what i’m getting into when I accept a remote position. You want to ensure you’re hiring someone who also understands these aspects or has at least thought through them.


5. And maybe most importantly, someone who isn't afraid to say to a slack channel that they are stuck, frustrated, or need help. Without this personality trait, the individual won't be successful because asking questions is probably the most important skill a developer can have.

I find the best way to learn about all of the characteristics above is to ask behavioral interview questions. Instead of the interview where you decide if you'd like to chill with the candidate, ask about scenarios. For example, tell me about when you were stuck on a problem, what did you do? What if no one was available to help you? What was a time you had an issue with a teammate, how did you address it and how was it solved (if at all)? 

Now finding the right candidate is half the battle, but you also want to make sure they’re set up for success. A person isn't an island. They can only exist and thrive if they're put in an atmosphere to do so. Companies sometimes feel they don't have enough resources or structures in place to support a non-senior person but if you have the right candidate, you actually just need a few small things to ensure success.

1. A good manager who has had some experience/training. This person will be vital for support and working through issues that may come up on the team. They should be an ally and be able to recognize when issues are actually opportunities to help the team as a whole grow and learn more about things like diversity, empathy, mentorship and more. 


2. A kind, caring team. It is easy as a non-senior Dev to be scared of asking questions but if the team they are put on is supportive, thoughtful, positive, and constructive it will really go a long way in creating an environment with lots of psychological safety where it is easy to learn. 


3. A system of regular check-ins. It's great if you have a good manager but that manager (or even a tech lead) need to be regularly checking in with this person, especially at the beginning. I think 1-1s are a vital part of a healthy team culture regardless of experience level or if folks are remote, but it’s even more important when you don’t see each other every day in person.


4. A partially remote team. Even if your current team of remotes are only senior, having a partially remote team means you understand some of the baseline difficulties of remote work regardless of level. It also hopefully means you have some processes in place to allow for easy, async communication and remote pairing tools that are widely used and understood. I'm not saying it won't work if your first remote hire is non-senior but it's definitely going to be a steeper mountain to climb. 

That's it. Really not as involved as you thought it'd be, is it?

Here are the original slides from the talk I gave: https://speakerdeck.com/asheren/remote-non-senior-developers

Stay tuned for Part 2 next week.

And if you’re interested in hiring a remote software developer or want to speak more about the points made here, get in touch!

Technical Interviews - A Revised Process

I recently attended a handful of conferences, some of which I’ve spoken at. A topic that is frequently discussed based on the research I’ve been doing in regard to the the benefits and challenges of being a parent and developer is technical job interviews. More specifically, people focus on the questions of what do companies ask? What do they expect?  And how well do these processes actually asses an applicant’s ability to do the job? One of the things I’ve found in my research is that parents have difficulty showing what they are capable of because they have less time to contribute to open source and side projects. The proliferation of take home code challenges as a response to the backlash against white boarding in interviews has solved some problems but created others. Giving a large chuck of focused time and attention outside of work hours to accomplish a code challenge is often difficult for parents, caregivers, or people who have significant outside-of-work responsibilities. As a result, I’ve done a lot of thinking and discussing about what an effective interview process might be, especially for developers with 2-3 years of experience.

I started by thinking about what I do at work. I refactor (a lot). I research (a lot). I learn (a lot). And I work through understanding code that other people wrote (a lot). What I don’t do a lot is code from a blank page. Companies always say that they just want to hire people they know can solve problems and can learn. From what I’ve heard, most technical challenges don’t really accomplish this. I’m not saying the methodology below is perfect but I think it comes closer to a solution where unconscious biases and the dependence on a significant amount of free time are less of a factor while still showing technical capabilities.

Here is what I suggest an interview process contain. Ideally this would be broken up into a short (1.5-2 hours or less) take home portion and an in-person or virtual conversation in lieu of a pairing session and/or take home code project. I think I see the first three items as ideal for a take-home portion and the last two as either take home portions with additional discussion or fodder for some fantastic technical conversations.

1. Breaking apart a problem or feature. 

One skill I find extraordinarily useful in my day-to-day experience is to be able to break apart a problem or feature. I’m often looking at issues and asking additional questions based on my knowledge of the codebase, and making sure that something doesn’t strike me as problematic within the context of a solution. An example to use in a challenge could be technical, but that may be difficult without a lot of domain knowledge. Keep in mind that an interviewer can also tell someone’s prowess for problem-solving by giving a candidate a scenario that is completely unrelated to tech. How do they reason through it? What pieces does someone highlight? What additional questions would they want to ask? If it seems applicable, what might a diagram of the solution look like? All of these reasoning come into play really often, especially for developers who have 2-3 years of experience, oftentimes a group that is looking to grow in this area and understand what additional questions and considerations more senior developers ask when solving a similar problem.

2. Research a topic, library, or other implementation strategy. 

This is a great one because we look at this stuff all day long. Developers hear about new tools at a meet up and think about if it’s applicable or if it could help their company in any way. During the day, developers are asked about a feature or functionality and want to see what’s out there and what might be worth implementing or do you want to roll your own? Having to do this research, including listing potential pros and cons, commenting not only on the result but how a candidate came to that conclusion is really powerful. A candidate could include what they read, where they looked, how they got started and more! They could also not include these things which would also be extremely telling in an interview. Ultimately, the “right” answer might depend on project context but this would tell the interviewer a lot about what they might do on the job and how much confidence you could have in something they recommended. Finally, one of the things I love about this question is that it is scalable to every level since you expect junior developers to evaluate possible items differently than a senior developer might.

3. Provide an explanation for something. 

Oftentimes at work, developers are helping to teach each other and learn from one another. I think great code reviews sometimes include a person commenting “what’s this?” or “I haven’t seen this design pattern before. Can you explain it a little further or provide some learning resources?” Most companies want to make sure they’re hiring a team player, someone who isn’t just writing code but contributing to an overall positive culture for a team. For this, I’d suggest a simple term (not some complex process that has lots of different polarizing opinions surrounding it), possibly something related to the company’s codebase that they’ve found new people coming in don’t have lots of experience with or that they need to be taught. Make sure to say it’s okay to google and use resources if a candidate needs to (I assume that a good answer to this question will likely site at least one or two different resources). As an additional consideration, I’ve talked about the importance of actually interviewing for mentorship if that’s something your company values. In this case, if mentorship and team learning is a company or team value, a company interviewing might ask for two different explanations… one that someone would provide to peers at a similar experience level and one that would be a more appropriate explanation to a junior or brand new developer. This is also a great way to get other people on the team involved in the interview process. Show a couple of teammates at these levels the explanations (without the candidates name, if possible) to see if they understand them.

4. Refactoring

We all know that this is what most developers do every day. We refactor. We solve bugs, we tweak features, and we refactor. I LOVE refactoring and I like to think most other developers do as well so provide that as a technical challenge, or even something to pair on. Provide either a method or a file with some code you, as an interviewer, would consider dirty, smelly, ugly, slightly confusing, or whatever other adjective you want to use for it and have the candidate refactor it. You can see their thought process when approaching code, you can probably have a really amazing conversation about this thought process, methodologies used to refactor, different ways of refactoring, and more. If you’re providing a file or more than one example, let the interviewee pick where to start. Again, while this can be a portion of a take home assignment, I think both interviewer and interviewee will get more out of the exercise if they’re doing it as a part of a conversation and it also helps the company interviewing be mindful of outside time spent on challenges.

5. Tell me what this file is doing.

Finally, the last item on this list is a blanket- what is this file doing? How many companies have big, complex monolith applications at this point? And how many times do you spend time during your work day working through code, figuring out what’s going on? This is another perfect example of something that can spark a great conversation, show an interviewer how a candidate goes about figuring these problems out (there are a variety of ways to do this) and this skill likely directly affects a person’s ability to accomplish the job successfully. Another super scalable activity because you can show files of different complexity levels to different candidates based on their number of years of experience.

Again, I’ve written these suggestions as good options for mid-level developer interviews, but, as I mentioned specifically in a few points, they could be altered slightly to be applicable for interviewing at any level. What do you think? If you interview, do you employ any of these strategies? If you currently depend on long (I define long as anything over 3 hours, even for a junior level developer) take home challenges, would these alternative “assignments” help you asses a developer more effectively when looking at their everyday responsibilities?

And if you do interview like this (or would love to test it out), I'd love to talk because I'm looking for my next great career opportunity. Get in touch.

Write/Speak/Code: the conference highlights

Last week I attended Write/Speak/Code for the first time. Now, I’ve attended a good amount of conferences. I find most of them pretty interesting, I always learn something, but I was blown away at how much I was able to take home from this conference. From the pedagogical approaches to the actual content to the awesome women I met, this is a conference to keep your eyes open for in the future.

I took a grand total of 20 PAGES OF NOTES, so this is going to be my attempt to recap what went on. I want to start by saying that I’ve never been to an all-female conference and honestly wasn’t sure what to expect. I have a lot of male friends and so it wasn’t really until I entered this industry that my “otherness” of being a women became a thing. I have to say that it was actually really awesome. It is so rare that you’re in an entire room with smart, technical women respecting one another. I think, as a result, this conference had a very different vibe and the interactions I had with everyone were just lovely.

The sessions were quite interesting. I decided to participate in the alumna track since I’ve already done a fair bit of conference speaking. The alumna track was focused on leadership development, self care, and personal realizations that can be put to use in personal and work settings.  Some of the highlights included K Wu’s session on ask vs. guess culture. I’d never heard these terms before. She did a great job describing both cultures and also giving tips for interacting with colleagues, managers, and direct reports who might come from the opposite culture as you. From there, we looked at leadership and conflict styles looking at the Hippocrates four temperaments as behavior preferences and different conflict styles and how we interact with our team as a collection of individuals who might have very similar or very different conflict styles. Examining our conflicts styles really made me think a lot about processes in tech and how some processes might give an advantage or disadvantage to folks with a specific conflict style.

One really interesting point was that over and over again, there was a clarification made in sessions to think about your responses, personality, and style in the context of how you are at WORK. This was interesting to me because women often are expected to act differently at work than in their personal lives and often many of us feel like we can’t bring our whole selves to work. I would be curious if men also feel this way and if there would have needed to be such an emphasis on “are we talking about our overall selves or our work selves in this scenario?”

There were a couple of interesting talks that had really tangible, actionable steps. For example, Annyce’s talk on creating videos and Neha’s talk on branding yourself were two of the best I’ve seen in those areas and really provided great, easy steps anyone could take and work towards in a thoughtful productive way.

There were also some tough sessions… one about self-care which really magnified the pressure many of us feel in the industry and put forth some coping solutions and some very real- talk about whistleblowing, being taken seriously in the industry, and how to give and receive advice.

There was a FASCINATING talk by Liz on algorithmic accountability and algorithm biases which taught me about how the ways in which a human develops an algorithm, especially a learning algorithm. can introduce biases. That’s definitely a topic I want to learn more about and found the examples incredibly interesting.

One major accomplishment for me was contributing to open source. I helped build a gem years ago to open source but have basically been scared of OSS ever since. I don’t have a ton of time and Ive heard some really scary stories about getting involved in projects. As part of write/speak/code though you actually get time to work on OSS. This is a big deal for me because I basically have no unspoken for time in my life. I looked over a bunch of projects and ended up working on the callback women rails app (a twitter handle that I rely on to find out about conferences and LOVE). It was a great experience and by the end of the day, I had a PR that was merged in. I’m hoping to keep up with the community and the project and contribute more in the future.

Finally, the last day was self-care day. It was great. There were really interesting talks about burnout, personal journeys, wellness, and salary negotiations. Overall, the conference was fantastic. You could tell the organizers put an incredible amount of thought and effort into the event. The speakers presenting thoughtful, intelligent, actionable presentations. The fellow participants were engaged, respectful, and kind. And, of course, the swag bag was awesome.

For a full least of speakers, the schedule and the slides, check out: https://2016.writespeakcode.com/pages/schedule

Pull Requests - It's all about the details

Let’s talk about pull requests. Most people I know operate through a PR system at work. The basic process goes like this:

1. Write code
2. Push up the branch and create a pull request
3. Put a few details in the description about what changes were made
4. Wait for comments
5. Improve code based on comments if needed
6. Ship it

The description portion of the Pull Request can be incredibly important though in making sure your code is reviewed effectively and getting better comments. This is something I’ve been focusing on personally recently and that we’ve been focusing on more as a team. Even though putting more thought and effort into crafting a pull request takes a little more time, it helps us QA much more effectively and allows us to have better context when reviewing each other’s code.

So here are some quick tips to crafting effective PRs.

First, start with user stories. This is something I only recently started doing but it basically acts as a summary of what is going on in english. As a ___, when I ___, I want to see ___.

Example:

As a developer,

When I go to the github repo’s readme

I want to see clear instructions to get set up

As a developer,

When I go to the github repo’s readme

I want the setup instructions to work

Second, what happened bullet points. This is just an overview of the biggest changes. It should potentially re-iterate some of your git commit history but not all of it. If you’re still working on creating a clear git commit history with small, specific commits, this section might be a little bigger. 

Third, screen shots. To take a screenshot of a specific portion of a screen, on a mac, you use SHIFT + CMD + 4. It’s often helpful to annotate that screenshot by placing arrows or text onto the image. An easy way to do this is to open the screenshot, open the toolbox, and place the arrow shape into the image and then save it. You can see where all these things are below.

Open Toolbox

Select Shape

Select arrow option

Fourth, record video or screencast. I’m not great at recording a demo video but screencasts can be really helpful. RecordIt was recommended to me and it’s been great so far. It’s really simple to understand, use, and post where necessary. 

Fifth, Add QA instructions as a checklist. At my company, developers do a pretty in depth QA of each other’s issues in addition to code review. Creating a QA checklist also helps you as a developer think through possible edge cases or flag critical paths that need a more in depth look. This QA checklist should be specific, include links and then what should be seen. It’s often easiest to make this as a checklist so that whoever is QA’ing can just check off the items as the QA. The example below is VERY simple, but hopefully it is easy to imagine what instructions for a more complex feature or bug fix might look like.

Example:

Go to www.allisonsherenmcmillan.blogspot.com and sign in as an admin

Go to the consulting tab

[ ] You should see bold headlines

Sign out of the admin role

Go to the consulting tab

[ ] You should still see the bold headlines

Sixth, add labels in Github. This is more in reference to the code review processSome of the labels we use include things like “Ready for improvement”, “Don’t merge or review”, etc. Sometimes if I don’t have time to complete the description for a PR, I’ll just temporarily slap a “Don’t merge or review” label on there until I can complete it.

Finally, open your PR and get excited for some great feedback. By spending more time on your PR description, you'll get better feedback and you'll be able to ship more confidently.

Mentorship: Wants vs. Needs

Mentors generally have the best of intentions. They want to help, they want to teach, they want to give back to the community oftentimes because they received assistance and mentorship to reach the level they are at. But sometimes, what a mentee needs doesn’t quite match up with what a mentor wants to give. In conversations about mentorship, I feel this piece isn’t frequently addressed. There are plenty of conversations about mentorship and plenty of common topics that are discussed. I always hear about how to find a mentor or mentee, how to have a successful relationship, and i’ve written/spoken about these subjects in the past here and here.

One of the most important aspects to consider in both personal and professional mentorship is do the learning styles of the two people match up? I have different mentors for different subjects. I have some people I talk to about being a woman in tech or about work/life balance, etc. and I have other mentors that meet with me more frequently to cover technical skills. For me, I consider these technical mentors to be both personal people I meet with and more experienced developers I work with every day. Thinking about learning styles is important for both. People learn and teach differently. When establishing a relationship with a personal mentor, make sure you’re working with someone who understands how you think and make sure you understand how they explain things or walk through code with you.

Companies with a focus on team health and personal growth have good intentions and look for senior developers that have a vested interest in mentoring in order to grow their less experienced developers. Less experienced developers look for teams and team members they can learn from. When looking for opportunities, talking to senior developers about how they mentor is incredibly important but even better is when you can pair or ask a technical question to see how they explain a concept and whether they use language and an approach you can understand. One of the most important questions to ask when pairing or interviewing at a company is “can you repeat that?” or “can you explain that in a different way?” Those questions reveal mountains of information about how they might interact with an individual on a regular basis, and how much one can expect to learn from a person or team while working there.

Additionally, for companies who feel mentorship is an important team value, consider including your least experienced developers in interviews, and not just in the culture-fit interview portion. Involve them in pairing session or in one of the technical interviews. It will show candidates that you are serious about mentorship and the growth of the whole team, and will ensure that you hire someone that your less experienced developers learn from effectively. While this likely isn’t the case for everything related to hiring, when it comes to mentorship on a team, It’s not about what the senior developer or company wants, it’s about what the less experienced developers need.

A learn/teach mismatch can be extremely frustrating and emotionally taxing. A mentor might get frustrated explaining the same concept over and over again, while a mentee (especially one who’s new to the field) might think they don’t belong in tech or just can’t understand. This same experience can be true in the context of work. A more senior developer might think the members of their team aren’t growing or aren’t learning. They may get frustrated if they’re re-explaining concepts. Less experienced developers feel stunted in their growth, feel bad about asking the same question more than once, and feel themselves like they aren’t meeting their potential. The broad implications of this are, at best, general dissatisfaction and, at worst, a lack of desire to play the role of either mentor or mentee in the future.

Parenting and Developing

A few months ago, I was learning how to balance being a new-ish software developer and a new mom. I reached out to a few mothers in the community and was amazed at what I heard. Every mom talked about facing similar challenges which got me thinking... do all parents feel this way? Are we all feeling isolated about the same issues?

As a result, I put together a survey and tweeted it out to parents (mothers and fathers) who are also developers. The results have been fascinating and very telling of issues and trends in this area.

The great people at Ruby on Ales allowed me to speak about the survey and it's findings this past weekend (video will be posted once it's available).

As I mentioned in the talk, this research will be ongoing. The more data I can collect, the better! If you are a developer and a parent, or know someone who is, Please fill out this survey if you have a chance. It's super short and we're all busy parents so don't worry about complete sentences or well-thought out responses... just a simple stream of consciousness is more than okay with me!

Thank you in advance!!! And ping me if you've got any questions.

Survey link: https://allisonmcmillan.typeform.com/to/BbVmbH

Searching through logs

Recently, I needed to check out which endpoints in a specific version of our api were being hit/ if they were being hit at all. This involves searching through the paper trail logs, which was an interesting process so I thought I’d write about it.

First, I want to say, there is a better path than the one I took. It wasn’t until after I did all this log downloading and searching that I discovered the paper trail CLI. I haven’t had a chance to take a deep dive into it yet, but I assume using it is better than downloading 30 days of log files and than combining them into 1 log file.

Which is what I did first. I had to look at 30 days worth of logs, so I went to the paper trail heroku add-on and downloaded all 30 days worth of logs. Then I used cat *.tsv >merged.tsv to put all of the 30 files into 1 file. After that, I checked which endpoints I needed to look at by just looking at the routes file. Luckily, there are a pretty finite number of endpoints for the specific version I was looking at. I think, if I was dealing with significantly more endpoints, i’d need to figure out a better systems for ensuring that I’ve checked all the endpoints.

Then, for the simple endpoints (ie- /livestreams or /livestreams.json for the index endpoint or /livestreams/ for the show endpoints) I just ran a simple grep -c command which greps for that path and then counts it. For example cat FILE_PATH | grep -c /v1/livestreams.json.

When I got to a slightly more complex endpoint, for example, one that had a path like /v1/livestreams/something_unique_here/watched I couldn’t just grep for the endpoint, I needed to use a grep compatible regex to find the number of results that had “watched” at the end. I did this by searching cat FiLE_PATH | grep -c ‘/watched\b’ which looks only for the last bit of the url.

And that’s it. Pretty simple but I hadn’t handled searching through large log files or any sort of complex grepping before.

Arlington Ruby's Ruby Retrosession 2016

Arlington Ruby RetroSession… Retro ruby for short was this past weekend. I’ve been to retro ruby the past few years, with the exception of last year when I was in labor. It was so fantastic to be back at a community event. I love the unconf idea and feel like I always get a lot out of the conversations so it was great to be able to participate.

The sessions were as follows:

• Rspec
• Advanced Newbie (including mentorship, cs without a cs degree, importer syndrome, and ways to step up as an advanced newbie)
• Freelancing
• Everything APIs
• Functional web stacks
• productivity tools hack
• infrastructure as code

and

• making a safe space.

Since this was a 2-track conference, I only went to half of these. There was also ice cream, a retro at the end, and lightning talks.

In addition there was a separate newbie track. Notes and resources gathered from that track are here: https://gist.github.com/kalimar/1a23222b59fd0208f88d

So first I went to the advanced newbie session. We started by talking about mentorship and setting up both formal and informal mentorship opportunities. We never really got into ways to step up, but one CS subject that was mentioned as important for non-cs folks to know was Cryptography and a specific place to do this is through CryptoPals. Another suggestion related to learning cs fundamentals was by watching university courses. A list of these are available through the Github repo awesome courses.

Next I went to everything APIs. The conversation kicked off by asking what do you want the JSON return to look like and how that is a major decision what crafting an API… looking at the response types. I took some notes about things related to APIs that I didn’t know like how api versioning relates to 2 things, the schema and endpoints, where, I think, only the endpoint is usually considered.

There was a great discussion about good practices for external APIs which includes different strategies of putting docs into the actual api. And another discussion about how people like to create APIs… both grape and active model serializers were mentioned.

Some random tools mentioned and things to look up were: Swagger yard was also mentioned as a way to auto-generate documentation. Pact which writes tests in web mock style and then generates a JSON fixture file which gets shared with the micro service where the JSON is generating the response. It then uses a rake task, I think, to execute the tests. This goes along with pact broker which is an intermediate layer. Graphql is really strict about endpoints but generates great docs and is just 1 endpoint… you tell it what object or data structure you want and then it just gives you back only that stuff. Statsd helps you figure out what is still being used which helps with what endpoints are still needed or can be deprecated. I/O docs generates query explorers.

Finally, for API design, someone mentioned tasty pie which is big in the python community and would be great if something similar existed for the ruby community and HATEOAS which is a response call that tells you everything else you can do with your API.

After I bounced between productivity hacks and functional web stacks but spent most of my time in productivity hacks. There’s always great stuff out there. A full-ish list of what was discussed can be found in the hackpad.

The last session I attended was about infrastructure as code. This was really interesting to me because, I feel like one of the next steps for me is to learn more about devops and how deployments, etc. actually work, without the magic of Heroku. The session started out talking about what we think about when we think about infrastructure as code… things like Docker, Ansible, version control, Puppet, and Chef. It is humans changing code and code changing computers. The reason we do this is so that the infrastructure code is repeatable and can be replicated in the future. There are lots of challenges to infrastructure as code but the main thing mentioned was that if you don’t stay up to date on it, then there can be lots of security holes. Additionally, if you want to start learning about thing like Docker, etc. the barrier is pretty high. The tutorials are fairly difficult and since it’s all changing so quickly, lots of information, tutorials, and documentation is out of date.

Some tools mentioned: flynn.io which is a platform as a service. There’s an interface for Docker, push heroku-like commands, and buildpacks. Open shift by Red Hat. Teraform which is a command line utility that can go across services and configure them (i’m not sure this is the best explanation but this is at least a piece of what it does). Otto by Hashicorp which is an opinionated system which seems like it might be a good option for an off-the-shelf solution.

Some good resources to get started include AWS in plain english and twelve factor app which talks a lot about the decisions that need to be made and the things you should be thinking about when you’re looking at infrastructure stuff. Finally, it was suggested that to get started learning about this, to just create a VM on your machine and play around using something like vagrant. And remember, devops is stressful so find a mentor, find a support group, and practice #hugops often.

I didn’t take as many notes on the lightning talks. Someone gave a great talk about note-taking (which I obviously love doing) and suggested to take notes in markdown and to create a notes folder in every repo (or just in your projects folder) and add it to your .gitignore. I actually love this suggestion because recently, I find i’ve got over 10 notebooks filled with notes and without having the time to add color coded tabs to these notebooks, it’s getting more difficult to find things I KNOW I learned so I’ve been debating starting to take these notes in a more searchable fashion (but don’t really want to just have a gazillion notes in evernote) so this sounds like a great suggestion. Also, taking the notes in markdown would force me to become better at it which I think would be super beneficial in general. The other thing I wrote down was a github repo called Dug which provides a more transparent view into open source software and allows you to organize github notifications better than you can with just gmail filters. Also, there were a few talks that related to sleep but I didn’t take notes on any of those because I have an 11 month old. One day I’ll sleep again.

That’s all! Retro Ruby was awesome. It was so much fun to see people again, learn stuff, and have great conversations. Here's the Hackpad with notes from the whole conference.
Plus the t-shirts glow in the dark!!!!

Rails Runner to the Rescue

Yes! I finally have something good and technical that I can blog about!!

This week, I was working on one of our smaller applications. At GA, we send out surveys to students in order to get feedback on courses and programs and I was looking to add a new survey template. After becoming familiar with the codebase, I discovered that new surveys have previously been added by creating a bin file and then running that script since new surveys require tons of validations and therefore it is too complex to just add a survey via the console. And so that’s what I set off to do. Now, the actual creation of the survey wasn’t so difficult. The app is very modular and pretty clean and easy to understand. I finished up that task (as well as updated the readme to find this sort of information a bit easier) and then I said, ok great, well, now I have to deploy it to our staging environment. And so I sat for a moment and thought, well, how do I run a bin script only in staging. Enter rails runner. Rails Runner is an easy way to execute 1 file in an environment of your choosing. You can find a tiny bit more about rails runner in the rails docs here.

So based on this post I ran what I thought was the correct command…

heroku run bundle exec rails runner ./bin/file_name -r staging

and I got an error

/app/vendor/bundle/ruby/2.2.0/gems/railties-4.2.2/lib/rails/commands/runner.rb:62:in `eval': /app/vendor/bundle/ruby/2.2.0/gems/railties-4.2.2/lib/rails/commands/runner.rb:62: syntax error, unexpected '.' (SyntaxError)
./bin/file-name

WHAT?!

okay well, maybe I don’t need that ‘.’ in front of /bin and that is the issue. and so I ran

heroku run bundle exec rails runner bin/file_name -r staging

and got another error

/app/vendor/bundle/ruby/2.2.0/gems/railties-4.2.2/lib/rails/commands/runner.rb:62:in `': undefined local variable or method `bin' for main:Object (NameError)

well, now I was confused. I obviously needed the ‘.’ there and the first error was pointing to a syntax error… was there a typo in my code? I looked (and had a colleague look as well) and couldn’t find anything. I searched and searched (there really isn’t much about rails runner, which is why I decided to write this blog post!). okay, a little while passed and so I said to myself “it’s time to pair!”

I grabbed a colleague who suggested to see if we could even just get into the shell and then run the command from there, so I entered heroku run bash. Success! I’m in. Then we just did an ‘ls’ to make sure we were in the right place. Yup, right place. So then we did ls bin and the file wasn’t in the bin folder! Here’s where I had my moment… I thought that I needed to run the bin scripts BEFORE deploying the PR to staging so that the files would exist and the surveys would appear in our staging environment. HOWEVER, rails runner was looking into the staging code base in order to find the files but of course, they weren’t there because I hadn’t merged the branch in.

Merged the branch in, and then ran

heroku run bundle exec rails runner ./bin/file_name -r staging

and the problem was solved. Just a simple order of operations issue.

On what the heck to blog about

A few months ago, I made a commitment to start blogging again at least once per month. I keep this reminder on my to-do list and try to keep a running list of topics that I can write on. This WAS great when I had a lot of hours to put into extra learning, extra reading, and all those other great things you do when you’ve got more time. I blogged about side projects, issues I faced, interesting blog posts I’d read that week and a whole bunch of other things that I thought were pretty interesting.

Now that I have a small kiddo who periodically requires some attention (and by periodically I mean I looked away for like 5 seconds the other day to finish something and he totally face-planted), even more of my learning is done on the job. What I do at work is really interesting. The app is fairly complicated and so I new and different things every week. From feature builds to bug fixes to investigations, every day is varied. However, with all this learning i’m doing at work, and all the notes I take in my notebook so I can study and remember everything in the future, it’s hard to blog about these things. Why? Because there’s so much contextual knowledge around the problem and the solution. Aside from the fact that a lot of things are proprietary, you need to know a lot about the application, data structure, and history of development in order to understand why we need to solve some of the problems that we do. Furthermore, oftentimes what I am doing is a small piece of a larger puzzle since my tasks are often more digestible than whole large-scale tasks and to blog about this small piece would require a significant understanding of the larger component I’m working on. Finally, I still find it difficult to figure out which solutions are only applicable to that specific problem I’m solving and which are applicable to many different situations.

So, what do you blog about when you’re not working on a side project? How do you come up with ideas? I wish I could blog more often but I’m currently feeling like it just takes so long to figure out what to talk about!