Chris Jarling

I’ve recently relocated to Denmark from Germany, and even though its a direct neighbor, there are some things that are vastly different.
I want to write those things down when I notice them and while they are still new and exciting, before I get used to them.

You may have noticed that I was very optimistic and labelled this article “Part 1”, indicating that this will be an ongoing series. I really want this to become a series. Maybe it will happen. If you read this a year after it was published and there is no second part to this, please do annoy me about it.

With that out of the way, let’s jump into the first thing that I enjoy about Denmark: Electricity.

Electricity Pricing Models

In Germany, there are a few new electricity providers that offer variable electricity prices. Variable electricity prices in of itself are nothing new. Electricity is bought at an exchange and prices vary depending on supply and demand: If a lot of people need electricity (i.e. in the morning or evening), prices rise. If there is low demand for electricity (i.e. because a lot of people are at work/school), prices drop.

Historically, German electricity providers did not pass this fluctuation in price on the the customer. You usually have a contract with the provider for a set price per kWh. Those new providers allow passing on the variable price. That’s nice, because when you work from home you can just start you washing machine when prices are low and save a few bucks.

However, what’s needed to be able to profit from those prices is a way for the provider to know how much electricity you used when. In Germany, you usually have to install special hardware that allows monitoring your energy usage on your electricity meter. This has to be connected to Wifi, which prevented me from using it in my old apartment, since the electricity meter was located in the basement.

This is not the case in Denmark. Basically every provider offers both fixed and variable prices, and without the need to install anything. Why? Because in Denmark every electricity meter is a remotely read smart meter.

Smart Electricity Meters

Since the end of 2020, every household in Denmark has a smart meter installed that is operated by EnergiNet, an independent but publicly-owned company that runs the Danish energy infrastructure (by the way, the executive order that every household in Denmark should have a smart meter was issued in January of 2019, so it took about 2 years for this to be done).

For me as a customer, that means a few things. First, I’m able to be use variable prices, since my usage will be measured anyways. I can now just check my energy providers website for todays (and tomorrows) electricity prices. For today, this tells me that prices are high in general (so maybe I want to skip laundry) and are very high in the evening (7pm and 8pm, so I would definitely want to skip laundry there).

Another cool thing is that I can easily check my current consumption in almost real time (there is usually about 24 hours of delay) online without having to walk to my meter and enter a bunch of numbers. Here’s what we’ve used to far since moving in:

Initially, we had a lot of laundry and dishes to wash, so the first few days our consumption was quite high. It’s gone down a little now.
I don’t really get much out of this currently, as our consumption seems to be on the lower end for a family of four, but it’s nice to look at it every now and then and see how we’re doing.

Availability of data

Also very interesting is the fact that all of this data is publicly available. For example, here is a dataset for the spot prices of the next day. This allows apps like Min Strøm to exist. This app not only shows the current and upcoming prices, it can even show how electricity is currently generated.

At the time of writing this (in the middle of the night), most electricity comes from wind (is sure is windy tonight) and biomass. Over the day, about 50% usually comes from solar.

For Danes and probably other Scandinavian folks, this is probably nothing new. But I was absolutely flabbergasted that this is just the norm in Denmark.

There also seems to be more you can do with your smart meter in connection to your CPR number. Unfortunately, I’m still waiting on mine, so I’ll likely come back to this topic in the future.

I think I’ve mentioned it here and there already, but never explicitly, and it feels like a thing I’d want to explicitly mention: We’re relocating to Denmark. While we’re not completely finished with the process, we’ve got a good chunk of it done already and I’m currently writing this from my desk in Denmark.

I’ll likely write more about this move and how I’m settling into this new life in the future, but the whole process of physically moving has been very eventful and exciting already, which justifies writing about it. It’s probably something I would be upset not to find a record of in this blog a few month or years down the line. So, let’s being.

Before moving to Denmark, we’ve lived in Cologne. We terminated our lease for the Cologne apartment in the end of April and thus had to leave it in the end of July. The lease of our apartment in Denmark started in the beginning of September, so we’ve had a month of potential homelessness to cover. Fortunately, we were able to move in with my mother in law. It was a good chance to see some family and wind down a little after packing up our lives in Cologne. It also meant living out of boxes for a month, which was exhausting. I cannot tell you how glad I am to know (with some certainty, at least) in which cupboard our glasses or my keyboards are.

My mother in law lives about an hour from our old apartment, so that also gave us the chance to perform a sort of rehearsal for the actual move: We planned to move everything in the biggest van I was legally allowed to drive (which was 3.5 Tonnes). We were not sure if a) everything would fit and b) we’d overload the van, weight-wise. If any of the two would occur, this would allow us to go around for a second time and then adapt accordingly for the move to Denmark (which, with a drive time of about 10 hours we could not just simply make in two trips).

Fortunately, everything worked out and we got everything over in one go. We also got rid of a lot of stuff in the month before the actual move, so we arrived with even less in Denmark ¹. Thinking about it, fitting all belongings of a four-person-household into a small van is pretty nice from a minimalism standpoint.

Now, with all of this out of the way, let’s talk about the actual move. This must have been about the most exciting thing I’ve did in my life (apart from witnessing birth).

Dropping of the wife and kids

Since we have a cat and a dog, and the dog is too big to travel in the cabin with us, we did not want to fly all together. However, we also have two kids and only three seats in the van, so driving all together was also not possible. This left us with the constellation of me and the pets going in the van, while my wife and the kids flew over.

Our rental period started on the 1st of September, which was a Sunday, so we were to take over the apartment on the following Monday at 9 a.m. Given the restrictions from above, that left as with few possibilities, but we chose the following: The wife and kids flew over on Sunday afternoon and handled the apartment takeover on Monday. I would then drive over with the van as soon as possible afterwards.

So, on Sunday afternoon we all drove up to Düsseldorf (because the Cologne connections were mediocre) and the wife and kids hopped on to a plane to Copenhagen. Because my wife was not feeling well right before they got into security, I waited until they had successfully started, then drove back to our temporary home to pack up some last things.

They landed safe and sound in the evening and made it to their hotel which they’d live in until I was there with the van.

Getting the Van

On Monday morning, I hopped into my car and drove to Cologne. I turned up at our car shop, which offered to sell our car for us. I unregistered it online while sitting there, left the paperwork with them and tried not to cry over a such a stupid thing as a car. There were a lot of memories attached to it and it felt like giving up a bit of freedom. But, it had to go².

I then jumped into a tram to pick up the van which I then drove back to my mother in law, again packed up some last things and waited for a friend and my brother in law to show up to help me pack it (again, a huge thank you for that!). Loading the Van took about two hours, which was faster than I anticipated.

I then tried to eat some dinner, pack up some last things and prepare everything for the next morning. Now all that was not in the Van was the animals, me, some clothes and the cat’s litter box. I failed miserably at going to sleep early, had a very bad night and woke up to my alarm at 5 a.m. the next morning.

Driving

The first thought I had when I woke up was “Oh damn, I don’t want to do this”. I then got up, made coffee, took the dog for a walk and packed my backpack. I cleaned the litter box and put it in the van together with my blanket. Then grabbed the cat and the dog and started driving at about 6:20 a.m., only about 20 minute later than I planned.

The drive was rather uneventful, for the most part. I set cruise control to 100 km/h and tried to stay behind a truck in the hope of the slipstream saving me some fuel.
At 9:10 a.m. my wife called me to tell me the handover had been done and the apartment (which she hadn’t seen in person before) was actually decent ³.

At 10:30 a.m. I took my first break. Because I had the cat and the dog with me and it was quite hot, I could not leave them in the car, so going to a shop was not possible. My provision was a large pack of Oreos and two cans of coke, because apparently I’m a 12 year old trapped in a grown-ups body.

I entered the Bremen/Hamburg area around noon and there were now a lot of customs cars observing the traffic. I was quite sure I wasn’t overloaded (we didn’t have much stuff and the tires looked fine), but did not have a scale to be sure, so my anxiety-ridden brain made sure to paint out all the scenarios where I was pulled out, weighted and had to unpack half the van. Nothing of that sort happened.

On my second break around 1 p.m. I notice Google Maps showed “Tolls” on my route, but I was avoiding ferries and was sure Denmark has only toll-free roads. Turns out there are two bridges that are actually tolled. They accept cash (Krones and Euros) and credit cards for payments. Funnily enough, my credit card had expired on the first of September which I did not notice while being in the midst of a move and I had no idea if they accepted EC cards. Luckily, I found and ATM at the rest stop and got 130 Euros (which I though would be way to much - but I’d rather be safe then sorry - but turned out to be just enough).

At about 2 p.m. I entered Denmark and was pulled out by customs right away. Anxiety brain was right back at it. The officer asked my what I was doing in Denmark and I told him I was moving here. He said “okay, exit is to the left” and that was it. I was very sure my journey in the van would end there.

I arrived at the apartment at 6:30 p.m. and stared to unpack the van (mostly by myself, while my wife was watching the kids and helping with the heavier furniture). We were done by 10 p.m., which was also way faster than I anticipated.

Returning the van

Because the van was registered in Germany, it was not possible to return it in Denmark. This meant I had to drive back to the closest German city, which is Flensburg. This also mean crossing the whole of Denmark again, which makes it the second time within 24 hours I crossed the entire country.

Me and my older daughter quickly picked up some furniture from IKEA while we still had the van and I made my way back to Flensburg at 4 p.m. My first stop wasn’t the rental company, though, but an electronics store: They had a Dyson vacuum way cheaper than in Denmark, and while I was there I picked it up. It was 7:15 p.m. by the time I left the electronics store. The plan was to go back by train and there was exactly one leaving at 8:50 p.m. So I filled the gas on the van, returned it and made my way to the train station by foot.

I arrived about half an hour before the train left with the intention to find something to eat. I did not know though, that the station in Flensburg has absolutely no stores, whatsoever. There are two vending machines, both of which only accept coins that I did not have. So my Dyson and me boarded the train to Fredericia hungry.

Luckily, Denmark had me covered with a 7/11 at the station that allowed me to grab some food (a disgusting wrap and a bar of feastables) and something to drink before boarding my train to Copenhagen

I arrived in Copenhagen at 1:20 a.m. which meant the commuter train to our apartment was not going anymore. I had to wait for a night bus, with this stupid Dyson in hand, always certain the next person passing by would just mug me for it. I finally arrived home at about 2:50 a.m., after two of the longest days ever.

---

This is the story if how we physically got here. We’re still in the process of obtaining a residency permit and our CPR-Numbers, so the whole thing is far from done, but we’ve made a lot of progress already.

When people asked me about the move in the past I often said “it’s going to be an adventure” and it definitely was one getting here. It taught me a lot about what I’m capable of doing.

Footnotes

1. I want to formally thank my wife for taking care of the most of this while also caring for a 6 year old and an infant, while I was mostly working. ↩

2. Denmark has a pretty aggressive tax policy towards non-electric vehicles. If we wanted to keep it, we’d have to pay about 150% of its current value in tax, which was just not economical. ↩

3. She told me again today that I did a good job picking it, which is probably the highest praise I’ve ever gotten in this regard. ↩

Jest is a great JavaScript testing framework and I love to work with it. On a daily basis, I mostly work with it and describe blocks and it's matchers. I've recently come across one of it's lesser known features. Or, at least it was lesser known for me personally: Loops.

For both it and describe blocks, Jest offers Looping functionality. Loops allow you to write a test case once and pass different data into it for each run. Here's the example from the Jest documentation at the time of writing:

it.each([
  { a: 1, b: 1, expected: 2 },
  { a: 1, b: 2, expected: 3 },
  { a: 2, b: 1, expected: 3 },
])('.add($a, $b)', ({ a, b, expected }) => {
  expect(a + b).toBe(expected)
})

We basically just pass in an Array of data in whatever complexity we want and every run of the test code has access to one of the array items.

Now, if you think "wow, that was kind of hard to read, I would have preferred three distinct cases albeit the duplicated boilerplate" – keep reading, because this is what we'll talk about next.

When to use Loops

As always, the answer is "it depends". However, my standard answer to wether you should Jest loops or not in a given situation is "No, don't use them". Loops are a powerful tool and can be helpful at times, but they're also an easy way to introduce unnecessary complexity into a codebase. And engineers love complexity!

Even just from the example above you can see how much complexity we've added here: There's a data structure passed into the loop that the user has to understand (which is simple enough in this case, but I'm certain given enough time an Engineer will find a way to add something that's "quite elegant and saves us some repetitive code") and this data has to be passed around and referenced in three places. The naming helps, but let's see what we've really saved by using a loop:

it('.add(1, 1)', () => {
  expect(1 + 1).toBe(2)
})

it('.add(1, 2)', () => {
  expect(1 + 2).toBe(3)
})

it('.add(2, 1)', () => {
  expect(2 + 1).toBe(3)
})

Yes, we have some repetition, but I find that easier to read compared to the above. ¹

There are cases where I like to use loops, though. Usually those cases have a few things in common:

1. The input array consists only of primitives (string[] etc.)
2. The loop tests business logic that is required to behave in a certain way for this specific input and we want to be notified once it behaves differently for one of these cases²

A better example?

Let's assume we have a small program which allows our users to enter their name into an <input /> field, press a button and the program then will display a message, greeting them by name. Two of the functions we'd need are parseInputValue() and constructGreetingMessage(). I'll skip the implementation here, since it's not important and you can probably imagine it just fine. How would we test this?

For constructGreetingMessage(), the tests are rather straight forward:

it('constructs a message that greets the user by name', () => {
  const message = constructGreetingMessage('John')
  expect(message).toEq('Hello, John!')
})

And the same for parseInputValue():

it('returns the input value', () => {
  const expectedInput = 'John'
  // ... render the input
  // ... fill the input with "John"
  expect(parseInputValue()).toEq('John')
})

That's great, we add a few more tests, deploy the first version and watch the users come to use our app. A few days later, our boss, the CEO of GreetMeApp LLC want's to have an immediate call with us. He notifies us that user have been abusing or app and entered naughty words in the input. This has to stop!

We're dropping everything else to ship a fix asap. We consult our data team and they provide us with a list of common naughty words. It's a list of 53 words in total and they assure us that they did extensive research: The list is complete and will not change in the future. It has every naughty word in it that there is. We go ahead and build in a filter to our parseInputValue() so that is just returns "User" if someone enters a naughty word. Great, the day is saved.

But how do we test this? We definitely want to make sure that even on future changes, none of these naughty words makes it back out of the filtered values. We cannot risk taking a hit on our MRR again.

This is actually a good use case for a test loop:

const naughtyWords = ['poo', 'bum', '💩', '...']
// naughtyWords.length => 53

it.each(naughtyWords)('filters out $word', (word) => {
  // ... render the input
  // ... fill the input with the naughty word
  expect(parseInputValue()).toEq('User')
})

Now we can make sure that a test fails in case someone removes one of the words from the filter list and affects important business logic, while the tests remain fairly simple to read.

I realize that this example is... somewhat constructed as well. But we have used loops in test suite in a similar manner lately. The array the loop took in contained only three items but the test cases were quite long. The main advantage of having a loop in this case was that it made clear that for all of the values we passed in, we expect the exact same thing to happen. If we need to adapt the cases for one of these values, it will hopefully ring some alarm bells and make people aware of the consequence of the intended change.

Footnotes

1. : I understand that this is an constructed example for documentation purposes and there might be better examples to show when a loop is useful. But this is what we currently have. ↩

2. Often times, you can just test two cases to make sure you code handles the distinction just right, but sometimes it's required to make sure the code handles all of these cases right. ↩

I enjoy seeing pictures of other peoples' desks, but I rarely upload pictures of my desk myself. It's probably nice to look back over the years on where I worked with which setup (which I can do, because I have pictures, but I don't have any written documentation on it). Time to change that.

The first one is a little messy (sorry for the cables), because it's a temproary one. I'm only in this room for a month. We're staying with my mother-in-law because we're moving countries. The lease for our Cologne apartment is terminated already, but the new lease only starts in September, so we have a month in between.

A few notes on the setup:

• I didn't bother installing my widescreen monitor for the few weeks. The desk mount is heavy and on the bottom of a box. Not worth the hassle.
• Using a 2021 16" M1 MacBook Pro
• I have this mounted on a cheap Amazon laptop stand and use the Magic Mouse & Magic Keyboard to have at least some sort of posture
• Mostly using the Airpods Max while working
• I started keeping a legal pad on the side of my desk for any temporary notes. I use that a lot more than my Field Notes. The Field Notes have a higher quality, which makes me hesistan of just jotting something in. I want it to look cool.

If you’re a web developer, you have probably used the JSON.stringify() method in JavaScript. And if you’re anything like me, you will most likely have used it with just an object value that you want to stringify, either to store values in localStorage or to return a JSON response in an api route.

But did you know that JSON.stringify() method actually accepts three parameters?

JSON.stringify(value, replacer, space)

Let’s talk about the other two a little.

Space

We’ll start with the last one, space, since it’s less complex. Space does what it sounds like: It allows you to add space to the JSON string the method produces.

Let’s assume we have a user object that looks like this:

const user = {
  name: 'John Doe',
  age: 25,
  email: '[email protected]',
  address: {
    city: 'New York',
    state: 'NY'
  }
}

If we call JSON.stringify(user) without any other arguments, we’ll get a valid JSON string, but it will be one long line:

'{"name":"John Doe","age":25,"email":"[email protected]","address":{"city":"New York","state":"NY"}}'

That’s fine if the recipient of the string will parse it, but what if we wanted to display this somewhere? It would be nicer if it was properly formatted. Let’s do that using space:

console.log(JSON.stringify(user, null, 2))

// => 
{
  "name": "John Doe",
  "age": 25,
  "email": "[email protected]",
  "address": {
    "city": "New York",
    "state": "NY"
  }
}

That looks a lot nicer!

space can be either a number or a string. If it’s a number, that indicates how many spaces should be used for indentation. If it’s a string, this string will be used for indentation:

console.log(JSON.stringify(user, null, '🙈'))

//=>
{
🙈"name": "John Doe",
🙈"age": 25,
🙈"email": "[email protected]",
🙈"address": {
🙈🙈"city": "New York",
🙈🙈"state": "NY"
🙈}
}

Both of these are capped at a depth of 10. You can also pass \t into it to indent using tabs.

This can be useful in various use cases. For example, I wrote a JSON formatter to wrap my head around the topic. The formatter heavily utilizes the space option of JSON.stringify().

replacer

replacer accepts either an array (of either strings or numbers) or a function.

If we pass an array of strings to it, stringify will only return matching key/value pairs:

console.log(JSON.stringify(user, ['email', 'name'], 2))

// =>
{
  "email": "[email protected]",
  "name": "John Doe"
}

Note how the order in which the key/values pairs are returned is depending on the order in which they are defined in the array.

Also note that this only works for string or number keys, if we try to get a symbol key it will be empty:

console.log(JSON.stringify(user, ['email', 'address'], 2))

// =>
{
  "email": "[email protected]",
  "address": {}
}

However, if we want more control over the returned values, we can pass a function in. If we (for whatever reason) wanted to shuffle all strings in our JSON, we can do the following:

function replacer(key, value) {
  if (typeof value === "string") {
    return value
      .split("")
      .sort(() => Math.random() - 0.5)
      .join("");
  }
  return value;
}

console.log(JSON.stringify(user, replacer, 2))

// => 
{
  "name": "JoDohne ",
  "age": 25,
  "email": "[email protected]",
  "address": {
    "city": "NeoY rwk",
    "state": "YN"
  }
}

As you can see, JSON.stringify() is not just a simple method for converting an object into a string. Its replacer and space parameters can provide you with additional control over the stringification process, allowing you to filter and format the output in various ways.

It's important to make a distinction between a side project and a side hustle for this article to make sense. When I talk about side project in the following, I exclusively mean programming side projects.

Almost every programmer I know has some sort of side project going on¹. If you ask a programmer what they are currently working on, there is a good chance they will tell you about their side project instead of their day job.²

I think there is two reasons for that. First, when you start out people tell you to build things that you can show around to land a job. People in the industry usually don't care about schools and degrees as much as about what you're capable of. And there is no easier way to find out than looking at a project someone did. Second, programmers tend to like programming for the sake of it. A lot of programmers don't want to stop after work or on the weekends, so they start side projects.

So you start out in your career and you go build a side project. Then you open twitter and discover other people and their side projects and one of them is making $10k a month. You decided to check out their friends on twitter and they also all have side projects that pay a lot of money. So you think: This is it. I need to have a side project that generates money and has a lot of users. One that has a purpose. And suddenly, all side projects you do become a job.

I had a few side projects like this. I started them with the intention of having a bunch of users and charge them money (spoiler: none of them ever got any users, nor did they generate any money). I was motivated in the beginning, but over time more and more anxiety crept in until it slowly became something I felt i had to do instead of something I wanted to do. I basically was under constant stress while working on them.

It was time to take a step back and ask myself what I really wanted to get out of a side project:

• Making some money on the side sounds nice, but everything comes with a cost. Generating revenue means having users. And having users means having to address other peoples needs in addition to my own. Needs of people that paid for something. It likely means doing support and fixing bugs even if I don't feel like it. It basically becomes a job, and I already have one of those that I love ³.
• Learn something new: Usually I start a side project because I want to learn. It could be a technology that is not in our tech stack at work or something I'll need in my job in the future and that I want to hit the ground running with. It could also just be pure curiosity: I wonder how X or Y works and try to find out by building it myself.
• Freedom: It's nice to just hack away, like when I first started programming. No worrying about maintainability or tests or clean code. Just mess around and see where it's going.
• Relaxation: My wife doesn't really get this, for her it's doing the same thing I do at work, after work. But it really isn't. Just coding for fun, listening to music or having a video play in the background is deeply relaxing to me.

So here I am, making the case for starting goofy side projects. Projects that have no product market fit. Projects that will not get finished. Projects that will have a $0 MRR for ever. Projects that will likely never be used by anybody. Projects you do just for fun. It's okay to have those. Capitalism has us thinking that we need to be productive, that we need to make money off of everything we do, or else it's wasted time. I'm here to make the case for wasting time.

The next time you want to do a project but catch yourself thinking about how that already exists or how nobody will pay for this, accept that. It's fine. Do it anyways.

I also have the theory that a good chunk of successful side projects start out just like that: As fun things where someone started to think "I wonder what happens if I just try..." and then just start building.

Footnotes

1. Which does not meant it's a necessity. I know great programmers that do nothing on the side. ↩

2. I think that's because a side project is something that is 100% directed by you. You usually choose your day job based on interest, but what exactly you're working on is not your decision alone. ↩

3. We're hiring, btw: https://join.gigs.com/ ↩

Say we have the following form using zod and react-hook-form:

const schema = z.object({
  duration: z.number().optional(),
});

export const Form = () => {

  const { handleSubmit, control, register } = useForm<FormData>({
    resolver: zodResolver(schema),
  });
  
  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register("duration", { valueAsNumber: true })} />
    </form>
  )
}

Submitting the from will not work. We can inspect the errors to see what's wrong:

export const Form = () => {

  const { handleSubmit, control, register, formState: { errors } } = useForm<FormData>({
    resolver: zodResolver(schema),
  });

  console.log(errors.duration)
  
  // ...
}

Which will yield: 'Expected number, received nan'. What happened?

Looking at the react-hook-form documentation, we learn that valueAsNumber will fall back to NaN if no conversion is possible¹:

Returns a Number normally. If something goes wrong NaN will be returned.

Let's move over to zod: The documentation for optional() shows that the inferred type expects the defined type or undefined.

const user = z.object({
  username: z.string().optional(),
});
type C = z.infer<typeof user>; // { username?: string | undefined };

Remember that NaN and undefined are different values. So we know why the form is not validating: We're passing an unexpected value for duration.

How do we fix it? Luckily, react-hook-form also provides another option for register, setValueAs(). We can use that instead:

<input {...register("duration", 
    { setValueAs: (value) => (value === "" ? undefined : parseInt(value)) }
  )} 
/>

This way, we make sure we set the value to the expected undefined if the input is left empty.

---

moshyfawn suggested another approach to the problem on twitter using zod's coerce functionality, shifting the value transformation from react-hook-form to zod:

const schema = z.object({
  duration: z.coerce.number().min(0).optional(),
});

Footnotes

1. This is a limitation react-hook-form has inherited from the native HTMLInputElement ↩

There's a bunch of different conditions that can cause distress in a baby. Here's an incomplete list:

• Too cold
• Too hot
• Hungry
• Tired
• Full Diaper
• Tummy hurts because there's air in it
• Tummy hurts because a fart isn't coming out
• Tummy hurts because poop isn't coming out
• Tummy hurts, in general
• Joints hurt because they're growing
• Sensory overload
• Progressing what happened during the day

However, they only have one way to communicate: They cry.

It's a little bit like trying to debug a program that's not working, but the only output you get is Uncaught Error: Error with no stack trace at all. It's... interesting.

Obviously, this is a shitpost to a degree. But it's also true. While there are nuances that may give you a hint to what's wrong, the only chance you have is trying out things and eliminating possible issues until you find what works¹. And the next time, you start over new.

Footnotes

1. Also, if you're thinking "just use StackOverflow" let me tell you: You haven't seen a site of toxic know-it-alls until you browsed some parenthood forums. ↩

Growing up, I thought the world is huge. There are 7.8 billion people on this planet and I only knew a few of them. But really, the world is kind of small. Reaching out to people you think of as unreachable becomes easier once you know a few people. An example: Paul Graham.

Pretty well known in business, seems unreachable. However, Gigs was part of Y Combinator, so chances are our founders know Graham. So this would make him a 2nd level connection for me:

me -> our founders -> Paul Graham

(not sure if they actually know him, but if not, they definitely know someone who does. This would make him a 3rd level connection)

Let's get a little more ambitious, even: Barack Obama.

I know a founder I worked with in the past (he also was the one to introduce me to this connection idea). They know someone who organizes a big conference in Germany. They had Obama talk on their conference once. So Obama is a 3rd level connection:

me -> founder -> conference organizer -> Barack Obama

This does not mean that I could get an introduction to PG or Obama right now. But if I wanted to get in touch with them, I at least had a route that could prevent me from writing a cold email.

This boggles my mind.

"You can't steer a parked car". I came across this in a video the other day and it resonated a lot with me. ¹

It's easy to sit around and think about doing something and trying to plan every eventuality. This is a fool's errand, though.
First, your plans will never just work in life. It just doesn't happen.
Second, you cannot possibly know what problems and issues could arise on the way, until they do.

The logical thing is to just start moving and figure things out on the way. It's scary to do that at times, so thinking about something is the easy way out for the brain. It will trick you into believing you're doing something because you're thinking about it.

Here's Nat Eliason:

You find what you like by trying it, not by thinking about it.

And, somewhat related, my favorite video by Casey Neistat originally from @farrellybros:

Life is like going the wrong way on a moving walkway. Stand still and you go backwards. Walk and you stay put. Gotta hustle to get ahead.

Footnotes

1. I think it originally stems from a religious context. At least all the sources I found online are from religious websites. The original saying seems to be "God can't steer a parked car". The god part did not resonate with me, so I left it out. ↩