Creatives vs. Technicals: Which Should You Focus On?


Photo by rawpixel on Unsplash

One of life’s greatest conflicts is between the arts and the sciences. The right brain and the left brain. The creatives and the technicals.

In reality, no one thinks that one of these groups is inherently useless. But what’s the right mix? Honestly, it changes depending on what sort of project you’re looking at. A SaaS company would need a larger proportion of technicals rather than creatives, where something like a film project might require more creatives than technicals, and a video game might be split roughly 50/50. I also believe that the greatest competitive advantage here are the people who are focused on training both sides of this dichotomy. If you’re well trained as both a creative and a technical, you can do wide swaths of the work yourself; this not only helps with expenses on projects but can also help in terms of career options.

Everyone is naturally aligned with one of these two. I found from a young age that the creative element aligned with me greatly, but that I had trouble fulling realizing projects due to that missing half. Over the last couple of years, I’ve tried honing my technical side by focusing more on programming and engineering projects, in hopes of equalizing both these sides. I’ve found that doing this has helped me greatly, and I’d recommend it to most other people. There’s certainly more technical guides and tutorials out there on the internet – probably because technical knowledge is less ethereal than creative knowledge – but there are still resources out there for things like art, writing, and design.

Overall, the question should not be about being a creative or a technical, but rather a creative and a technical. Some might argue that more focus is better; I’m not saying that you can’t be more focused in one area than another, but I do believe that having at least basic knowledge contained in both fields will do wonders for you long-term.

Anyway, that’s all for this one. I do want to point out that we have a brand new newsletter! Following this will give you the low-down of all the new stuff I’m working on. Subscribe here!

Getting Past the Bump




I wanted to talk about something that I noticed in both of my previous projects: the 100DaysofCode and Startup Challenge. It’s about the Bump.

The bump goes something like this: you’ve decided to learn a new skill. As you always do, you check out the tutorials for it online. Things go very smoothly. This thing goes there, this goes here, and it all fits. You can even apply it to! It actually works outside the tutorial! Wow, this is fantastic; you feel productive, valuable, all sorts of… wait… what the hell? What is that thing? How are you supposed to do that? Is that even possible? Well, what if you put in… nope, that didn’t work. It’s not how to learn, but you can always copy and paste from the tutorial and … oh my. This is not an error that the tutorial mentioned. And looking it up in google gives zero results. Wow. This sucks.

Everyone’s had to deal with the Bump at some point. Perhaps not like that specific example, but the same idea applies. I’ve been dealing with the Bump when it comes to programming for quite a while now, in various shapes and forms. I know that programming isn’t my strong suit; at the same time, I recognize programming as an essential skill for the future. So, how do I get past the Bump?


For the most part, I’ve found the one thing that’s been the most helpful to also be the most ironic: brute force. Trying out as many problems, tutorials, etc. that I can find and trying to complete each one until I hit a point where its truly impossible to complete. Still, I’ll be the first to say that this isn’t the best strategy to go for. Building up momentum for a short while only to have it all collapse again can make you demotivated to finish the job as well as further lower your opinion of your own abilities. So, post-100DaysofCode, I’ve decided to draft up a new theory when it comes to tackling the Bump.

The first thing is this: execution matters above all. I now believe that it matters less that you spread out on a bunch of different tutorials and learn bits and pieces from each. When you hit a roadblock in a project and then actually get past that roadblock¸ it feels INFINITELY more rewarding and grants you with much more knowledge. Instead of avoiding roadblocks, you should focus on tackling them head-on. Make the goal less of finishing the project, and more of beating the roadblock. Once you realign your focus on the challenge like this, I hypothesize, you’ll come in with a much healthier mindset.

A second major piece of it is that just because you struggle doesn’t mean you can’t come out the other side. I think programming is one of the most notorious things out there in terms of the struggle. I see a constant stream of posts on Medium, Reddit, etc. about people banging their head on the wall because they just can’t get coding. This makes me feel a lot better about my own position. What also makes me feel good is recognizing that, when they stuck to it, the majority of these people successfully ended up making it to the other side. And if they can do it, why can’t we?

Overall, I’d still say that my level of programming mastery is novice. I left 100DaysofCode disappointed in expecting more progress, but at the same time I got a new goal out of it: to break past the Bump and get on to the next level.

That’s all for now. Feel free to follow this blog or my Twitter if you wish to see more. New posts should be up every Monday!


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.