Tag Archives: Ruby on Rails

help wanted

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

2 Replies

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.

aha moment

Learning to Program and When to Start Building Your Own App?

2 Replies

After completing 8 weeks, I have hit a critical point in my learning to program journey – I’ve begun coding my first app. I feel a new excitement because this is what I’ve been working towards for almost 2 months now. But, how did I arrive at the point where I was comfortable enough to start programming my own app?

tl;dr: I didn’t feel comfortable. I felt nervous and unsure of my abilities. But, to make my learning process more targeted, I needed a project to direct what to learn next.

Where’s My ‘Aha’ Moment?

If we wait until we’re ready, we’ll be waiting for the rest of our lives. -Lemony Snicket < Tweet This>

Remember those standardized tests we took throughout elementary and middle school in which we proved our arithmetic and reading comprehension was sufficient to move us on to the next grade? There’s no equivalent competency test in computer programming (at least that I’m aware of). So what did I use to evaluate my own proficiency, in that I had acquired the necessary foundation to begin programming on my own?

Here’s the funny part – there was never a moment when I hit a particular milestone or understood “enough” technique that told me I was ready to begin building. Interestingly, it was more a specific moment at which I felt continuing the tutorials and intro lesson were no longer beneficial.

It occurred to me while reading about cookies and storing sessions in Action Controller in the Rails Guides. At that moment, it struck me; how can I understand the impact of cookies with no frame of reference? I realized I’d hit the point where I needed to build an application in order to guide what is relevant for me to learn.

Additionally, my mentor through this process assured me that I’d never get to a point where I felt perfectly comfortable building on my own. Part of learning to program adventure is diving into unknown territory.

Hitting Highs and Lows

tea cups dizzy

My brain starting to program. Photo courtesy of Andy Castro.

Starting on my first project was a rush. This euphoria was quickly followed by the realization of how lost I am. Staring at a blank project made my brain feel like it had been on the tea cups ride at DisneyLand.

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

With my foundation from 8 weeks of tutorials, I’ve built a simple app. Each step in the app’s functionality that I can’t execute sends me a quest for answers. Using StackOverflow, blogs, and Twitter, I’ve found help and overcome obstacles.

This is the essence of project-based learning. Rinse and repeat this break-learn-build process a few hundred times and I’ll have built a functional web app while learning Ruby.

At least, that’s the plan.

Update: Join the discussion thread on Lobste.rs

Featured image courtesy of Rishi Bandopadhay

measuring

How I Measure My Progress to Learn to Code

4 Replies

Taking the plunge to go full-time to learn to code was exhilarating. I knew what I wanted to accomplish and began laying out a project plan.

I also knew it would be important to measure my progress along the way. I definitely didn’t want to simply throw up my hands after 18 weeks and shout “Ta-Da!”

Receiving this Tweet from @mdbenner prompted me to write out specifically how I’m measuring my progress.

Think About The End First

In order to track my progress, I had to have an end goal by which to gauge. I struggled with coming up with a specific, tangible achievement goal.

My initial thought was to base it on finding a short, contract job as a developer. My rationale was that if someone else believed in my abilities enough to hire me, then this was validation enough that I’d achieved a certain level of knowledge and understanding.

After much thought and consideration, I abandoned the “job goal” for two reasons. First, my decision to learn to code is not motivated by finding a job or improving my career opportunities. I’m going down this path because I want to be able to build and execute interesting products. Thus, making my success dependent on a job felt counterintuitive.

Second, I sought out input from talented developers and tech people that I admired. Several, especially Tara Brown and Buster Benson, helped me realize that if I made the job the end goal, then this outcome would influence me and my plan. It would be easy to make decision about languages, tools, and platforms based off an employment motivation; ultimately, I didn’t want unnecessary external influence finding it’s way into my plan.

At this point, I took a step back and realized I was making it too complicated. If my goal is to increase my technical skills to build a product, then it makes sense to create a product as the end goal.

If you’re inexperienced, create goals based on learning the code necessary to build a product. <Tweet This>

Obviously I couldn’t build a product from day one. So, I’ve divided the 18 weeks into two halves. In the first 9 weeks, my focus is on completing as many tutorials as possible, reading Ruby on Rails Guides, and getting familiar with developer basics, such as RubyGems, Bundler, Rake, and version control (Git). The second 9 weeks will be dedicated to a project-based learning style, where I’ll be learning by building.

Learn to Code Tracking Progress

I do track my progress and what I’ve completed. For one I want to keep myself honest and ensure I’m completing ample work each week. Second, I want to have a record of the work I’ve completed.

I use Pivotal Tracker to record each tutorial or lesson I complete. Using Agile development mentality, tutorials and lessons are logged as “stories“. I score each story as either 1,2,4, or 8 points based on difficulty and time required to complete. I also log my time for each story, in order to understand how long a story took to complete.

Note: I’m not Agile nor Pivotal Tracker expert; I simply adopted these systems in a manner to meet my own needs.

Pivotal Tracker

My hope is that I complete as much or more points each week. However, I’m mindful not focus too much on simply churning out stories each week. If a tutorial isn’t helpful, I’m not afraid to abandon it before completing it. These aren’t homework assignments; my focus is on learning. Therefore, I try to balance the importance of completing a steady pace of work each week, with ensuring that my time is dedicated to learning.

How do you track progress on your goals? Share your thoughts in the comments section.

Featured image courtesy of Louise Docker.

team work

Why It’s Important to Learn How Developers Work

Leave a reply

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

 

email mac

4 Factors Crucial for Choosing Your First Programming Language

9 Replies

In creating my plan to learn to code, I made the decision to learn Ruby. The first programming language is a very important decision and one that I didn’t take lightly. Below is the process I followed to make this decision.

First, a bit about web technologies (you can skip to the 4 factors if you’re familiar with web technologies click here). If you’re like me, someone without a technical background, you’ve been amazed by a first-hand experience with an amazing web application.

While that amazing web app is a cohesive product, it’s important to understand that there are several layers or tiers of functionality you’re experiencing simultaneously. Before you choose your area of study, consider how each of these areas apply to you.

Tiers of Web Functionality

  • Graphic Designer – This person creates the visual aesthetics of an app, including colors, logo, and layout. The graphic design determines the immediate impact felt by users and the mood conveyed by a site. Graphic design isn’t truly a web development tier, but I think it’s important to recognize because of its impact on users.
  • Web Designer – Using primarily HTML, CSS, and JavaScript, the web designer brings a web app to life and makes it interactive to the end user.
  • Web Applications Developer – This developer is concerned with the interaction between the client (web browser) and the application server.
  • Web Database Developer – In complement to applications developer, the web database developer ensures a smooth connection between the application server and the database.

Web Browser, App Server, and Database Diagram

Experts in each of these areas work collaboratively to execute a complete web application. In reality, most everyone learns skills across different tiers and it’s not practical to dedicate yourself to learning only one area in a vacuum separate of any others. But, you do need to select your primary area of expertise and that should the focus of your first programming language. This level of specificity will ensure you have a clear end goal and focus of study.

Once you’ve selected your tier of expertise, you need to select a specific language. Just like there are different spoken langues to express “Hello“, there are different tools and languages within your chosen area, each with pros and cons. I won’t start to name all the specific options, but instead show how you can evaluate these options and pick what programming language is right for you.

I selected the Web Applications Developer tier and then narrowed my language choices to python, PHP, and Ruby. Here is the process I used to evaluate different languages and decide where to start.

4 Factors for Learn to Code

#1 Executing a Prototype

You want to learn because you want to build something which serves a purpose. Your first development attempt will not bring you fame and fortune. But, you may build a prototype which either inspires someone else to work with you or to invest in your idea. How easily you can build this basic mode is a strong factor to consider.

Learning programming is a means to an end objective and getting outside support can expedite your process. Because Ruby has the Rails framework, I felt confident I’ll be able to get up a working prototype by the end of my 18 weeks.

#2 Learning Feedback

I’m part of the ADD generation. Our brains have been trained to expect immediate gratification. If you’re learning and there is large barrier to begin executing, it’s going to make the process more tedious. If you have the dedication, then more power to you. Be realistic about your expectations and commitment to your goal.

#3 Access to Mentorship

Don’t underestimate this factor. There are unlimited resources avaiable online and in books, but the talking with someone one-on-one is a huge help. Use meetup groups locally where you can meet web developers in your selected language. Developers were in you’re shoes once, and most are willing to help you. Even better, find mentor-specific opportunities to get involved with.

I was lucky to get connected with Tara Tiger Brown in Los Angeles and the Teach My Stuff program. Through this program, I’m working with Joe Goldberg, who’s Ruby expertise helped me plan my own learning program. We meet every two weeks and he’s available to answer questions when I need clarifying.

#4 Future Relevance

While not as important factor as the first three, it is still worth considering. Web development changes rapidly and you wouldn’t want to bank on what’s going to happen in the future. You should consider your future opportunities, both from a career standpoint and the type of projects you’ll be suited to work on.

For example, there are many people who have a passion for Latin and thus choose to learn what’s considered a “dead language”. But, your future opportunities if you learn a programming language that’s the equivalent of Latin will be diminished.

Conclusion

These are the factors which I considered when choosing Ruby. Do you agree or disagree with my reasoning? Are there factors that I didn’t include, which should be considered? Leave your thoughts and questions in the comments.

Update: Join the lobste.rs discussion here.