I graduated from college with a philosophy degree and took a job in marketing. That job wasn't really marketing, despite the title, and I ended up spearheading a digital marketing effort that was 95% technical project management. That was the point when I realized I wanted to be the person making the products, not managing the people making them.
So I did everything I could to get closer to the technology. I quit my job in the non-profit sector and moved to Chicago, took a job as a project manager at a technology/marketing company, learned QA processes, taught myself python over 12 months, built some scripts to automate tedious parts of my job, and eventually got a job in Automated QA.
Now I'm an engineer in SF Bay Area at a startup. And yes, every day I go home and realize that my brain is wrung out, my mind is exhausted, and I am totally happy with it.
Hmm, I really hope it doesn't go away. It's the best part of the job. I have seen a number of my peers still doing this after many years, and still experiencing the same thing.
I wish that all project managers knew how to write code. In my experience this is not the case. None of the time that I spent managing software projects was while I knew how to code. That's about 1 year doing vendor evaluation for a non-profit, 11 months doing requirements docs and manual QA, and 7 months in a 'Scrummaster' role.
I'm currently learning how to code. The biggest problem that I consistently have is getting the damn thing to work. I'm about halfway through the Hartl Rails Tutorial, and moving at a snails pace because I have to google error messages every five minutes.
I end up spending hours changing permissions, re-installing packages, and poring over StackOverflow posts. I get that real-life software development is very similar, but I'd really just like to build something.
Coding isn't all that hard (in my experience). It's the tangential stuff that makes it hard, and as a result, turns people off from learning.
Run into a problem you can't figure out? Time to get resourceful...go for the common solutions first: Think through the problem and try to figure out where you went wrong. If that doesn't work, look at similar examples and documentation. If that doesn't work go to the common win areas: StackOverflow, Google. If that doesn't work, go on to IRC or forums. If that doesn't work walk over to a knowledgeable collegue etc. etc. until, all at once, the solution comes to you like a bolt out of the blue and it is like you've known it your whole life. Rinse and Repeat until you've built something useful.
The hard part is not cutting corners and sacrificing your original intent for the sake of getting over a hump. This is not so hard when expectations are clear like a tutorial but it is all-too-easy when creating a new product or feature.
I have come to believe that tenacity is the most useful skill (or trait) that programming can teach (or ingrain).
Done well, the tenacity that a programmer possesses looks almost super-human to outside observers as well as being extremely valuable in other areas of endeavour.
I think what makes a difference is how you react when something goes wrong. Do you flip out and pull your hair out and complain? Or do you calmly try to understand what the problem is, spend some time figuring out what YOU did to create the problem and then fix it. I work with people who look in all the wrong places to fix a problem thinking some hidden magical set of code breaks things at random.
Once you realize that the clues are all in the errors and they're not just random bits of text, that's what sets you free and gives you the power to fix.
I spend almost 30% of the project time helping people setup their environments or tracking a problems that are not directly related to the task they are assigned to do... that's unfortunately part of the game.
But the bright side is that it will take less and less and less time to solve this kind of problem after a while.
Getting efficient (not proficient, just efficient) at programming has a lot to do with experience and smoothing out all those errors from past scars.
If it makes you feel any better, that slow grindy Google-heavy progress is normal for any programmer working in an environment they aren't experienced in. Toss a senior backend guy into frontend JS and CSS. Watch him rend his clothes to shreds. (CSS is fucking evil btw.)
You slowly get better/quicker at learning new things, but nobody really walks into something different and just instantly knows how to do everything.
The most important skills you can develop for ameliorating this is getting ace at debugging and static analysis. Both are close to my primary knack, above and beyond anything else I do as a programmer. I'm the go-to guy for my team whenever an intractable error/issue comes up.
It is with great pleasure that I've been told this is Rich Hickey's knack as well, although I sincerely doubt I'll be anywhere near that good in the next 20 years.
Good story. I did my undergrad in history and came out wanting to do something else.
I spent a year on help desk, two years as a system and network administrator (skills I acquired by studying while I was on help desk) then I transitioned to development (which I studied for while doing admin) and now I lead my own projects. Like other have mentioned, it's all about dedication, tenacity, and passion.
However, I don't want to overlook the importance of the people along the way who took a chance on me. Those people were just as important to me being able to continue down this career path as the my own efforts.
A lot of my friends have the opposite problem. They're in college in order to learn programming so they can make games, but they seem too content with enjoying other people's games to realize how satisfying it can be to actually create your own.
I am interested in what you found to be the most effective learning tool or tools along your path. How did going through the rails book compare to the learning experiences on the job? Did you consider one of the many bootcamps, online programs, or other more structured learning?
Most effective for me have been Railscasts, building real projects and not just following the book. Learning on the job far surpasses the book as I'm actively engaged and not just following along on Rails (sorry, had to)
Great post - I did the same thing, and 2 years on, best decision I've ever made. It takes time but the main thing is to take the plunge and stick with it. Great job!
I graduated from college with a philosophy degree and took a job in marketing. That job wasn't really marketing, despite the title, and I ended up spearheading a digital marketing effort that was 95% technical project management. That was the point when I realized I wanted to be the person making the products, not managing the people making them.
So I did everything I could to get closer to the technology. I quit my job in the non-profit sector and moved to Chicago, took a job as a project manager at a technology/marketing company, learned QA processes, taught myself python over 12 months, built some scripts to automate tedious parts of my job, and eventually got a job in Automated QA.
Now I'm an engineer in SF Bay Area at a startup. And yes, every day I go home and realize that my brain is wrung out, my mind is exhausted, and I am totally happy with it.