Tag Archives: Pair Programming

4 Tips to Find a Programming Job

Programming Job I often get asked by programmers and aspiring programmers if I know of any good job opportunities currently available. I always offer to keep my ears open for anything and am happy to do what I can to help.

To non-developers, they only hear about the large paydays at Google, Facebook, etc. that recent college grads snag and incorrectly assume that programming jobs must fall into the lap of every programmer. That’s just not the case.

For anyone looking for work, it’s always smart to work your extended professional network to find jobs, and that’s true of programmers. I typically see that many roles are not filled through online job postings nor the traditional application & interview process. Instead, many roles are filled through networking and 3rd party services (recruiters).

To take advantage of these non-traditional job channels, developers can do the following:

Continue reading

help wanted

How I Landed a Job Offer After 18 Weeks Learning to Code

tl;dr:
127 days of intensive self-study + pair programming = Programmer Job Offer.

Note: In September 2012, I set out full time to learn to code. This article is the culmination of my experience, which resulted in a job offer in January 2013. 

My background is in working with amazing startups and technology companies focusing on sales and marketing. But, I wanted to do more, to build and to be at the core of building a product. On September 10, 2012 I began an adventure, a mission to teach myself to code.

Before I started my journey, I considered myself a very computer savvy, non-technical person; I understood the basics of the web, front-end design, and had run through a few Codecademy tutorials. But, I couldn’t code up a web page from scratch, had never interacted with a database, nor did I fully grasped the web stack.

Why Learning to Code Full Time?

Why did I decide to drop everything and learn to code full time? Learning to code part-time, in my free time, wasn’t sufficient for where I wanted to take my skills and understanding. I didn’t gain the breadth of knowledge or tool set I needed to do anything meaningful, while learning to code at night and on the weekends.

Also, the timeline didn’t make sense to me. Patience is not one of my virtues. To push myself above a novice programmer, I was looking at grinding away slowly in my spare time. I’m results driven and need to see a more immediate impact to keep me motivated.

Going full time removed time and work hurdles from my learning to code experience. I was fortunate to have built a business to a place where I had a financial cushion.

While it was successful, I was running full steam and exhausting myself. As a result, I either needed to expanded the business (hire more people) or refocus the strategy. After carefully analyzing the opportunity, I wasn’t attracted longterm to a B2B services business.

So I took the money and invested it in myself, paying myself a salary for three months while I dedicated 100% time to learning to program.

My Learning to Code Plan

I crafted my own plan to learn to code, with lots of help and insight from others. I learn by doing.

Therefore, I utilized a project based approach to learn to code. The first seven weeks I spent reading and completing various online tutorials. In week 8, I started working on a web app project of my own. This important step was to force me into more critical thinking.

I should have started writing my own code earlier. Starting on my first project was a rush. This euphoria was quickly followed by the realization of how lost I was.

But these mini-panic moments were actually helpful. Hitting a moment when I don’t know how to move the app forward, was actually learning opportunities (disguised as error messages) literally popping up on my screen.

This is as a good time as any to emphasize how much I relied on other people to learn. I was very fortunate to meet amazing developers who gave up time to help me out. Discussing code, pair programming, and line-by-line code reviews were the single most important steps in my entire process.

Big props to my mentor, Joe Goldberg, who guided me throughout the entire process.

Entering the Job Market

Heading into the 12th week, I felt my best opportunity for growth would require me to work full-time as a developer. My biggest strides occurred working alongside other developers.

Finding a suitable job opportunity was the most difficult aspect of this experience. I applied to entry-level jobs listed on job boards. I used my network extensively; I spoke to developer friends, folks from meetup groups, recruiters, and I responded to 63 Hacker News job listings. Companies in which I was interested simply didn’t have the resources or desire to train me. I was turned down many times.

As weeks passed, I was beginning to lose hope. I contacted Originate in Los Angeles, and they too didn’t have a place for me. I reached out directly on LinkedIn to Rob Mallery, an executive at Originate.

We jumped on a 20 minute call and he referred me to the recruiter who would ultimately find me the job offer. She knew of a few companies looking for junior developers. One comapny, a web development agency with 12 engineers, had an opening that in particular grabbed my attention. I was very under qualified as compared to the required skills, but the recruiter encouraged me to apply anyway.

The Interview

Based on my resume, I was invited in to interview. I spent the 24 hours leading up to the meeting prepping for questions.

Funny side story: When I arrived, there was a buzzer to enter the office space. However, when I hit it, there was no sound nor response. I knocked and hit the buzzer several more times without any response. I could see lights on inside and started to panic.
Wait. Was this my first test? I had read harrowing “Google-Amazon-style” interview tests that potential engineering hires underwent. My mind raced. Was I being tested right out of the gate?
Well, no it turns out the buzzer was just broken and another employee happened to appear and let me in.

To minimize this already growing post, I’ll cut short details regarding the interview process. If you’d like more specifics about the interview process, let me know in the comments.

Job Offer Result

I spoke to the recruiter that same afternoon, told her I thought it went well, and was told I would either way soon. The next morning she sent me email saying I was offered a junior developer role with a strong base salary, 401K match, 17 vacation days, and medical/dental/vision benefits.

Conclusion

So I’m a Junior Developer Engineer now, right? Well, the story isn’t that simple. After much contemplating, discussion with family, friends, and trusted mentors, and a serendipitous set of circumstances, I ultimately turned down the job offer. I’ll save my reasons for that decision for my next post.

bridge support

Learning to Program Supporters

“It Takes A Village to Raise a Programmer” – I just made that up for this post.

So yes I did fabricate this quote for my own purposes. But it seems to fit my situation well, as I truly have been the benefactor of tremendous support and efforts of many. And as those of us in the US settle into our annual time of thanks, I feel incredibly grateful to everyone who has shown me support.

Heading down this path to learn to program required a strong leap of faith, and I don’t regret it for one second. That’s not to say it’s been all positive; in between learning and building, there have been times of stress and frustration.

But the support of everyone from family to complete strangers has been overwhelming. It’s great to know there are people pulling for my success.

Tweet of Support

I’ve placed the following tweet on this site from the beginning. An amazing number of people, many strangers, have sent this tweet out to support me.

“I support @andrewkkirk on his journey to go from total noob to programmer in 18 weeks.” < Tweet This Message >

I send a big thank you to all of you that have taken time to support in one way or another. Theses gestures mean more to me than you could imagine.

The Importance of Sharing

Once I made the commitment to learning to program fulltime, I knew it would also be important to write throughout my entire process. My hope is that others will benefit through documenting my experiences, and even avoid certain pitfalls by avoiding my mistakes.

An additional result, which I didn’t anticipate, is that I’ve reconnected with people who find out about my project from social media. For example, I recently received this note from a high school soccer coach I hadn’t spoke to in several years.

I just read most of your blogs on your page about learning to program. I wanted to let you know I am proud of you for taking this leap. Good luck and I know you have the determination and commitment to get it done. I look forward to hearing about your progress. Take care.

Isn’t the internet incredible? Of course, if I hadn’t written about my process and widely shared it, I wouldn’t have had this benefit.

“On-Call” Support Team

Finally, I’ve add several people take time out of their busy schedules to support me by meeting up to pair program with me, discussing code on skype, and answering questions when I inevitably break something. These folks have gone above and beyond, all in the name of helping a fellow developer.

Remember to be thankful not just for those family and friends close to you, but also to those people that make a subtle impact on us. Without their support, I wouldn’t have made it this far. Thank You!

team work

Why It’s Important to Learn How Developers Work

The focus of my learning to code project has been on improving my understanding of Ruby and building an app with the help of Rails. Until, this week I hadn’t given much thought about how developers work, especially in a team environment.

That changed recently when I attended Carbon Five bimonthly Hack Night. Twice a month, this developer shop opens it doors to all and invites people in to work on their own personal projects.

logo carbonfive

It’s an informal setting, and I took the opportunity to work part way through Daniel Kehoe’s RailsApps Project. Two hours into the evening, Travis, a Carbon Five developer, and I struck up a conversation. We spent very little time talking specific code or functionality and instead discussed how developers work. As a recent convert from .NET to Ruby, he provided some great insight.

Travis and I discussed many aspects of developing in a team and here are 3 most important I came away with.

#1 Pair Programming

The concept that two people would stand together at one computer working simultaneously blew my mind. Upon hearing this idea, it immediately contradicted how I would imagine you best use developer resources.

But, Travis described to me several scenarios where he and another developer at the onset didn’t individually know how to accomplish the task at hand, but were able to harness pair programming to drive though a development sprint. Working as a duo, these two could accomplish more than either could working separately. This multiplicative effect in efficiency is an incredible result.

In addition to the project benefits, pair programming helps you learn new concepts and become familiar with the techniques and style of your coworkers.

Travis even offered to pair program with me when I feel ready. I can only begin to imagine the learning benefits to be gained of working side-by-side an experienced developer.

#2 Like-Minded, Not Like-Skilled Coworkers

I want to be a developer who is constantly learning new skills. This mentality seems particularly important with web development where the programming languages change rapidly. To learn from other developers requires finding others who have a different skill set.

But while the skills are different, it seems important to share similar philosophies for development practices. For instance, it would be difficult to learn from another developer if your attitudes on testing differ greatly. And I’m sure there other characteristics which are important to consider. I’m interested to pick up more insight around this thought process as I progress.

#3 Test Driven Development

The upfront investment in writing tests before coding pays off dividends in the long run. Specific to Ruby, I inquired Travis’ thoughts on Test::Unit vs. Rspec. He suggested I understand at least the basics of Test::Unit. I’m interested to get more feedback on learning testing.

As a new developer, I’ve heard the importance of testing. But, I’m not so much inspired to to learn testing as I a feel it’s an obligation of the trade. I want to learn it sufficiently to build web apps that don’t break. If that means I can use Rspec without diving into Test::Unit, I’m all for it.

How Developers Work Conclusion

As with any environment, there is not a “correct” way by which all developer teams should operate by. Being introduced to the concepts was extremely important and I’d recommend all new developers be introduced to it early in the learning cycle. Use Meetups focused specifically on programming (not networking events), or if that’s not an option, ask a more experienced developer directly if you can spend a few hours observing an informal work session.

Share your thoughts in the comments section.

featured image courtesy of elmastudio