I’ve always been a design guy. Always more comfortable on the front-end.
I could tip-toe my way around back-end code and carefully fit my HTML and CSS around it. But actually wiring up a database and making things work? I always left that to the “real” developers.
Over the years, I spent tens of thousands of dollars hiring developers to bring my front-end software ideas to life.
The thinking was, I shouldn’t even consider trying to learn to code my own apps, front-to-back. There’s just no way I’ll ever be as good as a career back-end developer. Why try and catch up now? Stick to what I’m good at, hire out the rest.
My thinking changed this year.
Having built my productized service business to a point where it largely runs without me, I found I had more time to devote to learning again.
So I’m taking this opportunity to finally fill that frustrating gap in my skill set. This is the year that I go from front-end designer and non-technical founder to Full Stack Product PersonTM.
I believe this is a super power that’s worth pursuing. The ability to go from idea to design to functional MVP to market—at will—is huge. It means not having to bet months of cash savings on unproven ideas. It means saving that precious cash for when the product shows traction and is ready to grow.
It means being able to design every aspect of the product, from front to back, and make smarter product decisions because of it. It means I’ll be better at hiring and collaborating with developers, once traction justifies taking that step.
So the question is, how can I acquire this ability to code and ship my own software ideas in the most efficient way possible?
Like everything I do in business, I try and take a methodical approach. Learning how to code is no different. I’ll share my learning roadmap with you below.
But first, let’s start with the goal: To acquire the toolset and knowledge I need to build simple software products. A foundation to build upon as the years (and products) go on.
As I write this, I’m about three months into this journey. And guess what? I launched my first app! A simple to-do list manager. Nothing fancy, but it was fully designed, coded, and built by myself in just a couple weeks. Three months ago, I wouldn’t have had a clue as to how to build something even as simple as a to-do list app.
Shipping my first app was a huge personal milestone. It proved to myself that I’m capable of learning a totally new (and highly technical) skill and putting it to real-world use. I’m feeling a lot closer to that dream of being a Full Stack Product Person today than I was just a few months ago.
I’ll break this down into “Phases”. Each has its own goal or outcome, which unlocks the next phase. In reality, there was a lot of overlap and circle-backs throughout this process. But hopefully this clarifies the path forward:
I started by trying to find other entrepreneurs who’ve taken this path that I intended to take. Historically, I found the most motivation and inspiration from learning from the real-world stories and experience of others. In this case, I wanted to hear from non-technical founders who’ve taught themselves how to code and then used that acquired skill to bootstrap and launch software products.
My interviews with Ryan Kulp, Ryan Buckley and Jason Schuller were eye-opening for me. I also found Mackenzie Child’s article and YouTube series (building 12 apps in 12 weeks) very helpful and inspiring. These are people who come from similar backgrounds as mine and were able to pick up this skill and actually make something of it.
I’m also in touch with a few founder friends who are also currently going through this learn-to-code journey. It’s been very motivating to share notes, resources and quick wins.
By the way, this article you’re reading here is exactly the type of story I was hungry for at this stage.
I felt it was very important to dedicate time to fully vet the decision of which tech stack to learn before fully diving in. Choosing the wrong one could result in all sorts of setbacks.
I spent about 2 weeks Googling, consuming podcasts, and picking the brains of engineer-founder friends to try and nail down answers to these questions:
I ended up with a toss-up between Ruby on Rails and Laravel (the Rails equivalent for PHP). Both nicely check all of the boxes above. I’ll come back to my final decision in a moment.
I need to note that I’m intentionally avoiding the more cutting-edge / trendy / younger frameworks and languages. While these show a lot of promise and popularity, I can’t afford to learn something that might be replaced with a newer shinier thing a year or 2 from now. Plus, a less mature framework changes very rapidly in the early versions, making it more difficult to learn. At the time of this writing, both Rails and Laravel are well into their 5th versions and nearly a decade or more into widespread use. That’s a reassuring place to start.
I have always been a “learn by doing” person. With coding, I absolutely am taking the same approach.
But there’s not much I could “do” when I’m basically clueless on how to use the command line or set up a local dev environment, let alone write a line of functional code.
I need to be “taught” before I could walk, speak, or play with building blocks. The question then is which learning resources should I commit my time to?
Again, this opened up a bunch of questions:
For me, I very much prefer video-based lessons over other formats. I can pause videos while I code along and I can watch at 2x speed to get through more material faster. While there are plenty of comprehensive coding books available, some of which I skimmed during this journey, they just don’t move the needle for me as much as targeted video lessons do.
I also decided I would pay for course(s) rather than rely exclusively on free material from YouTube and the Googles. Paid courses tend to offer a well-thought-out curriculum, explained by a proven teacher.
YouTube, Stack Overflow and blogs will come in handy later as I get into troubleshooting and learning as I go. But first, I need the structure and efficiency of a video-based course.
OK. Enough research. Time to dive in.
At this point, I was still undecided between Ruby on Rails and Laravel. So I went through introductory courses on both.
For learning Laravel, it’s really a no-brainer. Laracasts by Jeffrey Way is the place. It has a huge library of high quality video courses, ranging from beginner to advanced topics. I burned through these, in this order:
As for learning Ruby on Rails, it’s a different story. There isn’t one definitive go-to resource like there was for learning Laravel. Also, quite a few of the courses/memberships that are mentioned a lot are a bit out of date and don’t cover the latest Rails version and best practices.
I ended up focusing my time on these:
So… Which one did I choose? Rails or Laravel?
The decision became pretty easy once I finished the above course work. It came down to this question: Having learned the basics, which one was I confident enough to go build something with?
With Laravel (and PHP in general), I still felt a bit lost. I understood the concepts while following along with tutorials. But once it came to building something new (without the help of a tutorial), I was a deer in the headlights. Frozen. My sense is that if you’ve had experience as a PHP developer, then Laravel should be easy to pick up and use very efficiently. But in my case, having never coded back-end, it still felt too steep for me.
Rails, on the other hand, felt much use-able. I knew exactly where to start. I knew how to go about getting simple functionality up and running in the browser in minutes. I clearly felt more confident and “ready” to build something using Rails.
So it was decided. Ruby on Rails it is for me from here on out!
Finally, I’m ready to truly learn by doing. That begins with building a practice app from start to finish.
I decided to build a to-do list application. I know, I know… That’s the “hello world” of practice projects. But it seemed to be a good starting point for me.
I set out to accomplish a few things with this project:
How did it go? Well, I shipped! It wasn’t fast or easy, but it was insanely productive from a learning perspective.
It involved lots of Googling for error codes, combing through Stack Overflow threads, re-reading documentation and re-referencing some course work. At one point I resorted to buying 30 minutes of help on codementor.io (that site is dangerous for someone learning to code!).
But I did it! Here’s a look at my little app I called Summit:
It’s fine to keep building stuff and relying on good ‘ol Uncle Google for help. But it’s not the most efficient way to learn, and it can often lead you down the wrong path (without you even knowing it).
This is a great point to find a coach. Someone who is a seasoned developer, who has worked in the trenches for years, and also has the patience and natural skill to be a great teacher and mentor.
I reached out to my network and met with a couple different people who offered trial sessions. All were super helpful and I’m settling into a regular schedule of mentoring sessions with one of them.
This is a great way to speed up my learning curve. A coding mentor can look over my shoulder (sort of speak), point out things I could improve or refactor, and gotchas to watch out for. In one of my early sessions, I had about 5 “ah ha” moments that I never would have stumbled upon through my own Internet searching.
Throughout this process, I’ve been keeping a running list of app ideas. Some of them are silly practice app ideas (a lawn care reminder app? really?), but most are real software ideas that I think have legs.
I’m now working through this list, cracking open my code editor, and getting to work!
One idea is an internal software tool to help me streamline my payroll process for my productized service business (a manual process that takes me hours to do each month). Another is to convert one of my WordPress plugin products into a SaaS. And eventually, I’ll work up to laying groundwork for a larger SaaS product.
Let’s be real: I am by no means “ready” to be shipping production code for large scale apps used by thousands of people. But I am (finally!) capable of building simple early versions of those apps. I now have the foundation I’ll need to keep learning by building.
This, to me, unlocks a super power of sorts. It completely changes the math and the roadmap I use to bring new products into the world. It’s a step closer to that holy grail, being a Full Stack Product Person.
Away we go…