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

 

progress

Learning to Code Progress – 3 Weeks Completed

1 Reply

I’m now three weeks or 1/6 into my learning to code process and my progress to date can be summed up in one word: slow

slow moving

Photo courtesy of Ian Britton

Alright that’s probably being a little harsh on myself. But, when I first started out this process, I thought I could be plugging away and building something after three weeks.

Instead, my time has been spent completing lessons and Ruby on Rails tutorials, but I’m not yet to the point where I feel I could begin building a project or web app on my own. That’s a frustrating current state because I have ideas that I want to execute.

Maintaining Perspective

I’m staying positive and my Teach Me Stuff mentor, Joe Goldberg, is very helpful in this area. Here’s a snippet of our reacent phone conversation discussing my progress:

Me: “I feel that I’m learning, but it’s going much slower than I imagined at the onset.”

Joe: “I’d be surprised if you told me any different.”

It’s incredible how reassuring it was for me to hear this simple phrase. Learning to code is foreign territory to me and I have no point of reference by which to judge my progress. On the other hand, Joe is experienced with Ruby and development. This support is a large benefit of having a web development mentor.

Adjustments Moving Forward

I’m not planning any major changes. However, one very important takeaway for me has been the idea that I need to focus more specifically on learning Rails, a framework for building with Ruby, than Ruby itself.  My focus for this 18 weeks needs to be moving to where I can build a product. As a result, my comprehension of Ruby will, understandably, not be as strong.

In the future, I may have to backtrack or dive further into Ruby because I’ve missed something in this first 18 weeks. That’s a short-term sacrifice that seems reasonable. I don’t want a preoccupation with learning every facet of Ruby to hinder my ability to create an app.

Leave your thoughts about my progress, focusing more a Rails, or any other thoughts in the comments below. Also, for those interested, here are the specific tutorials and lessons I’ve completed to date.

Completed

group learning to program

The Power of Group Learning to Code

2 Replies

I was in San Diego this week and a friend invited me to attend a San Diego Tech Immersion Group (SDTIG) meeting. It’s experienced computer programmers who want to learn new technical skills.  I was struck by the unique group learning to code environment being fostered by the group.

The group consists of 3 developer leaders/mentors and approximately 100 developer participants, who follow a new learning track every six months. The Fall 2012 track is focused on web development (HTML/HTML5, CSS, Javascript, JSON, and JQuery). Monthly, each member completes the same reading assignment from a book for the current technology and the topics are discussed in a more detail during monthly meetings.

Here are few amazing features of this group learning:

Learners Helping Learners

Members help each other overcome stumbling blocks while learning new technology. In addition to the monthly meetings, there is a forum for group discussion. Because each person is going through the same track, there’s great opportunity for collaborative learning, members jump in to help when they understand the material.

Expert Mentors as Guides

These mentors serve as an expert resource for the group. More than just subject-matter expertise, these mentors also plan the learning schedules, select the materials, and determine an appropriate learning pace.

Learning isn’t easy and creating a plan to learn a foreign subject is a challenge. These experts greatly reduce that burden.

Social Pressure = Accountability

This aspect was never directly mentioned during the meeting, but I couldn’t help notice it. There’s no financial cost to join the group, but by actively choosing to participate in a group environment, there is a social force at play. You don’t want to fall behind so you complete the reading and come prepared to discuss.

Conclusion

I’m always on the lookout for new and interesting resources for learning to code. The SDTIG was a new experience and not like anything I’ve come across locally (if you know of something similar in LA, let me know).

There are characteristics of a traditional classroom setting, but there is much more collaboration amongst the members. Also, members complete individual learning, but it is in a structured, expert-guided fashion. This mix and match of learning styles, guidance, and support are great for beginners learning to code.

featured image courtesy of UBC Library 

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.