Becoming a Full Stack Product Person

by Brian Casel on July 25, 2018

See what I was up to that year · Subscribe

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 Person^TM.

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?

Learning to Code in Months (Not Years)

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.

My Learn-to-Code Roadmap

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:

Phase 1: Inspiration

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.

Phase 2: Picking a Tech Stack

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:

Which coding language & framework has the largest adoption?
Which has the largest pool of learning resources available?
Which has the largest selection of tools, plugins, and things that accelerate the building the process?
Which is the most “proven” and likely to stick around for the years to come?
Which is best suited for the types of software applications that I’m most likely to want to build in the coming years (specifically SaaS)?

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.

Javascript is in the mix no matter which back-end framework I go with. I know I need to de-hackify my Javascript skills and move beyond my reliance on jQuery. Early on, I want to firm up my pure JS skills. As for moving into the more popular frameworks (Vue, React, Angular, etc.), I’m a bit wary and holding off until I feel these are truly worthwhile choices—both in terms of my investment of time, but also how necessary they are in new apps (does every app have to be a single-page-application? I don’t think so). Of course, I could be wrong. I won’t know until I get further down the rabbit-hole.

Phase 3: Choosing how to learn

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:

Should I use books, courses, or bootcamps?
Should I pay for training or rely on free YouTube videos and blog tutorials?
Which ones are suitable for a total beginner like me?
Which ones offer the most efficient curriculum to get me up and running the fastest?
Which ones are still current and teach the most recent versions and best practices?

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.

Phase 4: Consuming first lessons

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:

The PHP Practitioner – Teaches the basics of the PHP language (not yet Laravel).
Object-Oriented Bootcamp – Teaches the concepts of Object-Oriented Programming (in PHP)
Laravel From Scratch – A long course that provides a broad understanding of the Laravel framework, and the concept of MVC (Model, View, Controller).
Build Your First App – Reinforced the concepts in more practical project-based lessons.
Sublime Text Mastery – I skimmed a few of these lessons since I hadn’t been an every-day Sublime Text user and that was slowing me down.

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:

One Month Ruby – Unlike PHP, which I had been exposed to through my work with WordPress, I’ve never really touched Ruby code before. This course was super beginner-oriented and it was perfect for teaching me just enough to be able to proceed.
One Month Rails – I liked the teaching style in One Month Ruby so I purchased their Rails course. This gave me a great introduction to the framework.
- By the way, although they promote these as “One Month” bootcamps, they give you all of the material at once so you can go through at your own pace. I completed these in about a week each.
Rails Guides – The official documentation of the Ruby on Rails framework. Unlike other docs out there, these are very well-written, easily digestible, and they cover the most up-to-date information. I’ve been reading (and re-reading) these guides on an as-needed and daily basis.

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!

Phase 5: Building something! (for practice)

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:

Create it in a way that I’d actually want to use it. From layout, to useability, to design. Build it as if I’m building a real project for me and for others to use.
Incorporate Ajax for most of the interaction instead of lots of page refreshes. I’m totally new to implementing Ajax, so this was a great learning opportunity.
Get it up on Heroku, slap a domain on it, and put as much fit and finish on the project as I’ll allow myself without spending more than a week or two on it.

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:

Phase 6: Find a coach

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.

Phase 7: Build products! (to sell)

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.

Unlocked Super Power

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…