I often get asked by peers and colleagues how I learned how to program. In a world in which technical talent is increasingly valued across most industries, software engineering is indeed an attractive skill set to have on your resume. And that skill set serves a purpose beyond just interview leverage; especially at startups where many different business units interface with new and exciting technology, a baseline level of technical knowledge is a prerequisite to engaging in many important discussions not only about product and engineering, but also about growth strategy, marketing, and operational efficiency.
Truth is, I’ve had a hard time articulating a good, clear answer when I’m asked for the best way to learn programming; I never did a bootcamp, don’t have a degree in CS, and never really envisioned myself being a programmer. My academic focus always erred on the side of STEM, but I opted to focus on the physical sciences in undergrad and programming wasn’t part of the curriculum.
Just over two years ago, I began my career as an Account Development Representative (startup slang for entry-level salesperson doing a whole lotta cold outreach) for a growing startup seeking to establish product-market fit in the data analytics space.
I was our 48th hire.
As you can imagine, I had no clue what I was getting into; I had studied chemistry and physics in college, and had accepted a fellowship with Venture for America, and thought startups were rad. Like most fresh college grads, I didn’t know what my day-to-day would look like when I actually touched down and started my career. Regardless, the company seemed like a place where I could learn a ton, the people were smart, and I wanted to learn what the “big data” buzz was all about— this was a compelling opportunity to dive into the intersection of tech and entrepreneurship.
Soon after I began, the company hit turbulence. An ambitious growth strategy coupled with a resource-starved product forced our executives to lay off 70% of our employees about two months after I joined the team. The rest of us would stick around and focus on narrowing our vision to pursue our product line that was beginning to see traction. I was chosen to stick around because, well, I was cheap, eager, and had proved that I was willing to go the extra mile to help in any way possible.
After a tempestuous few months that included a handful of voluntary departures from the company, a full spinoff of our secondary product and the team responsible for running it, a lot of discussion around our direction, and some vision-casting, we ended up with a group of 7 people ready and willing to do whatever it took to build a product that generated value for its users.
We went heads-down for a few months. I remained in a growth role (albeit with fuzzier definition than the one I had joined for), and our engineers locked in on defining the vision for our next-gen MVP.
Once we finally had something to release to the public, things got crazy pretty quickly. We had an increasing number of prospects wanting us to build specific features and felt strongly that we had stepped on a landmine of product/market fit.
Along with the accelerated interest came the need for engineers; as it turns out, when you’re a small team in the early stages of building a developer tool, technical expertise is essential across every area of the business. There was just one problem: we were quickly running out of cash from our previous round of financing and couldn’t hire the folks we needed to push some of our critical technical projects over the finish line.
We had an endless list of engineering projects that needed to be pushed forward, and, at the time, our CTO, CEO, and a single junior developer were doing the bulk of the technical heavy lifting. One of the features that our growth team desperately needed involved collecting payment information from users of our SaaS product. We were maturing fast and beginning to generate real value for our customers; people wanted to pay us for the service, but we didn't quite know how to collect their credit card information and lacked the resources required to build a robust integration with any popular payment APIs.
I’ll save the nitty-gritty details of the work required to build a solution that made sense for my project write-up, but to make a long story short, we had a lot of interest in our product and no way to get people to pay us money. This meant we had no way to grow our revenue footprint, which meant that I was failing in my job as a Growth Manager. Something needed to be built, and it needed to be built fast. We were in dire straits and developing a technical skill set was, at the time, the only way to do my job effectively.
Whereas desperation lit the flame, a collection of other factors kept it burning increasingly brightly over the year that followed. I chose to use Stripe as our payment integration tool, as their API is extremely well-documented and they had open-sourced a ton of example code that
For folks who haven’t worked with Stripe products before, I highly recommend checking them out. Their docs are awesome and, as far as I’m concerned, taught me a good chunk of what I needed to know to launch my career as a developer.
So, let me do my best to summarize, experientially, what helped the most when learning to code.
No, I don’t mean a web or mobile application. Rather, learning programming, like anything in life, is much more approachable and enjoyable if you have a place to apply your knowledge as you develop it. For me, the application was in the billing app that I was building to make my job easier; having a final deliverable that I was accountable for kept me learning in the late hours of the night even when things got super frustrating and it felt like I hit a brick wall. Before you start writing a single line of code, spend a few weeks scoping out a final project that will have real-world use for your personal life or job. Tailor your learning and every hour you sink in towards the delivery of that project.
Learning to program is intimidating, especially if you work in an environment surrounded by senior engineers who naturally are going to speak way over your head. Accept the fact that you’re going to be miles behind the people around you when you start and don’t hesitate ask all of the stupid questions (by the way, feeling miles behind means you’re doing it right). Then ask them five more times. If someone answers you in a condescending way (this is unfortunately typical in engineering culture, although I was lucky enough to be shut down sparingly), find someone else to ask.
I was unbelievably lucky to have a strong coach by my side in Astronomer CTO Greg Neiheisel. Even in his infinite wisdom and jam-packed schedule, he was willing to spend time with me at any hour of the day or night debugging menial issues and walking through junior-level programming concepts. In what felt like a massive victory for me, as I continued to learn I was able to pay some of it forward by helping him with some easier projects that he wouldn’t have otherwise had time to do. His patience was massively key for me here- as mentioned above, it’s super intimidating when you first start learning to code and are surrounded by seasoned engineers and, without a support system, it’s easy to fall off the wagon. Surround yourself with patient individuals who have a vested interest in your learning process and you’ll be well-poised to succeed.
I truly cannot wait for the day I can help someone get as excited by programming as Greg helped me get.
I’d argue that programming is the
If "value" describes ROI on each dollar spent learning.
Many people try and fail in their mission to learn how to program. Working to become a hireable asset is a challenge that requires a massive up-front investment that proves to be a barrier to entry to many. The secret that they don’t tell you is that, after a good amount of up-front investment, a lot of it becomes pretty easy. The first leg of the learning curve looks something like this:
And running through that curve leaves you as an ultra-hirable technical product manager or junior to mid-level engineer. The beautiful (and terrible) asterisk on that statement is that, once you develop that base of technical knowledge, you find out that no one told you that the y axis on that learning curve isn’t to scale, and the graph actually looks like this:
But feeling dumb again isn’t as bad as it seems! The process of constant learning and development is why programming is so awesome- it’s a never-ending rabbit hole of self-education and, while the path forward can be overwhelming, building a foundation exposes you to a new world of professional and personal development that is all too worth it.