First Test Passed . . . Literally!

In order to gain access to the Metrc API, there are a series of steps one must get through. One of those is to "Attend a Metrc training class and complete the test". Check that step off the list! I am a certified "Third Party Vendor". The next step is to get access to the Metrc API sandbox and start experimenting.

Since I'm not looking to leave my current full time job, I'm doubtful existing software companies hold appropriate opportunities for me. However, I found it very interesting to find the OLCC approved four companies to provide retail sales tracking. I might investigate whether these systems have APIs worth exploring as well.

Converting failure into motivation

There's goes another failed side project! 

This one went from really promising to utter disaster over the course of a few days. There were so many warning signs and red flags I should have seen. Lack of clear vision (no business or marketing plan), disorganized priorities (going public prior to having any revenue), and complete lack of experience of software products or development were all there . . . and I choose to ignore or rationalize them away. While it sucks to spend hours and hours working on software that will never see an audience, in hindsight, I'm glad it fell apart before money got involved.

Even though we parted bitterly, I hope "the company" goes on to become profitable. Therefore, all I'll say about the application is it targeted the cannabis industry. It was pretty data heavy and had some interesting challenges to solve. Fortunately, I've learned a lesson from previous side projects that applied here:

Projects that are fun to program will never end up being a total waste of time

But that thing about targeting the cannabis industry . . . that's the silver lining! It's an industry in it's infancy which promises to be enormous. For nearly 70 years, prohibition attempted to suppress demand, without much success. While there's still a stigma around marijuana, I believe billions of dollars in sales will soon change that perception.

Since I don't want to be prejudged as "a stoner", I've been reluctant to open up about my desire to work in the cannabis industry. I feared being associated with pot might cost me an employment opportunity in the future. But this project made me realize:

I don't want to work for a company who views marijuana negatively

I don't expect my employer to allow lighting up at work (despite having refrigerators full of beer). But if being associated with a marijuana related business is a reason not to hire me, then it's probably best I don't work there. In fact, a job where I can get fired because a pee test says I've consumed THC in the past month is a job I don't want. Consider what would happen if employers fired every employee who had consumed alcohol in the past month . . . that would make for a pretty empty office!

So instead of hiding the fact I'd like to be involved in this newly formed industry, I'm going to dive in (at least with my spare time). My first goal is to gain access to the Metrc API. I'm not sure exactly what I'll do after that, but I'll cross that bridge later. My employment status won't change, nor will any of my activities affect my day to day work. But I'm hopeful ability to write custom solutions that leverage the API will provide entry and exposure to cannabis businesses.

One reason the project failed was "the company" had a complete lack of understanding or experience in software. They thought knowledge of the cannabis industry was enough to develop a successful software product. And while I tried to provide guidance, an inability/unwillingness to accept principals like agile and iterative development made creating an MVP like chasing butterflies. I like working with people who have nothing but a good idea, but now I've learned:

You must know how the software will be profitable before you start coding

Notice I said "be profitable" instead of "make money" or "generate income". Maybe your goal isn't to make money. If the goal is to reduce the time spent repackaging production batches in Metrc, figure out how much time you expect will be saved. If you're starting or joining an open source project, determine what you expect to get out of it. If you want the project to feed you, you'd better figure out how it's going to spin off cash before you start planning features for your MVP.

Finally, while it's important to agree what will happen if the project succeeds, it's just as important to decide what will happen if it fails. Waiting until things are crumbling around you is too late! I learned a valuable lesson, and while I wish I had never made the mistake, I'll try to keep it in mind in any future work:

Agree upfront what will happen to the code if it's determined it will not become profitable

When the project melted down, I reacted impulsively. We didn't have any agreements in place, much less one that covered what would happen to the code if a disagreement surfaced. The hardest part of the whole ordeal was being accused of being dishonest and disingenuous. In an attempt to prove I had nothing but good intentions, I zipped up the entire code base and sent it to "the company". I told them to use it for whatever they wanted. I said I didn't expect or want any payment. To be honest, at that point I just wanted to get the fuck away from a toxic situation.

By not getting an agreement what would happen if things went south, I ended up losing a lot of interesting code. I don't care about giving away almost 100 hours of coding for no money, but I kick myself for making it unusable or unsharable. One day I may ask if I can publish it under an open source license (though I'm not sure it's worth it). I may need to settle for being paid in lessons learned, fears overcome, and motivation gained.