Thursday, April 17, 2014

Hire this guy!....My Interview with a Daniel P. Clark

I thought we'd switch it up for a change and have an interview with my friend Daniel Clark. I first met Daniel a couple years ago at the Global Code Retreat the same one that I met my soon to be mentor David Bock @bokmann. Daniel was miles ahead of me then at coding and still is :-)

Daniel also knew a lot of Python besides just Ruby and had already made several Ruby Gems that had been download several thousand times. I was always shocked that he didn't go out sooner and get hired as a Ruby developer.

Well after talking over the years and coding together atseveral Meetup groups, that time has now come and Daniel is fresh on the market and ready to get hired as a junior developer. Finally!!!

 ANY company would be a fool not to beat a path to Daniel's door and hire him tonight, tomorrow might be too late =-)

Here is the interview I had with Daniel, I hope that it inspires and encourages others along the path to becoming a developer and one day getting hired as well, I hope you enjoy it! Feel free to leave some comments for Daniel, follow him on Twitter and check some of his cool stuff on Github, I always love sitting down and seeing what he's working on :-)

"Tell us a little bit about your background, what got you into wanting to be a developer?"

"I'm a bit of a jack of all trades kind of guy. Growing up I always dreamed in adventures. In my dreams I'd always be running towards something, or away from something, but I never knew what. I love to be curious, and I love solving mysteries. 

Not mysteries as most would think of them. While I was still a toddler, to my mom's surprise, I found a screw driver and took apart the dining room furniture. I've always enjoyed taking things apart to understand them better.

My dad is an excellent computer programmer. He introduced my to qBasic when I was in 5th grade. I grasped a very basic concept of 'functional programming'. I was gifted an old computer around that time and the curiosity drove me.

I learned computer systems with hands on experiments. Break it, fix it, repeat. I was very interested in programming, and I so wanted to learn Java. Java was this amazing language that worked on everything. It seemed like the way to go. 

Well when I first started learning it I became very frustrated. Too many lines of code for simple things, it was object oriented and I only understood functional programming at the time, and I simply didn't have fun figuring it out.

So that kept me away from programming for a while. Around 10th or 11th grade I'd discovered a language called Python. And it was perfect. It looked like English, and it was very friendly with my functional programming style. 

To accelerate my learning with it I challenged myself to design an open source video game for school. So I wrote a game called PyC4 which is a Connect Four game. I won a first place for that entry in the Science and Technology Fair. From there I was hooked. I could do anything."

 "What has been the hardest thing about learning to code?"

"The hardest thing about learning to code has been thinking anything is difficult. To think that really turns your brain off and makes everything harder to grasp. There are often many ways to solve a problem.

It is most helpful to learn the tools you have at hand and use them in creative ways. If your process of deduction isn't continually improved then your brain isn't as sharp as it can be. It is how you think, your method, that needs to be improved. You don't need to know the answers to the world, you just need to know how to find the answers when you need them."

 "What do you like most about coding?"

"What I like about coding is it's always fresh. I love a good mystery, a good challenge, and the process of problem solving. I also like the difficulties to overcome.

Yes... when the code just doesn't work and you don't know why... What do I know when that happens? Well these are the times that I can improve my process and become a better programmer for it. The process is the most powerful part of programming. Having my mind become stronger
for the difficulty is worth those moments."

 "What has been the coolest thing you've built or helped to build so far?"

"I have written many things that I've been proud of. I mainly have developed small projects and scripts. I've written some web automation, including YouTube, Twitter, and search engine optimization scripts.

I've written many system scripts for handling, and processing, videos, images, and audio. I was also contracted for a script which paid out teachers for an educational media site through PayPal.

As for cool, I kinda like my random YouTube video script which grabs three dictionary words and gives you the first YouTube video response. Yes that's silly. But as a 
programmer you need to have fun now and then ^_^. "

 "What advice would you give someone who is just starting out wanting to learn how to code?"

"I highly recommend beginners to be a bit relaxed when starting out. Don't ever assume something is hard or difficult. Knowing where to go is really key to progressing quickly. 

Fortunately in the programming world Google search results generally provide very good answers. This seems true for the more popular programming languages. For any particular questions you can head over to It's wonderfully easy to use for Q&A and for all things software development."

"Knowing what you know now, what would you have done differently with your path to learning how to code?"

 "Deadlines. Starting out having deadlines for accomplishments really drives efficient progress. I say that because the school project had me learn a huge amount to accomplish the game.

 The thing about deadlines is it indicates a commitment to complete the task at hand. This largely helps prevent any idea of giving up, or abandoning it. Also find a competitive partner. Some one who's willing to challenge and push you further. 

This will open up whole new worlds before your eyes. If you need something to compete with then websites such as provide excellent challenges."

"Where do you see yourself as a developer in 5 years? 10 years?"

 "In five years I see myself as a community organizer and leader. I can see myself involved in the 
development process and growth of a company. In ten years I can easily see myself as a founder of one, or many companies. I can also see myself as being heavily involved in helping the community in so many ways."

 "What are some long term goals that you have?"

 "I have many. I have always wanted to own my own software company. I want to be a lead singer of a band and have the band stay together. I want to found a music label as a non-profit ministry. I'd like to be part of a video ministry. I want to master several languages. And I want to be a great athletic runner and a master of parkour."

 "How do you feel about your development skills?" 

"I feel I'm capable of some of the greatest achievements yet to be. I am able, I only need to hone my ability in on target and all will be well. This is how I feel about my skills. Do I know everything? Not even close. But I am as capable as anyone else on this earth. I can chose many different paths. Which do I truly want to be a master in? Yet another mystery. I look forward to the future."

 "What is your favorite language?"

"I love Ruby and I love Python. I like Ruby as a powerful language to accomplish things to the finest details. And Python I like for beauty and consistency. Python has a game development library PyGame, and an amazing network protocol library Twisted.

So for game development I clearly favor Python over Ruby. As far as web platform, I really like Django, which is a Python based platform. I fully believe the consistency of code between developers on this will help the code be easily maintained, and not a problem to maintain in the long run.

In Ruby you can have so many different ways of writing code that it can make for a more difficult time when working with other programmers. Think of it like people in Ruby have such extreme accents it's hard to tell what they're saying sometimes. But that's not a bad thing, it just keeps us looking up more details online and learning all the more.

My first choice to program is Ruby, but I'll quickly go to Python for it's well developed libraries if the task calls for it.I would like to say I'm open to learning many other languages. HACK, by the makers of Facebook, is one I really want to learn. I love web applications, and this looks like a beautiful language. A true programmer will continue to learn more languages."

"Do you like to do more front-end or back-end development?"

"I like whatever remains simple and beautiful. For front end development, everyone has a web browser on every device, and it's simple to develop for. So for me the best front end development is web development. But that's just aesthetics. I love mysteries remember? So give me the back-end problem solving code and I'll be on the hunt."

 "Tell us something that most people don't know about you. :-) "

 "I know that the mind is the best tool you can utilize. It is your 'way' of thinking that defines, or redefines everything. What I speak of is worldview(s). We often limit ourselves by believing before knowing. What this leads to is what I call “self-fulfilling prophesy’s”.

If you believe you will be poor all of your life, then you end up living in such a way that proves that. For example; some one who believes a jump won't hurt them, are more likely to make the jump. And one who is afraid of a jump, will most likely not jump and believe their fear to be fact. These are self limitations.

I believe that in all area's of thinking we can expand our worldview and become bigger and greater people for it. And so I help myself expand my worldview, and my understanding, by reading and studying patterns of good thinking. Author's that have helped me greatly are people such as Zig Ziglar, Jim Rohn, Dale Carnegie, Ravi Zacharias, and many others. There will always be more to read, learn, and grow from.

Lastly I root my understanding, and my foundation, in the Holy Bible and Jesus Christ, the risen Son of God. He provides reason for living, hope, meaning of existence, purpose, and lastly He gives us value. I love sharing and seeking truth, and I am open to all who want to talk on these subjects.

If anyone would like to take a look at some of my projects and code feel free to head over to my GitHub. " And feel free to follow me on twitter @6ftdan

Tuesday, April 8, 2014

Everything is basically an API

I apologize for not writing, I am kicking butt trying to learn new stuff and loving it!!! I am getting one on one instruction 3 times a week for a minimum of an hour each session with our chief computer scientist so I am pretty stoked!

The only drawback if you can call it that is he has a WEALTH of computer science knowledge not to mention a PhD in computer science. The man is intelligent and knows so much that I think his hardest part is trying to dumb stuff down enough for me to understand it =-)

Basically I feel giddy with excitement. I mean think about it, I'm getting paid well to learn one on one about node.js and computer science in general from a PhD computer scientist with 40 years of experience. Can you feel the excitement, and the reason why I haven't had time to post lately?

I had to write today to let everyone know that it doesn't matter what your background is whether you are a: truck driver, painter, college student, construction worker, etc you can make the switch.  Which by the way I have received emails from people in all of the previously mentioned professions that are all trying to learn to code and one day live the dream.

The hardest part with learning to code is that it's easiest to quit when just getting started because everything is SO overwhelming, so much to learn & so many new concepts to decipher. Not to mention the verbage I mean COME ON! Why can't everyone just call a method a method or everyone agree to call it a function. NO! instead it can be called: 'method', 'procedure', 'function', 'calling', 'running', a 'subroutine' I mean my goodness not to mention all of the other computer science terms that make your brain hurt when you've never been exposed to them before.

One that confused me for the longest time was client, server and API relationships, how it all fit together. I'm not there yet but let me just say it's all making a LOT more sense, although I think it's too much to write in this post. Basically everything in computer science is all just layers and layers of abstraction all with an Application Programming Interface. It's almost like: 'OHHH...this isn't as hard as I thought kind of moment, it starts to all make more sense :-)

Well that's where I'm at right now, keep coding peeps!

Thursday, March 20, 2014

Udacity CS 101 versus Stanford's CS 101

I am currently learning Javascript, It's funny how many different ways there are to learn: tutorials, classes or just simply making something which is what I am doing currently.

I am still taking Udacity's CS 101 converting the Python into Ruby, which is going well. I did half of Stanford's CS 101 course but ended up stopping because although a nice introductory course, it doesn't teach you how to write code which is in actuality the hard part and takes skill which can't be faked.

I am realizing more and more that a lot of online places (that charge you $25-$30 a month just to use their courses) actually aren't super concerned, if in the end of taking their courses for a year, if you are really able to write any code on your own or not.

When I originally started learning how to code I naively thought that the more expensive a class was the better it would be and the faster I would learn. I think most places are more concerned about getting you to come back each month and pay them some more money.

Not that they are all bad but I do have some bad stories that I may or may not share in the future about some of my own experiences.

It has taken me a long time to also figure out how to spend my learning time ONLY on things that will help me become better at coding. I can sit at a computer and spend 3 hours learning cool things about I.T. but am now learning that I can do that for the rest of my life and still not be able to solve coding challenges.

The emphasis I realize is for myself and wanting to become a really good web developer. I need to spend 90% of my learning time actually writing or playing with code. Sounds stupid I know but that is why I dropped Stanford CS 101.

Stanford CS 101 is a great course, great teacher and it's FREE! But, you really won't learn much about how to code, which is the toughest part of coding. I would say maybe 20% of the class is actually coding exercises. It's a good basic CS overview if you want one. Just don't expect to improve your coding skills from it. 

Udacity CS 101 on the other hand is just the opposite. It starts off deceptively easy and then ramps up the coding challenges and becomes tough quite quickly. I don't think I could recommend it for an absolute beginner because it assumes you already can code and have STRONG logic and problem solving skills. Which probably isn't the case if you are just starting out.

The good news is Udacity's CS 101 really DOES teach you how to code. There is tons of coding challenges for every Unit and then LOTS of additional optional homework for each unit. Just so you know when I say lots I'm talking 15 or more additional optional homework assignments per unit, which can be challenging.

That's one of the many reasons why I am just on Unit 3 of 11 in Udacity's course and the fact that I am doing all of the optional homework by converting Python to a Ruby. Which is teaching me how to look through the Ruby docs better. 

What is funny is that while both classes are called CS 101 and are college level classes, Stanford's CS 101 can be done in 1 week if you work hard. While Udacity's CS 101 will take all of 7 weeks and probably even more while working hard on the coding assignments. Unless of course you just Google and paste in someone else's code. I am assuming that you really want to learn how to code, meaning that you personally have some coding skills and can solve some coding challenges on your own.

That my friends is the hardest part. You can find really cool frameworks like Rails and in a handful of commands have something up and running but the actual ability to know how to code (meaning solve coding challenges not just run a command) is a much slower and harder process yet still enjoyable process.

I'm making a class for this fall that I'm thinking I will do on Skillshare. It will be a beginner's class and focus on making a website from start to finish for a client in real life and in the end you should walk away with a profit. It would be cool to show students how to actually make some money while learning to code versus always paying $30 and having to eat those costs.

My idea will be something close to spend $20 for the class and then I will walk you through step by step, in a real life project, while you make your own as well. At the end of the course you sell yours for $100 (or more) netting you at the very least $80 or so depending on the exact dollar amounts.

There are SO many cool, dirty secrets that no one tells you about but EVERYONE who makes projects in real life does except for the noobs who have no clue.

Anyway that's this fall. I want to help new developers learn how to code quicker. I want to show others how to cut through all the clutter and make the learning to code journey fun and dare I say profitable.

Keep coding peeps!

Friday, March 7, 2014

Coding headaches are actually good.

At one time I actually had this idea that I would eventually outrun, this constant learning which can leave you slightly frustrated because you don't quite understand something, or a 'coding headache'.

Well here's the thing, after being hired for 8 months that feeling of always struggling to LEARN, LEARN, LEARN, MORE, MORE, MORE!!! has yet to leave and I now doubt it ever will, which is probably a good thing and not a bad thing after all. I am being to feel just a little more comfortable with being presented with something and not knowing it and then starting to try and figure it out.

This whole learning to code and hopefully one day be a top notched developer is a constant battle for more knowledge and understanding. I can't reveal the details, but all I CAN say is that I absolutely MUST start learning Javascript in the next 3 months no excuses because of some things going on. Another day another dollar, time moves on and in learning to code it's time to buckle down and study during lunches and at night when my 2 & 4 year old are in bed it's time to study some again. Then it's off to work to code and then the cycle repeats itself almost like an infinite loop, until either my head explodes or I am really good one day :-)

My one piece of advice to those who are trying to do like I did and teach themselves to code and then get hired, start getting used to not knowing something and try not to let it scare you. Instead do what I do now when walking through the office doors at work, be grateful and happy that no matter how stressful and swamped you feel, whether or not you get everything perfect, you will leave with more knowledge and information than when you walked through those doors that morning. Embrace it don't fear it, even when you screw up and get chewed out at work (and rightly so) for your mistake. Embrace it don't fear it, just one step closer to the goal of becoming a better developer.

My goal remains the same 4 years and 4 months from now, I want to be working as a senior developer somewhere. Laughable? Crazy? Maybe, I don't care I say make no small plans. Embrace it, don't fear it!

Keep coding peeps!!!

Thursday, February 13, 2014

How to know if you are cut out to be a developer

On days like this when there is lots of snow on the ground I used to fire up my forge, heat the horseshoes red hot, warm my hands and make special handmade forged clips on the horseshoes.

After 5+ years of shoeing horses full time for a living, I began to wonder if this was all there was for me, could I be anything different. I wasn't like the other redneck tobacco chewing, drinking farriers, I'd never worn a cowboy hat, or ridden a bull, but I longed to know more, be more and do more.

After making the switch to development almost 7 months ago, I have been emailed hundreds of times by people asking my advice on how to become a junior developer and also how to know if they are cut out to be a developer.

Here are 7 traits that I have observed the best developers I work with and know personally all have in common:

1)  Attention to detail, especially the smallest of details.

The old saying that 'almost' and 'close' only count in horseshoes and hand grenades is true, in development getting something 95% correct is still not going to work, a method that 'almost' works or a Css rule that has an image centered 'close' will not work. It's that extra 5% of effort to get things right that really counts and makes the difference.

«««  If you hate details, then you might not want to be a developer.

2)  Learning ALL the time.

At first this sounds sexy, your like AWESOME! I love learning new things! Especially if you come from a boring job or something that never changes like horseshoeing =-)  After a while though, it becomes a steady stream of knowledge, and if you don't like water, it will feel like you are stuck in a never ending, never knowing enough waterfall of learning that just won't stop. I literally learn 10 - 20 little new things every single day and I love it! My brother wants things that don't change and are consistent, he has told me he wouldn't ever want to learn how to code.

«««  If you don't like constantly having to learn new things just to keep up in an ever changing field, then you might not want to be a developer.

3)  Handle pressure, stress, and deadlines.

Yes everyone loves USING apps, but how about meeting business time lines, deadlines, and goals? When will this be done? How long is this going to take? Can we do more of these in this amount of time? Now remember the attention to detail? What are you going to do, hurry? Rush through your work and hope it's close enough? In a perfect world coding is so much fun, let's write some code that does something cool, eat pizza and have a coke. In real life there can be stress, not all the time, but it is VERY different then simply doing an online 30 minute tutorial. I love being pushed to my limits and I want to grow and become a better developer so I don't mind.

««« How are you at time lines and working under pressure? If you tend to shutdown under stress, then you might not want to be a developer.

4)  Organized

Now I know a lot of messy developers, who could SEEM unorganized, but what I am talking about is the ability to have an organized work flow. Meaning can you find how to do something on your computer easily and quickly? The good developers I know are usually able to quickly locate what file they need or have a built in alias or script to do tedious tasks, it's all about efficiently.

««« If you learn something new, do you write it down, or figure out a way to be able to repeat the same procedure? Can you organize a lot of different tasks? If not, then you might not want to be a developer.

5) Extremely inquisitive

When I was a teenager, a lady at the church I attended would tell me probably once a month, that I needed to STOP asking SO many questions and that it could be annoying. Although offended at first, I've come to realize that the best developers are always asking 'why'? Whether it's how a new app works or the way a building is being built across the street. Conversations around developers can always be heard starting with: " I wonder why they did it that way...?" I used to feel like I was weird when I would ask lots of questions, but I see now, that at least in development, it is a good trait to have.

«««  Do things that you don't understand making you curious? Do new things excite you to figure them out? If you don't have at least some level of natural curiosity, then you might not want to be a developer.

6)  Self taught

Yes I know many developers come from colleges and great schools, but that's not what I mean. Great developers are always looking up code samples or documentation to learn how something works, they don't knock on the bosses office and say: "We need a corporate training class for this new software". Good developers are constantly learning and figuring out things on their own, whether they have no degree or 5 degrees.

«««  if you need someone to train you or are waiting to take the 'perfect' class to learn something, then you might not want to be a developer.

7) People skills

This is not a common trait among developers, the truly great ones do have good people skills, but the vast majority don't. If you can get along with people, your boss and the business side of the company will love you for your ability to communicate and not look down on the rest of the world because they can't code.

««« If you hate people and have a hard time getting along with others, then you might not want to be a developer.

Monday, February 3, 2014

Learning to code: Day 468

It's been a while since we last spoke, but I assure you that I have not been sitting on my butt. On the contrary I have been busy every day trying to conquer the enormous gap of coding ignorance that separates me from where I want to be which is the Tiger Woods of coding (minus the whole getting hit with a 9 iron by his wife part) =-)

My friend owns this site and as you can see it needs some love I have been building her new site, and a friend of a friend wanted me to do some Wordpress stuff for her and said she'd toss me $300 for the trouble, so that was fun and also hard to refuse :-)

I'm still working on the Udacity course and loving it, just going at a snail's pace at the moment do to other factors. I can't say really much about work just that I have more responsibility which I love but it is also a challenge and keeping me extremely busy with my head down all day at work.

I have a course in mind that I know I want to teach on Skillshare or Udemy later this year, probably in the fall. I need to make sure that my idea can actually be done successful so I am starting to work on testing it out... can't really say much more on it then that for now, but I am really excited with the idea!

My friends new site isn't done, but I thought I'd put up a pic of the home page, I don't have it up on Heroku yet or else I would give you a link. The main image is just a 'place holder' for now. Sorry it's so small, I'll put up a link soon. keep coding peeps!

Friday, January 17, 2014

The 8 most essential Git commands

This time last year I could taste blood in my mouth, my front teeth felt loose, and I was so angry I had just been kicked in the face by a donkey whose feet I was trimming. It happened so fast it took me a couple seconds to really understand what had happened.

Well it's been over 5 months since the last time I have touched a horse. I no longer make my living shoeing horses. Over the past 5 1/2 months as a junior developer I have learned 8 Git commands that have saved my butt countless times and that I deem absolutely essential especially starting out as a new developer in the field. The first rule of development is just like in medicine: "First do no harm".

There are basic git commands, like 'git push' 'git commit' and stuff like that, but these 8 rules while simple are the keys to becoming trustworthy and responsible to not screw anything up on your development team.

1- 'git status'

I used to "sometimes" check what I was committing, when working on my own projects. Now after working on a development team I ALWAYS 200% of the time do a 'git status' or 'git st' as I have it for short on my machine. I then do a...

2- 'git diff' or use the GUI 'gitx'

I know some "purist" developers would never consider using ANY sort of GUI but I have to say using 'gitx' from the command line has helped me SO much to make darn sure of exactly what I am committing. Without 'gitx' installed, the next best thing is to type 'git diff '. I think it's personally a little harder to read, 'git diff ' will show you what was changed in the files about to be committed.

3- 'git log'

Now don't jump the gun, we still are not ready to commit anything yet, one last step I like to do is to check the log, just to make sure that I am paying attention and know exactly what branch I am on and what has been committed before, I do a quick 'git log', if every think looks fine and I am sure that I am on the right branch, then I go to...

4- 'git add  filename'  WITHOUT the ' . '

Yes it's fun to just do 'git add . ' which then adds EVERYTHING all the files at once. A much safer way is to manually do a 'git add filename' it's the same thing, just you have to type in each file name as you add them to git. I think for me that it helps me to establish good healthy work flow patterns so that I am less likely to make a mistake when under pressure or stressed. I will have a good mentally strong git work flow.

5- 'git commit --amend'

You then of course do a 'git commit -m "my first commit" ' but what is really cool and helpful as long as you are working on your own branch and haven't released your work to any other developers is to use: 'git commit --amend' after making your first commit to a project. It basically just keeps stuffing each commit into the next one so that you don't have a lot of different commits for small tweaks to files or in tweaking a CSS rule or something. The more important less routine the work, the less I will use 'git commit --amend' but otherwise a really handy command to know.

6- 'git reset HEAD-1' or 'git reset HEAD^'
If even after being as careful as possible you do add a file or something you didn't mean to, you can simply undo the last commit you did by either doing: 'git reset HEAD~1' or if you prefer 'git reset HEAD^'. This command is worth a million dollars when you are brand new and make a mistake as all new young developers will, not an excuse for not be careful, but definitely a git command life raft.

7- 'git branch -d  branch name'

When deleting lots of branches in my case usually 10 - 15 branches every week, I ALWAYS use the lower case '-d' versus the '-D' to check if the branch can be safely deleted. It's basically a built in git safety, use it.

8- 'git rebase -i HEAD~4'

I never thought I'd care about how many commits it took to complete a task or project. I thought as long as it was done and worked correctly, that was good enough. Well actually no, when working on a code base with thousands and thousands of commits, development teams like to keep commits as clean and meaningful as possible. Which means if you took eight commits to do something that should have taken one then you will need to interactively 'squash' your commits and then re push your work back up to git as one nicely formatted commit. Pretty complicated the first time you do it but it's really too hard once you get used to it. Something you should probably practice on your own project the first few times. Take a look at interactive rebasing and don't be scared.

Keep coding!

Sunday, January 12, 2014

Garbage Collection

I used to believe there was no difference between a software developer and a computer scientist, and when I read things online that said differently I chalked it up to people wanting to stroke there ego and just wanting to have a cooler sounding title.

I was wrong, recently I have been seeing the error of my ways more and more. I love the fact that I can make things using Ruby on Rails, and that Rails has all this magic that I don't understand. I also like the low barrier of knowledge required to start to make things, but I am also realizing that I don't know ANY computer science.

Take garbage collection in Ruby, sounds fairly boring till you read more about memory management and memory allocation and find that Ruby uses a mark and sweep method for garbage collection and that is one of the reasons Ruby can be slower in doing some things.

I am finding previously "boring" subjects are actually more interesting when you start to understand them and what they do little bit better. I guess the biggest difference between a programmer and a computer scientist is a programmer can use a language and a framework, to solve a problem. The computer scientist looks at the problem and decides which language or framework to use if any, while weighing out many factors and possible solutions that the average developer who just knows a certain framework or language would even consider.

The lesson I am slowing starting to understand is that I have about 300 years worth of learning to actually become a computer scientist and that is daunting as well as exciting. No longer do I just want to learn a specific language or framework.

By the way it's simple to see garbage collection at work in Ruby. Just type 'irb' and press enter into your terminal. Once irb is running, type ' GC.stat' to see garbage collection information. You can also run: 'GC.start' which will return nil, and then run ' GC.stat ' again and see the difference like this screenshot shows:

Yes, this could be boring, but I am actually finding it kind of cool to learn more and more things of what goes on under the hood. Keep coding peeps!


Tuesday, January 7, 2014

Udacity CS 101 Lesson 1 of 11

Well that took a while but lesson 1 is done, only 10 more to go :-) The course is supposed to take 7 weeks but we'll see. Here's the link to my Udacity Github Repo Udacity-CS-101 if you want to clone the repo and  run it on your local machine. The purpose of the repo is just for me to document what I'm doing and to keep honest with completing all of the assignments.

The course is done in Python, but I really want to learn Ruby so I'm doing everything twice, once in Python and once in Ruby. Already I've noticed some differences between Ruby and Python the biggest difference so far has been indentation. When I am using Haml I am SUPER careful on how I nest and indent elements, but in Ruby I guess I'm a little sloppy or just don't think about it.

I had 4 errors while doing the exercises in Lesson 1 and I looked through my code I couldn't find anything wrong. Then I realized I had one more space in front of one of the lines of Python. It's funny how you don't think about that when using Ruby.

I was going to go on and do another Udacity course after this one, but after looking around, I think I will take either one of these 2 courses here: Stanford CS 101 or Harvardx-cs50x . I really am enjoying the slow no pressure pace of the current course, and I just am thinking to myself that Stanford is the number CS school in the world at least according to the Huffingtonpost: best university computer science.

Who am I trying to impress? Why not take my time and get a really good solid computer science foundation by taking a couple different CS 101 courses, especially considering they are free. As long as I am learning new things everyday, and am able to take care of my family I'm a happy camper.

One day (many years from now) I want to be the Michael Jordan of software development. Today I had a small taste of what it would be like to REALLY  have an advanced skill set. I was able to use an advanced Css skill to solve a problem I was having while making a site. NOTE: I am not a Css expert, I have only been doing Css for the past 6 months, however it felt really good to know how to fix something using an advanced skill.

Anyway enough bragging, I'll let you know how the course goes, so far I highly recommend it!


Tuesday, December 31, 2013

Udacity CS 101

I am a very goal driven person and as 2013 comes to a close, I always plan ahead for things that I want to accomplish in the new year. I had several things in mind for 2014 that I wanted to do that I thought would have the potential to make fairly good money and others that were just cool.

I have instead decided that I need to focus on filling ALOT of missing Computer Science knowledge instead of being so much of the entrepreneur that I typically like to be. With that being said, I will be taking Udacity's CS 101 starting in 2014. Hopefully after that course is completed I will continue on with other Udacity courses. Here's a link to the course: CS 101 . The course is done in Python, but I will also be writing it in Ruby on my own as well.

Last year was such a rush and a constant trying to learn as much and as quick as possible as I could that I felt like I was drowning in CS sometimes. This year I plan on really enjoying learning new things, and not caring how long it takes. I'll give updates on how I am liking the Udacity course as it goes on.

Since I've been getting pretty decent traffic on the blog these days(usually over 10,000 unique visitors per month), I decide to put up one ad on the side of the blog just to see how it went and if it would bring in maybe $50 bucks a month or so. The first day running the ad I made $3.40. I then decided that I didn't want 'Viagra' style ads or religious ads on my blog, so I went into Google's ad sense settings and edited which ads were allowed on my blog in the end removing quit a few.

Long story short after tweaking the Adsense settings for the blog, I have been making roughly $0.03 per day, which is why I decided today to remove the ads. I didn't mind an ad as long as I wasn't in my mind being a 'sell out'. Well no more ads, lesson learned. It was a good learning experience looking up how Google sells batches of ads and stuff.

On a different note, every year my wife picks a word for her year. I decided that this year I would do the same so, my word for 2014 is: Positive. I want to be more optimistic and positive in everything that I do and my entire outlook on life. I hope you have a great new year and that you are looking forward to 2014 as much as I am!

Keep coding peeps!


Monday, December 23, 2013

My old arch enemy ' rm -rf ' rears his ugly head again!

Some people are great friends all the time, some people are good friends some of the time, ' rm -rf ' is almost NEVER a good friend :-(

So I made this little html file that called external css and javascript files that hid a scary monster image until a button was clicked. I wanted to show you some cool new things that I've been playing around with lately and show you the little site up and running until I made a HIDEOUS mistake and accidentally deleted the entire folder that had the files.

How?...a long story that is ultimately pointless and happened :-(

So, you will just have to check these out on your own for now until I make something else to show you:

Get a website hosted directly from your GitHub Repository for free, I never had heard about this or knew about it, pretty cool.
I had always heard of Jekyll but never looked at it, it's cool and worth checking out!
I love Heroku, but when I first made a site and hosted it, the site would take FOREVER to load. I found a cool little trick here: Heroku: Depriving your free dyno of sleep and thought I would pass it along, I have Uptime Robot running on 2 sites of mine now.

All the best peeps, keep coding and have a Merry Christmas!

Tuesday, December 17, 2013

The Blacksmith secret that a "junior" dev uses everyday to stay mentally sharp

For the longest time I wasn't going to admit to anyone that I actually do this much less show you. 4 1/2 months ago when I was shoeing horses for a living, whenever a client was late or didn't show up I would take a golf ball and bounce it off of my 2 1/2 pound rounding hammer to pass the time.

After learning to code and getting hired as a "junior" developer I gave away all of my shoeing gear and equipment to other local blacksmiths and farriers. The entire first month at work as a "junior" dev I would always go home with a headache. I noticed that after lunch I would feel a mental "coding fog",  the stress of a whole new environment and constantly trying to learn as much and as fast as possible was burning out my brain.

One day at lunch I was feeling mentally "tired" and thought back to how I would always feel mentally "sharp" after doing "hammer drills" for 10 minutes while waiting for clients to show up.

I looked around the office found a small hammer and a golf ball that our front end manager had.
I went to an empty conference room and  after 15 minutes of practicing bouncing the golf ball off of the hammer and switching different hands right then left, right then left I felt amazing! I went back to my desk feeling extremely refreshed and very focused. Since then, at lunch I sneak off into a conference room and do 10 -15 minutes worth off "hammer drills"

Every night I work on small projects on my own time to try and improve my coding skills, whenever I get stuck with something or find myself stressing out and having to read something multiple times, I do 5 minutes of "hammer drills" and am able to concentrate much better.

Laugh if you want, yes it's kind of awkward/embarrassing, but there are lots of studies on how "juggling" makes your brain grow and become more focused due to "active stress". I don't know, what I do know is that it works for me, and I thought I would let others know so if you are feeling crazy "coding" stress you could give it a shot.


 Don't knock it until you try it! Though if you haven't been shoeing horses your whole life, you might want to try using a wider hammer like a mallet the kind you use for knocking in tent pegs. Give it 10 minutes next time you're feeling stressed and see if it doesn't help you focus better.

Keep coding peeps!


Wednesday, December 11, 2013

The Git command every "junior" dev needs to save their butt.

Unless your perfect and never accidentally hit the wrong key when you don't mean to than keep reading.

Most Github articles walk you through some good basic commands others are WAY too advanced and in depth for beginners.  This command is the one to know when you have messed up. After knowing this command, you will have the absolute confidence and ability to not freak out when you do make a mistake.

I was doing front end work last week and made the mistake of getting caught up emotionally in an email from one of my bosses to check on a different site I had just made...BLAH..BLAH..BLAH long story short I ended up making some tweaks to the site that I was emailed about and quickly committed the changes as a "dumb-trying-to-impress-his-boss-noob" developer does.

Now here is where the story actually gets good. 3 Months ago I would have been freaking out and cursing myself under my breath for not being more careful and "measuring twice before cutting once".

However now after committing the coding atrocity I simply typed in 1 command and life was good once again and no one was the wiser to the fact that I had violated every good and healthy safety code check that should be done before committing your work. The magic Git command?

All I typed in was:            'git reset HEAD~1'

That's it! That command is your: "Get out of jail, I messed up with Git command"!

The best part is, its a totally safe command that doesn't erase your work or do anything that you don't want to happen. You are simply resetting the last commit, it doesn't erase anything it simply resets everything to how it was before the commit. You can reset the last commit many other ways, but for me this was a really easy one to remember that hopefully I WON'T need anytime soon  =-)

Please share in the comments what I did wrong, I know I was an idiot but being able to fix my mistake and not having to ask for help from the other developers, like the first month at work. I  realized that other young developers might want to keep it handy as well =-)

Monday, December 2, 2013

Why new developers should write crappy code.

Some things about development are not taught in college, some things about development are not even taught on the job. Some things you are just "assumed" to know, almost as a 'gut' instinct. You can take every great tutorial on How To Code and memorize all of the "Best Practices" but that is no better than simply memorizing the answers to a test in school. At the end of the day, what did you truly learn? What do you really know?

As a junior developer working on a team with a lot of senior developers, I get to spend my lunches listening and learning from them and I am very fortunate and grateful for that. Yes, I got hired  from a very blue collar background of shoeing horses for a living with no college education and although that's great I am painfully realizing that I am lacking any 'gut' instinct. I had simply memorized enough of the 'test' answers to get hired.

How does one develop a true 'gut' instinct for knowing how and what to code? Everyone will give you all sorts of different answers from: You'll get there eventually to Never look stuff up to Always look stuff up that you don't know. I think the answer (at least for myself) is writing crappy code and making tons of mistakes. I think we should encourage young developers instead of learning everything about the best practices with methods right off the bat. Just try to make a little command line game, like Hangman, without using ANY methods.

No longer will the conversation be: "What's the reason why we do 'x' like this or that?" or "What's the best practice?". Young developers will truly KNOW what not to do, and will instinctively go towards better ways of making the code better especially if they know an experienced developer that they can go and ask questions which can also help prevent bad habits.

I know for myself if I don't know why I am doing something I am going to try to make a program not using the thing I don't understand and see what happens. For the last few weeks everyday after work in the evenings, I fire up the text editor and just start making things. I know without time pressure or this is the only way to do it mentality. I have learned so much and am having a BLAST!

I am slightly embarrassed to admit that at lunch today I showed a program that I made on my own time that was giving me an error to a very senior member of our team and the first thing he said was: "Josh this is bass backwards!" and showed me why I was getting the error. That lesson today at lunch clicked in my head and will not be repeated because I had spent an hour last night trying to make the program work.

I know at least for me in my free time I am going to be writing code and enjoying the whole learning process without worrying about if it's the perfect way. I don't think new developers should write experimental code like this obviously in ANY sort of production code base but I think young and upcoming developers shouldn't be pointed to just tutorials. They should just make something on their own regardless of how crappy it is. I think that is how a true coding 'gut' instinct is born.

Wednesday, November 27, 2013

How "junior" developers can become Regex wizards

You need a Regular Expression to validate a phone number or a user's email address, so what do you do? Go onto StackOverflow and copy someone else's code and paste it into your code and be done with it? Well that may work, and if you are in an absolute pinch that can work, but what have  YOU personally really learned? Zilch.

At my job as a "junior developer" I am starting to have to use Regex (Regular Expressions) quite a bit to validate/check for certain things. I could become a "Googling wizard" but I'd rather expend the energy and effort now to become a "Regex wizard" instead. The truth is, Regular Expressions seems
daunting and intimidating, and they may be at as they get more and more complicated, however I think Regex are just different and you need to slow down and think of them as symbols and not try to rush through.

With that spirit in mind I recorded myself doing a basic Regex date string, I did it "cold turkey", so as to be authentic, and real. I did make one mistake and then fixed it, so you can see I'm quite new to this and human :-)  The point is not how much I suck, the point is to go ahead and just try to make your own Regular Expression before just "Googling the answer". I want to be a good developer one day, and I think as a young developer we should put in the extra time to try and really understand something and not just always do what is the quickest.

If you are new to Regex, is your friend. Put test strings in the box on the site and then look at the Regex "cheat sheet" on the bottom of the page when you get stuck or need a refresher. To the right you will see a blue bar that tells you if you are matching the 'test string' correctly or not which makes it easy to tell if the Regex you are making is actually correct or not.

The other thing is, DON'T RUSH, if you can't take a few minutes at work to fiddle with Regular Expressions, then make sure while eating some turkey and watching the game at Thanksgiving tomorrow that you pull out some random strings to try and match, I find it's actually really fun and not stressful if you don't pigeon hole yourself into a time crunch.

I always have my "mentor" developer at work double check my work when in doubt. NEVER put something that you are unsure of into production. Certainly on your own projects and stuff you should be able to take 5 - 10 minutes to have fun with some Regular Expressions.

Keep coding!

Monday, November 18, 2013

I give you permission to no longer ask for permission to learn to code

Craziness happened this last week. My blog post went viral on Hacker News and Reddit, over 34,000+ people read the article in one week. Needless to say I got inundated with emails from lots of people who are trying to learn to code, others who are trying to get hired. I'm still trying to get back to everyone so I apologize if that's you.

What amazed me was the fact that people are asking "MY" opinion, (feeling like an impostor) just because I started from zero knowledge and actually got hired. Here's the thing though that I would say to everyone who is wondering if they should learn to code or if they "can" learn to code. Here's the thing: if you want it bad enough you can accomplish virtually anything so my answer is of course, "Yes! and Yes!".

I'll tell you a secret that helped keep me motivated when I was really discouraged and felt like I would never understand something. I would watch the movie In the Pursuit of Happiness with Will Smith. No matter how bad things got, they were never as bad as he had it. Not only is it an inspiring movie but it's also a true story. I find that a lot of people that email me are basically saying: "Hey how can I get a really really easy job that pays a lot of money... TOMORROW!!?"

I explained that it actually takes a lot of hard work and usually that's the last I hear from them. Then you have the other side of the coin: You have 80's mindset developers who practically scoff at the idea of "teaching yourself to code" and always point you to Peter Novig's article Teach Yourself Programming In 10 Years. I honestly like Peter's article and agree with it, BUT I think you can learn enough programming/coding skills to be able to add value to a company in a junior role certainly in 6 months to a year.

It's not like a company is going to give you the "root" passwords to their databases on day one even if you were a database wizard. Some things are simply about trust and establishing a relationship over time proving the quality and type of person you are.

So I give you permission to no longer have to ask if you can learn to code or get hired, the short answer is yes if you want it bad enough. That may even mean you need to relocate. Which brings us back to the question of how bad do you really want it?

The hardest thing for me about working in a new field is not being that good at it and having to ask for help and then banging my head against the wall or apologizing and fixing my mistakes. When I was a Blacksmith/Farrier I felt 100% confident that I could make 99% of all the horses that I worked on to move and feel better. I love the confidence that comes from absolutely knowing what your doing and having the experience (from lots of mistakes) of what doesn't work or isn't the "best" way to do something.

I no longer have that same confidence I had when dealing with horses when it comes to coding and in fact most days I have a slight migraine from trying to learn and absorb everything I can. That is what drives me now, I don't want to just have a job. I hate not being really good at something, I hate being the guy who can do the task but if anything goes wrong outside of the norm, I would drown. I push on for the day when I have enough coding history that I can actually draw from it. It's many years down the road but the quickest way to get there is to step on the gas.

I've been bad about blogging, lots of things going on but I do have some big plans for the end of December - early January. I'm playing around with some smallish ideas until then so don't worry. This isn't a "ghost" blog that will dwindle away. It just took me a while to get acclimated to the new place.

Watch out peeps, I've got big dreams let's see if we can make them happen!

Keep coding :-)  


Ruby on Rails: Faliure

When I was a kid whenever I would put too much food on my plate and then not eat it all my dad would say: "Josh, I guess your eyeballs were bigger than your stomach...don't take more than you can finish".

Well apparently I still have not learned my lesson on that completely which brings me to the very sad news that +Dustin James  and myself have mutually agreed to end the:  Get hired the hard way mentorship program. 

Why? Not from lack of effort on Dustin's part, in fact he is much farther along at one month than I was at 3 months. The simple reason being there are zero listings for RoR jobs in Manatobia, Canada and a very small sporadic Ruby user group. The truth is I should have checked the tech market place and done some research. In short I failed,  my eyes were bigger than my stomach.

The good news is Dustin is still learning Ruby on Rails and I will be giving updates from time to time just not at such a "rabid" style pace. The man is smart and very talented. He will do well! Keep following him along his journey on his Blog

I guess the lesson to be learned is, you may have to move to get hired even if you are good at RoR. There are definitely certain areas of the country where it is easier to get hired as a junior dev just because the demand is so great.

My apologies to the junior rails community, keep coding :-)

Sunday, November 3, 2013


Everyone everywhere is pushing this whole "Learn To Code" movement, but is it actually possible? This former Blacksmith/Farrier says a resounding: "YES!"

I wrote a Book on how to do what I did, but here's the condensed version of how I went from zero experience writing code to getting hired 9 months later as a junior developer and how you can do the same! I finally decided to teach myself to code after getting my hand kicked real bad and breaking my thumb while shoeing a horse. I came home and told my wife that I was done with shoeing and I was going to teach myself how to code and get hired, despite no experience and no degree. That was October 23rd 2012. (9 months and 2 days later I was hired by ZipList in Reston, Virginia).

Month 1
~Pick a language to learn. I recommend Ruby on Rails because it's fairly easy to learn and there are a lot of entry level jobs for Junior Developers. In order to get hired 8 - 9 months from the day you start, especially with no degree as such in my case, you MUST start marketing/networking NOW!
~ Start a blog today and blog 3x per week.
~ Start a Twitter account and start getting some followers (they may later become your employer).
~ Join every local Ruby on Rails Meetup group within 50 miles and attend EVERY meeting. Start making relationships now and let people know what you are doing. You'll also learn more than you can imagine just by listening to "coder lingo".
~ Start installing stuff and getting your "dev" environment set up.
~ Download and start learning how to use Sublime Text 2.3 .
~ Complete Zed Shaw’s excellent book: "Learn the Command Line the Hard Way". If you are not familiar with using the terminal.

Month 2
~ Start Chris Pine's "Learn To Program" Book.
~ Complete the first 15 lessons of Git Immersion which is free online.
~ Take Mattan Griffel's excellent course which cost $49. Trust me it's the best money you'll ever spend and I don't receive a penny for recommending, it's just that good!

Month 3
~Complete Zed Shaw's other awesome book "Learn Ruby the Hard Way". It's tougher than Chris Pine's book but you should be ready for it at this point.
~ Spend the rest of this month catching up on all the loose ends of stuff you didn't totally understand or got done in the previous month. Completely "flesh out" the Rails app you made while doing "One Month Rails". "Learn Ruby the Hard Way" is a lot to do in and of itself in one month.

Month 4
~ Make a basic web app and get it online and DNS working correctly.
~ Find a friend with a TINY small business (any business) or you can just find a crappy old site that needs a serious facelift (farmers markets are a great place to find these).
~ Make a basic site using Twitter bootstrap (look at Michael Hartl's Rail's Tutorial for help).
The goal is to make and deploy online a real website for a small business. You will learn so much from having to make something from scratch and have it online in 30 days. You'll struggle but don't give up!

Month 5
This is where things get real, by the end of this month you should have made a pretty kick butt Twitter app. Now is the time to take on the BEAST of all tutorials:
~ Michael Hartl's Rails Tutorial, all 547 pages of it. The first 3 of the 11 chapters should be easy because of the other things you've done. Go through all 11 chapters and NO "copying and pasting".
This tutorial will probably take you a solid month if you work hard on it. You have now made 2 sites to show potential employers down the road! You should volunteer to speak at local meetup groups and give a talk on how to do something basic for beginners, this is the best marketing you can do.

Month 6
You are getting close and at the 6 month point you want to really let people know that you are serious and are actively pursuing a junior dev job.
~ This month you will want to launch your own personal site. Make a video on your site about who you are and what you've done and that you are looking to be hired.
~ Put your resume up on,
~ Make a Linkedin portfolio to get the word out.
~ Give another talk at a meetup group because this is where you'll more than likely make your connection to get hired.

Months 7 & 8  
This is where you start juggling.
~ Give as many short talks at local meetup groups.
~ Get back to recruiters, do phone interviews, respond to emails.
~ All the while within these 2 months you need to make a web app with 2 other developers to show employers that you can work on a team and also to make a really cool app to demo to potential employers.  Stay the course, you’re almost there. Soon you will be sitting in engineering meetings and drinking free espresso every morning!

The last 2 months were the hardest for me personally to keep up with. From interviewing to working full time, with a family and still trying to learn and make an awesome web app so needless to say- I didn't sleep much. Plan on getting around 4 - 5 hours of sleep until you are hired. Know this though: if you study hard and follow the plan, you can get hired 8 - 9 months from today!

I studied 21 hours per week mostly from 10pm - 1am or until I fell asleep on the couch. If you can study 3 hours per night you can get in 84 hours a month, which is really good! Don't give up, stick with it and you can change your life, start a cool career, and make great money in a short amount of time!

Wednesday, October 23, 2013

Learning Ruby on Rails Day: 365

1 year ago I came home from shoeing horses hurt, angry, and determined. I hugged my wife and cussed at "them" and said: "I don't care if it takes the rest of my life, I am getting out of shoeing! I am going to teach myself how to code and get hired!"(quite a few cuss words were removed from that sentence) =)

What a year, what an adventure and man do I have a WAYS to go. I can't wait to get to work each day and to learn more, it's great! 4 years 9 months from now I want to be a lead/senior RoR developer, so I need to get learning and make "magic" happen if I'm to accomplish that.

Thanks to everyone who has helped me out especially +David Bock, +Jim Gay,  
+Jason Wieringa ...there are MANY more but those 3 encouraged me the most and I am grateful. I started 1 year ago with zero knowledge, zero connections, and knowing NO one.

Everything I've done, anyone else can do and probably quicker and better. The purpose of this blog was to hold myself accountable and make it publicly known what I was doing. The purpose of this blog now, is to help of noobs, to make it as "junior" developers and to document my 5 year junior to becoming a "senior" developer.

In other news....I offered to do a monthly Google Hangout, but didn't get much response, so I won't be doing it after all. I didn't get to hang out with @codestoic last Sunday, because he had some internet problems, but will make it up this coming Sunday. I will keep you posted on how things are going for him and his journey!

I truly believe we can accomplish 99% of what we set our minds to. 
As Babe Ruth said: "It's hard to beat a person who never gives up."

keep coding peeps!

Wednesday, October 16, 2013

Learning to code: Day 359

Well I can't believe it, it's almost been 1 year from when I decided to teach myself how to code and get hired on my own. A lot has happened in less than a year it's hard to believe sometimes. I am just now getting used to not shoeing horses and catching myself saying: "I shoe horses" when asked what I do for a living.

I was shocked when someone at work said: "Oh he's one of the engineers" I was thinking, I hope no one hears that :-)  My back used to hurt me SO bad I couldn't sit in a chair for more than 30 minutes. It is just now starting to really feel quite a bit better and not hurt all the time. I've lost my last callous on my hands. I was riding home with a weird feeling today thinking: "Holy crap, everything is so different for me now."

Some big things are happening still, my friend +J. Terrell Allen who 's learning to code himself and is currently an awesome writer recently took my book and gave it a much needed facelift and made it look like super sweet. I will have the "much better formatted" version up on Amazon sometime this week. Thanks J! If you guys need any work done in regards writing, you need to look J up at @jterrell. Even if you don't need any writing done, check out his inspiring "learn to code" blog at J.T's Big Coding Adventure J is a former pastry chef, technical trainer and currently author and freelance writer. The man is going places :-)

This week I was also just contacted by Listen and Think Audio™. They said they really liked my book and wanted to make the audio version and put it up on, Listen and Think Audio™ heard about me from Dan Miller's Podcast. The whole process to pick out a narrarator, record the book and get everything done will take 6+ weeks so it won't happen tomorrow but it felt really good to have a company contact me out of the blue.

I currently am mentoring +Dustin James for the next 8 months (or until he gets hired) and do a Google hangout with him every Sunday night when my kids go to bed. I was thinking though that I'd like to teach some basic things that would be useful, maybe do a monthly "group" hangout, just for an hour or so. I'd teach things like: "How to quickly make a Gist using Jist", "How to install some basic Gems", "How to do some basic Html/Css", "How to convert Html to Haml", "How to use Firebug like a pro". 

I'm not sure how many people can get on a Google hangout at one time, and I'm not sure how much interest there will be. If enough people are interested, I'll do it, if it goes well, I'll do it again.
Email me if you want to be in the first "group" learning session. Email me at Also tell me 3 or 4 things you would like to know more about. 


Monday, October 14, 2013

Ruby on Rails Interviewing: Final

I've mentioned him many times before as one of the instrumental people in helping me on my learning to code journey Jason Wieringa. Jason is located here in Northern Virginia and is an excellent RoR developer who is looking/exploring his options looking for a good fit to be part of an awesome development team. If you would like to know more, contact Jason on Twitter at @jwieringa, +Jason Wieringa  or his email:

How many of our most important or break through moments come unexpectedly or not how we thought they would? 

I was given the opportunity to apprentice with a really skilled highly respected farrier because I made his friend's "Triple shot White Mocha" "the best", while I was working as a supervisor at Starbucks.

 I was able to shoe for an Olympic equestrian rider because a client said: "Oh, Josh he's the best at shoeing Dressage horses!"…boom, I'm shoeing for an Olympian! 

I was hired not by replying to every email and answering the phone for every recruiter that called, but by getting lost in the wrong building and bumping into Kalimar Maia who was also in the wrong building =)

Yes, that's it no secret technique, I was lost and introduced myself to Kalimar and asked if he was going to the Ruby Meetup group as well, and he said yes. We talked a little and hit it off well. We found the right building and I happened to give a short 5 minute presentation that night. Kalimar said I did a good job and that we should get coffee some time.

Kalimar emailed me the next day and I said I'd love to meet for coffee and get some advice on how to get hired or just about development in general. Anyway long story short I had no idea that ZipList was thinking of bringing somebody new onto their team. We met for coffee and towards the end of the conversation mentioned the idea of applying to ZipList. Just over 1 month later I started my first day at ZipList on August 1st!  2 weeks later I completely finished up with all of my shoeing practice and have not touched a horse since!

The moral of the story is: BE NICE TO EVERYONE!….especially when on an elevator =)  Seriously though the "secret" to getting hired as a junior developer is to simply go religiously to local Meetup groups, give short 5 - 10  presentations as often as possible without being obnoxious, and finally after the meetup has finished, go to the local "hangout" afterwards.

From all the emails I receive, I find there are 2 types of people who want to get hired as junior developers. Those who are highly talented/skilled yet never attend any local events or meetups. Then you have the people who basically want to get hired after 2 days of "learning to code" and think they should be making $100K a year and can't believe it actually takes a lot of work to get good enough to get hired.

I know 5 people who are really talented developers (who I won't embarrass here) that no company even knows exist or else they would snatch them up in a heart beat. The reason these 5 developers aren't hired is simply a lack of networking/marketing. You don't have to be a butt hole to get your name out, just be nice and have something interesting or helpful to share and do it consistently.

Yesterday's Google Hangout with +Dustin James  went well, the guy has made fantastic progress putting in 18 hours with still 2 days left in his week! I love working with someone who doesn't mind a little hard work. Watch out for this guy, he is going to knock the coding world's socks off! I am VERY impressed!

Note: Dustin is studying 21 hours per week and lives in Canada, if you want to pair program with him, to learn from him or help him learn faster, hit him up at @codestoic. He is currently in Chapter 11 of Chris Pine's "Learn to Program", so if you've gone through the book before, maybe a Google Hangout is in order :-)

Keep coding peeps!


Thursday, October 10, 2013

Ruby DCamp 2013

I've been pretty busy these past 2 weeks and have been just getting over a serious illness.

Ruby DCamp, yes I was one of the "chosen" only 78 people from around the country and some from Europe get to attend Ruby DCamp each year, and yours truly got to go. First let me say, it was either "nerd heaven" or "nerd hell" depending on your take on the matter. I was warned that I would see some "nerdness" that might be slightly unsettling :-)

Over the weekend I got to learn some: Kung Fu, the ancient game of 'go', Rspec testing, Lots of pair programming, Conway's game of life, how an 'unconference' works, had great food, played Frisbee golf, and got to hang out and talk to some of the coolest/nerdiest people I've ever met :-)

My little kid Ian ended up getting really sick and I had to go home a day early but all in all, I highly recommend going if you can find a way in. A shout out to Chris Mar for taking the time to slowly walk me through Rspec testing, he has an awesome way of bringing things down to your level and making them very easy to understand. That 45 minute pairing session with Chris was worth going to the entire camp on it's own!

I was surprised when I first started trying to learn to code, how every programmer/engineer I talked to who would always "get philosophical" on me whenever trying to explain or describe something. I thought it was interesting to see that it's not just a "local" thing. There were moments when I thought I was in a "theology seminary" and others at an "atheist" convention. Programming and design is all around us in life, I guess I shouldn't be surprised to see these type of conversations prevalent in the development community.

Anyway, had another great day at ZipList, kicking butt learning lots everyday and enjoying it! I can't believe it's been just over 2 months working here now, and to think I haven't picked up a single horse's hoof in the past 6 weeks! I hope to continue that streak for the rest of my life :-)

I'm doing a Google hangout with Dustin James the guy I'm mentoring from Canada who is going to get hired using the "road map" outlined in my book. I am so excited to get this whole thing moving along. I never wanted to be a "teacher" growing up and work at a school, but I realize as time goes on I do love teaching/coaching in general whether or not it's in an academic enviroment.

I'll let you guys know how it goes :-)    


Monday, October 7, 2013

"Get Hired the Hard Way" ...And the winner is???

I apologize for the long delay but I assure you it was worth it. I was surprised by how many people signed up and applied for "Get Hired the Hard Way". After much deliberation I narrowed the field of candidates down to 4 and then had to make some VERY hard choices and finally decided on 1!

Welcome to the winner of "Get Hired the Hard Way": Dustin James of Manitoba, Canada! Here's a short bio of Dustin:

My name is Dustin James - father, husband and Canadian.  I have a business degree and have worked in that field since graduating from University way back in 2006.  I have a small background in web development and am a co-founder of a start-up community here in Canada.  Personal interests include comedy, cartoons (I'm 30), fitness, sports, coding and thinking about the world's problems. I am unwavering in my attempt to find truly fulfilling work and I decided that Josh’s challenge was just what I needed to finally take the plunge and chase some dreams.  Looking forward to self-authoring a new chapter in my life with direction and help from someone who has done the same!

Today is October 7th, 2013 my promise is to help mentor/coach Dustin along and to have him hired no later than 8 months from today June 7th 2014! There I said it, hold my feet to the fire, follow along and if you ever needed a kick in the pants to get started and stick with your goal, now is the time!

Don't just watch success unfold before your eyes and wish it was you, make it you! Start a blog, open a book, fire open the text editor and make something! 8 months from now you'll be a totally different person...but you must start!

Okay, enough of that, Dustin has started a blog so please go follow it, and also go follow his Twitter account, this guy is going to be awesome!

Blog: Follow Dustin's Blog

Twitter: Follow Dustin on Twitter

Dustin has agreed to the tough challenge of studying a minimum of 21 hours per week! I will be giving updates on his progress and how the studying/training is going and stuff we are working on.

If Dustin does not get hired by June 7th 2014, I will have failed and will be publicly embarrassed, so let's get doing some serious coding! =)