How to get started

I keep meeting people with the same story: “I wanna change careers — how do I become a developer.” As someone who made a mid-career shift myself I have a soft spot for others who want to give it a try. It’s not easy — but it’s also not as hard as some might think. Here is the process I recommend:

Step 1: Join Github

Source control involves the tools developers use to track changes to their code and coordinate working together. There are lots of flavors — but I recommend learning git ( Github is a git source control server and developer social media website all rolled in to one.

I used to let new developers learn a bit of HTML, CSS, and maybe a little Ruby before I taught source control… I’ve since decided git is the most important skill a developer can have and teach it first. It’s a complex concept for someone just starting out; but with it you can:

1.) Make it easier to show your work to others
2.) Make it easier for others to give you feedback on your work
3.) Make it easier to work alongside others on projects
4.) Make it possible to undo changes to your code… which will sound trivial until the first time it is EXCESSIVELY valuable.

For the ladies among us there are GDI classes for it… and a ton of material on the tutorial sites all over the internet… including online classes from Github.

One other note — if you are following along writing code from tutorials definitely use git to store your code… however place all your tutorial projects in one single repo (you’ll learn what that means with Git). Ask me about that later if it doesn’t make sense — but as an employer I REALLY appreciate it when I can tell a candidate’s original work from work done following an example or recipe.

Step 2: Write Code

Write code. Write a lot of code. Definitely use tutorials — but try to come up with an original way to use what you learn as you go. Write good code and bad code… and write it all in public.

This one always seems easier said than done but it is vital to both learning and getting a job. Once you have your Github account create a public repo and start working on a practice project in there. Use Zoe Rooney’s collection of PSDs if you need designs to practice on.

One note — there is a tendency for people starting out to be embarrassed by mistakes… and a follow on tendency for people to try to hide the mistakes they make in public. Resist those tenancies. Everyone makes mistakes. All of us. I have been doing this for 20years and have proven I will *never* produce flawless code. If you have a mistake make a fix and commit it (you’ll also learn about that in git!) to your project. Flawless commit histories (GIT!!!) look fake. Don’t look fake.

Don’t try to learn too much

I’ve seen a lot of new developers try to learn everything they can regardless of language. You wouldn’t try to learn French, Russian, Somali, Chinese and Japanese all at the same time… so don’t try to learn Ruby, Python, .net, Java and Haskell all at once either. Stick to HTML, CSS, JavaScript and *maybe* one serverside language to start. If you decide to go with a serverside language I recommend Ruby or Python. Both have big friendly communities (and jobs) in Philadelphia.

Don’t assume you’re interested in front end development

HTML/CSS/JavaScript are all awesome and rewarding — but always stay open to hearing about other new stuff. I am a Ruby developer — last year I took a class on Scala. I ended up not being a fan (I don’t like desserts, either… so you only go by me so much)… but I learned a ton while doing it… and actually write better Ruby code now because of it!

It’s worth noting if you decide to make this your job you’ll never be done learning… which in a way can be scary but it can also be liberating. As they say: “You’ll never know less than you know right now.”

Step 3: Show code to others

Once you have your git repo full of some code — ask others to review it for you and make suggestions. Ask developers you know and developers you wanna know. Remember that any critiques that come back are about your code… not you. Also remember that if someone recommends something it doesn’t mean you *have* to take their advice. Sometimes a suggested change is a bad idea. Sometimes it will spark a different idea. Whatever — you’re trying to learn… and getting people to look at your code is a fast way to do it.

Step 4: Read other people’s code

Ask your friends if you can look at code they have written. Learn what developers out there are well known and read their code. If you need a start — look at CSS Tricks. You can also pour through GDI events to find instructors — look at their twitter accounts and github accounts to find code to read. If you have questions about things — ask. If you find things wrong — suggest changes. You’ll be surprised at how fast that sort of thing will get you hired.

You’ll also want to read a few books. While pricy I recommend the Jon Duckett books on HTML and CSS — they are beautiful, well written, and well illustrated. I’m also a huge fan of the Stephan Wintermeyer Rails 4.0 Guide if you wanna do Ruby… but skip the print version because the type is in the tiniest most unreadable font ever.

Which reminds me — get a tablet or phone with a kindle app and start reading your books digitally. “But I like paper better!” works fine until you have a 50 pound library you’ll want to haul with you everywhere. Try to buy your ebooks through the original publisher rather than Amazon — most run regular sales and will provide free updates if the book improves.

Step 5: Get involved in the community

Find local meetup groups and start going.

Go through meetup and look up ones that sound like they are about topics that interest you. If you are in Philly check out PhillyJS, Philly Content Strategy, Philly.rb, and PhillyPUG. You will learn things and meet people who can help you get going. “Hi — I met you at a <fill in the blank> event… can you help me do X?” goes a *LOOOONG* way.

Also — don’t be afraid to go through meetup and visit groups that involve technologies you *don’t* know… even if you’re not interested yet. Worst case scenario — free snacks. Best case scenario — you learn something awesome or meet your new boss.

If you ever want to visit a new group in the city, know me, and don’t want to go alone I’d be happy to tag along. I like both free snacks and learning things.


Anyway — that’s a long blerb. Ask me questions. Ping me for advice. Ask me to look at code. Let me know if you need new developers to look at your code. Let me know what resources you need. Let me know if you don’t know what resources you should need.

It’s not going to be easy… we get paid for this because it is work. …but it’s not gonna be all that hard either. You can do this… we’re here to help.