Articles

Shutting down Fridays with Zell

If you stuck around for a while, you might have noticed I used to post a video (and an audio) every Friday for most of 2018. I call them “Fridays with Zell”.

In 2019, I decided to stop making videos. I want to share why I decided to stop making videos.

Why I started making videos

I started making videos because of three reasons:

  1. I thought it would be fun.
  2. It would be good practice if I want to release video-based courses in the future.
  3. I heard good things about video helping to bring more subscribers

I finally got a chance to try making videos at the start of 2018. I committed for one year (and made 44 videos in total). That’s approximately 1 video per week.

Why I’m shutting down Fridays with Zell.

Two reasons:

  1. Videos don’t bring me additional subscribers
  2. Video-making is not fun for me

I should probably say more about each statement, so here we go.

Videos don’t bring me additional subscribers

Here’s a chart of subscribers in 2018 and in 2019. Green bars indicate the number of new subscribers.

Subscriber count hovered around 250 a week with or without videos

The number of new subscribers hovered around 250 per week from 1st January 2018 to 22 May 2019. I stopped posting videos in January 2019, but the number of subscribers remained at 250 per week.

This tells me the videos didn’t bring in new subscribers. My videos were mostly watched by people who are already following me.

Video-making is not fun

A lot of work goes into creating videos.

  1. I had to put myself in front of the camera
  2. Speak in a manner that doesn’t feel too fake
  3. Edit the hell out of what I spoke (the hard part)
  4. Write an article that goes along with the video

Points 3 and 4 are killers.

I loathe the editing process. I hate scrubbing and trimming the audio. This process is not fun at all. I would rather do ANYTHING else than edit a video.

Plus, converting a video into an article takes a hell lot of work too. I have to write a transcript of what transpired in the video, create images, and write an article that flows.

It’s not fun.

It’s too much work.

I got burned out.

So I decided to stop.

Will I ever make videos again?

I can’t say for sure. Maybe I will make videos again when the dread fades away. But if I ever start making videos again, I’ll do it in a different way.

Final words

You won’t know whether you should (or shouldn’t) do something until you’ve done it.

Give it a try.

You can always walk away if it’s not for you.

If you walk away, you’ll know why it’s not for you. You’ll have a better idea about what you want/don’t want to do. And you can focus better on the next thing.

Sometimes, what’s right for you now doesn’t mean it’s never going to be right for you.

Keep experimenting, and continue to challenge your assumptions.

Using Standard with VSCode

I use Visual Studio Code as my text editor. When I write JavaScript, I follow JavaScript Standard Style.

There’s an easy way to integrate Standard in VS Code—with the vscode-standardjs plugin. I made a video for this some time ago if you’re interested in setting it up.

But, if you follow the instructions in the video (or on vscode-standardjs’s readme file), you’ll come to notice there’s one small detail that needs to be ironed out.

Try writing a function the old way, and save it repeatedly. VS code will toggle between having and not having a space before the left-parenthesis of the function.

VS code toggles between having and not having a space before '('.

You get the same problem when you write methods with the ES6 method shorthands:

Same problem happens when you create methods with ES6 method shorthands.

How to go through the job application process—an interview with Chris Lienert

“Do you have any advice on finding a job as a developer?”

Many people have asked me that question, but I can’t give a proper answer because I have never been hired as a developer before. What I did was:

  1. Wriggled my way into a Wordpress dev role in an admin-based internship
  2. Freelanced
  3. Run my own company

So I’m horribly inadequate at answering a question about finding a job.

But Chris Lienert is an expert at it. Chris has experience hiring and building teams of excellent developers. (A fun aside: He used to co-run CSS Singapore, which is a monthly CSS Meetup in Singapore).

I managed to grab Chris (before he left Singapore for good) and asked him to talk about the job application process. You’ll hear golden advice in this interview from Chris, like:

  1. Chris’ opinions about the hiring process.
  2. How to improve your chances of getting an interview
  3. What to do if you don’t get a job
  4. How you should write your CV
  5. What to do during the actual interview
  6. What questions to ask during the interview
  7. How to answer any tricky questions you get

Note: We jumped around a lot in this 1.5 chat because Chris has so much to say about this topic. I highly recommend you listen to the audio version if you can.

To make it easier for you to digest, I also summarized what we talked about into three stages:

  1. Preparing your CV/Resume
  2. Before you apply for a job
  3. The interview process

On Advocacy

We’re fierce and protective when we talk about stuff we care about. And as developers, we care a lot about these topics:

  1. Accessibility
  2. Web Performance
  3. CSS
  4. JavaScript
  5. Frameworks
  6. Inclusivity and Equality

There are no problems with voicing your opinion. We all have our opinions and we want them heard. I understand and respect that.

But we should be mindful of the way we say things. If we voice our opinions as complaints, name-calling, and shaming, our opinions don’t get heard. No change would happen. They simply create a vicious cycle of worry, hate, and anxiety.

If we change how we project our voice, we can make real change happen. And our culture will change for the better.

Maybe we should step away from the online-world for a bit

We developers have become quite a toxic bunch of people to be with. We create fierce “debates” on every media we’re in. Twitter, Facebook, wherever we’re at.

We talk about how CSS suck (and how they don’t).

We talk about Accessibility and Performance (and bitch companies that don’t do them well).

We talk about frameworks vs no-frameworks. React vs Vue vs Vanilla JavaScript. And why you SHOULD learn frameworks vs why you SHOULDN’T learn frameworks.

We also talk about how some technologies are “dead” (even though they still continue living for quite some time).

Everyone has opinions. Most of these opinions are complains. We spread anger, fear, and worry in our communications. Daily

This should stop (but it won’t, because you can’t control what people say or do). What you can do is take a break and ignore what everyone else has to say.

Dealing with nested callbacks

JavaScript is a strange language. Once in a while, you have to deal with a callback that’s in another callback that’s in yet another callback.

People affectionately call this pattern the callback hell.

It kinda looks like this:

firstFunction(args, function() {
secondFunction(args, function() {
thirdFunction(args, function() {
// And so on...
})
})
})

This is JavaScript for you. It’s mind-boggling to see nested callbacks, but I don’t think it’s a “hell”. The “hell” can be manageable if you know what to do with it.

JavaScript async and await in loops

Basic async and await is simple. Things get a bit more complicated when you try to use await in loops.

In this article, I want to share some gotchas to watch out for if you intend to use await in loops.

A new (and easy) way to hide content accessibly

When I want to hide content accessibly, I always turn to Jonathan Snook’s snippet.

.element-invisible {
position: absolute !important;
height: 1px; width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}

But yesterday, I happened to chance upon Scott O’Hara’s article on hiding content. Scott says we only want to hide content in three different contexts:

  1. Hide it completely
  2. Hide it visually
  3. Hide it from screen readers

JavaScript async and await

Asynchronous JavaScript has never been easy. For a while, we used callbacks. Then, we used promises. And now, we have asynchronous functions.

Asynchronous functions make it easier to write asynchronous JavaScript, but it comes with its own set of gotchas that makes life hard for beginners.

In this 2-part series, I want to share everything you need to know about asynchronous functions.

Publishing packages that can be used in browsers and Node

When you create a package for others to use, you have to consider where your user will use your package. Will they use it in a browser-based environment (or frontend JavaScript)? Will they use it in Node (or backend JavaScript)? Or both?

If you want to create a package that’s usable in both browsers and Node, this article is here to help.

You’ll learn:

  1. How to write packages for use in browsers
  2. How to write packages for use in Node
  3. How to publish your packages for use in both browsers and Node
×

Hold on while i sign you up…

Woohoo! You’re in!
Now, hold on while I redirect you.