I loved school.

I loved meeting new people in each of my classes. I loved being exposed to new ideas. I loved learning new things. I loved collaborating with my classmates. I loved the feeling of competition between groups in class. I loved having to go somewhere every day.

I loved school so much, I graduated Honors with Distinction from Drexel just because I enjoyed the classes that earned that title; they were the most difficult, social, and mind-opening. I loved moving the goalposts back for myself.

Many of those experiences remained true after graduating. I started working on Arcade with Dan Mall and Leslie Camacho. We were learning together and building something new and exciting, and almost every week, we had a demo scheduled with a team from another company. The idea was thrilling.

Today, I experience almost none of those things. I work full-time for a medium-sized company where the product has plateaued on growth. I spend every single day working alone in my apartment. I'm rarely exposed to new ideas. The amount I learn has slowed dramatically. I'm meeting no new people on a consistent basis.

Needless to say, I feel drained. Some would say I'm burned out, but I'd argue it's the opposite. I've been under-stimulated for so long that I've entered this mode of mental stasis. Constant lethargy. The persistent state of ambition I once had now takes so much energy to muster up. It's gotten to a point where it's starting to affect how I see myself; have I failed too many times? am I no good at building things? am I a fake entrepreneur? have I been wasting my time? should I give up entirely and lean into full-consumer mode?

I acknowledge that those thoughts are negative and that I should actively combat them, which is what this post's purpose is. I want to reclaim my building pride, light the fire of ambitions inside me, and feel the electricity between myself and others. That's when I'm happiest, so that's where I need to get back to again.

Here is what has worked for me in the past:

- Teaching at Drexel last winter was amazing. I met so many amazing, talented students who really inspired me. Many disappointed me, but I think the good ones outweigh the bad ones. I loved being in person with them, teaching, sharing knowledge, and feeling respected by others.

- Building something the right way. Arcade was so much fun to build because we got so many messages from people asking us to see what we were building. People cared. We were solving a real problem for people. The path to revenue was clear. We were doing it right, and it was legit.

Here is what hasn't worked for me in the past:

- Better work. Pretty much everything related to my full-time job is a drag. The suspension of disbelief that my full-time company-work matters has long been broken, and I simply don't care. It's not meaningful to me.

- Coffee shops. Sometimes when I feel like I've been alone all day I work from a coffee shop. I order a decaf coffee from the barista and then say not another word as I work in the coffee shop without talking to anyone.

Here is what I'm unsure of:

- Remote work. I love being able to get my laundry done or hop out of bed and onto the computer or drive somewhere to run an errand if I have to. I don't know if this is a good thing.

- Finding purpose through a full-time job. Is the full-time job just a paycheck? Should I look to have my full-time job fulfill me? Or should I be trying to find this fulfillment outside of a 9-5?

- New technology. Every once in a while I'll get a kick out of learning a new framework or tackling an interesting problem, but I see those as "quick-fixes" rather than a sustainable solution for the long-term.

So now, I'm not sure how to move forward in the new year. I want things to change. I need things to change. It's going to be up to me to change them, but I don't know how. Where can I feel like I'm surrounded by smart and ambitious people? How can I feel accomplished, prideful, and part of a larger community? How can I feel socialized while building something great?

Advice and recommendations welcome.

Looking back, one of my biggest lessons learned from building Gatsby is to avoid pre-mature automation.

What do I mean by this? Take our payments system, for example. Integrating Stripe was quite a doozy: a custom subscription job, saving payment methods, handling failed payments, handling account balances, etc. There was so much logic that went into all of this. All in all, it took about two months to complete our integration and get to the point where it works. (And at this point, total development time for Gatsby was only at ~3 months, so the payment system was 40% of total time spent. Yuck.)

That system, in hindsight, is completely overkill for the business' needs at that point. We had no users, no recurring revenue, nothing. So why did this payment system get built?

It's easy as a developer to get carried away with automation. "If only x was built, I wouldn't have to worry about y", is a common trap—and honestly, it's often not an incorrect one. As engineers, we're always thinking about scale. Yes, it's true that building this thing will make your job easier down the road when we have 10,000 users. The allure of stress-free development is tempting, especially if you have multiple tasks you're dealing with and want to run the business as passively as possible.

However, one must account for the business' position and its priorities. When considering further automation, you have to challenge yourself: "with the current position of our business, is this challenge worth undertaking right now?" More often than not, it's not. Elon Musk has a brilliant quote in this department:

The machine that makes the machine is vastly harder than the machine itself.

The whole tweet is a perfect descriptor of what we're trying to accomplish: scale. If everything is automated, scale won't be a problem! However, the difficulty of automating that solution is much much much more difficult than creating a repeatable, manual process for solving that same problem.

That's what I wish we did for Gatsby. Instead of jumping the gun on automation, I wish I had created a lightweight admin interface where I can see whose turn it is to send an invoice that day. Then send them to a pre-built Stripe checkout page. That would've been the true minimum viable product answer. Instead, we over-optimized by over-automating and burned through two months we could've spent on marketing or improving MVP features elsewhere.

I can't help but think about how this would've been avoided if I had properly outlined the work ahead and determined my appetite for this work. Basecamp created this idea of determining appetite, and this quote sums it up well:

When shaping, we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth?

If I had taken the time to understand that no, this payment integration idea isn't worth spending two months on, or 40% of our total development time, we could've avoided the over-automation.

In the end, it's a lesson learned. Treat all development efforts with great respect and always challenge what "needs" to get built next. I mean, it's not all bad; the payment integration is ready to go, so if we ever do hit scale we'll be set. However, we definitely skipped over some steps in between and certainly mismanaged our time.

This is one of those situations where it's tough balancing being 50% engineer and 50% businessman. Automating processes is tempting, sure, but automating too early can lead to wasted resources and wasted time.

One of the most important aspects of the Gatsby platform is enabling communities to earn money. We're "monetization-driven", which means many of our features will be designed to enable community owners to make some fat stacks of cash.

We came up with two strategies for implementing the collection method. Think about which one you'd choose. They differ very slightly, or so we thought...

The first method: when a user pays a community, the payment enters Gatsby's collective bank account. In our database, we keep track of the community owner's balance, not before Gatsby takes its percentage. When they're ready to use that money, they can set up a Stripe account within the Gatsby interface and trigger a deposit to their bank account.

The second method: before a community owner can start collecting money, they have to create a Stripe account. Then when a user pays a community, the money enters directly into their Stripe account. Gatsby takes a percentage on its way out. From there, they can send their money from Stripe to a bank account.

So, if you were building Gatsby, which method would you choose?

With the first method, you'll have direct control over the funds. Everything that enters the Gatsby platform will enter this account, giving direct control, insight, and safety to the business.

With the second approach, we don't have to worry about the security issues, balance tracking, and communities will get their money right away. However, it won't be so easy to reuse the money they earn. The term "Use your Gatsby Balance" probably won't be a thing.

So, have you thought about it? If you were building Gatsby, which method would you choose?

Well, turns out, there are some serious legal implications operating with the first method. Technically, the platform would become a Payment Facilitator, and like I said earlier, it's pretty similar to a bank. Now you have to be aware of how certain individuals could use your platform to cause harm. If you said option two, you are correct. (The first option is not impossible, but the overhead is way too much for a small team of one.)

In fact, the FTC would not take too kindly to a lackluster implementation of the first method. Here's an example:

Let's say you're a community owner and you happen to live in a country the U.S. has active sanctions on. Then let's say, in the future, the platform had an option to withdrawal your money without using Stripe. The combination of those two things has now enabled a loophole for foreign entities to use Gatsby as a means for fraud and other financial crimes. Yikes!

When (not if) this gets uncovered, you'd be under investigation by the Financial Crimes Enforcement Network, the Office of Foreign Assets Control, the Federal Trade Commission, and whoever else decides they want to throw the book at you. They'd be queuing up fines in the many millions.

The reason method number two protects you is because we'd require Stripe authentication before you can earn money. So if you're cool with Stripe, you're probably cool with us. We'll let them do the hard work here.

Can't we still offer method one but not allow them to withdrawal to anywhere but Stripe later on? Yes, but that would set up a customer service nightmare (and potentially a PR nightmare as well). If these "restricted" users start earning money, then go to withdrawal and find out they can't because of where they live? Can you imagine the emails we'd get? "Robbery! Theft!"

Plus, another one of our pillars of success is a great user experience. And that, my friends, would not be a good user experience.

Just use Stripe.

From Peter Drucker's The Effective Executive:

1. Ask, "What needs to be done?"

2. Ask, "What is right for the enterprise?"

3. Develop action plans

4. Take responsibility for decisions

5. Take responsibility for communicating

6. Focus on opportunities rather than problems

7. Run productive meetings

8. Think and say "we" rather than "I"

The first two practices gave them the knowledge they needed. The next four helped them convert this knowledge into effective action. The last two ensured that the whole organization felt responsible and accountable.

Listen, we hear you.

We're entering a period where organizations are growing faster than ever.

Your tech teams are being pushed further and further to make their technology support more and more.

Multiple platforms. Multiple brands. Multiple themes. Jeez! It's getting crazy.

Your team has probably spun their own solution, and it probably works okay, but then the question becomes "how the heck do we do scale this correctly?"

Well, a change in expectations demands a change in workflow and how we think about building products. We're entering an era of Responsive Design 2.0.

To support these changing design and technical needs, we built Arcade. Arcade the product, but also Arcade the idea that scaling your brand is not random. There's a right way to do it at the subatomic level: design tokens.

Arcade will enable your team to leverage design tokens in the correct way. Your designers will be able to use and update tokens in their Figma file, your engineers will have access to zero-configuration code exports, and anyone will be able to see the live-updating tokens in Arcade. One functional source for everyone. It's a thing of beauty.

If you know what design tokens are, you're in the right place, because today we're accepting our first 10 teams to help (well actually 9, one spot is already gone)!

Arcade is here to help scale your organization by instilling best design token practices, enabling multi-platform design synchronization, and unifying cross-team collaboration on a single source of truth... for developers and designers.

If you want in, we're asking for $2,500 which includes a year of early access for your team. Once the first 10 are in, we'll be deferring any new registrants to the next round!

So go check out our new site and get ready to eat design tokens for breakfast.

-----------

The Arcade team is launching a few posts today, check them out!

Play With Arcade, by Dan Mall

Arcade: Scale Brand Decisions with Confidence!, by Leslie Camacho

Arcade has a big week this week.

On Monday we're opening up Arcade to its first 10 customers. We're pushing a new website live, sending some emails, making some announcements, and more. It's gonna be a big week.

When starting a new project, I have the habit to use "when we launch" as a cornerstone of communication regarding timelines and goal-setting. We were using it all the time on our Zoom calls and Slack to frame some conversations.

It wasn't until we started getting into arguments about what needed to be done that we realized we never actually defined "launch". We know it means some form of "something about this is becoming public", but we never specified what the heck we're launching, what's included, what that will look like, and more.

For our team, Dan set us on the right tracks and made it clear that "launch" would be incremental. It wasn't going to be all-or-nothing like I had originally thought. For our first launch, we'll release to 10 customers. That's it. No plan to launch beyond that (just yet).

Once that definition was set, it enabled us to actually plan for this launch way better and enabled clearer communication. Now when we talk about a launch, we know exactly what that means and makes our meetings much more productive as we remain on the same page.

For every subsequent launch that we have, for Arcade and elsewhere, I'll be sure that we define launch and get on the same page.

It's one of those things that nobody tells you to do when you're building cool things with other people. It's something we had to realize, learn, and fix. But since you're reading this you don't have to worry, I gotchu. Define "launch".

I wrote every day for 2 months and 11 days while only missing a single day. For now though, I'm taking a break.

On January 1st, I said I was going to write every day of 2021, no matter how long or short and about any topic I choose. It was a great idea! I loved it the first month. February got a little more difficult, but the quality of the posts were still good. March came around and it has become near impossible to write something of quality.

I've said before I want to write with purpose. I wanted to write posts that matter, that mean something and possibly carry a message that you, the reader, could take away. When March came around, my energy to create declined severely, taking with it the quality of my posts. I felt exhausted. Posts became more diary-like rather than a captain's log. Something that I wanted to avoid. Writing every day became a chore rather than an enjoyment, especially when working on the business was hard enough that day.

Eventually, the posts stopped having purpose. The messages were insignificant if present at all, the posts lacked links, and they were generally weak. On top of this, I didn't feel like tweeting or sharing links, so there was no feedback or reception without direct work.

Then, when I discovered Beeple's daily art, something inside me gave up. It was a weird mixture of inspiration and futility. A feeling of "THIS is where I want the quality of my stuff to be at, but I can't do that." Seeing his work made me admit to myself that my writing was declining in quality, and I wasn't happy with its current state. That's the important part: I wasn't improving. So that was the last day.

At the very least, a break is needed. Writing, like most things, is something that takes time and energy to produce quality work. I was so focused on quantity that I was unable to maintain quality.

I may come back. I'll probably write again when I'm ready or inspired. But for now, I'm drained and defeated. I need that creative muscle to recharge.

I want to produce things that wow. Something viewers can consume and be impacted. This medium, this writing, is not it. I want to discover what that thing is for me.

And no, nobody's getting $50. Fuck off.

Business things don't always have to be so serious. Dan said right from the beginning that he wants Arcade to be fun (hence the name). These past few weeks I'm really starting to feel that. There's no pressure, we're making progress, and everything is okay.

There's no reason not to have fun.

Perhaps the most underrated benefit of bootstrapping.

Every feature should improve the quality of the demo.

I’m constantly thinking about two of Chamath’s three rules: deliver the wow moment as quick as possible and as often as possible.

The sooner we’re able to convey our product's value, the sooner our potential customer is thinking “I’m in”. That level of early conviction will make any bumps experienced later in the demo much smoother to get over.

After so many demos, I can see the wow factor reactions getting stronger over time. Removing opportunities to say no and delivering wows. That’s my goal.

Today marks the one year point of giving up liquor. I still drink wine and beer, but liquor is off limits. Last March I realized I didn't like blacking out, I didn't like waking up feeling like death, I didn't like not remembering what happened, I didn't like my stomach being in shambles for a week after, I didn't like losing control. And liquor was always the catalyst that got me to those points.

I realized what's the point? I have way more fun when I'm not completely shit-faced and in control of myself. And to people that say "just drink less", liquor sneaks up on you. Especially as a big guy, you can never tell if you're a heavyweight that night or its taking some time to have an effect. Moderating is hard, especially in the heat of the action.

So, I decided to cut it out altogether. I didn't even like the taste. It's still hard to say no to people, but I think my friends are finally understanding and supportive of it.

One year was the original goal I set when I started this challenge last year. However after seeing how great the change was, I don't know if I'll ever go back. But saying forever is always harder than saying for now, so let's set another challenge: two years.

Cheers.

Every few weeks, I get this really strong urge to build something new. Even though I'm building literally every day, this feeling comes over me where I get obsessed over an idea.

A concept comes into my head and I can't let go of it. My brain refuses to move on unless I write it down or pursue it in one way or another.

I've said it before, so this is nothing new to those who know me, but something I've always wanted to do was build the most kick-ass home security system. I'm not paranoid or anything and I certainly don't feel in danger, however the concept is really intriguing to me.

To me it's a perfect mixture of software and hardware. Hacking together locks, cameras, RFID cards, a local server and database, facial recognition, cell phone alerts, etc etc etc. I can go on forever.

It'd be so sick to create the best home security system that's connected to everything. It'd be so FUN. Especially learning the hardware aspect; I don't know much about hardware so that would be really fun.

At the same time, it's not necessarily something I have the brain energy for these days. I'm focused on other things. But one day, these are the types of projects I'll love doing.

Then when that's all done, I'll be able to move on to the other thing.

I just realized my past two posts have been about the future. That's a good example of where my heads been at lately.

Not looking back and ready for what's coming.

Whatever was lingering on the past is now minimal. Whatever anxiousness existed about the future is now minimal. There may be unknowns, but those will be faced when I get there. Hope, excitement and optimism are at a maximum.

Spring is coming.

Ideas of the future are often filled with cities, robots, technology and industry. This perspective is so refreshing—a view into what a rural future might look like.

The best part? It’s an ad.

Awesome.

After reading enough contracts, you start to get good at picking out what's good and what's bad.

I'm at the stage where I can look at an agreement and find holes that need patching or terms that need adjusting—future-proofing.

I guess that's the essence of building a business isn't it? Preparing for the future, for customers, for experiences, for scale, for growth. Everything needs to be accounted for in the foundational systems we develop when building a business.

One of those unspoken skills that you need when you're in a position like this: an ability to predict. Intuition.

If you predict right, nobody notices because you're prepared. But if you're wrong, well, you better hope you're over-prepared and not under.

The worst part about this blog is being in the absolute ZONE with coding and realizing a blog post needs to be written before midnight.

I've been laser-beam coding since 9am. Pushing 13 hours right now.

I made this meme as a way to demonstrate how much I'm in the zone.

Alexa, play "In Motion" from The Social Network soundtrack.

Back to work.

My general rule: if something won't leave my head after three days, I do it.

Usually it's a fear of judgement, a fear of rejection, or fear of failure that deters me from doing what I want to do. The three day rule puts pressure on myself to overcome that. I've chosen to not let these ideas bother me.

No matter what the consequences are—good or bad—dealing with the consequences are better than having this lingering thought always bothering me. And after some experience, I realize judgement, rejection and failure aren't so bad anyways.

And let me say, when that lingering thought is finally gone, that third day is the best.

Today the three day rule took effect with two different ideas. One result sucked, the other was great. But overall, both are out of my head and in the world. Now I have more room to think about what's in front of me rather than ideas of possibilities, and it feels great.

Take action on your ideas. Don't let your dreams be dreams. A ton of shots will miss their mark, but some will stick. And the ones that stick make it worth it.

One year since quarantine started.

One year since I spent my last days living on a college campus.

One year since I separated from my first serious girlfriend.

One year since I moved back home.

One year since I've last seen so many of my friends.

One year since I stopped drinking liquor.

One year since I met one of my co-founders.

One year since challenging myself to exercise happiness. Not wait for it.

——————————————

Needless to say it's been a roller-coaster of a year. March is when it all started. When this month began last year, I never could've predicted how much would change in the coming 12 months.

I barely recognize who I was this time last year. I've learned so much about myself and who I want to be. I've learned to be grateful. To see the upsides. To enjoy where I am and not where I might be. To challenge my answer each time I'm about to say yes or no. To be better.

This year, from March 2020 to March 2021, has been transformative for me. There were a ton of ups and downs, but I'm thankful for it. It's been a period of growth, priming me for the challenges ahead and my next steps in life.

One year ago I was lost—I didn't know what kind of man I wanted to be or even could be. Now I know.

The other day I wrote about "productive unproductivity".

I mentioned to my dad today that I feel like I've been unproductive for weeks. Then he said something interesting which surprised me: "Your product is built. Now it's all about the small improvements that make it great for users. The improvements feel small, but they add up and will be meaningful when people are using your product."

I was shocked at how right he was.

After weeks and months of pushing huge features, pushing the product further day after day, I've reached a point where the most important thing I can do is polish and perfect that last 50%.

It feels uncomfortable, but these small improvements are what will define the product as whole. Reflecting back at what has actually changed vs what I feel changed, the improvements are more than noticeable.

These past three weeks of "unproductivity" have elevated the user experience and functionality of the product very much. The improvements are quite substantial looking back.

Even though it feels like I'm being unproductive, the reality is the opposite. Many small refinements makes for a very different pace than few big feature additions. A pace that I'll have to get used to and accept.

Besides, sometimes these small improvements are the most rewarding.

I love building. The feeling of creating something feels so good, it must be tapping into something deep inside me. Has to be in my genes or something.

Right now that takes the form of code. It enables me to build powerful, usable stuff that anyone can use. But the most important part: I can do that without any resources or capital and a minimum amount of risk.

That being said, my passion isn't coding. It's definitely not computers, it's not software, and it's certainly not SaaS. I love it, but I'm not obsessed with it.

So when Arcade becomes successful (when, not if ;-)), the next thing I do won't be another software thing. I don't want to sit alone in front of a computer all day again. It's tough. As an extrovert, I'm constantly craving working with others and the ability to collaborate. Unfortunately in a bootstrapped scenario that is usually the only option. I don't want everything to be virtual and remote.

The next thing I do is going to be tangible. A physical product. Something that I can touch and feel. Something that exists in the real world. Something that I can easily show others. Something that my friends and family can help me with and possibly use. Something that enables me to meet interesting people and do cool things with others. That's my ideal form of creating.

Coding isn't my passion. Creating things with others is. Solving problems, helping others, and contributing back. Right now, coding is a means to do that. In the larger picture, software is my vehicle to capital—and subsequently, freedom to do what I want.

When I have that freedom, coding isn't what I'll be doing.

The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.

- Swagger.io

I like this a lot. I wonder if there's a quick way to generate an OpenAPI JSON from sniffing the source code. Hmm...

I'm starting to forget why I chose to write every day. On days where I'm exhausted or frustrated, it's very hard to sit down and write one of these posts. In the end, most of these are garbage and most of the time nobody will read it, so why do it? When I have that itch to get an idea out, that's when this platform is most useful.

I am not as obsessed with growth as I was at the beginning of the year. I don't feel the need to have 1000 people reading everything I tweet. I don't measure my success through followers. And I'm starting to realize that in order to get followers, you kinda have to sound like a broken record repeatedly saying the same thing over and over again so people will listen. That's how you become "that guy". I don't really want to become that guy anymore.

I like who I am. I like what I do. I'm enjoying it. I don't need anything extra on top. If some form of internet popularity comes, so be it. But I refuse to let this blog turn into a means for that to happen.

I write what I write. Every day? I'm not sure if it's entirely all that useful. We'll reevaluate in the future.

Straight up, sometimes I don't feel like coding. Sometimes I don't even feel like working at all.

Nothing is wrong, I just don't feel like it. So instead of forcing myself to do work I don't feel like doing, I find work that I'll actually enjoy doing.

This way I can be productive while technically procrastinating.

That level of freedom is really quite relieving sometimes. The idea that "nobody is expecting this" enables so much freedom and creativity where it wouldn't otherwise shine through.

The results and the subsequent reactions from teammates always make it extra nice too. And hopefully, nice enough that tomorrow I'll actually want to do the work I didn't feel like doing today.

Integrated Intercom into Arcade today and WOW it's cool.

Honestly, I usually find it annoying on website landing pages because it serves as a sales tool for companies and provides no benefit for a majority of site visitors. However in an authenticated app like Arcade, where we know who the user is, it provides such an easy avenue for customer support.

A user can ask a question and everyone on our team will be notified (through email, Slack, whatever) and be able to answer as quick as we see it.

This is where I can see the tool being very useful for customers. Instant customer support. And damn, it feels good using a tool that can save me so much development time.

That's where I want Arcade to be: a no-brainer decision that'll add a ton of value for developers and designers.

I've noticed that reactions are where my biases, assumptions, and predispositions are most prevalent. That split-second doesn't allow enough time for logical reasoning to take place, and if emotion is involved, it's ever-more toxic.

Today we were discussing adding a plugin tool to Arcade that I had prior judgements about. My gut reaction was "ewww" and instantly rejected the idea without any thought. I was ready to send a message to the team to speak out against it, before I realized I didn't know what the hell I was talking about.

After considering its usefulness and reading the documentation, then actually implementing the damn thing, I realized how great it actually was. It'll quite literally save me hours of development time and provide a great experience for our users.

Now that I went through that process, I began to wonder where that gut reaction came from. It was biased and entirely inaccurate. I don't even know where that reaction came from! I have zero bad experiences with the tool in the past so my biases were completely unfounded.

It's super hard to ignore. We're always told to "trust our gut" but fail to acknowledge that it may very well be wrong, whether we trust it or not. What separates gut reaction from intuition?

Intuition - the ability to understand something immediately, without the need for conscious reasoning.

By this definition, I understand intuition as a correct gut reaction. Intuition is undoubtedly a strength and provides an edge. It cuts learning time significantly and assumptions become more powerful as you notice more patterns... but what is it called when the gut reaction is wrong?

It's very human of us. Emotions are certainly involved in both gut reactions and intuition, and emotions change frequently. If we feel frustrated, we're quicker to lash out at an idea. If we're confident, we're more likely to take bolder stances.

I'd even argue that the emotionality of someone drives the strength of these reactions. Passionate feelings drive stronger knee-jerk reactions. It works both ways; it can hurt or help.

For instance, I believe an empathetic person is more likely to understand how others will react to a decision, and combined with strong pattern recognition, fuels better predictions and more accurate gut reactions. Emotion forms better intuition.

Regardless of where it comes from, it can be wrong. It will be wrong. It takes patience to recognize when an opinion comes from gut rather than reasoning.

The ability to recognize this and change your thought process to a more logical one is a skill. The idea is not to reject gut reactions, but challenge them with reasoning. Take a second to think, process, and form objectively better opinions.

I'm developing a certain feature to improve the user experience of Arcade. It's nothing fancy; a loading element that smoothly renders components when the API data is ready.

While the feature isn't complicated, it adds so much to the value of Arcade (or at least, perceived value). The better the user experience is, the higher-quality the product feels, and the more it's worth.

I like to compare these finishing touches to one of those restoration YouTube videos. When the video gets about halfway through, I always think "wow, that looks freakin great", yet there's still half the video left! But it's what happens in the second half that makes the restoration go from great, to wow. It's where their expertise shines.

The paint, polish, anti-rusting, and general preparation for future use is what takes the restoration to the next level. And that's where I'm at with Arcade.

This isn't faked or some mirage of quality—the product is good. Really good. But I want users to know that what they're paying for is as good as I know it is.

It's that last 50% of detail that makes something great. Thinking it's good isn't good enough. There is always room—room for improvement.

Whenever I feel stressed, overwhelmed, find myself overthinking or frustrated, it usually means I'm lacking at least one of two things:

Food or sleep.

Those are the fundamentals. 99% of the time the feeling disappears after a good sleep or filling meal.

Or sometimes both.

Yesterday I read this article by Ryan Holiday. How does it feel to accomplish everything you've ever wanted? His answer: nothing.

I believe him. I've lived my whole life thinking about goals and where I want to end up, I can see how disturbing it would be to actually reach it. Because then what? What's next? What do you work for?

That's the wrong mindset however. It's not about the destination. It's not about challenges and beating them. At the end of the day, that feeling of nothingness will come again. Ryan puts it perfectly:

Advancing higher in the ranks, moving the goalposts a little further back, telling yourself that it will be different next time—this is the definition of insanity (expecting new results from the same inputs).

So instead of framing life as a series of obstacles that you have to overcome, I'm going to frame it as the journey being the destination. The privilege to work on challenges that occupy my time and make me think—that's what is valuable. Not the outcome.

I took a happiness class my senior year at Drexel, and one of the articles outlined three equations for happiness. In one of the sections, it mentions work. Work and productivity is how we find our purpose. But what kind of work? Anything? No:

What makes work meaningful is not the kind of work it is, but the sense it gives you that you are earning your success and serving others.

I resonate with the first point there; purpose derived from work that earns your success. Hard work that pays off. Climbing the mountain. But once that mountain is climbed, the second point starts to become evermore relevant: serving others.

That, is what I think the secret is. Enjoy and appreciate the journey as you climb the mountain, but if you hit the top? Start to help others up there as well. Don't try to climb another mountain.

To close out this untypical post, I'll leave you with a little bit of wisdom I read in a Reddit thread.

I aim for 90% of my designs to be powered by my design system of reusable components. It should be good, but it shouldn't be anything special.

The last 10% is what will be custom-made and provide those wow moments.

But if my 90% isn't good, they'll leave and completely forget that special 10%, only remembering the shitty 90%.

I aim to make most of my design good but forgettable, so that what isn't forgettable has its opportunity to shine.

Just two years ago I was writing my first backend code for Junior Workshop at Drexel. Today I was configuring security protocols on my API endpoints, managing fine-grain access permissions, and overhauling security on our server.

Thinking back on it, two years feels like a lifetime ago. I couldn't have possibly imagined the amount of problems I'd face and overcome, and the resulting growth from solving those problems.

I'm proud that when I say "full-stack", I mean it. The person I was two years ago would be so proud of my current self. Surprisingly, I'm not surprised. Something deep down inside me always knew I wanted to be fluent in some form of creation. Whether that was actually a call for independence or some underlying itch to build, I'm not sure. But it was always an inevitability in my head.

The progress has led me to a mindset that if you really want to learn and do something, you can get there. It takes time, persistence, and an unending curiosity. Grit.

Where will I be in two more years? I have no idea, but I'm excited to see.

While building Arcade, we're discovering so much about design tokens that go against conventional understanding.

One of our newest revelations is that tokens aren't static. What does that mean? Today, most people would simplify design tokens by describing them as a key-value pair. A name and a value. However, we created a way for a single design token to have multiple values.

Before digging in to that concept, we need to address the idea that design token = key-value pair. To me, this is wrong. Instead, we've been thinking of a design token as a big object of instructions that include how to transform the token, the context of the decisions behind it, various meta information, and more.

This big object of instructions is the design token. Those CSS, SASS, iOS, whatever variables that get outputted are exactly that: an output of a design token. Not a design token itself. In short, design tokens only exist in a pre-processed state at the source of truth.

So within this big object of instructions, we can now specify a field for dynamic values. This means that the value of a token can change depending on certain circumstances, like what platform we're rendering. Dynamic values gives huge amounts of power in enabling tokens to support multiple platforms.

For example if we render CSS, we can use sizes in rems or px units. If we export to Android however, we can use values in dp, sp, or whatever we see fit.

This puts so much control in the hands of a designer or developer. There's no implicit transformation happening if you don't want it to. Everything can be explicit if you need it to be. No more arbitrary units that might not fit your needs.

It's worth noting that this is only possible with a custom engine. If Arcade relied on Style Dictionary or Theo for our transforming, we'd be very limited with what kind of operations and optimizations we can perform.

The more we work on Arcade, the more we understand the depth of what a design token is. Each day it becomes more and more of a living entity that changes over time.

Most of all though, we're excited to see how people might use these concepts in a way we never imagined. For us, it's all about empowering the designer and developer.

Don't work when you don't want to work.

Especially when working asynchronously and remotely, the weekends can turn into workdays very easily, and vice versa. I don't stick to the typical M-F 9-5 because it's unsustainable for me. I work when I'm ready to work.

That mentality enables me to go farther, for longer.

The best type of business relationships are the ones where each party only benefits. No downsides. This sounds obvious but it's worth acknowledging because I realize how rare they actually are.

In my experience, even the best opportunities involve at least a little bit of opportunity cost: the chance that you might be missing out on something better by seizing the opportunity. While deals may not be perfect, sometimes it's still worth taking.

I'm currently in a situation where an opportunity is so good there doesn't seem to be any downsides. The best part? I bet the other party would say the same thing.

Absolute mutualism. It's like two puzzle pieces fitting together perfectly, and damn it feels good.

So much of creation is "figuring it out as you go." It's impossible for one person to know the answer to every problem off the top of their head or every detail of every tool needed to complete a job. That's an inconvenient truth when you consider that creating something involves problems around every corner.

Of course, as a creator you can ignore all of this and choose the easy option: work somewhere where they've figured out all the hard problems and stand on the probably-now-rich-shoulders of giants.

But if you're interested in the challenge, excitement, or potential reward of building your own thing, problems are inevitable. It's a daily occurrence finding something I don't know how to solve right away. Some problems are harder than others, sure, but those hard problems will come.

Especially when you're deep into your own architectural/logical bird nest that some problems are so specific, asking for help is nearly impossible. Sure you can hire someone that can dig into the problem for you, but it you're just starting, that's an unsustainable solution. More problems are coming, so you better get comfortable being stumped.

Grit is what will define you as a creator, entrepreneur, whatever you want to call yourself. What's grit? Your resistance to frustration. Your ability to overcome adversity. Your ability to figure it out.

That's what defines success: the ability to operate and execute no matter what stands in the way.

And if you do have these traits, don't waste them.

Plugin development and integration is hard. It's so crucial to keep it in mind when building a product, but crafting a well-built plugin might be just as difficult as building the product itself.

It's one of the most apparent pain-points for teams we've interviewed while building Arcade. The ability to link teams and workflows together is undoubtedly a huge benefit—a worthwhile challenge.

It takes time to develop a fully linked ecosystem. I'm looking for experts who already focus on platform-specific plugin development to partner with. Hopefully through strategic partnerships, we can bring teams together faster and more effectively.

After a kick-ass demo today led by Leslie Camacho, Arcade feels like it's on the brink of explosion (in the best way possible).

My theory of run out of ways they can say no is starting to take effect. At the end of each call, the company usually ends with "we love it, but here's why we cant use it." That list of reasons keeps getting smaller and smaller with each demo we do.

It validates my idea of how product-building is similar to the scientific process. We're getting so close to having a no-brainer solution to such a complex problem. It feels surreal how far the product has come, and each new feature distances Arcade from its past-self and competitors alike.

I coded for about 9 hours straight today. It was when I had a headache at dinner did I then realize I had forgotten to eat that day. Unhealthy? Yes. But that's just how much energy is going into the product right now. I'm firing on all cylinders.

We're getting faster. We're getting better. And we're not stopping.

We're so close.

Being able to write every day is not easy. I must accept that each post won't be completely thorough, won't include detailed examples, won't have custom graphics or fleshed-out code examples. Hell, sometimes it won't even be good writing.

These posts aren't going to be perfect.

I usually take about 10-30 minutes writing each one at the end of my work day. If I wanted each article to be perfect, writing daily wouldn't be possible.

Today on Twitter, someone commented on one of my posts saying how it would've been nice to see a concrete example; details about the schema I was talking about and more specifics.

While I would love to include details like that, sometimes I simply can't do it. It would take too much time or too much effort to produce these posts. I wouldn't enjoy it anymore. If the quality of content suffers, so be it.

I know people stumble upon my blog expecting to find a thorough example-filled article. They may not know I write every day. I know my posts are going to disappoint people that come here with those expectations, but that is something I won't do anything about.

The goal of this blog is to inspire thought. To get you thinking. That's the only goal. It's not a blog of tutorials or lessons or anything like that. It's whatever comes out of my brain when I sit down that afternoon.

Accepting criticism is healthy. Getting used to disappointing people is also healthy. Living to fulfill others' expectations would only drive me crazy and drive readers to form even higher expectations. I'm going to disappoint and that's okay. I run this blog for me, not for you.

In short: you get what you get and you don't get upset.

Design tokens are a new concept in design and development that simplifies how we think about supporting brands across different platforms. They enable a single collection of variable objects to power the design of web, iPhone, and Android products, as well as any other branding that a team may need.

There's no standard for working with design tokens, however there are efforts currently underway that are trying to standardize definitions and best practices. The effort is being tackled by a W3C working group, individuals, startups, and established companies alike.

My team and I at Arcade have been building a design token manager for this reason and have been learning a ton on the way.

Design tokens are new. As we think about them and apply them in our workflows, our understanding will evolve. Two days ago while discussing Arcade, that happened to me.

I know what I'm about to say may not be received well. It's going to challenge the current consensus of what a design token is. You've been warned! Here we go...

Design tokens only exist in a pre-processed state.

Once compiled and transformed, the output is no longer a design token. Instead, it's simply what it is: a key value pair fit for the platform. A variable in a form the platform can understand.

The reason for this conclusion is because the purpose of a design token is to exist as a value, surrounded by context, ready to be transformed. When the design token goes through that transform process, it will inevitably lose nearly all of its meta information. That meta information is very important: it provides context to the token and instructions for how that token should be transformed.

For example in Arcade, we have a schema for our tokens that supports fine-grain control of how the rendering engine will handle that specific token. Should this token be ignored for a certain platform? Does the value change depending on the platform? Should we only render this token in certain circumstances?

This is only some of the information that makes up a design token. Each token object grows more and more as we find more useful information that can be stored in them. Once that crucial information is gone though, we lose its transform-ability.

Think about it: we can go from our token source to CSS very easily. We can also go from our token source to Android very easily. But can we go from CSS to Android? No. Because we lost all of the meta information and rendering instructions that were included in the original, pre-rendered design token. Not only that, but the name and value might have completely changed from the source!

When explaining this concept to the team, I used a metaphor of a tomato. You can go from a tomato to pasta sauce very easily. You can go from a tomato to a slice of it on a sandwich very easily. But can you go from sauce to a sliced tomato? No! Because that original tomato has been completely transformed and its original state is completely unrecognizable.

So moving forward, I'm going to be using this frame of thought when talking about design tokens. I can't see it any other way. While organizations might not have this expansive amount of information around their design tokens yet, I imagine they will soon to further enable their teams. Considering what is and isn't a design token is important.

Design tokens only exist in a pre-processed state in their source. Do you agree? Disagree? I'd like to hear what you think.

A few months ago I proposed an idea to my brother Nick: what if you could use code components to compose videos? This way you can code elements once and reuse them, fueled by data.

Then yesterday, I see this tweet:

WOAH. That is exactly what I had in mind, and so beautifully executed as well. This is just the beginning, the earliest stage of what can be the most powerful video creation tool ever.

While the implementation is great for a version one (seriously I was so impressed), the possibilities are huge. Now that video can be containerized like this, you can create a whole library of video components that someone can easily drag and drop into their project. I can see an environment similar to npm enabling users to quickly add video components to their composition. Templates become data-driven and so powerful.

Working with code also enables, for the very first time, responsive video. So now a video can be composed once and work for any size screen! Advertisers and marketers no longer have to consider all of the different banner sizes, window frames, or screens their video may be played on. Design once, render and use anywhere.

Not only this, but video processing can now easily be programmatic. That is, remote servers can render videos automatically based on certain data changing. As a simple example, imagine having a program automatically render a custom video every time it's someone's birthday. You can then upload that video to Twitter, YouTube, or Facebook, and share it with everyone. All without doing anything except some initial preparation.

This is really groundbreaking stuff. If I had money or time to invest, this is where I would do it. There is a lot of money to be made here somewhere. I don't know where exactly, but with enough time in the space, it'll jump out at you. (Even if something new isn't quite a rocket ship, Adobe wouldn't let a potential competitor come anywhere close to Premiere or After Effects' market. High chance of acquisition.)

Stay tuned. This is big.

Asking this question has revealed so much. It's obvious what features we have, what problems we're solving, and what our product is, but what are we selling?

The answer usually isn't obvious. If it's obvious, you're probably not building anything new or you're pretty damn good at this. Regardless, take a chance. Think about it.

Oftentimes, what we're selling isn't actually the product, but the result of our product. For example, task management tooling companies don't actually sell a task management tool; they sell time saved, money saved, team organization, etc. Sell the why, not the what.

If you're lucky, the introspection from asking the question will uncover something deeper though. Something overlooked. Perhaps something that makes you unique, or something that you haven't thought about. Or maybe a closer look at a feature that you've been undervaluing—one that has become so normalized to you that you have forgotten what it's like without it.

Whatever it may be, the question inspires a new look at what you've created. A fresh perspective that includes the totality of your product, not just its most recent developments.

So much understanding developed from such a simple question. Today, this question might have inspired a decision that will fundamentally change the way we work for a long time, at least on our small team. I think this same question can uncover so much for you as well. And there's nothing to lose from asking it.

So, what are you selling?

"Nobody reads advertising. People read what interests them, and sometimes it's an ad." - Howard Gossage

Nobody likes watching ads. We watch what entertains us, and sometimes it's an ad.

The more entertaining, the better the ad.

Super Bowl sponsors kill at this.

A pattern I've noticed during sales demos is how similar the process is to the scientific process.

That is: Observe, Hypothesize, Experiment.

When showing potential users your product for the first time, so much intuition is involved with a hint of empathy. As the creator, you have to listen and understand how your user feels when viewing their product. You must observe their reactions, whether it be positive or negative. These reactions can be expressed through involuntary face movements, intonation of their voice as they speak, the types of questions they're asking, etc.

It's very rare that a user is going to say "I feel happy!" or "I feel sad that this feature isn't there", you have to really listen to what they're saying and the context of how they're saying it.

The human element involved in selling was really surprising to me.

Another important part is to take these observations and form hypotheses regarding your product and approach: if we had X feature then we could enable teams to do Y, or if we said X then they would've known we can do Y. If you're a programmer, these hypotheses should be easy; they should always take the form of an IF THEN statement.

Each hypothesis then leads to experimentation. Does changing this thing lead to more success? Whether that be a more successful sales process or a more valuable product for your users, each hypothesis should render some form of results. Make it clear, make it testable. Rinse and repeat.

After realizing this, it kinda blew my mind and everything became simpler. Building product is invention.

And invention is science.

You can't make a good product without a good team. It's as simple as that.

When you're building something as difficult as a business there will be issues.

The ability to communicate, voice frustration, work through those issues, and make a plan of action to correct what was wrong is a skill each of my co-founders have and skills that I appreciate so much.

It makes the product better and it makes the team unstoppable.

Both Leslie and Dan are such good listeners and even better teammates. Can't thank them enough for how they work and being who they are.

Absolute communication killers. And we're only getting better at it.

I've never sold anything before. Now I'm trying to sell every day.

Giving demos and presenting your product to strangers is such a difficult, exciting challenge. I started out so, so bad at it. But as it goes with any skill, I feel like I'm getting better at it through practice. I'm not ready to say I'm good at it, but I'm certainly getting better.

It's all about confidence. Confidence in knowing what you're talking about, confidence that your product is the solution to their problems, and confident that you are the expert on the subject. Even if you know those things, acting the part and projecting that forward is a whole nother challenge.

It's an exhilarating process; one that can be perfected and a worthwhile challenge.

Channel your whizbang. Channel that innner Jordan Belfort. Always! Be! Closing!

Today while thinking about the platform translation Arcade has to do, I had a question:

To my surprise, there wasn't really a good answer. And I feel like there should be.

When creating a design token source, you want to write them to be platform-agnostic so they're ready to be translated to whichever platform you need.

So storing a variable's value as 24px, for example, would be incorrect. The px unit indicates CSS or and is too specific for a token.

Why not? The problem arises in transformation. Let's take a few approaches and see why.

The first would be blanket transformation, where we assume each number has to be transformed to Swift's pt values. So with a value of 24px, you'd strip the unit from the number, divide the px unit by three, and add "pt" to the end. Boom, you've successfully translated a CSS value to Swift.

But then what happens when we have a font-weight property? Usually those are stored in a unit-less number like 600. With a blanket transformation, since it's a number you'd turn your 600 font-weight into 200pt. Ew.

So, let's specify type! We can say what numbers are sizes and what numbers are font-weights. This will let our transformer know which values to translate into pts and which one to keep. This approach would work! Explicit types is a great aproach.

However, what if we want some sizes to stay as px values? How do we know those values should be transformed? Their types are both size, so type isn't quite the whole answer.

Style Dictionary kinda solves this by allowing you to use unit-less numbers. So in this example, "1" would translate to 16px.

This still requires explicit types on each number value so you know whether you're working with a font-weight or size.

While explicit type setting is good for tokens, that one extra input value is annoying to me. For Arcade, I want to keep token creation as easy as possible with the lowest cognitive load. I don't want any token to require more than a name and value. Everything else is extra.

So, I propose the creation of a unit that describes a platform-agnostic, pre-processed value (before transformation).

By using this unit, you'll know exactly what values should be transformed and which ones shouldn't. If another unit is used, we'll keep that unit. If there's no unit, we'll assume you want to keep it unit-less. And if the special unit is used, we'll try our best to transform the value to its appropriate platform value.

This enables implicit types for rapid token creation and maintains the cross-platform nature of token storage.

Maybe this idea sucks, I don't know. Or maybe it doesn't.

One way to find out.

Yesterday I stumbled upon this video of Chamath giving a talk about scaling Facebook to a billion users. The whole video was great, but the message boiled down to three basic questions that every feature proposal was required to answer to:

If the feature wasn't trying to answer any of these three questions, it was rejected.

The goal is to focus on those three questions and to keep delivering on it. Find your product's core value-offering and maximize delivering that as soon as you can, as often as you can.

Ignore all those math calculations about optimizing for the best X value. Stop over-focusing on that one feature. True growth comes from wins that scale. That button color is not a long-term growth catalyst, so ignore it.

And perhaps the most important piece of advice from Chamath: ignore your gut. Stop listening to your biases and your ego. The product is about the users, not you.

That's how you make a great user experience, and subsequenty, a great product. Keep thinking about why your users are there and deliver what they want as soon as possible.

Give them a bang. Make them happy.

Outlined in his autobiography, the Ben Franklin Effect is a technique used to get someone to like you more. It's pretty simple: asking a favor from someone will get them to like you more than if you did a favor for them yourself.

Franklin describes how he dealt with a rival legislator as an example:

Having heard that he had in his library a certain very scarce and curious book, I wrote a note to him, expressing my desire of perusing that book, and requesting he would do me the favour of lending it to me for a few days. He sent it immediately, and I return'd it in about a week with another note, expressing strongly my sense of the favour. When we next met in the House, he spoke to me (which he had never done before), and with great civility; and he ever after manifested a readiness to serve me on all occasions, so that we became great friends, and our friendship continued to his death.

To be honest, I think it's a little psychopathic to use tricks like this to get people to like you. It's weird. Don't brag about this if you do do it. So then, why am I telling you about it?

Because I totally fall victim to it. If you ask me for a favor, I will 100% help you just for the enjoyment of it and instantly think of you as a good friend (as long as you say thank you).

The linked Wikipedia talks about cognitive dissonance as the reasoning behind the "trick". However I think there's something more human—more communal—behind its roots. We as humans find enjoyment from helping others. When the problem is solved, both helper and helpee find satisfaction.

A certain level of trust has to be involved too, as the person asking for the favor must respect the helper's abilities and put faith in what they can do. When trust is received, trust is given.

I get a lot of enjoyment from helping others, so to me, the Ben Franklin Effect makes a ton of sense.

If you ever need help, you know who to call.

On Sundays my energy for the week is somewhere on a scale between totally burnt out and PUMPED to work.

This Sunday I'm absolutely pumped. I've got Tweets scheduled, demos lined up, no work-in-progress, and a whole lot of energy.

I'm locked-in and ready to sell. Nothing but progress on Arcade this week. We're getting closer and closer to our first paying customer and I can't wait.

The product is shaping up to be something really special, and it feels like every day it distances itself from the competition just a little bit more. When the product becomes public, it won't even be close.

It's always day one.

I'm on fire. Let's get this fucking money.

This is a retroactive post written to maintain the daily structure.

I failed! I missed a day. The time I remember to write has been slowly crawling closer to midnight until yesterday, when I completely forgot all-together. I should've seen that coming considering how the day before my post was published 3 minutes before midnight.

Finding the mental energy to write after a day of work is hard. Sometimes it feels like I'm juicing my last few brain cells dry.

The results have been worth it though. So instead, I'll have to start writing at the beginning of the day rather than later. I have to challenge myself to not wait until the last minute. I'll see how that goes this week.

In the meantime, I'm out $50. Ouch.

A composite design token is when a design token's value is made up of other values.

Pretend you have two tokens:

GLOBAL.COLOR.BLUE = '#0000FF'

GLOBAL.BORDER.OUTLINE = '2px solid'

If you combine the two to make a new token, you can say:

THEME.BORDER.PRIMARY = '{GLOBAL.BORDER.OUTLINE} {GLOBAL.COLOR.BLUE}'

The final value would be '2px solid #0000FF'.

This is different than an alias token, because it is doing more than just a reference. It's composing multiple tokens together.

Alas: composite tokens.

Today has been crazy with the $GME fiasco. It's fascinating.

No piece of news has distracted me more than today's. I'm completely hooked: refreshing my Twitter feed, seeing everyone's reactions, hot takes, predictions, Robinhood shutting down, the wave of politicians responding, texts from family, basically the entire internet imploding.

It's so much I can't look away. It feels like the world is changing right in front of us. Between this and the insurrection a few weeks ago, it seems we're entering a new age of decentralized organization: a huge amount of people aligning their small behavior in a specific direction to cause a big impact. It's a new way to organize. A new way to change the world. And it's all through our phones.

It's been made clear that institutional stability is very much in the hands of the people.

But who stopped each effort? The insurrection was extinguished by the suspension of 45 from Twitter and other social networks and the hedge-fund attack was stopped by Robinhood and other trading platforms (probably just temporarily). Tech leaders continuing to flex their muscles... King Jack, anyone?

Regardless of how distracting and engaging the whole crisis is, it's still my choice to participate in it. At the end of the day, the second I put my phone down, everything is back to normal.

For now, at least.

You know what I've been saying about reducing cognitive load and how the Arcade engine has to be excellent?

After a ton of work today, the engine is now re-architected to be stronger and more flexible for future needs, while also being easier to understand and maintain.

It's a thing of beauty.

When you're confident in what you build, something changes. It enables you to walk, talk, and sell with confidence. Gives you and your product swag. Pizaaz. A certain kind of whizbang that you wouldn't otherwise have if you were insecure or unsure of what you built.

Strive for that, because damn it feels good.

Sometimes, not solving a problem in the best way possible is not an option.

If you read my post yesterday, you'll know I'm absolutely fixated on the code that drives the language transformations within Arcade. I like to call it the engine.

It's becoming a really complicated piece of code and it's a huge value proposition to the business. Right now it does its job, but I'm foreseeing some limitations that might hinder its capabilities later down the road.

While most of the code within Arcade can be minimally viable and not exactly perfect, the engine is something I need to be excellent. I know customers are going to be requesting different formats and customizations, so I want to be prepared for that. The current complex architecture may limit those possibilities.

I've re-written the engine once already and I'm considering doing it again. There's so much potential with design APIs, I want to be able to capture it fully and be in a position to respond to users' needs as best as possible. Without a solid foundation, that's going to be difficult.

If Arcade is going to be a source of truth, then fostering the ability to export is a top priority. A source of truth is useless if the information is stuck inside.

It'd be really easy for me to say it's good enough, throw a blanket over it, and not think about it ever again. But for me personally, I need everything to be rock-solid. There is no room for foundational weaknesses that a competitor can exploit. Not solving this is simply not an option.

If it was an option, why would I be doing this? To get beat? Hell no.

Cognitive load is the amount of working memory your brain requires while solving a problem. The more complex a problem is, the heavier the cognitive load.

Today I was building a new feature for the engine that powers the exports of Arcade. Fueled by platform-specific configuration files, what started as a simple series of functions to generate file strings has grown to a complicated beast of code. The engine has become very difficult to operate in.

You know when your computer has a million programs open and everything is becoming really slow as your machine gets hotter and hotter? Yeah, that's pretty much my brain while building new features in the engine.

This is a warning sign. If something is so complicated that it's difficult to work on, then it's probably not written well. A heavy cognitive load is a red flag to be beware of in software; if it's hard for me to understand, it'll be impossible for other developers in the future.

Unfortunately, it's hard to imagine a better way to do it. It's not like I just hashed this thing together willy nilly. There was a lot of thought that went into the engine. It's one of the features that defines the power of Arcade. It has to be rigid with defined rules, yet be flexible enough to handle the needs of any format.

So, optimizing for cognitive load will be an investment. I need the engine to be easier to work on so I can make it better. This means I'll need to avoid creating cognitive debt. If I'm not simplifying, stop, and rethink.

Simplification through addition isn't easy. But it'll be worth it.

Man, I don't know anything about building for Google. This is the first project where I'm thinking "yeah, I guess that'd be pretty nice."

I tested searching one of my articles and the result is weird:

When searching "carbonemike make work not suck" this is the first result. For some reason, it seems to be combining the titles of two very separate articles. Make Work Not Suck and I Want You To Breathe were posted seven days apart from each other.

I have no idea how or why Google is deciding to form the result like this.

They're not next to each other, they don't link to each other, and they're not even related!

When investigating the meta information of the page, the title and meta info looks good:

Within Google Search Console, the meta information that supposedly drove the generation of the search result is the same. So, I'm baffled.

This is one of those problems I don't even know how to begin diagnosing and fixing. I suck at SEO, I don't understand Google's generated results, and while I want to learn, I don't really want to dig into SEO world either. It seems to be pretty toxic from the surface.

Any ideas?

Contracts and other legal documents can be intimidating if you're not a lawyer. They're filled with so much information and fancy language it can be really hard to decipher if you're not used to them.

I like to make sure I have an understanding of the contract myself before hiring a lawyer, that way I can point out any confusing sections, points of concern, or areas where the lawyer's summary doesn't match my understanding.

Reading contracts before sending them to lawyers will get you a better bang for your buck (and you should ALWAYS consult a lawyer before signing a legal document).

I've surprised myself with how accurate I've been reading and summarizing my own contracts compared to the lawyer's summary, so I figured it might be valuable for you to see how I go about it so you can read over your own contracts.

I'm NOT a lawyer and this isn't legal advice. I'm a developer. This is just my two-cents.

Tip: Take Notes

Easy: if you see anything you don't understand or don't like, write it down. These notes will be helpful for your lawyer and will help them provide feedback or suggestions for you. If you don't write things down, you're gonna forget.

Tip: Read the Definitions

Every contract usually has a definitions section after the summary at the beginning. These definitions will help explain whatever the heck the document is talking about.

Tip: One Section at a Time

Most of the time with contracts and legal documents, each section is trying to make one point. If you can find that one point, one section at a time, you'll be golden. Each subsection is really just another level of specificity for the main part, usually outlining what happens in hypothetical situations.

Tip: Look Up Words You Don't Know

If you come across a term you don't know, look it up and mentally replace that word with the definition. For example, the term pro rata was coming up a bunch in one of my contracts. I looked it up and it was a fancy word for proportionally, so every time I saw that phrase later in the contract I mentally read it as proportionally.

This is a good way to simplify the lawyer talk.

Tip: Look Out for Dilution and Vesting

If you're signing a document regarding ownership, understand and look out for these terms. In short, dilution is how your shares are affected when new shares are issued. Do you own less? Do you get a chance to buy more shares? Make sure your contract doesn't leave room for squeezing your ownership out.

Vesting is a timeline for when your ownership kicks in. The contract will probably say you can potentially own x amount of shares. However, you don't get all of that right after signing. You may get 25% of it after signing, then 25% after a year, then another 25% the next year, and another 25% the next until you officially own all of your shares. This timeline is called a vesting schedule. Make sure it's reasonable.

Tip: Don't Skip Anything

Read every section! Even if the title doesn't sound important, if it's in the contract, it's important.

Even if you skim through looking for important words, don't skip the entire section.

Tip: Hire a Lawyer that Operates in the State of the Contract

Usually, lawyers are only licensed to practice in one or two states. If the contract is about forming a company in New Jersey, hire a New Jersey lawyer. If you try to hire an out-of-state lawyer, be prepared for the "we're not licensed yadda yadda" speech.

An in-state lawyer will be more prepared to deal with the document and will be more experienced with the state laws that govern the contract.

Tip: Be Real With Your Lawyer

Find a lawyer you like (surprisingly hard). Send the entire contract with your notes attached, including what confuses you and what concerns you. They'll appreciate your diligence and will 100% address your concerns. Your lawyer is on your side, so be real with them. Tell them how you feel about the contract. They'll either reinforce your concerns and give you next steps to address them, or put you at ease.

Contracts look big and intimidating but they're not too bad when you take it slow.

Get it done, son!

In an effort to deal with the content overload I've been experiencing and to drive more traffic to the site and my Twitter, I'm beginning to syndicate my blog posts on Medium (AKA reposting).

My goal is to get my content in front of more eyes, and link back to my Twitter in each of the articles. Hopefully the consistently scheduled posts will favor me in the eyes of the Medium algorithm. In every article, if I can, I embed a Tweet of mine, and always reference where and when the original article was posted like this:

Each post is scheduled during the week at 9am. The best posts are saved for Tuesday-Thursday, the not-so-good ones are scheduled for Fridays and Mondays.

It took a good amount of work transforming the article to the Medium-acceptable-format, especially looking for a cover image (the ones sent from carbonemike.com are dynamically generated).

If the experiment goes well, I'll customize my CMS to better prepare for Medium's format and try to automate the process.

Let's see how it plays out...

While I'm definitely able to write another substantial post tonight, I have to pace myself. I have too much content from this week that I still have to share to Twitter, Reddit, etc. It's becoming overwhelming!

This problem also has me thinking about how I want to manage all of this writing. I think there's some gold in here already, and I expect more to come. With more and more content, it's going to get hard keeping track of all this. The site is really minimal and I want to keep it that way, so adding more shit to the blog isn't a solution.

I've been thinking of posting my best posts here to another platform where they might get more visibility...I was thinking Medium or something else. Medium has its downsides, but the copy on the blog will always be here. That way my best posts are easily searchable and all in one place.

I'm not sure! If you have any ideas please slide in the DMs!

As creators, it's our responsibility to keep up with the demands of users and build the best possible experience for them. As time goes on, users' expectations rise as they see what is possible with current technology.

It only takes one innovator with one great experience to show what is possible and to change our users' expectations forever.

Consider dark mode! Just five years ago it was somewhat of a rare feature. But now, users expect the option from almost every website they use.

That's what makes building a product so difficult: our users' needs are always changing. It is our job as creators to respond to our user's needs and provide the best experience for them. And like I said before—if we don't, our competition will. And users will always go where the best experience is.

It you go back to 2010, you'll see the emergence of Responsive Web Design; the process "that makes web pages render well on a variety of devices". While the title is referring to a web page that responds to different viewport sizes, I like to think that term has another meaning: the ability of a web page to respond to users' needs.

In 2021, we're entering a new stage of user's needs and expectations—Responsive Design 2.0. Today, users expect a certain amount of theming abilities and accessibility features. Take a look at this Tweet below covering the new WhiteHouse.gov:

This is becoming standard across all websites and applications. Designers and developers have to adapt their process of building new products to account for this new demand. And if they don't, your company will lose users, and subsequently lose value.

So, how can developers and designers meet this new need of theming, accessibility, and customization? Think about it from the very start. Prepare your code to handle these types of features. Focus on creating a reusable design system from the very start, and consider how design tokens might power the components to create beautiful experiences like this.

Don't put it off either. The longer you wait to face this challenge, the harder it'll be to fix later on. And the longer you take, the more time you give your competition to eclipse your functionality.

So there you have it. Looking for something new to learn and master? Responsive Design 2.0: themes, accessibility, and customization. Let the user specify their preferences and respond to their needs.

I conducted five interviews today and several others in the past few months. These interviews were conducted with design system engineers from companies of all sizes.

You know what they all have in common? Two things:

1. Design tokens are HARD

2. Keeping in-sync with the designers' Figma file is impossible

As someone trying to bring developers and designers closer together in the creation process, this is really frustrating to hear! Figma is a tool to produce design prototypes. That's it. It is NOT designed to be a source of truth for anything.

I get it—it's your organization's design tool of choice™. That does NOT mean every design decision should live there. To everyone else on your team, Figma is an inaccessible black box, impossible to keep track of, and simply a mess to others not familiar with your orchestration of chaotic good.

Just because it can store this information, doesn't mean it should.

Look at this screenshot. Look at the abundance of text and information on this screen. Now imagine you're an engineer that has to find a certain color for a certain state. Do you see the problem?

For a simple task of finding a color, it may take an engineer 5 or 10 minutes to find what they're looking for. Scale that to every front-end engineer on your team, several times a day, every day per week. That's a lot of money.

(Actually, I did the math: if it takes an engineer making $150k/yr a total of 5 minutes per day to find what they're looking for (conservative estimate!), and let's say there's a team of 10 engineers... that's costing $267.50 per week!)

And for everyone else in the organization? Forget it. Good luck finding anything in here, or even finding the link to the Figma file.

So let's fix this: for those teams that are using Figma as a home for your design system or design tokens, or in the process of making that so, stop. Your engineers, your marketing team, your project managers, and pretty much everyone else in your organization will thank you.

To clarify, I have nothing against designers or Figma. Designers do be designin' and that's alright. But Figma as a solution for brand decisions is a great way to make those decisions inaccessible to the rest of your team.

The lack of structure will only lead to scaling issues, documentation issues, knowledge-sharing issues, developer-designer synchronization issues, etc etc etc.

Think about the goal of a design system: to have a modular, cohesive design language for your entire organization. Figma is not for an organization. It's for a designer.

An alternate solution? Communicate. Stop operating solely within the confines of your Figma canvas. Talk to your engineers. Make decisions together. Instill a process for this decision making process and document it. Fuck it, print something! Make a little reference card for your teams! Make your work visible and accessible to everyone! MAKE YOUR DECISIONS KNOWN!

In short, teams need to be brought together. Based on the interviews I've conducted, teams are struggling to maintain cohesion at the very infancy of their design system. Think that'll scale?

So designers: please stop living in Figma. It's not designed to do what you want it to do. No matter how many plugins you throw at it. Instead, make your work visible to everyone. Make your work accessible. Find the right tool for the job.

Yeah, I'm gonna catch some flak for this, but someone had to say it.

How do we solve big problems? We break them down into smaller ones. And each of these smaller problems have their own, tiny solution. So we go down the line finding little solutions to our little problems, one after another. Until soon enough, we realize we've solved enough little problems that we've reached our original goal and solved our big problem!

Designers and developers, you know what I mean.

Think of the last big thing you designed. The last big thing you coded. It took several little steps and areas of focus before you got to a place where you could give it the chef's kiss and say "It's finished. And it's beautiful."

So when I hear a company is struggling with "design consistency", "designer-developer synchronization", "design system governance"... these are BIG problems. And they're hard ones.

But just because they're big problems, doesn't mean they need one big solution. Instead, let's solve these problems like we solve all of our big problems: with a bunch of smaller, more manageable answers.

In my opinion, the big problems I listed and several other organizational issues can be solved with the same little solution: design tokens.

For those of you that humorously just blew a little extra air out of your nose, let me elaborate.

Design tokens are not just variables. They're a new way of thinking. They break big, complex decisions into small, manageable answers. They push modularity and reusability to the extreme.

And most beautifully of all, they can be whatever you need them to be.

---

This is the beginning of a series I'll be writing on design tokens. More to come...

Joined Clubhouse today. Holy shit, it was so cringe.

Every speaker acted like an "authority" of whatever subject they were in. Regardless of whether they really should be in a position to give advice, their reason for being a speaker felt extremely disingenuous. They felt fake. And it did not inspire me to care about what they had to say.

It reminds me of a video I saw from journalist-youtube-chef Adam Ragusea a while back. He gets into the topic of Authenticity vs. Authority.

His point: authenticity is more trustworthy than authority, and therefore creates a more engaged audience. In his videos he doesn't try to act like the best chef of all time because he knows we would all roll our eyes and see through his bullshit. Instead, he teaches his viewers from the perspective that he's just like us. He doesn't say things are right or wrong, only what works best for him.

Adam Ragusea acknowledges his biases. He knows he's not the best. He knows he shouldn't be telling his viewers what to do. He's not speaking from a place of authority. He presents information as if we should be taking what he says with a grain of salt. And yet, it has the exact opposite effect—it makes us even more inclined to listen to him.

That's what Clubhouse was lacking. Too much authority and no authenticity. Not a hint of humility.

Their motives of self-growth were so transparent, with each speaker referencing their Instagram accounts every two minutes. The absolute lack of authenticity sucked away any trust I might've had for any of these speakers. It made me not want to listen and not care. These people weren't human, they were robots.

From here on out, I'm going to try to be as authentic as possible. I never want to be an "authority" and act like those Clubhouse guys.

If you want people to listen to you, don't be authoritative—be authentic.

Authenticity is the new authority.

We pushed Arcade to version 1.0 this week.

The effort started a few months ago after showing a proof of concept to a bunch of potential customers. The feedback we got was overall really positive, however the interviews exposed some flaws within the design.

For one, how we define "design token" has changed drastically. Armed with the feedback from our interviewees, I reworked the entire API and interface to meet their needs. It took longer than expected, but I'm so happy with the results.

Some of the features I've built are really next-level, and I am so excited to get our first customers onboard. I'm tempted to send a Tweet out saying "so who wants to use it?"

Honestly, I think Arcade is already a million dollar company. I think Arcade can be a billion dollar company. This team is filled with talent, and our market is poised to grow immensely.

The list of ideas we have keeps growing as we dive deeper and deeper into this niche. The possibilities are endless.

While I'm proud of the progress we've made, I know this is just the beginning.

Today, levelsio Tweeted this:

And I asked if there would be a prize for the winner. He asked if I had any ideas. I replied:

After thinking about the idea, I thought damn, this is a pretty good idea! I think the community would really rally around awards for makers, chosen by makers.

I like to imagine it as ProductHunt, but for makers already on their journey. We'd choose a "class" every week or two (rate TBD), and the community would vote on their favorite. Factors we'd account for is the actual business performance, how well they're building in public, traction, design, performance, etc. Then myself and other high-profile community members would help determine the winner from the top-voted.

This would also be a fun project to build in public myself. It'd be a cool opportunity to engage the community, and a situation where I can document my process for building these sorts of things. With that type of content being produced, I'd be able to use it to promote across different mediums like Twitter and YouTube, and hopefully help in reaching my 1k or Bust goal.

My only concern is burnout. I really want to focus on Arcade, but I also feel the need to build something that I can do for fun and document without worrying about leaking competitive information.

I'd love to not work alone on this. I'd love to build this with others. I'd love to have others contribute to the design. And I'd love to figure out a way to make this possible! Hmm...

You, reading this right now. Breathe. Take as deep of a breath as you can.

With all the things constantly happening around us, the endless list of things to do, the goals and challenges we have, the expectations and pressure to perform... it's easy to forget who's driving this ship. Your ship.

It's easy to feel like you're not in control. It's easy to feel like you're on rails, like there's no other option other than to do what's next on the list. It's easy to think about what's next so often that you lose the moment you're in right now.

So I'm here to remind you that you don't have to do those things. You can stand up right now. You can walk out that door and go for a walk wherever the land beneath you stretches. You can leave that meeting. You. Can do. Anything.

Let's do an experiment: look at your right hand. Now think to yourself, "I'm going to lift this hand and put it in the air." Now, on your own time, on your own volition, raise your hand for no other reason because you can.

Now think: when was the last time you did something because you can? Not because you were supposed to or that it's a habit of yours. The last time you made the conscious effort to think "I'm going to do this."

For me, it's been a while. I forgot my freedom today. I forgot that I do things because I choose to, not because I have to. I feel like I snapped out of a trance.

To fix this, I promised myself I'm going to exercise my free-will muscle tomorrow. I'm not going to do anything unless I want to. Not because I have to or that it's expected. What will that entail? I'm not sure, that's for future present-moment me to decide.

I'm challenging you to do it too: really think about what you're doing. Why are you doing it? If the answer isn't "because I want to", stop doing it. Take back control for at least a few seconds. Breathe. Raise your right hand. Remember your power.

And most importantly, despite the world around us making it so easy: don't forget your free will.

Standing in the swallowing shadows,
shoulder to shoulder with those beside.

A shimmering sight of what could be,
where walled impression of stone stands high.

Tall as ten-fold and built to be seen,
the towering wall attempts to hide.

Many ignore its plain disguise and
the freeing truths of what lay inside.

Out from those shadows there will rise
a Hero’s quest and battle cry.

The hero builds so he can find
where he belongs on the other side.

A doubtful feat but worth his life;
a choice to live or just survive.

With all his will and all his might,
he pushes through, he starts to fight.

Covered dark within the black of night,
the wall that stands will fall tonight.

To take what is his dying right—
aid his efforts or stand aside?

Misery Loves An Audience is my best performing post and my personal favorite. I keep wondering why that is.

Then today, Paul Graham tweeted this:

And I think that's it. Misery had a point. It had a purpose. The reason for that post was clear, it was educational, and there was something the reader can take away. It wasn't preachy but dense and concise.

So moving forward, I'm going to make it a goal of mine to write with purpose—to make sure you, the reader, can take something away from every post.

That doesn't mean posts will get longer, in fact I'll try to do the opposite: say the most in the fewest amount of words. It's going to be hard. And if you don't believe me, here's a quote from Mark Twain:

I didn't have time to write a short letter, so I wrote a long one instead.

So what's today's point? Join me in trying to be intentional with your words. Speak and write with purpose. Make your words matter. Every character counts.

A few people were sharing their routines on Twitter, and decided to share mine too! Thanks @Dan for tagging, and thanks @Colin for starting the thread!

I put Winter in the title because my schedule drastically changes when the weather is nice. Lots more outside time, hanging with friends, and bike rides.

This schedule also fluctuates drastically every day, so take the times with a grain of salt.

-----

10:30am: Wake up, catch up with brothers, sisters, and parents also working in the house, check updates on phone.

11am: Open laptop, check in on Slack and emails. Start coding by working on an easy problem.

11:30am-4pm: Focused work. Get majority of work done here. Usually a bowl of cereal or light snack in here. Sometimes a coffee. Sometimes lunch.

4pm-6pm: Lift and work. This is something new I've been trying and it's been going really well! I bring my laptop to the basement, blast some music, pump out some sets and write code in-between. Surprisingly productive.

6pm-6:30pm: Finish up work for the day. Knock out what I wanted to finish, decide what I'll want to do tomorrow. I'm realizing now I do this each day. I never want to wake up not knowing what I'll work on.

6:30-7:30pm: Consume enough food to feed a small African village, shower, protein shake. Laptop is closed at this point. Lots of guitar strumming in this time.

7:30pm-9:30pm: Chill, watch TV with parents, play chess, write my daily blog post, phone time.

10pm-1am: Gaming with my brother and cousin or friends. This is actually a super important part of my day. This is where the majority of my social time comes from. The laughs, the catching up, the fun. If I skip this, it noticeably affects the next day's productivity.

1am-1:30am: Go to bed, watch YouTube. Usually chess videos, Bumgartner Restoration (#bumGang), TED talks, or Adam Ragusea until I fall asleep.

-----

That's usually what my day looks like!

Some comments: yes, I sleep in! Sometimes I'll start my mornings a bit earlier (that's more of a summer thing), but the sleep is nice and don't really want to wake up earlier if I don't have to. Plus, the late night is way more valuable to me.

Yeah, I don't have a ton of meetings usually, so my work is usually pretty packed into the middle of the day.

Because I operate on my own schedule with the late mornings and late nights, some people think I don't do anything all day. I hear it in their tone of voice and the way they talk about what I do. They think I'm lazy, and sometimes equate me to being unemployed. That really frustrates and annoys me.

I take pride in how hyper-focused I get in the middle of the day, and my current and past teammates can attest to that better than anyone. Having the freedom and liberty to make my schedule does not make me lazy. In fact I'd say it's the opposite: it's a benefit of starting a business. That's not easy.

Anyways, I really appreciate this thread for that reason—it's really cool to see how different people operate on their own time.

We all have the same number of hours in the day, and that's how I spend mine.

This weekend, Facebook and Twitter banned the current President of the United States from their platforms.

Think about that: two private companies effectively cut the pipeline between a world leader President and hundreds of millions of people.

That begs the question: who is more powerful here? Who is really running the country?

If the most powerful person in the world can be silenced, do they really deserve that title?

Maybe, maybe not. But the move this weekend can't be understated— Jack and The Zuck flexed their muscles and put on a display of power for the world to see: it doesn't matter who you are, we're the captains of our own ships.

And with such a huge audience on those platforms, it effectively acts as a new form of checks and balances. An arbiter of truth and reason. A new form of oversight with the very important ability to punish.

And yes, this punishment really hurts those in power. Like I've said before, misery loves an audience. Taking away a leader's microphone cuts them at the jugular.

We're entering a new stage of corporate governance. A world where private companies wield an immense amount of power and leverage.

What's happening? The little blue bird really spread its wings this weekend. What started as a small social network app now shapes the future of the world's most powerful seat.

I had an idea to create a weekly recap of these posts, showing an overview of the blog's performance that week. Not just including quantitative metrics, but also qualitative data like how I felt writing that week and what my favorite post was.

The first weekly recap was posted on Twitter yesterday, and the reception was great.

In fact, that Tweet drove a ton of traffic here. From that Tweet alone (and in conjunction with yesterday's post), we're up to 103 total views. It was 68 two days ago.

In my 1K or Bust post, I said how my strategy for growth was going to evolve. These weekly recaps will definitely be a recurring thing for the growth benefits alone. It'll also be good to have a record of my progress.

And let me just say, having people actually consume what I'm producing feels so good. It's hard to convey how excited it makes me.

So, thank you for reading.

Almost every bit of luck I've encountered has been a direct result of me just saying yes.

The Honors College needed more applications: I said yes, and got in.

My friend that worked for a production company needed some extras for the background: I said yes (on a cold, wet, December morning) and ended up meeting my first serious girlfriend.

A class was being offered on design systems at my school. 9am and online (yawn), but I said yes, and ended up meeting my good friend and co-founder Dan Mall.

Even the most random "sure why not" trips with my friends were some of the best moments of my life.

There is almost no downside to saying yes either. What's the worst that can happen? You miss some couch time with your phone? Neither your couch nor your phone are going anywhere.

And yet, the potential upsides are limitless. Anything can happen—but if you don't put yourself in a situation for something to happen, nothing will.

So, I challenge you: just say yes. Break out of your comfort zone, see what's out there, live your life.

Opportunity is everywhere, you just have to put yourself in a position to find it.

I hit such a sick flow state today.

Brought my laptop down to the basement and would code while lifting, in-between sets. Somehow it was the most productive work session of the week. The blood was flowing, the code was pumping, it was great. I felt like Christian Bale from The Big Short.

(Yes, I'm aware of the code-bro bucket this post is putting me into. That's for a different post.)

My work day starts around 10:30am, and goes until around 4 or 5pm. In that time, I'm able to juice out about 4 hours of good, quality work. Everything else is kind of fluff. And that's working until I can't any more. Those times fluctuate day-to-day.

Why are typical work days 8 or 9 hours? Meetings, bloat, whatever. I'm glad I don't have to deal with it. Getting through a work day after waking up at 6:30 in the morning was horrible.

Glad I don't have to do any of that anymore.

Regardless of the timing of things, I'm more productive than I've ever been before. My time is my time, and when I use it how I want... that's when I'm most effective.

And I think that applies to most people. Find where, when, and what atmosphere you're most effective in. It makes the work easier and way more fun, and it can be entirely unique.

Working from home has its advantages, so use them before the world wakes up from the pandemic.

Make work not suck, at least for a little while.

It'd be naive to think technology isn't directly responsible for today's events.

Populism and cults of personality can only rise through media. It's their bread and butter for promoting their own idealized image and their strongest outlet for creating an enemy to hate; a "rival cult". Previously this media took the form of radio, cassettes, newspapers, pamphlets, etc.

Media, the plural form of medium: "an agency or means of doing something."

Today, media mainly takes the form of Facebook, Twitter, and television.

It's our responsibility in the tech industry to understand how what we build might further polarization. This will prove difficult, especially for those contributing to those companies I mentioned. The goal of social networks aligns pretty damn well with the goal of a populist—both more or less interested in reaching the widest possible audience.

With such aligned values and the deteriorating state of wealth inequality, 45 won't be the last populist we see. It is our responsibility to recognize the signs of a cult personality and actively take away their tools of growth; their agency, their means of doing something.

Disable them from spreading lies. Cut the legs out from under them. Take away their largest audience. Encourage objective truth in the face of subjectivity.

We win as a country when we stick together. A leader who appeals to our most primal instincts to foster division will only create a losing situation for everyone, like we saw tonight. We have to do better.

I encourage you to read the Wikipedia entry for Cult of Personality I linked above, and to specifically look at the "Role of Mass Media" section. I'll leave you with one of my favorite quotes from the article, from Robert N. Bellah:

It is hard to determine the extent to which the media reflect the cult of personality in American politics and to what extent they have created it. Surely they did not create it all alone, but just as surely they have contributed to it.

Also, today's my birthday.

Patience.

It's impossible to succeed as a programmer if you are impatient.

Today I spent hours messing with a component to make it work how I needed it to and it made me think of this. In fact, every project is a battle of attrition between myself and the problems. If I was impatient, the table my laptop sits on would be flipped daily.

Now I'm not saying I don't lose my patience, that happens at least once a week. The patience doesn't come easily though, the hard part is getting used to failure. Failing at solving small problems over and over again.

When I was first starting out, I never understood how my brother Kevin just knew how to solve these problems. I never thought I'd get over the frustration of failing.

But now I know: get used to it. Fail till you don't feel frustrated anymore. Fail till you develop patience and learn to operate within frustration. Fail till there's only one way out. Fail till the only thing left to do is succeed. Fail till you don't.

Fail till you win.

I like to think you guys are salivating at the mouth waiting for me to skip a day.

Well at ease soldiers, that day is not today.

Anyways first day back on the Arcade grind after the winter break and DAMN it felt good to get back on it. The product is so close to being ready for some real-world testing, just a few tweaks to go. And man, it's really exciting. Some of the features we've cooked up are pretty killer, and I think a lot of developers and designers are gonna be pretty hyped once they see what we got. It'll change the game.

Today Dan said "Happy 2021 all! IT’S THE YEAR OF ARCADE."

With all the moves we've been preparing over the past few months, it feels like we've been winding up a trebuchet and the potential energy is ready to freakin send it. Part of me thinks this will unfold slowly, but most of me thinks this year is going to be just explosive. In a good way. And I'm excited to see what happens.

So, 2021 is the year of Arcade. Hell yeah it is, Dan. Hell yeah it is.

Today I decided I'm going to hit 1,000 followers on Twitter by the end of the year.

Currently I'm at 210. That means 790 followers in 362 days. A little over 2 followers a day.

There's a few reasons why I want to hit this goal:

The first is because it is hard. I like challenging myself and pushing my comfort zone further and further. Marketing and growth has always been such a black box to me.

It almost seemed magical how some people could grow their Twitter account so... effortlessly. And in their replies, people care. People genuinely are interested in what they have to say. It's not some hacky thing they did to build their audience. They created fans. How the hell? It's like they manufacture themselves to be popular; not by chance, not luck, not one moment of virality, but through work. There has to be something here I can discover, so I'm going to look.

The second reason is because there are very tangible benefits to having an audience. With an audience, anything you create instantly has a core group of fans; you'll never have to start from scratch again. You can foster a community. You create relationships with people. You have an entire network at your fingertips for anything, and they care. Now THAT is valuable.

Seeing someone popular on Twitter or Instagram or YouTube was always one of those wonder-moments for me. I still remember being obsessed with Freddie Wong on his old freddiew channel. The following he had from making YouTube videos absolutely amazed me.

Now that I'm older though, I've developed this mindset of "why not me?" Why can't I be that person? What's so different about that person, and what do they have that I don't? I've realized nothing can stop me. If I want to put myself in that position, I will.

I researched how some marketers grow on Twitter and began to employ some of those strategies. I have a feeling my strategy is going to evolve and grow over time. I'll keep you updated.

And that's my mindset for gaining followers. I want to be one of those guys with fans. I don't ever want to make a post like the one I did yesterday. And I can do it. 1,000 followers is just the first goal.

Reception doesn't define the work, but a good reception makes the work easier and more enjoyable.

Disappointment can only exist with expectations. So when I'm feeling disappointed, I think about my expectations, and why I expected that.

Today, I feel disappointed about yesterday's announcement of the blog and the reception from Twitter.

When I'm creating a post of any kind, there's usually a few people I have in mind who I'm hoping react in a certain way. A like, a retweet, a comment, whatever. And when those certain people don't react how I hoped they would or don't even acknowledge the post, it leads to disappointment.

That's what happened yesterday.

My gut instantly thinks "oh jeez they didn't like it", but there can be a million reasons why somebody didn't react. They could've not even seen it! Especially yesterday by posting on a holiday.

But in the end, I know my happiness doesn't depend on how my work is received. Hell, if any artist did they'd all be in shambles. Shit, maybe they are. Van Gogh syndrome.

And those reactions (or lack thereof) certainly don't take anything away from the work itself.

So regardless of expectations, it's important to acknowledge to myself that I'm proud of the work I've created. And if someone I thought would like it, didn't?

Fuck em.

So much has happened in the last year. A lot of ups, a lot of downs, and a ton of change. My only regret is not doing a better job at documenting it.

In 2021, I'm going to change that.

So every day, I'm going to write and share a little of my story. It can be however short or long and be about anything. The only requirement is that I do it once a day. I'm hoping that by flexing this writing muscle I'll become a better storyteller and do a better job at sharing my experiences.

(If you feel lost and don't know anything about me, I made a short video to fill you in: https://youtu.be/aevMlN5HCag!)

You might be thinking "yeah right, this guy's a chump", BUT, to keep me honest, every day I don't post, I'm going to give $50 to one of my Twitter followers. Then I'll have to go back and retroactively write a post for the lost day.

This might be the most expensive decision I've ever made. It may result in nothing changing, or it may be a great decision. Who knows on day one. But we're going to find out.

And that's my new year resolution.