Learn With Jeff

I learn by teaching

Can You Learn to Code?

I get this email three or four times a month:

I’ve recently had a thought that I should learn how to code. I have a full time job. Can I learn to code? How long will it take me?

I often hesitate to respond since it often results in a series of exchanges that leaves me frustrated and the original author unsatisfied. So I hope to clarify or extend my almost two year old post How to get a Job as a Developer in Less Than Six Months with this one.

Can You Learn to Code?

Short answer:

I have no idea.

Slightly longer answer:

Yes. I emphatically stand behind the idea that almost anyone has the mental facilities needed to comprehend programming.

However, when reading my post my circumstances are easy to forget. I had no job. I had just graduated from college. I had three months of money saved up. I was living at home with my parents.

Not everyone has those privileges.

I was able to devote all of my available time to learn to code.

There is a reason that the Flatiron School and schools like them encourage students to not be employed during while they are attending.

learning to code is hard work.

Even now, when I am learning something new I find that I need to block off at least two hours at a time in order to be productive.

So ask yourself some questions:

  • Can you reduce the amount of hours you work?
  • How many (consecutive) hours can you devote each day to learning how to code?
  • How long can you sustain that pace?

Your answers to those questions still won’t help me answer your original question because this will be different for every person reading this post.

The resources are out there, the community is out there. I am happy to pair with anyone on almost any project. I will review your code. I will recommend code schools – Flatiron School – but at the end of the day I cannot decide if you are capable of learning how to code.

Only you can.

Free Consulting

I’ve struggled for a while to figure out where I fit into the activist community. I have learned lately that I (another cis white hetero male programmer) don’t have much, in the way of experiences, to add to the greater conversation.

But I recently helped a writer/activist with some programming tasks, and I realized there might be a lot of activists for whom the Web is complicated territory. So, if you’re an independent activist who works to fight injustice, and you need help on anything Web-related, I’m happy to provide it, free of charge.

email me at anytime: jeff (at) jeffreyleebaird.com

I have no idea how many requests I’ll get so if it becomes too much to handle I’ll have to put some sort of limit on it, but for now let’s just see where this goes.

Easy Broiled Rib-eye

Sometimes, after a long day of work, the last thing Clare and I want to do is spend an hour crafting the perfect Paleo dinner. This steak and salad combination is a great way to have dinner ready in less than 20 minutes and have it feel like a gourmet meal.

Broiled Rib-Eye

Tools

  1. A 12-inch, well-seasoned cast-iron pan. I use this one from Lodge.

  2. A meat thermometer

  3. Pepper Grinder/Mortar & Pestle

Ingredients

  • 2 Rib-Eye Steaks
  • ½ tablespoon fresh ground pepper
  • ½ tablespoon sea salt
  • Olive Oil

Prep

  1. I like to leave the steak on the counter for about 30 minutes prior to cooking. It seems that this allows the steak to cook more evenly

Cooking

  • Turn on the Broiler. When it is warm put the skillet on the top rack and let it heat up for about 5 – 7 minutes. It may start to smoke, open a window and turn on a fan.

  • While the skillet is heating up salt and pepper the steak, gently pressing it into the meat. Then, drizzle the steaks with olive oil. Flip the steaks over and repeat.

  • Pull the skillet out of the broiler (it will be extraordinarily hot; use a thick pot holder) and put the steaks on it.
  • Return the skillet to the top rack of the broiler and set the timer for 4-5 mins.
  • Check the steak. If it is at 125 degrees it is ready (rare, the only way it should be eaten).
  • Let the steak sit for about 3 to 4 minutes before cutting it.
  • Eat!

Clare prepared a spinach salad ahead of time so maybe I’ll be able to get her on here to write about that. Enjoy!

The Easiest Stew

I think we have all realized by now that I am a pretty awful blogger.

I haven’t reliably posted, ever.

But, I am going to give it another go.

So let’s start with cooking, at least that is something I can write about. Let’s start with my stew.

Jeff’s Paleo Stew

Ingredients

  • 1.5 lbs of stew meat (Trader Joe’s sells pre-packaged pre cut stew meat)
  • 1 large or 2 medium sized onions (Any Kind will do, I like Vidalia but I used Red Onions here)
  • 8oz of whole White Mushroom
  • 1 lb of carrots (I use baby carrots here but usually prefer rainbow carrots)
  • 2 – 3 sweet potatoes or regular potatoes
  • 1 quart Beef Broth
  • 5-6 cloves of garlic
  • 2 Bay leaves
  • 2 tsp freshly ground pepper
  • 2 tsp salt
  • 1 tsp rosemary
  • 1 tsp thyme

Steps

Collect your ingredients:

Stew Meat:

Beef! It's whats for dinner

Onions:

Onions, try not to cry :'(

Mushrooms:

Mushrooms, wash them well, they grow in shit

Carrots:

Carrots, Wish I had rainbows

Potatoes

Potatoes, I like em sweet

Garlic

Keep away the vampires

Beef Broth:

dead animal juice

Spices:

Not the drug

Prep your ingredients:

Cut the ends off of the onion

step 1 prep

Cut the onion into eight wedges

step 2 prep

step 3 prep

Wash the mushrooms very well then slice them in half

step 4 prep

Scrub the potatos and cut the into (approximately) 1 inch chunks

step 5 prep

Cut carrots (if not using baby carrots) into 1 inch chunks

Put it in the cooker:

Start with a layer of about ½ of your onions

step 6

Add about ½ of your carrots

step 7

Add about ½ of your potatoes

step 8

Add about ½ of your mushrooms

step 9

Put in the two bay leaves

step 10

Put in all of your meat

step 11

Put in your garlic

Put in the rest of your vegetables

step 13

Sprinkle on all of the spices

Pour the entire quart of broth into the slow cooker (try to cover as many veggies as possible)

Give everything a quick mix

Set the slow cooker to ‘Low’ for at least 10 hours. I have set it for as long as 16 hours, the longer it cooks the more tender the meat is.

step 17

EAT YOUR CREATION:

step 18

Moving to Portland

Moving to Portland

It feels like yesterday that I was writing about new adventures. Here I am, planning another crazy but exciting move.

The last 18 months have involved an insane amount of change for me. I changed careers, moved to New York, then switched jobs again. Now we are starting a new chapter in Portland, Oregon!

Clare, my fiancee, was recently offered a feature writing position at The Oregonian newspaper! I am excited for the adventure, the prospect of a new job and a new city, but I will miss my friends, Brooklyn and the Flatiron School immensely.

In the last few months I have watched and helped train 32 of the most amazing people I have met. I have no doubt that over the next few years we will see amazing products coming from these students.

This move is a little bittersweet. In a few short months the team and Flatiron School has become like a family. I’ve learned so much from my bosses and coworkers, and I’m incredibly grateful to them.

My time at Flatiron School has changed me as a person and as a programmer.

This is goodbye, but hopefully not forever. New York, I’ll miss you.

Moving Beyond ‘Advanced Beginner’

Last year Erik Dietrich wrote a great piece called How Developers Stop Learning: Rise of the Expert Beginner.

Just in case, here’s a quick summary.

Dietrich’s main point is that some beginners reach a point of complacency with their expertise long before they ever reach the “expert” level on the Dryfus Model of Skill Aquisition. This results in many over-confident programmers writing production applications and often leaving the team before they have to suffer for their mistakes.

He has a great little graphic to explain what he means:

"Expert Beginners"

I think Dietrich has an excellent point, yet it isn’t really a problem I see in my role as a TA at the Flatiron school. I think, instead the bigger question raised is “What is an Advanced beginner to do?”

I have been working as a rails developer for about a year now. I have a fair grasp of the basics; I feel I can be productive on most rails projects without too much of a ramp-up; I can pick up new languages with relative ease; I’m slowly developing my personal style as a programmer.

I still have a long way to go.

One of the most prominent traits of an expert beginner is extensive breadth and a lack of depth. As a guy who loves “shiny” things, I am faced with a problem. I tend to pick up new technologies before I have truely mastered the ones I get paid to know.

I’ve posed the following question to myself: how do I level up from here?

The options seem endless. A year ago, I only wanted to build web apps, now I want to try writing a VM, a compiler, or a language.

That is only the tip of the iceberg. The more I learn, the more I realize I don’t know. I feel overwhelmed because I want to do everything.

So what is an advanced beginner to do?

I’ve decided to set a series of high level learning objectives, followed by goals that will give some amount of concrete accountability to them. The Web is where I am least comfortable and will likely have the biggest impact on my career going forward, so that is where I’ve decided to focus.

Objectives

  1. Gain a deep understanding of TCP/IP
  2. Learn how to effectively use WebSockets
  3. Become comfortable with the DOM apis
  4. Understand Event Handling

I almost put a line about learning Functional Reactive Programming in the list above, but I think it is a good example of me trying to ‘pre-maturly optimize’ my knowledge for problems I don’t have yet. That being said, FRP is really freaking cool.

Below I’ve sketched out some projects to help me reach these goals.

Projects

  1. Build a web application using at least one major JavaScript framework, currently leaning towards Ember.js.
  2. Write a simple webserver in Ruby from scratch.
  3. Read TCP/IP Network Administration.
  4. Read The Definitive Guide to HTML5 WebSocket.
  5. Build an interactive browser game using JavaScript.

Readers, what do you think? Is there something I should add, subtract or expand on? Let me know on twitter!

A New Challenge

Man, it has been a long time since I’ve written a blog post. The last time you heard from me I had just started working for Medivo. My experience at Medivo has been amazing. I learned from some amazing developers, worked on a product I care deeply about and made some great friends.

But all good things come to an end, and as of this Monday I started as a Teacher’s Assistant at The Flatiron School. Look at the title of this blog — teaching has long been a passion of mine. I am pumped to take on this new challenge in my life.

In other news, I’ve been playing a lot with Go. You should go over there and check it out. I will be writing on it soon :–)

How to Get a Job as a Developer in Less Than Six Months - Learn With Jeff

So the month of June came and went, and so did July. A lot has happened, but I wasn’t able to complete my goals

I did, however, make huge strides in my programming skills – so huge, in fact, that I was hired as a junior developer at Medivo!

This post is about how I got hired for my dream job with less then six months of programming experience.

Learning to Program

Work your ass off:

This isn’t how to fake your way into a position. It is how I got real results in a short amount of time.

I was, however, in a unique position. I didn’t have a job, I was only taking one class and I had fallen in love with programming.

So, in order to make the kind of strides I made, expect to spend at least 10 hours a day, six days a week dedicated to programming activities.

Read a shit ton:

The Pragmatic Programmers is now your best friend. If you are learning Ruby, get the Ruby 1.9 manual, Learn to Program, and get their Pragmatic studios learning ruby course (It is $200 but worth every cent). Start with the Pragmatic studios video course, and after about five lessons, start step two of my process while continuing to work on the videos.

Join your local ruby group:

This is a must. If you ignore everything else I say, still join your local meetup group.

This is imperative for three main reasons: First, the people you meet may become your employers, or they might introduce you to your future employers. Second, you will be around the people that have the jobs you want. Listen to them, jot down notes about the things they say, and if you don’t understand, then go research it. Last, if you show passion, you will likely find enthusiastic mentors from this group of people. I would not have made it as far as I have without Gavin Stark, Aubrey Goodman and the rest of the Tampa ruby brigade.

Write a ton of code:

Learn git and get a GitHub account. Push code to github EVERYDAY. There is no exception to this rule.

There are no shortcuts, you must write code, and a lot of it. It doesn’t have to be good code, but you must write it. If you look at it and think, “boy, this is shitty,” document the code and explain what you were thinking.

Make everything public:

This is an important aspect of writing a ton of code. If you keep it to yourself, it can be as shitty as you want. I find that if its public, every line of code has to be defendable, even if your reasoning is flawed. It is easier to adjust how you do things if you know why you did it in the first place.

Get a GitHub account, learn git like a boss, make every repo public.

Blog about your challenges:

You will face challenges just like everyone else. Blog about them incessantly. You can’t get any better unless you are asking for help. Also, having a record of your progress will come into handy later when you are trying to get that job.

Make sure you also blog about your successes. When you get something right, especially early on, it feels like the most epic of wins. Tell everyone about how awesome it feels and how you did it.

Getting The Job

So now you know a little programming. Don’t wait to get to a point where you feel skilled enough to get a job, because you will be waiting a long time. There is a desperate need for developers, and you are doing a great disservice to yourself and to the community. By learning on the job, you will give yourself a much more focused learning environment. However, here are a few things that will make the search go a little smoother.

Learn to speak like a programmer:

You’ll get a little of this from your reading and from your meetup groups, but there is more you can do. First, listen to related podcasts, I recommend every episode of Ruby Rogues, next subscribe to Rails Casts and Destroy all Software two great programming screen casts.

Some of what is discussed will go right over your head. That is okay. The point of this is to learn how developers speak. When you interview this will be an important skill.

Cast a wide net:

I got my job by sending out this email to the NYC Ruby community:

Hey NYC.rb!

I am a (relatively new) self-taught programmer moving to NYC from Tampa, FL at the end of July. Tampa’s awesome Ruby community inspired me to learn Ruby as my first language, and I’m excited to get involved with the New York City Ruby community.

I am graduating in a few weeks with a degree in business and entrepreneurship from the University of South Florida but found my passion, programming, while I was hiring a developer for one of my businesses.

I am looking for an internship/apprenticeship/junior programming position open in the area. If anyone has or knows of such a position, I would love to meet in June when I am in town for GoRuCo.

I am getting fairly proficient with Ruby, know the basics of JavaScript, HTML and CSS and am currently working with Rails. I learn quickly and work hard.

You can see where I am with my skills on GitHub, and I blog about my learning at learnwithjeff.com. Any feedback or advice is greatly appreciated!

I look forward to meeting some of you and getting involved with the New York City Ruby Community.

Sincerely, Jeff

I got 40+ responses in 18 hours. I also found every NYC ruby shop I could and read about them.

Next, I made a list of my top 10 companies and I worked my ass off to get interviews with all of them. I also stayed open to a few more pending discussions with the people on the team.

Don’t underestimate your value:

When I started this search I thought I would be scrubbing toilets in exchange for nightly code reviews. While that determination was probably a good thing, the market is currently in favor of devs looking for work. You may be a n00b, but don’t underestimate your value.

So to sum up:

Work hard, write a lot of code, be transparent and be enthusiastic.

In February 2012 I had never written a line of code. But, as of July 11, 2012 I am employed as a full-time Ruby Developer. You can do it too :).

Goals for the Month of June. - Learn With Jeff

In my learning, I find it immensely helpful to set lofty (but possible and measurable) goals. I didn’t my goal for the month of May but it was pretty straight-forward, publish a gem. I accomplished that goal, twice.

I’ve decided to talk about my goals out for the month of June since they are much more challenging than my goals for May. First, I want to publish a “useful” gem/plugin/program/app. Second, I want to make some contribution to an open source project.

Both of these are a little subjective, so let me define further. I define “useful” as someone other than myself uses it. Not just downloads it, actually uses my creation. Now, since I can’t control whether or not my contribution to an open source project is accepted, I will be a little more loose in that definition. I want to issue a meaningful pull request on a public repo that has multiple contributors.

I realize that the above are huge challenges for a beginning programmer, but I wouldn’t get anywhere if I only tried to do comfortable things :)

Testing - a N00b’s Reflection - Learn With Jeff

I have officially spent more time testing and refactoring my code for my black jack game, RubyJack, than I have on the original code base and it has taught me a big lesson: TEST FIRST.

This is a topic that I don’t have the breadth of knowledge to really attack. Jeff Atwood does a much better job than I, here. I do, however, feel that I can add the perspective of a new programmer.

The challenge of testing first as a n00b, is that when you are learning to program, you generally learn

    def print_hello_world


      puts "hello world"

    end

    print_hello_world

before you learn

    it  "prints hello word" do

      print_hello_world.should == "hello world"

    end

I wouldn’t say this is a mistake since testing is inherently more complicated, but it does create a significant barrier to entry to the new programmer. This barrier is mainly a comfort level thing.

When I was first learning about testing, I thought “I can really see the theoretical application of this, but my programs are so simple now that I don’t need tests.”

BIG F&%$ING MISTAKE.

The big example, in RubyJack, of where writing my tests first would have helped me, was during the refactoring process. The first draft of my code may not have been bad for a new programmer, but was(is) poorly written software on a whole. There were methods in classes where they didn’t make sense, arrays of strings where they should have been arrays of objects, 25 line methods that did one simple task and many, many other problems.

Up to this point my tests consisted on running the program through my command line, playing the game till it broke and reading the error message. Not super efficient.

So, after I published the first version of the gem (gem install RubyJack) I started to move stuff around. First, I did some simple refactoring of individual methods, no problems. Then I thought “oh, well this method that starts the game probably should be in the ‘Game class’ and not the ‘Player class.’”

All Hell Broke Loose.

Nothing worked anymore, I couldn’t even start the game let alone deal a card or initialize a deck.

Thank god for “git reset –hard”.

I was able to hop back to my latest commit and start again (more about using commits to your advantage later). Then, I wrote some tests. It was hard;  it hurt my head; I didn’t like it.

I struggled through them and got (most of) them to pass. Around this time I brought in some professional help, Gavin. Gavin was nice enough to sit with me and help me do a little (a lot) of refactoring of my code. We moved some methods into classes where they made more sense, and created classes that should have been there from the beginning.

Then I tried to do some more refactoring on my own, which led to even more problems. I hadn’t learned my lesson.

Once again, I found myself reaching for “git reset”

It was then that I resolved to write better tests. I re-watched the pragmatic studios video on unit testing and peppered Gavin with some more questions. Then, I wrote a bunch of tests and MADE THEM ALL PASS.

When I originally wrote my tests, if I couldn’t get a test of a certain functionality to pass, I marked it as “pending” instead of figuring out the problem. Not this time. It took me hours, and until 2am, but I made them all pass.

I then entered the process to which Gavin introduced me to:

Red

Green

Refactor

What that translates to is this:

Check my tests, if they pass I make one small change. I then check my tests again, some of them may be failing, I want to make sure they are the ones I expect. Then, I continue tweaking the code till I get it to pass all the tests again (sometimes tweaking the tests too).

Then I start the process all over again with my next change.

The benefit to testing first, as I see it, is as it concerns the thought process towards your code. As J. Timothy King States:

You ask, “What code will I write to generate a solution?” But that’s backward. The first thing you should be doing… The first thing you ask is not“What code will I write?” The first thing you ask is “How will I know that I’ve solved the problem?”

So, my tip for other n00bs out there is to learn to test sooner rather than later. You won’t regret it.

Thank You!

I want to give a huge public thank you to Gavin Stark for helping me with the refactoring process and answering all my crazy n00b questions. Thanks Gavin! Also, thanks to Aubrey Goodman who graciously takes my questions at all hours. Finally, I’d like to say thanks to Andy Lindeman who went through and commented on my code on github! It is people like you guys that make the Ruby community awesome and make me glad to be a part of it.

Disclaimer, links, and tweets

I love to learn and I do not pretend to be an expert on the topics I post about. If I’m wrong please, let me know in the comments, I love feedback and you won’t offend me. Follow me on Twitter; I love to discuss Ruby, books and anything interesting.

If you want to help an aspiring Rubyist, I’m on GitHub and would love any feedback you have to offer.

Many people have helped me learn, I would love to return the favor! Get in touch and I’ll see if I can help.

Thanks for reading!