Overview
Halfway through 2020, I knew I had to be with my family during the pandemic. At that time, I was a consultant working overseas. Moving back to the US meant leaving my job, and with it, some interesting work and amazing colleagues. But it was the right decision, and I’m glad I did it.
A much tougher decision to make, however, was what to do after the move.
The pandemic seemed to slow down time. I saw this as an opportunity to do something I’ve always wanted to do, but never had the courage, know-how, or time to do it – build products. And not just any product, but a digital product. And not just any digital product, but one in music, a field I’ve been passionate about since childhood.
To be fair, programming and building technologies are not completely new topics for me. As a consultant, I accidentally stumbled into a product management role (this was the best accident to happen to me professionally). I also took coding classes in graduate school and through MITx. However, *designing and coding a digital music product entirely of my choosing *was something new, and to me very exciting.
Over the past six months, I’m grateful that I’ve had the time and support of the Flatiron School to build several music technologies – some admittedly simple and some complex. These are a few of them:
- An app that transcribes raw audio to MIDI and persists the data to Google Cloud
- An app that stores and displays a user’s Spotify listening history (excellent for Spotifiers who can’t wait for their Wrap Up each year)
- A prototype of how Apple’s Album Artwork screen saver could function for Spotify users
- A scraper that fetches and analyzes public data from the Billboard Hot 100 charts
Writing the code for each product and product feature has been an extraordinary experience. I’ve learned a wealth of knowledge not only about programming but also about music technologies – how far we’ve advanced in some areas, and at the same time, how much further we’ve yet to go.
For my final post, I wanted to leave behind some of my takeaways about software engineering, building products, and music technologies, along with offer a couple pieces of advice to prospective and current students.
Takeaways on software engineering and building products
• Ownership. Programming reminded me a lot about a time when I helped a women’s group launch a business in Cameroon. As a software engineer, you’re constantly faced with decisions (how to structure code so that other developers can follow along, how a feature ought to function to optimize the user experience, how to test your code, how to design assets that are accessible for all users, etc.). You frequently assess trade-offs between the user experience, performance, security, and time, among other variables. You make countless decisions, and many times, you’re forced to do so quicker than you might like so that you can stay on top of schedule. Decision-making and time-management are as critical to running a business as they are to software engineering.
• Flexibility. Designing and building products demand a lot of responsibility but can be very rewarding for the right individual. One huge benefit is the flexibility you can have over your calendar. I’ve enjoyed the freedom of deciding when to push hard late at night or over the weekend, and when to step off the pedal to go for a run or spend time with family. I have deadlines and milestones to meet but lots of liberty in determining how to achieve them. Of course, this is also a luxury inherent to the Flatiron School’s self-paced program – you can trade-off developing a higher-quality product for time. More on this later.
• Resourcefulness. The incredible amount of public knowledge that exists and the openness of the developer community make it possible to write complex code quickly and create technologies that might have otherwise seemed impossible. Software engineering can be a very tough, individualized experience, but need not be for those unabashed to leverage online resources such as Google, Stack Overflow, Reddit, Medium, and GitHub to the fullest extent possible.
• Testing – and failing. Because tests fail far more often than they pass, software engineers and product developers learn to get extremely comfortable with failure. This hones their problem-solving skills, since testing/debugging and failing fast are critical elements to the problem-solving process.
Takeaways on music technologies
• Lots out there. I loved learning about so many different music technologies being developed today. One such technology, Magenta, explores the role of machine learning in creating music and art. Another open-source technology, LilyPond, allows individuals to create and edit sheet music digitally.
• Lots more to go. However, despite the tremendous efforts of many people and organizations, I think we’re still in the very early stages of many music technologies. For instance, transcribing music accurately still requires a trained ear (some notation software such as MuseScore works well, but aren’t perfect) and exchanging music files can be confusing. For music listeners, accessing data on your music streaming history should be as convenient as viewing your stats after going for a run, but it isn’t. Additionally, opportunities abound for streaming services and hardware manufacturers to partner more closely on a number of initiatives, from alarm clocks and screen savers to smartwatch features and VR programs.
Some advice, for what it’s worth
• Decide on your projects as early as possible. The sooner you can think about the type of things you want to build, the easier it will be to stay motivated during the program. Investing time upfront to plan will also give you time to change your idea should you decide to scale back your ambitions.
For prospective students, thinking about what you want to build before you apply could help determine whether the Flatiron School may be a good investment. For instance, you might decide that you really just want to build apps for the Apple Watch – if so, may probably want to consider a different program!
For me, I started the Flatiron School with five ideas in mind, including one app I knew I had to build. I was able to create four of the apps, including the one must-have. I consider this a huge success.
• Select the program pace (i.e. full-time, part-time, or self-paced) that aligns with your goals, time commitment, and financial situation. The more invested you are in building a specific product or learning JavaScript/Ruby, the more time and flexibility you may want to give yourself. Since I had a clear idea of the apps I wanted to build plus the gift of time on my side, the self-paced program made the most sense for me.
Final thoughts
The Flatiron School’s Software Engineering program was worth every penny. I leave the program feeling confident in JavaScript and Ruby and extremely proud of the apps that I built.
Since I took the self-paced path, I did not interact with an instructor very much. However, during the times that I did speak with one, I found the individual to be immensely encouraging, supportive, and smart.
Special thanks to Alice Balbuena and Dustin Anderson for reviewing my work and for all the feedback along the way.