Lessons Learned as Chief Tinkering Officer
As the last semester of my high school winded down, I was quickly running out of things to do. So, I headed over to Freelance Hackers and connected with a guy who needed a full-stack developer. Turns out he needed much more than that: a CTO to manage the development of his eSports application, dubbed Elympic. A true CTO is someone who has experience in every framework in existence and knows exactly what to do. I, on the other hand, had no clue where to start and just played around until something worked. So, I prefer to think of CTO as ‘Chief Tinkering Officer.’ Here’s what I learned along the way.
Docs > Examples. I settled on the MeteorJS Framework to built the webapp because of one reason: sample apps. From logins to user profiles, someone somewhere has done it with Meteor and can show you every step. I thought, “man, I won’t even have to write code!” Soon enough, I had tons of small applications that I copied off of tutorials and had no clue how to piece them together. Not only was the design inconsistent, but they all functioned in their own environments and did not share the same database. It would’ve been up to me to resolve the differences and deal with dozens of bugs to get the features working together.
That’s when I turned to the documentation, which carefully explains each and every feature available to Meteor developers. While it was more tedious to go the documentation route, I got to learn more about how MeteorJS works and knew the ins and outs of my application. For example, signing in a user is a fairly simple concept and you can easily find an example app online and get the source code. However, my registration involved more variables that needed to be hooked to the Mongolab database. The documentation carefully outlined how to go about building this, and I was able to make it happen. Example apps can give you a general idea of how something works, but think twice before using it for your project.
Over the past three years, maintaining the free Meteor.com hosting service for 10,000s of apps has taken a big toll on our ability to move fast on other products. Now that reliable, pay-as-you-go Meteor hosting is available for everyone via Galaxy, we’re confident that Galaxy is a better home for your apps and will give everyone the chance to try it for free. As a result, we will retire the legacy Meteor.com free hosting service on March 25, 2016.
Nothing Free Will Last. They say the best things in life are free, but they don’t say the free things last forever. At about halfway point of my project, Meteor suddenly shut down its free hosting feature, which took down millions of meteor apps across the world — including mine. We had to hold off our client meetings for a week while we configured the app to Galaxy, Meteor’s paid hosting option. Oh, and every Meteor app demo I could find online was now down (this also argues in favor of lesson #1). It’s okay to lean towards the free options, but be sure to have a Plan B in case things go south.
Prototyping is Key. It’s always fun to take an idea and run with it, but for enterprise-level applications it’s important to test features out before shipping. What’s that you say? You don’t have time or resources to test your products? Use this handy tool called Sprint. It’s essentially a five-day plan to test ideas , from journey-mapping all the way to prototyping. Google uses it, Slack uses it, and I decided to give it a try with some of the features on Elympic. I was able to quickly determine whether mean.io was a viable framework for our app, whether a blog in our site would be worthwhile, if we should expand to all eSports or just the big three, and so on. Instead of blindly picking an option and hoping for the best, I was able to collect user feedback quickly and make the smart decision.
Don’t Code, Think. The hackathon culture has taught us to ship apps as quick as possible and never look back. I tried this strategy while building out Elympic, and all I ended up with was broken code and a bunch of Atmosphere Packages (Meteor’s package source). What prolonged the process even more was that I had to peruse through each packages’ documentation and learn how it’s used to my specifications. I then decided to take another approach and start by planning out what I wanted the app to accomplish, and then broke it down into steps. For example, I initially installed an Atmosphere package for email verification, but after days of configuration issues I decided to go back to square one and break down what exactly I wanted:
- Email automatically sent out once user registers
- Bert notification saying email was sent out
- Option to resend email
- Link in the email that executes a POST request with the token
- Function that verifies key and changes the boolean variable verified to true
- Bert notification saying email was verified
Once I had each step planned out, it became much simpler to just implement the feature myself. Furthermore, I was able to extend this functionality to other parts of the app that required email.
Before jumping into the code and installing 2312 packages, first think about what you really want and evaluate the best solution.
Three months of being Chief Tinkering Officer taught me this much. Hopefully it taught you something as well :)
