The right amount of danger

san francisco wells fargo nick ang blog

I’ve been in the San Francisco Bay Area for the last 10 days and have learned a lot about the city and the East Bay and South Bay cities. The thing that keeps coming up? Danger.

Coming from Singapore where danger is literally nonexistent, the Bay Area feels almost too dangerous.

But I’d argue that Singapore is not heaven compared to SF.

Virtually guaranteed safety in day-to-day life has a way of making you complacent and incapable of living fully. There, I said it. I’m complaining about the city I grew up in being too safe.

It may sound ludicrous that someone might be unhappy with living in a place that is “too safe”, since first of all, does such a thing exist?

I’d argue yes, a place can be too safe, just as life can be. We’ve all heard the phrase “playing your life” followed by “too safely”, and possibly “you only live once!” Live too safely and, the critique goes, you might end up not having lived at all.

That is Singapore for you. It is too safe. Our streets are clean, both literally and figuratively. There is virtually no trash, and there is almost no crime. Walking around anywhere in the city is danger-free.

Nobody in Singapore pauses to think that they might need to hide their jewellery to prevent a burglary, and practically everyone leaves their laptop at the desk for toilet breaks.

The bad thing about this level of safety is that people are not kept on their toes. Deliberation is not a thing because it’s not needed.

Like a penguin with wings but cannot fly, people in Singapore live in such comfort and safety that we become unable to fully engage with our environment. Our minds focus instead on the menial things, finding fault in them. And everything becomes something we don’t experience and live but merely pass by.

Takeout dinner in Singapore

In Singapore, I’d ride my motorcycle out to get dinner. Because there is absolutely no need to worry about my safety (except of course the possibility of falling off my motorcycle), I often pick on things like the weather to feel miserable about.

When I queue to buy my mixed vegetable rice, my mind is already thinking about what I’m going to do when I’m home. That unresolved argument with a friend, or that obstacle in my project, or whatever. I can do that because there’s nothing in the immediate surrounding that worries me, that forces me to stay engaged with it.

Takeout dinner in San Francisco

Based on what I’ve seen over the past 10 days, I’m certain that going out to get packed dinner is not such a breeze in cities in the SF Bay Area.

First, there’s the point about the weather. It gets really cold here some days, and you either prepare for it or get sick. Maybe even die of hypothermia or something. (Again, no such thing in summer-year-round Singapore.)

Weather aside, there’s a good chance of one of a few bad things happening to you:

  • Get hijacked by a mentally unstable person asking for money, who will more likely than not shout at you if you don’t oblige.
  • Have your car window smashed (it frequently happens even in daylight).
  • Get robbed of your wallet and other valuables at gunpoint.

This isn’t hyperbole, by the way. Ask anyone who lives here and they will tell you the same thing.

This, of course, is a less than ideal way of living. It’s so dangerous you can never let your guard down – something bad is likely to happen when you do. That’s just tiring.

So perhaps it’s not preposterous to think that there might be a “right” level of danger for us to live fully. After all, death is ultimately the only thing that keeps us working harder and loving others. Without the potential to die, I’d probably just watch Netflix all day long for 100 years, and the programs probably wouldn’t be all that good, since filmmakers probably can’t be bothered either.

The right level of danger is somewhere in between Singapore (not dangerous at all) and the San Francisco Bay Area (too dangerous). That’s all I can tell for now.

Bye Inconsolata

inconsolata font on nickang blog
The old typeface for this blog – bye Inconsolata!

It’s official, I’m sick of the Inconsolata font!

The font you’re seeing now is good old Georgia, one of the classic serif fonts that have been used in print for decades and continue to be used in websites like The Financial Times.

I changed the typeface used on this blog as an experiment. I was curious to see if the modern monospace font would change what it feels like to read this blog. On that front, I largely succeeded, because I managed to feel more foreign visiting my own blog than reading someone else’s with a classy serif font.

That’s when I knew Inconsolata had to go.

Georgia, you’re up next!

Intro to Web Development Workshop in San Francisco

Today was interesting. Despite being a tourist, I got in touch with the right people and put together an Intro to Coding workshop (it was probably more like intro to web development) for a small group of NUS Overseas Colleges (NOC) students. I learned a few things along the way.

But first, a little about the workshop. It was a 2-hour long crash course in web development – how the Internet works, what is HTML, CSS, and JavaScript, and how they all come together to form a web site/app.

Being an alumnus of the NOC, I knew that not all students in the program are technical, and that could be potentially inhibitive for their work in a place like Silicon Valley, the mecca for software engineers. So I reached out in hopes that I might somehow be able to be useful to them.

With a quick poll, I got a sense that most of those who turned up wanted one of a few similar things:

  • To be able to converse with their developer colleagues at work
  • To appreciate what’s going on behind the apps that their company is working on

Since the workshop was free, why not just show up, right?

So that’s the workshop and the premise for hastily putting it together with the student leader (thanks, Xin Ru and Ken!). On to some of the lessons I gleaned from doing this.

Think of giving, not taking

Giving lowers the barrier to entry to doing something like this. No hidden costs, just giving something valuable for no expected return.

If I had gone to the students here and just asked for contacts and to “buy coffee” for people, it would be a lot less fun and feel much more transactional. I actually had fun tonight.

Unlikely to happen? Take a chance anyway

I’m here for 11 days and asked my friend Agus (who works for the university) on day 2 to try and link me up with someone here.

Even though that meant that if things went through, the student leaders and I would have to put together a decent workshop in less than 8 days (we did it in 8!).

If things went through, the student leaders and I would have to put together a decent workshop in less than 8 days! (In the end, we did it in 4.)

What’s there to lose? I knew if I didn’t try, there would be an exactly 0 percent chance of it happening. With that mentality, I just decided to reach out and try it anyway.

intro to coding workshop in san francisco blk71
Some of the people who turned up at the Intro to Web Development Workshop @ Blk71 SF (That’s me, first on the left)

To be honest, I was ready for it to not happen on this trip. I thought that perhaps in the future when I’m in some other city (or San Francisco again!), it would be easier because I’d have linked up with the right people already. And that would be true, regardless of whether this particular trip’s workshop was going to happen. Baby steps!

People like to help those who help them

This is probably a truism by now, but since I’m experiencing it myself, I’ll reiterate it. People like to help those who help them.

Our workshop ended at about 8pm and we went for pizzas nearby after that. Over pizzas, I had an ask of everyone: “tell me about your company, and whether they’re currently hiring!”

That led to a series of wonderful stories about life at company X and Y, and most of them offered to refer me to their company (if I decided to apply) knowing that I was looking for a job in the San Francisco Bay Area. I’m incredibly thankful for their generosity.

I suppose this could have happened because I was charming or for some other inexplicable reason like I smelled nice (for the record, I don’t think I was either of those tonight).

But this helpful atmosphere does seem to have been created from the fact that it was an evening of learning something together and having pizzas and wine while doing it. There was nothing but helpfulness and intrigue throughout the evening.

San Francisco Bay Area – I’m looking for opportunities!

I’ll end off by declaring that I’m currently looking for opportunities to work in the San Francisco Bay Area and will be relocating soon! If you happen to work at a company that is hiring a full-stack software engineer, please get in touch at hello at nickang dot com. 🙂

Real news

I was in a Lyft ride in San Francisco city this afternoon when the news of the school shooting in Florida broke over the radio. Spawned from my ensuing conversation with my Lyft driver, a black woman in her 40s, about gun ownership, I started thinking about the way the news was reported over the air waves.

The reporter interviewed someone who knew the shooter personally and said person gave an account of the murderer that I’m sure most Americans have unwillingly become familiar with. Unsociable, always having trouble with all his teachers, and known to occasionally do weird things like throwing a rock through the classroom window for no apparent reason. I found that all too familiar, and I don’t even live in America.

But it got me thinking. What if this wasn’t really the case? What if a shooter is a really normal kid, with no visible angry undertones to his/her life, and is actually kind of popular in school when he/she opened fire? Would the media report as it is, knowing that it might unleash pandemonium, since even conventionally good kids are committing atrocities like this?

Let me be clear – I’m not saying that this particular shooter is not being accurately described for what and how he is. I don’t know that, and I don’t know him. All I’m wondering is whether such news will ever truthfully surface when it happens.

I’d personally find it a lot more disturbing and become much more concerned about gun ownership if the interviewee’s account of the shooter was like this:

“He was a perfectly normal guy. We just had dinner the other day and I feel like he’s just like any other student in our school. He’s happy when there’s something to be happy about, emotional when something is upsetting, and he’s never exhibited any violent tendencies.”

Wouldn’t that be scary?

I did notice my Lyft driver nodding and mm-hmming as she heard the person who knew the shooter described him as a socially awkward troublemaker. It reinforced her confirmation bias – the news is giving her what she wants to hear. I just hope that she, too, questions whether this is a representative account of the shooter. Because if it’s not, then obviously something else is wrong other than unstable students.

News must always be taken with a pinch of salt and a healthy dose of scepticism – in my opinion, that just bodes better for any society. As for gun ownership and the laws in America, it will take more than a 10-day trip to San Francisco to understand and evaluate.

My problems are mine to bear

sunset glowing horizon nickang blog
Somewhere in Oakland along Market Street.

I’m currently in the San Francisco Bay Area for a short vacation. It’s been a fun trip so far and it’s also quite fruitful as I’m meeting friends who are based here who are mostly working in tech.

As an outsider with my own cultural lens, I can see that Americans are indeed much more individualistic than people in most Asian countries (though I’m generalising a bit, but am probably not too far off). Individualism is the hallmark of American culture.

Openly disgruntled

I’d only been here for 2 proper days and have already encountered a number of Americans (they may not be San Franciscans) who wear their emotions unapologetically on their faces and channel them into their actions. This manifests as unfriendly and aggressive behaviour that is rare-ish in an Asian society, like Singapore’s. An example will help.

In Singapore, if a service staff is feeling overworked or tired, it would be uncommon for her to act like she’s entitled to “being herself” and anyone who interacts with would be better off learning to deal with it. Here, I’ve already had two interactions with service staff who just can’t be bothered and expect me to deal with their foul attitude.

In Singapore, although not as much as Japan, people tend to manage themselves and not let their negative energy spill over to their work and people whom they’re serving. The burden of suffering is for that person him/herself to bear – not for others to deal with.

Read that last sentence again. It is by no means a superior way of being a person and for a society to behave collectively. Keeping emotions pent up and unreleased will wreak havoc on people’s psychology and overall wellbeing. That’s why Japan has so high suicide rates and loads of unfathomably fantastical, dark, and morbid manga.

I’m merely pointing out and recording an observation while it’s fresh. I’ll be in SF for 10 days in total, and I know from experience that that is enough for enculturation and transforming my perspective.

For now, I continue to value being a team player, a responsible partner in a conversation or transaction. My sadness, anger, and fatigue is mine to bear, not yours to tolerate!

How to setup ESLint for your next project

how to setup ESLint for your next project nickang blog banner
Photo by Norbert Levajsics on Unsplash

For over a year, I used ESLint at work without knowing. I didn’t have to understand what package exactly was doing the work of linting – it just worked, quietly doing its duty of enforcing no unused variables and imports, keeping consistent code styles, and all that nice stuff.

But I recently had to learn how to set it up for a project I’m working on on the side – a little concept game unpretentiously called the Object Oriented Ice Cream Shop Game. The name is fortunately temporary until I find a more original name. Among other things, one of the reasons I wanted to do a side project was to learn from linter rules of my own choosing. Quick detour about that, then we’ll cover how to setup ESLint for your project.

Learning from linter rules

I’ll write a full post dedicated to this idea, but in short: I believe it’s possible to learn a ton about programming from the linter warnings that frantically wave at you as you code. And I’m not just talking about language-specific learning points – I’m talking programming in general.

For example, I learned that having trailing commas when writing object or array literals is a good idea because it provides cleaner git diffs. That’s not something I can confidently say I’d have considered until it was made clear to me when my linter underlined it in red and I clicked through on its associated comma-dangle rule on ESLint:

comma dangle eslint linter warning

Nuff’ said. Let’s move on to how to setup ESLint for your next project.

How to setup ESLint

Setting up ESLint for a project is actually relatively pain-free.

First, let’s state one of the most important and often overlooked pieces of information you’ll need to setup ESLint:

There’s ESLint the npm package, and then there’s the ESLint code editor package for Atom/Sublime/etc.

You will need to install both to get ESLint to work as you code. If you install only the ESLint npm package, you will need to run this command every time you want to check your code:

That’s obviously not as powerful as having an omni-present code police.

Here are the steps to setup ESLint for your project:

  1. Run npm install --save-dev eslint to save package to your project’s node_modules folder and have it listed in package.json under devDependencies
  2. Create a .eslintrc.js file in your project root directory for configuring project-specific linter rules (alternatively, run node_modules/.bin/eslint --init to use ESLint’s interactive configuration file generator)
  3. Install the ESLint package for your code editor (Atom | Sublime)
  4. Configure ESLint to your needs, installing additional ESLint plugins for specific rules and style guides (eg. eslint-config-airbnb-base for Airbnb’s), and for libraries (eg. eslint-plugin-jest for Jest testing library)

Configuring .eslintrc

Here is an example of my .eslintrc.js file. Note that I chose to use the .js file format, but you can choose .yml and .json and use slightly different syntax.

With that, you’ll have setup ESLint for your project!

One last point before you go.

ESLint is for ES

One of the reasons I got confused was the fact that there are other linters out there.

Taking a quick look at the code editor packages I have installed shows me 5 different packages:

  • linter
  • linter-ui-default
  • linter-js-standard (for JavaScript)
  • linter-rubocop (for Ruby)
  • linter-sass-lint (for Sass)

If I’m not wrong, the first two are mandatory for setting up a linter mechanism in my code editor (currently using Atom). The last two are for different programming languages.

But the third, linter-js-standard, is for JavaScript! Wouldn’t this conflict with ESLint?

I’m glad you asked because it means you noticed that ESLint is for ES – as in, ECMAScript, or more popularly, JavaScript. ESLint is a specific linter software that comes bundled with a default set of rules for JavaScript.

This is my 6th linter package:

  • linter-eslint (to use ESLint to lint JavaScript)

ESLint is project-specific and I believe has become the de-facto standard tool for linting JavaScript. So when your project has ESLint set up, its code will be linted with ESLint and not the other JavaScript linters.

In fact, the linter-js-standard package has a settings option specifically for making this explicit:

linter js standard setup ESLint

Ok, I think that’s all the linter know-how any of us needs to get up and running.

Now just write code and trust that your linter’s got your back. You should, of course, verify that it’s actually working by deliberately making an obvious mistake… but you already knew that.

Happy days ahead!

Like posts like these? Subscribe to my newsletter to get more useful posts delivered once a month to your email.

Why do some developers use

BSP object hasownproperty
Original photo credit: Pete Wright

You might have read someone else’s JavaScript code recently and came across something like this:

And you’re probably wondering like I did before I dug deeper, why not just use instance.hasOwnProperty('getName')? It’s much shorter code, which probably means it’s easier on the brain and less prone to errors, right?

Turns out, not really. There are two main reasons to invoke the hasOwnProperty that is on the original Object.prototype.

Reason 1: objects can be created with no prototype

The first reason is the one cited in ESLint‘s no-prototype-builtins rule.

This seemingly overly-verbose approach to checking for a property on an object is actually a fail-safe. Consider an object initialised using Object.create(null):

In the snippet above, we initialised a new object using Object.create(null). Because null was passed in, the result is an object that is void of the default object’s prototype chain. No prototype means no hasOwnProperty method.

Wondering why anyone would want a completely empty object instead of just initialising with the object literal {}? I did too. Apparently, it’s a way of simulating a Map data structure in JavaScript before it was introduced in ES6. This hack is not so often used now, but with all hacks, it’s good to know it exists, if only just to help us identify them when we see them.

Reason 2: prototype properties can be overridden

This one should be easier to understand. If something can be overridden, it’s safer to refer to the source of truth.

When we call the method that is directly on the object instance, we’re one degree (or more, depending on the class inheritance) separated from the original method defined on the Object class.

Yes, I agree that this is an unlikely scenario and that if it does happen on your team, it reveals a serious lapse of judgement of the developer responsible for it. As a rule, never override an in-built method on the prototype chain!

But if being slightly more verbose can eliminate the possibility of just one extremely hard-to-spot bug, I’d choose verbosity any day! As an aside, I think that’s a big part of what makes TypeScript popular among in the JavaScript community despite its lengthiness.

Use the source of truth on the Object.prototype

I hope that clears the air for you. The ESLint “no-prototype-builtins” rule was what made me realise this detail, but for you, it might well have been reading someone’s code.

Either case, let’s opt to use from now on. It’s just the better way of checking for a property.