Insights

Looking back around 2000-ish when I was in high school, Friendster was the first social media app that was trending at the time. Similar to Facebook, Friendster was a place you could create an account, post anything on your wall, add friends, and even customize your profile page. People used different themes on their profile pages, others designed and built something unique from scratch.

Back then, you were considered a professional when your profile was customized with snappy graphics and silly animations. I remember being so excited about the endless possibilities to spice up your profile, so of course I decided to try everything out. For the first time ever, I installed and used Adobe Photoshop (I was using version 8 CS at that time), began studying simple photo edits and manipulations, and did some research on how to do HTML and CSS.

Every time I remember this from the past, I consider it to be the first time I found myself absolutely in love with designing.

Years passed by and I enrolled myself in a tech school for my college degree. The school offered engineering, computer, and design courses. I took a BS in IT with a specialization in digital arts, so I had tech courses with a major in design.

There’s a LOT to learn in the design field — from photography, creating 2D and 3D graphics and animations, editing photos and videos, building websites and mobile applications, and so many more things! All of the courses I had taken taught us more about introductions, tools to use and just the basics.

Four years later, I graduated and began the hunt to find my very first design job. I thought anything related to my degree was fine and worked for me. But turns out, it really wasn’t. There were so many job openings for design graduates, but I couldn’t seem to find anything that fit my skills and the experiences I had. At that moment, I was sure I was having a quarter life crisis and I went as far as to start questioning if I was on the right track (the story of every fresh grad, really). I was so overwhelmed with the skillset requirements that I thought, how am I supposed to know any of this?

I started to analyze and check every skill and ability that I had, until I remembered the moment and the reason why I chose this career path. That’s when I felt clarity on what I wanted to do.

I created my portfolio, took more online courses on designing websites and applications and then I started submitting CVs again. After being unemployed for months, I finally landed my first job as a junior web designer.

Regarding the question: Should you go to design or tech school? I honestly think it doesn’t matter. I believe it depends on the person and how they want to learn; whether they want a structured way by direct access to learning with professors and classmates or are hugely motivated to push at self-learning, the importance is the willingness to discover a new set of skills. Some might prefer learning through experience rather than through education.

There’s a plethora of different paths and ways to get training experience – you can take online courses, watch masterclasses, attend conferences and try new tech tools. Others have limited access to education: it might be expensive or difficult to manage in time. Others might be thinking to switch careers.

In my case, I entered tech school to learn extended areas of the design space, choose what field to focus on, and continuously learn my specific skills in UI design. If you’re applying for a job, what people might want to see is the experience you have.

Unfortunately, there’s no answer on what exactly you should do to become a designer. The advice I will give: don’t hesitate to try things on your own. You will find joy by doing the job you love and see yourself grow by continuously learning.

The early build phases of a technology startup are exciting. We have spent time speaking to prospects, uncovered a segment we are building for and validated our solution with some rough prototypes.

In several of my early startups, I skipped all that to get into the building part. Rest assured almost all of them ended in failure other than the ones I got lucky with.

Our rebuild process is a little different from other early-stage startups where you just have 2- 3 people wearing multiple hats. Our team size is over to 10 people and includes specialists that give us the ability to go deeper faster. (This is also a big risk in the rebuild project and we may easily overbuild)

As the product owner/founder a critical decision to make is whether we choose to work in cycles or just use Kanban to ship features when ready. I don’t think there is a single right answer to this question. Listed below is what we have selected:

We are working in single week cycles

1. I chose a single week cycle versus the Kanban method as I believe it provides the whole team with structure and some synchronization given our size. If we were a smaller team I may have opted for Kanban.
2. A week cycle helps to bring urgency as well as reduce feature creep that can easily set in if one were to let cycles run longer. One doesn’t have time to ensure that every border-radius and shadow depth are optimal. (I have burned through many work cycles being far too critical on the design which I have learned to let go)
3. We are able to discover blindspots faster. Today in one of our early iOS builds I found a broken flow that the backend was able to rectify immediately. Left unchecked we let our assumptions build up and that almost always backfires.
4. We are running without any cooldown days/weeks. This drawback makes this cycle unsustainable over the long run. I plan to switch out of this cycle once the beta has shipped by the end of the Q1. Otherwise, you will be running the team way too hot and it will end up in burnout or lower quality output.
5. Friday afternoons are internal demo days and most importantly a sense of progress for the entire team to see that they are working towards a set goal that is becoming a reality week after week.

I have found far more success with the above cadence. While this may be working for our team your mileage may vary. Speak to your team members, figure out what is important to you and at what stage you are in the validation and build cycle.

There are no perfect work cycles. There are several resources below that could be of some assistance in helping you find a cadence that works for you.

🧰 Resources

📚 Escaping the Build Trap

This books talks about cycles as well as not benchmarking your success only with output. Building features for the sake of building, rather than validating demand almost always ends in failure.

📚 Shape Up: Stop Running in Circles and Ship Work that Matters

The famous 6-week cycle broken down by Ryan Singer at Basecamp. This short read goes into detail on how they effectively use this cycle length at the company. It is a great read and one I would recommend everyone who is building products.

Today I was listening to an excellent episode on the Saastr podcast. Link to the podcast and some references are in the resources. Listed below are great insights from Auren Hoffman.

1. Don’t take the advice from people ten years older than you too seriously: I hadn’t heard this one before. He reasons that life is changing rapidly; most advice that worked ten years ago is not as relevant today. Early in my career, I made a mistake to rely too heavily on others’ advice rather than blazing my path.
2. Avoid good opportunities: This was my favourite takeaway from the episode. I have learned this again the hard way. Good options are where one doesn’t have an asymmetric upside. This advice also applies to people who have already attained some level of success. Good opportunities take the same work as great opportunities. Wait for those to knock on your day. Say no very often.
3. Delegate things you are good at: Common advice is to delegate those tasks we are not good at doing. Instead, we should delegate the things we are good as that gives us greater amounts of leverage and time to building our skills in the areas where we are weaker.
4. Smartest people think ten days and 30 years out: Think for the short term and optimize for the long term and not the midterm. High performers pass the marshmallow test with ease. They can delay immediate gratification; however, they are making decisions to optimize for optionality. By removing the mid-term outlook and thinking with the longest of horizons, we can make far better decisions.
5. Easier to decide which companies to invest in and which companies to start: To make money as an investor, you need to be both unconventional and right. To create a business, you need to have a third component to have the required unique advantage and desire to build it.
6. VC’s almost always lie when they pass on your deal: They may say your addressable market is not big enough or that your team is not right. It usually isn’t the case.
7. In startups doing trumps planning: Planning is critical at the earliest stages of your company. Referencing airforce pilots who use the OODA Loop (Observe, Orient, Decide, Act). “Being wrong will hurt you a bit but being slow will kill you.” Jeff Bezos. The need for speed is essential for all startup operators. There is always a balance that needs to be managed between 1% improvements and step functions.
8. True 10xer’s take more time to manage than high performers: They take longer to hire, they require more of your time as a leader, but at the end of the day they bring back the value to the company in spades. Discovering future opportunities before you can even see them. Take the time to nurture them if you have been lucky enough to have hired them. Keep on giving them more responsibilities.

He spends the second half of the episode answering audience questions which are worth a listen as well.

Resources

SaaStr 413: How to Build a Unicorn in 8 Simple Steps with Auren Hoffman, CEO @ SafeGraph

Join four-time Founder and CEO Auren Hoffman as he breaks down how businesses can become the right model for explosive growth, emulate their strategy, and join the path to Unicorn potential in eight simple, hand-made steps.

What’s an Asymmetric Opportunity?

Great write-up referencing many great resources for people who want to understand the concept of asymmetric opportunities in detail.

OODA LOOP: What You Can Learn from Fighter Pilots About Making Fast and Accurate Decisions

Another great gem from Farnam Street breaking down the OODA Loop in much greater detail for those interested.

Part of every developers dilemma is deciding which approach to take in addressing certain problems. Genuine solutions require a certain amount of effort and steps to achieve and there exists acceptable “workarounds” that tests every developers way of thinking.

Here are some simple workarounds that you might find helpful and will help save time in cases you still haven’t figured out the right solution.

For you to follow along and experiment your use-cases or check the results yourself, here’s a quick guide.

npx create-react-app my-app
cd my-app
npm start

Optional

Install your favorite UI library (in this example, I used ant-design).

1. Force re-render by updating component key property

There might be instances that you need to reset your component state (e.g. form states) after a certain action (click event, keyboard event, after certain requests, you name them…) outside your form component, and realized you don’t have access to the form library’s reset function.

Form component (use your favorite form state library, react-hook-form in this example)

import React from 'react'
import { Form, Input } from 'antd'
import { useForm, Controller } from 'react-hook-form'

const FormComponent = () => {
  const { control, getValues } = useForm();
  const formValues = getValues()

  return (
    <Form>
      <Controller 
        name="firstname"
	control={control}
	defaultValue={formValues.firstname}
	render={props => <Input {...props} placeholder="First name" />}
      />
      <Controller 
	name="lastname"
	control={control}
	defaultValue={formValues.lastname}
	render={props => <Input {...props} placeholder="Last name" />}
      />
    </Form>
  )
}

Usage

import React, { useState } from 'react'
import { Button } from 'antd'

// use your favorite library (e.g. uuid)
const getUniqueFormKey = () => (new Date()).toISOString()

export default () => {
  const [key, setKey] = useState(getUniqueFormKey())
  return (
    <div>
      <FormComponent key={key} />
      <Button onClick={() => setKey(getUniqueFormKey())}>Reset form</Button>
    </div>
  );
}

Result

By changing the components key property, we were able to re-render the component completely and reset its state

2. Access react state in event listeners via useRef

There might be cases that you’ll need to add an event listener, override specific key binding, access react state from useState and trigger certain actions from there.

Sounds easy, right? It feels natural, but your state will most probably be empty. Let’s try.

Component

import React, { useState } from 'react'
import { Input } from 'antd'

const App = () => {
  const [formState, setFormState] = useState({ fname: '', lname: '' })

  return (
    <div>
      <Input
        value={formState.fname}
        placeholder="First name"
        onChange={e => setFormState({
          ...formState,
          fname: e.target.value,
        })}
      />
      <Input
        value={formState.lname}
        placeholder="Last name"
        onChange={e => setFormState({
          ...formState,
          lname: e.target.value,
        })}
      />
    </div>
  );
}

Then add keydown event listener via useEffect

import React, { useEffect } from 'react'
import { Input } from 'antd'

const App = () => {
  ...

  useEffect(() => {
    const onKeydown = e => {
      if (e.code === 'Enter') {
        // do whatever you want with the state
        console.log(formState)
      }
    }
    if (window) window.addEventListener('keydown', onKeydown)
    return () => {
      if (window) window.removeEventListener('keydown', onKeydown)
    }
  }, [])

  ...
}

With this setup, this is what the state looks like upon triggering the “Enter” key from the keyboard, it doesn’t contain anything but the default values.

To access the updated state in the event listener, add the following modifications to the code

1. Import useRef and set the default value with the state’s value
2. Add another useEffect that will keep the formStateRef value updated every time the state changes
3. Use the formStateRef.current on the onKeydown instead

import React, { useEffect, useRef } from 'react'
import { Input } from 'antd'

const App = () => {
  const [formState, setFormState] = useState({ fname: '', lname: '' })
  const formStateRef = useRef(formState)

  useEffect(() => {
    const onKeydown = e => {
      if (e.code === 'Enter') {
        // do whatever you want with the state
        console.log(formStateRef.current)
      }
    }
    if (window) window.addEventListener('keydown', onKeydown)
    return () => {
      if (window) window.removeEventListener('keydown', onKeydown)
    }
  }, [])

  useEffect(() => {
    formStateRef.current = formState
  }, [formState])

  ...
}

Result

And we can now have access to the updated state via useRef in our event listener.

It’s good to note that the above workarounds will work on any stateful components, and are not limited to form components.

Conclusion

While it is always good to find a genuine solution to a problem, workarounds can be as creative as true solutions and I find some of them saving me from doing over-engineered solutions which convolute the codebase unnecessarily. Plus, it saves time!