30DayStartup: The Beginning

Photo by rawpixel on Unsplash. Business!

As promised, here’s my first post for the 30DayStartup challenge! This whole thing is already extremely messy; I wasn’t able to post last week like I had thought I would be and I’ve also already lost my place as to what day I’m supposed to be on this challenge. Guess that serves me right for jumping the gun and starting this challenge literally as school started. Whoops!

In this case, what you might end up seeing out of this blog instead is less of a documenting of the challenge itself and more of working my way through the ideas and business model of what I plan to create. That’s essentially short for this probably won’t be a 30 day startup after all – just a normal startup.

Then again, if I count correctly, we should still have 21 days until launch. So let’s get to it!

The Ideas Stage

Most of my time this past week and some change has been dedicated to the ideas process. Spoiler alert: I’m fucking terrible with ideas. I have an idea journal that I’ve kept for about a year and there’s only five things on it. And that’s not business ideas – that’s just ideas in general. Because of this, this was definitely the hardest part of the process for me. I ended up starting with four ideas before finally settling on one, but I’m just going to go ahead and reveal all four, because they either a) already exist and I’ve already made them, b) are way too vague, or c) I just want them to exist and listen someone more competent can make it for me if I can’t make it myself.

The first idea I had was that of a dropshipping site via Shopify. This one was pretty nice because you’re work is primarily in settling the business as the actual product work is done by another company via an initial capital investment. The downside is… there’s an initial capital investment. I mean, let’s face it, I’m a college student who has never had a normal job in my entire life. If we are gonna make a startup, we are going lean with it.

The second idea (also in the vein of fashion) was a Redbubble store. This was pretty easy – I already have experience in having a Redbubble store, and the product work is yet again pretty minimal – in this case, you’re not working at all on logistics like you would be in drop-shipping, but you do have to create the designs. And although I am terrible at art, I am decent at marketing and I’ve already gotten one sale from a few eons ago. The downside with this one is purely that it’s not in the spirit of the challenge itself. When you think side project, you’re thinking more of creating your own service or product – code or no code – and then setting up all the work for that manually. Using Redbubble just… feels like cheating in a way.

So, what ideas are “in spirit”? I had a lot of trouble thinking of ideas for mobile and web apps, but I managed to get a few mediocre ones. For a mobile app, I was thinking of a mentoring system that worked locally with connecting people who are farther along in crafts they wish to follow. In case this sounds familiar, it’s because it is. This “mentor app” idea has been made about a million times in hackathons, side projects, and, yes, even full on startups. Still, if it worked for everyone else, surely it could work for me – right?

And finally, there is the web app. Even though I do know HTML and JS (Thanks 100DaysofCode!) I did want to try out the functionality of nocode editors like Bubble and Webflow. Turns out, they are… uh… in very early access. Also, my idea for a web app was a Resume Editor, in which you could simultaneously edit work experience, education, etc. on all major resume sites – LinkedIn, ZipRecruiter, Glassdoor, the works. One issue with this – although it is a great idea (someone please make it oh god), working with that many APIs (as well as trying to get advanced permissions for each one) would be an absolute fucking nightmare.

So, in conclusion…

…I chose Redbubble.

There’s a couple of difference reasons why – first of all, Redbubble has the clearest and easiest tools for the job. Since this is my first foray into really doubling hard on a startup, I want to do something that in a way eases into the process. Secondly, I couldn’t (at the time at least) find any hard cons against Redbubble besides the fact that it’s not really a startup and also I’m kind of a shitty designer. When it comes to dropshipping, I literally don’t have the capital required, and for the mobile/web apps, I literally don’t have any ideas – cons that are much worse.


So, now what do we call it? What shirts are we gonna sell? What marketing tools are we gonna use? All these questions, and more, answered on the next episode! Follow this blog (or my Twitter) to get updates on this process. Happy starting!

Five Takeaways from #100DaysofCode

Photo by Luca Bravo on Unsplash. I don’t even use a Macbook. Also not sure if that code even does anything.

For the longest time, I’ve tried to code. From taking an AP Computer Science class in high school to trying to make a command line RPG in C++, I’ve always wanted to expand my knowledge of programming, understanding that it now plays a key role in our world. However, each time I’ve tried, I came out of the experience disappointed; continuing to see people discuss CS concepts that were far out of my league and witnessing people excel in the field ten times faster than I seemingly could have. So, when I found out about #100DaysofCode, I decided to take on the challenge with one simple objective: see what people are talking about, see what people find important today, and see what I want to know – then learn in that direction.

Today was my final day of the challenge. Overall, my experience was… mixed. However, I’ve found that I’ve learned a great amount – not just about coding, but also about learning principles and a few life principles as well. I’ve decided to use my last day of this challenge to write down five key takeaways I got from doing this challenge.

There’s a massive difference between learning to code and solving problems in code

This I think was my biggest mistake from earlier attempts, and I didn’t even realize it until halfway through the challenge. You can go through something like Codecademy or FreeCodeCamp tutorials, but all they really tell you is what you can do with a programming language. It teaches you semantics through a fairly trivial and easy set of problems – which definitely helps when you’re just trying to understand what you’re working with (and I think that’s the goal of these two sites), but they suck at teaching you how to code.

If you want to learn to code, you need to know how to use a programming language. HackerRank, LeetCode, and Project Euler are fantastic resources on this. If I could do it all again, I would say to spend the first one to two days learning about a language on Codecademy/FreeCodeCamp, and then spend the majority of the time practicing your knowledge through intuitive and challenging problems (and believe me, they are challenging).

Choose something and stick to it

I’m terrible at this. I really am. I’m currently reading six different books at once just because I get about 100 pages in to a book before I think “You know what? This book on AI is really fascinating, but tonight I’m feeling something more about design”. This escalates to a point where instead of reading 100 pages a day in one book, I’m reading like 10 pages from 10 different books and it totally stifles my progress.

A similar thing occurred while doing this challenge.

During my prepping for this challenge, I made an entire roadmap of different projects and courses I could do, when I’d start and end them, etc. I threw it out on the second day. From there, I went on to not finish things such as CS50, a Codecademy React course, FreeCodeCamp, and also Quantopian (to be fair, I plan on finishing that last one post-challenge). Now that I reflect on my completion of the challenge, I realize how much more I would have known by this point if I just stuck with my roadmap. My advice for the future: always use roadmaps. Design a path and stick to it. Don’t get distracted by the shiny things across the road; instead, if you must, save them for later.

An hour a day goes a long way

Not going to lie; I didn’t do the recommended one-hour session for #100DaysofCode every day. In fact, I did it very little. But the times that I took on the full hour, I realized just how powerful an hour of time is.

Optimally, you have about 16-17 hours in a day that you can fill up. One hour, in that respect, is a pretty small amount. However, one hour is also 60 minutes, or 3600 seconds; and that’s a surprisingly long amount of time. I try practicing piano for about an hour a day (well… tried). I played until my fingers got sore, and I got tired, so I got out the chair and checked the clock. Only 30 minutes had gone by. This happened a lot when I was doing the coding challenge as well – if you think you’ve “learned enough” within 30 minutes, that means that you’re learning 2x that much in an hour. Also think about how these hours increase over time – optimally, by the end of this challenge, you would have put in just north of 100 hours into coding. I have about 105 hours total in Guild Wars 2, and that’s felt like an eternity. Now imagine if I spent that time learning and practicing Python.

All coding languages can be very much the same (and very much different)

After doing this for 100 days, I feel certain of one thing: that all coding languages are pretty much the same thing. Just like real languages, they’re all an assortment of different ways of communicating the same thing.

However, just as Russian has almost 10x the amount of curse words as English, some languages have certain strengths for certain situations. You use SQL for databases. You use Assembly for low-level stuff. You use C# for software, and JS for web apps. However, the languages themselves typically stay the same; you can print, use for loops, make ints, etc etc. In this case, you only really need to learn one language; and then when you need to switch to another, you retain your knowledge and just uncover the small semantical differences (print vs printf, {} vs end, etc.).

Determination is one thing. Hard work is what counts.

And here I think is the probably my most important takeaway of the challenge – it’s that there’s a big difference between hard work and determination. To be completely honest with you, #100DaysofCode – for me at least – was less a challenge of coding and more a challenge of consistency. I don’t think I’ve ever done anything 100 days straight in my life. And even though I wouldn’t necessarily say I did the challenge for 100 days straight (there was a few hiccups here and there), I still completed the challenge, which is a big deal.

But as you can get from previous takeaways, there is still much to be desired.

Consistency is only half the battle.

I think I made good progress during this challenge, but let’s imagine the optimum path: if I had followed the roadmap, if I had done exact an hour a day, if I spent the majority of the time on solving problems, and if I had gone for 100 days straight rather than skipping a few here and there. I can imagine that, if this happened, my current knowledge of coding would be 10x what it is now.

Now, that’s not to say I think this challenge was a failure. At the end of the day, I’d say my coding experience with this challenge was much more positive than it has been in previous attempts. Focusing on my three views (what people talk about, what people find important, what I like) definitely helped me stay in the right direction. And now I know that I can apply these takeaways to future attempts at similar challenges, with which I know there are many coming… such as my next challenge, #30DayStartup, which I plan on beginning pretty soon (and also plan on documenting much more).

In the meantime, like share this post if you’ve found it relatable, or otherwise especially find it share-able. If you want to follow me on the next challenge, either follow this blog or my Twitter (@astukari) as I’ll be surely posting plenty of updates on both. ‘Til next time.