DEV Community: Darren Vong

What are some examples of awesome GitHub profile READMEs?

Darren Vong — Sat, 11 Jul 2020 12:34:41 +0000

GitHub has recently introduced a feature where we can include a README for our GitHub profiles by creating a repo named <your_username>/<your_username> with a README.md file in it.

What are some cool examples you've seen so far? Looking for inspirations!

Six non-technical lessons I learnt during my COVID-19 job search

Darren Vong — Thu, 25 Jun 2020 11:12:01 +0000

Cover photo credit: Christina @ wocintechchat.com at Unsplash

While polishing our technical skills is important for landing a job, it is equally as important to not neglect the non-technical aspects during your job search. In this post, I am going to reflect on the non-technical lessons I learnt quickly throughout my recent job search during COVID-19.

Table of Content

The short version

Learnings

Vet a company's financials
Make yourself discoverable
Focus on quality over quantity of applications
Follow up
Position yourself positively
Negotiate

The short version

This is a long post, so if you want a short and condensed version of my learning, here they are:

Empower yourself by vetting and researching a company's financial status before committing to taking a job at a startup;
Make yourself discoverable on social media like Twitter and LinkedIn, so the jobs find you rather than you looking for them;
Stay organised with your job applications using a calendar and spreadsheet to help you prioritise your interview preparation;
Follow up promptly after your interviews to help stand out from the crowd and serve as a reminder to the company if they forgot to respond;
Communicate the business value you can bring to a company and position yourself positively;
Start the salary conversation rather than sticking with the first (likely) low-ball offer to get the money you deserve!

(Making this also for my lazy future self 💁‍♂️ before delving into the details)

If you are interested in the more in-depth version, then read on!

Some back story...

TL;DR: If you are only after my findings, you can skip ahead to the first finding, but I want to leave this in to motivate why I am writing this post.

For those of you who have read my last blog post...

Five advice for a developer settling into a new team

Darren Vong ・ Dec 23 '19

#career #beginners

... you might be surprised to see this blog post's title before reading further, considering I started in a new job not too long ago.

The caveat is, I was working in an early-stage startup, and COVID-19 has unfortunately turned their fortune upside down. Being a recent hire, I was an obvious target to be let go.

So here I was again, back in the job search mode much earlier than I've prepared for. Determined to get back on my feet again, I opened myself to any suitable opportunities that come my way. Everything else after that happened so quickly that it's become a blur.

This has affected my plan on learning more in the open — inspired by Max Stoiber and other open-source developers I follow — after I have settled in my "current" work so I can harness brain capacity to do that and write about it.

But, rather than letting these past few months stay as a blur, I want to crystallise the experience, note the things I learnt and the mistakes I made in the last two job search efforts for future references.

Now that I've taken you around enough of a detour... let's dig into my learning!

1. Vet a company's financials

This is probably less applicable for larger companies (500+ employees), but if you are looking to work for a startup, considering 90% of them fail, not vetting the company's financials was the number one mistake I made.

When I said vet, I didn't mean anything more comprehensive than asking some key questions. For example, "what is the company's runway?" can give you a rough idea on how financially stable a startup is should things go sour. I didn't ask that when I was interviewing and I've certainly learnt the hard way.

"What is the company's runway?" can give you a rough idea on how financially stable a startup is should things go sour.

Another useful thing to find out is "when did the company raise the last round of funding?". You should ask them or find that out by looking up the company's name on Crunchbase. AngelList is also another good resource to do your research on a startup.

The big takeaway here is that by empowering yourself with information on a company's financials, you can make a more informed decision on if you want to work for a startup based on how risk-averse you are.

2. Make yourself discoverable

The title itself sums it up. The success rate of landing an initial interview with companies are much higher if you were referred by an internal employee, or found by a recruiter, rather than trying to pass the minefield, aka a company's application form.

On top of that, you save a lot of time as you won't have to fill out lengthy application forms (in some cases) and cover letters to catch the company's attention. They are already interested in you by reaching out in the first place!

Helena Milosevic did a great talk in React.js Conf on the importance of making yourself discoverable online, especially if you want to work for a big company!

So, how would you go about making yourself discoverable?

Post on social media - share your skills and the fact you are available and looking!

Twitter

I recommend starting with Twitter, as it boasts a strong tech and professional community.

Once you've tweeted, share it with everyone! Good starting points include your friends and family, your old coursemates and former co-workers. Even if they don't directly work in the tech industry, you never know who else they are connected to that does!

Also, there are several people with a large following who are willing to share tweets of job searchers after being laid off thanks to COVID-19.

// Detect dark theme var iframe = document.getElementById('tweet-1241860831614136320-328'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1241860831614136320&theme=dark" }

This means that even if you don't have a large following, or you don't know many friends on Twitter, you can tweet your availability and still have the potential to reach contacts you wouldn't have known otherwise!

Share [your post] with everyone! You never know who else they are connected to that does [work in the tech industry]!

LinkedIn is another good place to post and share your availability. Despite the disproportionate ratio of recruiters to direct tech company contacts on there (from experience), some high-quality contacts do exist and ironically, it is how I landed my current role.

In particular, if you have some experience already, you will likely get a large influx of recruiter messages. My recommendation is to prioritise direct contacts over recruiters, as it's mutually beneficial to discover that you are a good fit for each other. In comparison, most recruiters (and there are a lot of bad ones) are just after that commission from landing you the first job they can find.

Having said that, a good recruiter can be incredibly valuable to your job search as they can offer guidance throughout the interview process and handle the salary negotiation process.

Although, given the sheer number of bad recruiters out there, if you were to use one, I suggest using them selectively by choosing those with lots of strong references. A clear red flag is those who don't read your profile and reach out with jobs requiring skills you don't have.

3. Focus on quality over quantity of applications

My determination to get back on my feet quickly was both a strength and a big second mistake I made. I overloaded myself by applying to every job that looked suitable to my existing skillset.

In particular, if you are applying for developer roles, one thing that caught me out from applying to too many things was not factoring in how time-consuming certain part of an interview process is, namely take-home coding exercises. At one point, I was juggling three exercises simultaneously 🥴. It's fair to say the quality of my submissions suffered.

(The job offer I ended up with was when I had their take-home as the only exercise to do, so I was able to focus and show off the breadth of technical skills I had more effectively to increase my chance of passing it. A good reason to take it easy with the number of applications!)

As a result, it has taken a toll on my mental health rapidly. I feel I am still gradually recovering from it right now as of writing this, so I definitely don't recommend repeating what I did!

One thing I do recommend is to keep track of interviews using an online calendar tool like Google Calendar. Based on the volume of applications I was shifting through, the ability to see when my interviews were helped me prioritise and focus on my preparation so I don't show up without doing my homework.

Sketch from unDraw

(I did end up taking one or two calls without realising I told people I was free to do so as I was so overwhelmed and forgot to add to my calendar 🤦‍♂️. Luckily they were only initial chats so the stake was quite low. Reason #3 to not apply to all the things!)

Another thing that's helped my preparation was keeping track of the status of job applications in a spreadsheet. For each application, depending on how far I've progressed through its interview process, I've also colour-coded them accordingly.

This helped immensely for prioritising my preparation, as I can see from a glimpse which applications were more likely to become job offers, which allowed me to vary my preparation effort accordingly.

4. Follow up

Rather than waiting until the company replied with the next step, follow up with them after an interview, especially if it's a company you are interested in.

This includes a brief thank you email within 24 hours after the interview, and potentially another follow-up email if you don't hear a response after the date they said they will get back to you - or I'd say, after a week - whichever is sooner.

The general format I follow when writing up a thank-you email:

Thank the interviewers for their time (first sentence);
One or two sentences that were memorable about the interview;
One or two sentences to highlight how your skills align with what they're looking for (especially if you feel you didn't do that well enough during the interview) and/or close with your excitement about the role.

Considering more people are being let go thanks to COVID-19, the job market was (and still is, at the time of writing!) more competitive than usual. Therefore, sending follow-up emails serve two main purposes:

People are busy, so your email may help to remind them that they forgot to let you know you've progressed to the next stage of the interview process;
It shows that you care about the role and are interested in working with them. When they are done well, it helps you stand out from the crowd.

This ties back well to learning #3 about focusing on the quality over too many applications, as following up with everyone will quickly become infeasible otherwise.

5. Position yourself positively

Companies hire you because you possess certain skills that will help them convert into business value, hence understanding how you can bring them that value is a super useful skill to have. I wish I knew this earlier and I'm certain I'd have gotten more good offers.

I may be generalising a little here, but often I find developers are not very good at pitching why our skills are valuable and more importantly, why your unique skillset makes you especially valuable to a company over somebody else.

For a more in-depth discussion on this topic, I highly recommend checking out Heidi Waterhouse's talk on Tautology and Business Value (transcript available here).

For example, as a developer, the breadth of your technical knowledge will help the company build and maintain their product. That, in turn, will give them a product to sell that generate business directly.

As for skills that may bring them business value indirectly, this could be your technical knowledge on how to scale applications which will save them money as they won't mistakes you've experienced in the past.

Or it could be your mentoring skills which help onboard new and/or junior hires more effectively, increasing the team's overall productivity which maps to increased value by virtues of more things being built.

So, the next time you go into an interview, think about what you possess that the company needs and how that generate business value, either directly or indirectly, and embed those in your answers to their questions!

Doing it this way, I find it strikes a good balance of being confident yet not coming across as too arrogant. After all, the tech industry is increasingly swerving away from working with brilliant jerks, so you certainly don't want to come across as one!

6. Negotiate

As this is a skill I'd still need to improve on, I'll keep this brief.

Nine times out of ten, companies tend to low-ball you to start with, so negotiate! Even if you are not the best negotiator, just by asking and having a conversation about the topic can often boost your next offer by magnitudes of thousands of pounds/dollars.

Think about it from the company's perspective, it makes perfect business sense to low-ball you to start with (sadly). Why would they pay you more if they can get away with not doing so? Don't let them off the hook so easily and start the money conversation!

The worst they can say is no and at that point, you got to make a decision based on your circumstances. If it gets worse than that (for example, they rescind the offer because you negotiate), then it's probably a red flag and you got to ask, "do I really want to work for somewhere that undervalues my work?"

What have you learnt from your recent job search? I'd love to hear from you from the comments below! Let's learn together and help each other out. 😎

What are your favourite online remote working communities?

Darren Vong — Sat, 14 Mar 2020 01:37:14 +0000

Given how quickly COVID-19 seems to be spreading globally, most of us tech workers will have become remote workers. If you're like me, this might be your first time when you'll be working remote for an extensive period of time.

The main challenge I can think of is that feeling of isolation when working remote, especially in the current climate where we're advised to stay at home more than usual.

What are some of your favourite online communities that you are a part of that may ease this transition?

How do you (gue)estimate the size of the room you live in?

Darren Vong — Sun, 19 Jan 2020 22:29:33 +0000

Quite often, when I speak with people outside of the UK, one of the off-the-cuff questions we'd get into when we discuss the cost of living between different places is:

How many square metres [or insert equivalent imperial measurements] are the room/house/apartment you live in?

In all honesty... I never know the answer to this! The housing market in the UK tends to describe rooms with vague terms like "a large double room available", which is highly subjective.

So out of interest, what's your trick for figuring out roughly how big a room is without getting out the measuring tape? 🤔

What are your strategies for remembering information in your role?

Darren Vong — Sun, 12 Jan 2020 23:52:05 +0000

Cover photo credit: Fredy Jacob

Throughout our career, we learn many things ranging from new technical skills to softer core skills etc. In particular, I find that we get a lot of new information whenever we start a new position.

Unless you have a photographic memory... what are your strategies for remembering all of the useful things you learnt in your role?

Five advice for a developer settling into a new team

Darren Vong — Mon, 23 Dec 2019 11:46:50 +0000

Cover photo credit: Studio Republic

Congratulations on your new developer job offer! It is natural to feel an equal mix of excitement and nervousness; after all, taking on a new opportunity usually means changes such as integrating into a new team, adapting to new ways of working and potentially a new city... the list goes on.

As someone who is about to go through that process again (at the time of writing), I want to take the opportunity to reflect on five things I wish I knew or did when I joined as a new developer in my last team, with the intent of adding to this as I discover more.

To future me and especially any developers starting your first job, I hope you will find this useful. Without further ado, let’s get into it!

1. Add to the onboarding documentation

Unless you are starting in a brand new team, the chances are they will have some onboarding documentation which will help you get started with setting up your machine and get a better understanding of your team’s working style.

Read through them carefully and use them to your advantage! Highlight anything that seems unclear to you - this will give you good starting points to come up with specific and meaningful questions before asking Google, Stackoverflow or your teammates for help.

Once you have resolved the issues from the questions raised, offer to contribute and add that newfound knowledge back to the onboarding documentation! This will not only help retain knowledge within the team, but also new developers joining the team afterwards will have the answers to (very likely) the same questions or problems you faced before.

Adding to the onboarding documentation is a great way to consolidate the new knowledge you have learnt. The process of trying to explain how you solved the problem (and why it was one) puts you in “teaching mode”. As much as it sounds like a paradox, being in “teaching mode” is effective for learning since it focuses your brain to think critically before you write anything down.

Contributing to the documentation as you gain some new knowledge also has the added benefit of it written in a beginner’s mindset. In other words, you are more likely to write something in a way that only basic knowledge is required to understand the explanation, which will help to make the documentation more accessible for new starters. This is also a good time to spell out any abbreviated terms that have confused you so subsequent new starters don’t have to go through the same process again.

2. Start exploring with the unit tests first

Finding the appropriate place to start exploring a new team’s codebase can be challenging as the code and set-up are going to be more complex than personal hobbyist projects. Fortunately, most teams understand that and so it is unlikely they will expect you to make big changes from day one!

The best way to start is by picking up something small, usually bug fixes, that your team needs to get done for the current sprint. This will give you a good entry point and some focus on the specific parts of the codebase you need to understand before carrying out the fix.

Now that you have identified the parts of the codebase you need to look at, start looking into the files that may contain the buggy code. Try and look at the functions (and classes too if working with object-oriented languages) at a higher level first to see how they interact with each other, and only delve deeper into the function’s implementation details if necessary so that you don’t feel overwhelmed early on.

Once you have found potential functions where the faulty code might be in, start by looking into the unit tests for the relevant functions. The unit tests are a good place to start as it should show you the function’s behaviour and how they are intended to be used.

Photo credit: Ferenc Almasi

Reading through unit tests will also help you identify the appropriate place to start writing additional tests to try and reproduce the bug. More complex bugs may not be reproducible with unit tests alone, but if possible, adding unit tests as you fix the bug is generally a good practice. They ensure that if the bug appears again in the future, your new test cases should catch them before they end up in production.

3. Ask questions

This may sound like an obvious one, but honestly, asking questions is one of the best ways to integrate yourself into a new team. Good questions deepen your understanding of how your team works, why the codebase is structured in a certain way and any background information about the product that you won’t find from doing a Google search alone.

When asking questions related to why the codebase is written and structured in a certain way, it is important to do it with tact and empathy so you don’t come across as harshly criticising your team and put them in defensive mode. Instead, you want them to help you so you can get up to speed as quickly as possible!

Ultimately, no developers want to write bad code. While certain ways of structuring and coding styles may seem sub-optimal to you, there may be good technical reasons for doing so at the time (e.g. certain language features weren’t available). Respect your team. If you come up with ideas of improvement while trying to gain an understanding with your questions, suggest these in the next team meeting!

In addition to the onboarding documentation (see advice #1), the commit history of the codebase can be another great resource to use to come up with meaningful questions. The great thing about commit history is that it tells you exactly who has worked on certain files. If those people are still part of your team, they are probably the best people to ask your burning questions about that part of the codebase.

From experience, some good questions to start with include:

What software development methods do they follow?
How and why are certain decisions made (e.g. coding styles, structure, the software’s architecture etc)?
What is the history behind the naming of certain internal terms?
Do people prefer to work individually (and get help when necessary), or do they work better in a pair programming setting?
How are product decisions driven? Is it a collaborative effort between a product’s owner and developers?

4. Know your teammates

Building the company's product will involve working with your team, so get to know them! I am not saying you have to be best friends with everyone in your team, as some people may prefer to keep their work and social life separate, but having good working relationships with your teammates will make your life easier (for reasons outlined in previous advice) and more enjoyable.

A good place to start for knowing your teammates better is by looking out for any social or watercooler channels that your work chat may have. These will often range from people informally organising a time to make coffee together, having a game of pool/foosball (or whatever tabletop games your office have) to having lunch together. When you see an activity being planned, respond to it and agree to join in.

Photo credit: Bao Truong

For those of you who are more introverted, ask if one of the teammates who sits next to you can come along and introduces you to the rest of the team to ease the process. Hopefully, this shouldn’t be as tricky as you would have "broken the ice" already when you asked them for support initially. People in tech are generally quite friendly and receptive to new people joining their team, so they will understand the "newbie nerve" (I totally made that up). By the time you have been out with the group a couple of times, you will feel more at ease again.

5. Seek regular feedback

It is easy to come in the office, work away, leave and repeat, thinking that you are doing well. But really, how will you know for certain that your company and line manager think the same so that you will pass probation soon? You need their feedback!

Seeking regular feedback will help you focus on the settling in process, as feedback meetings tend to be where you set personal goals to aim for in between. They are likely going to be one-to-one meetings with your line manager too, so apart from getting feedback, these are also opportunities for you to raise any concerns and ask for any support you may need to help you succeed in the team.

Although this post is meant to focus on advice for developers settling into a new team, I want to stress that getting regular feedback after you have passed your probation, year’s work anniversary etc. is equally as important. In particular, once you have passed probation, these feedback meetings can be instrumental in getting your next promotion, pay rise and your career progression generally.

As the unofficial sixth advice, in addition to support and training you may need, I would recommend keeping track of small wins you have achieved such that by the time the big review meetings come around, you will have built up a strong body of evidence to support your next career move.

Is there any advice I have missed out that you think would be beneficial for developers settling into a new team? Let me know in the comments below - I’d love to hear your thoughts! 😊

Is using z-index in your CSS bad practice?

Darren Vong — Sun, 01 Sep 2019 23:02:13 +0000

When was the last time you see the z-index CSS property being used like so:

.some-element {
  z-index: 99999999;
}

Now suppose you want another element to be displayed above the element with the "some-element" class, a quick and dirty (yet seemingly common!) fix for this is by adding another '9' at the end of the z-index value above and apply it to this other element. For bigger web apps, this can quickly become unmanageable.

Since the default ordering is determined by the order of the HTML markup, with the element nearest the bottom appearing on top, shouldn't we use that instead of z-index? Can you think of a use case where relying on the markup's order alone is insufficient?

Do you wear earplugs at loud music events?

Darren Vong — Sun, 28 Jul 2019 03:15:46 +0000

Whenever I go to a loud music event (by that I mean going on a night out, going to a music festival etc), I dread that horrible ring (tinnitus) you get in your ears for the next day.

Earplugs seem the obvious solution to help with this, and yet for some reasons, I feel like not many people seem to wear them when they go to these events! Why do you think that's the case?

What word/phrase do you use to include everyone?

Darren Vong — Thu, 27 Jun 2019 23:29:31 +0000

The languages we speak and write in seems inherently biased. For example, to refer to a group of men, there are plenty of words to choose from: lads, gentleman, chaps... etc. The case is similar for women.

What if you want to refer to everyone, without using "everyone"? This may sound like a rhetorical question, but nine times out of ten, I find the alternative people use to do so is "guys". For me, "guys" is another word for referring to a group of men, so when you use that, are you really including everyone?

Speakers of some European languages may argue that by convention, the masculine plural words (like pronouns) are used and meant to refer to everyone in a mixed group. However, I'd beg to differ and claim that it's masculine biasedness and an outdated convention that doesn't seem applicable to the world we live in anymore.

To ensure everyone is truly included, be that in an event or a meeting, what are your alternative choices for referring to a group of people consists of mixed genders?

Some of my favourites (in English) are: y'all, folks, peeps. What are yours?

My takeaways from JSNation 2019

Darren Vong — Thu, 20 Jun 2019 08:11:53 +0000

Shortly after I shared my experience from attending React Amsterdam, the GitNation organisers invited me to come along to their sister conference JSNation (formerly AmsterdamJS), one of the biggest and longest running JavaScript conferences in the Benelux community, after they read my blog post!

Given that I currently work with JavaScript every day, and seeing a large number of core maintainers and founders from popular open source projects that would be at the conference, it was a great opportunity to ask questions, get new inspiration and so the decision to go was a no-brainer. And I am so glad I did!

In fact, as it was such an awesome experience, I want to share my takeaways from the event for memory’s sake and hopefully help anybody who is considering to attend the next one.

If the cost of attending is a big barrier to you, especially if you are an independent attendee like myself, GitNation works with sponsors like GitHub to provide diversity scholarships which let you attend the event for free. So if you are eligible, I highly recommend giving a go and apply, as it only involves filling in a short form.

Checking in

The main conference venue was Zuiderkerk, a former church built in 1611 and attended by the famous Dutch painter Rembrandt. It is centrally located just east of the Red Light District near the Nieuwmarkt. The church was easy to find, because not only it is quite an iconic building in Amsterdam, but also I was greeted with this JavaScript quirk as I approached the church’s entrance:

// Detect dark theme var iframe = document.getElementById('tweet-1136893748279939072-533'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1136893748279939072&theme=dark" }

Having learnt from my React Amsterdam experience, I reached the venue pretty much within minutes after the conference opened for registration, so there was no queue for me at all! Also, since this was a slightly cosier conference, and from seeing some of the queue pictures on Twitter at the time, I don’t think the queue ever got too long, so overall the check-in experience has been pretty smooth.

The day ahead

After completing the check-in, I collected my name badge, a JSNation branded goodie bag loaded with swags (which included a red JSNation mug) and the all-important programme guide for the day.

Before I had a chance to look through the programme, I was already too busy admiring how beautiful Zuiderkerk was:

Okay, I've technically cheated with this one (as it's taken at night)...

Deciding which talks to go to was challenging, as many high-quality talks were happening simultaneously in both tracks. To add to the challenge, the conference’s Node.js track of talks were held in Uilenburgersjoel, a former synagogue five minutes away from the main venue, which gave the conference this unique accolade:

// Detect dark theme var iframe = document.getElementById('tweet-1136893481228611585-793'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1136893481228611585&theme=dark" }

Luckily, to make switching between tracks easier, a small room playing the live stream of the Node.js talks in Uilenburgersjoel was set up at the back of the church. I took complete advantage of this as I tried to get a taste of the talks from both tracks.

Inadvertently (or was it intentional?), the room also turned out to be a quiet area for anyone who may wish to take a break from the crowd. Either way, big kudos to the organisers for setting this up, which allowed us to make the most of the conference.

For great visual summaries of the talks that took place, check out these wonderful sketch notes that were live drawn by Katja Budnikov, or this blog post by Mary Vorontsov for more detailed commentary of the talks in the main hall and another perspective of JSNation overall.

Alternatively, you can catch all of the talks using the following links:

Main Hall - https://youtu.be/Fj4Vm9m95Io

Node.js Hall - https://youtu.be/-rs-5ZL-f9w

Meeting new people

While attending a big conference like JSNation alone may seem scary, it definitely was not the case, primarily because the conference had a very active Slack channel and social media community, where I could reach out to other attendees who were in the same boat. Also, as cliché as it sounds, most people at the event were super friendly and opened to a good chat!

But above all, going alone meant that I had to go out of my comfort zone. Otherwise, I probably would not have:

Ended up hanging out with Anushree over lunch after we met from speaking with Kyle Simpson shortly after his inspiring keynote, talking about how awesome conferences are for the precise reasons I am writing about now;
Had a range of good conversations with Michel, Jarrod, Anushree and Henry over a stamppot dinner;

// Detect dark theme var iframe = document.getElementById('tweet-1137053464314490881-746'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1137053464314490881&theme=dark" }

Talked with Henry, Tobias and Ruben, all of whom I had great fun with hanging out over too many games of Codenames;

// Detect dark theme var iframe = document.getElementById('tweet-1137433650398748673-927'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1137433650398748673&theme=dark" }

Met Anna and Christina at the after party, telling them in person how much I enjoyed their talk made of Comic Sans slides packed with sketches of cinnamon buns and pets;

// Detect dark theme var iframe = document.getElementById('tweet-1137286696033300482-420'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1137286696033300482&theme=dark" }

Joined Robert, Oliver, Alexandra and Charlie for karaoke after party round three...

… and more people I spoke with that I’ve most likely forgotten. If we’ve spoken and you are reading this, feel free to ~~call me out~~ 😂 remind me on Twitter or leave a comment below!

The main point is, by stepping out of my comfort zone and start talking with someone I didn't know, the experience became so much more memorable and rewarding than if I had the choice and only talk with people I know. So, if you are thinking about coming to the next conference, don’t let having to attend alone put you off! And if you are attending with a group of colleagues, I highly recommend finding time to split up so you’ll be more inclined to meet new people and enrich your conference experience.

If dev.to would allow me to make this title larger than any first level headers in this post, I would, as this was undoubtedly the main highlight of JSNation for me!

Conferences are great for learning and getting new ideas from great speakers, but what makes them irreplaceable from just watching them on YouTube afterwards? It’s the people you get to meet, the in-person interactions, and that extra bit of humanity that you won’t get watching the event from afar.

Personal goals - how did I do?

Back in my previous React Amsterdam blog post, I mentioned that although I enjoyed the conference, I probably did not enjoy it as much due to some things I wish I had done. Generally, they served as good goals to enhance my experience for future conferences (like this one). So how did I do? Let’s review them:

Take selfies/pictures with people I met - admittedly not all out of my own effort, but I managed both - see the tweets in “Meeting new people” section!
Talk with speakers after their talk - once again, the pictures showed solid proof of that as most of them I talked with turned out to be speakers in the conference! This really shows how open and welcoming everyone was, such that I could walk up and talk with someone without having to think about whether they were a speaker or not. After all, speakers are just another human like us, so this should be no surprise!
Attend a pre-conference workshop - this one is tricky as an independent attendee, as I couldn’t quite afford some of the sessions outside of the conference both in terms of cost and time off from work. 😞 Perhaps this might be something I can do if diversity scholarships can help out with this in future.

Overall, I am happy with the progress I made since the last one, and will certainly take this new found courage to future conferences I attend.

Ideas for the next one

Whilst no definite dates have been confirmed yet, JSNation will be back with GitNation for its 10th year in 2020, after hearing the organisers asking for suggestions for the next one during the conference.

Personally, here are some ideas I have to make the conference even more awesome and inclusive:

A dedicated quiet zone

This could be a room like the one used this year for catching the Node.js talks. Since a large part of a conference involves talking with new people, some (especially the introverts amongst us) may wish to take a break from the crowds to clear our heads, meditate and/or recharge ourselves. By meeting those needs too, the conference will undoubtedly be even more inclusive.

A gaming hangout area

Depending on if there are free space available, such a space may be made throughout the conference, or at least at the after-party, so we can socialise over some card games or a game of table tennis if speakers/attendees like Henry are around to bring them:

// Detect dark theme var iframe = document.getElementById('tweet-1137467443922788354-582'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1137467443922788354&theme=dark" }

On the higher end of the budget, provide a game console with well-known games like Mario Kart, or an interactive VR headset with games like those shown by David Rousset at this year’s after-party:

// Detect dark theme var iframe = document.getElementById('tweet-1137078511620018177-789'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1137078511620018177&theme=dark" }

And so on… the possibilities are endless. I’d love to see what others in the community and the organisers will come up with if this idea is feasible!

Live captioning

In other words, have live subtitles being played during the talks! This might be the most involved idea of all, as it’s likely going to need someone (or a team in rotation) to type out the subtitles, or correct those generated from speech recognition software in real-time. Based on my brief Twitter research, this seemed to have worked well in ReactJS Girls:

// Detect dark theme var iframe = document.getElementById('tweet-1124341502879125504-424'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1124341502879125504&theme=dark" }

As with the quiet zone idea, this will greatly increase the conference’s accessibility for those who may not speak English as their native language, have hearing problems and/or for catching what the speaker said better in general.

Personally, I had a blast from learning less well-known features and how to fly some drones in Node.js to socialising with new people throughout the conference. Needless to say, I certainly hope I will be back for the next one to celebrate JSNation’s 10th birthday, and be spoiled with a similar experience again!

Five things I learnt from being a Code First: Girls instructor

Darren Vong — Tue, 11 Jun 2019 08:43:32 +0000

For someone who wasn’t overly active on social media at the time, I am still amazed by how I stumbled across this tweet, which is how it all started:

// Detect dark theme var iframe = document.getElementById('tweet-781867649227685888-412'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=781867649227685888&theme=dark" }

Fast forward to the time of writing, it has already been over two years since I’ve become a Code First: Girls (CF:G) instructor for their Python course in Sheffield!

A quick intro for those who haven’t heard of CF:G before: they are a not-for-profit social enterprise (in the UK and Ireland) which aims to encourage more women to pursue a career in tech and aiming to narrow the gender gap in the field overall. Currently, they have an ongoing goal of educating 20,000 women to code by 2020, and have just surpassed half of their goal at the time of writing!

For those who know me well in person, they know how much I love talking about my involvement with CF:G, and so this is really an overdue piece that I needed to write! As we approach the halfway point of 2019, it feels like a good time for me to reflect and share five things I learnt since becoming an instructor.

1. Instant feedback is important

Have you ever attended any courses where they ask for constructive feedback once you have completed it? Whilst end of course feedback is still extremely valuable for improving the course the next time it is being run, those improvements won’t be beneficial for those taking the course!

To ensure the students on the course can get the best experience out of the course, our instructor team took a more proactive approach to get feedback. At the start of each session, we hand out red and green post-it notes to everyone. Throughout the session, the students can then stick a red post-it at the back of their laptop to indicate they need help with the content just covered, or a green post-it to say that they are happy with everything so far.

This worked really well as it gave us clear, visual feedback on exactly who needs help, as well as a general indication as to whether we are going through things at the right pace.

At the end of the session, we then asked the students to leave one thing they enjoyed and/or thought we did well during the session on the green post-it, and one thing we could have done better on the red post-it. By doing this, we were essentially getting a mini end of course feedback, and so could promptly improve on things we did not do well in the next session. This meant both the current students and future cohorts get to benefit from the improvements, so it was a double-win!

Instant feedback with post-it notes.

2. Teach with a beginner’s mindset

As a developer myself, I have to admit that often we tend to talk about things in some language bubble that we automatically assume everyone else will understand.

Breaking down an explanation of technical concepts full of jargons to something lower level is an essential skill to ensure the course content is accessible to everyone. For me, it has certainly not been an easy process, but by doing so, it has helped consolidate my own understanding of coding fundamentals that I thought I knew well at first. After all, if I could not explain them in layman’s terms, I probably did not understand the concept well enough.

Let me give you an example. Suppose that a student had the following piece of (highly contrived) Python code, and asked: “why is it not printing anything in the command line?”

def print_message(message):
    print(message)

print_message

One potential explanation we could give would be: “Oh, that’s because you aren’t invoking the function. You’ll have to do that with a string argument before you can see anything!”

Beginner me:

Although that makes enough sense to me, having been a developer for a while, I can guarantee that to some beginners, that sounded like a lot of gibberish.

A good way I found to break down an explanation is to take a step back and look at how many technical words I’d be using in my first explanation attempt. Then, go through each of these words, and think about the following:

Are there simpler alternatives that roughly means the same thing? Replace it with that and repeat the process two to three times.
Is the explanation full of acronyms? Spell them out in full, and explain what they are!
Is this word really needed for the explanation in the first place? Remove it if not.

For the last point above - in written explanations, words like “obvious”, “simple” and “trivial” are rarely needed and should be removed. I find them patronising and off-putting for beginners. It achieves nothing apart from making some students feel stupid for not getting it the first time around, which is not the atmosphere we want to promote.

P.S. If you are interested in my beginner-friendly explanation for the given example, let me know in the comments!

3. Talk with the students in class

In sessions where I was not delivering content at the front, I found it helpful going around and talking with the students to gauge how well everyone is understanding the content.

Talking with the students also ensures those who are shy to speak up gets help too! You may be surprised to hear that, almost every time, when I asked the students if they need help, they will have a question about what we are doing. It was particularly effective in sessions when we were covering trickier topics, since some students were so far behind that they were too focused on fixing their current problem and forgot we were around to help. Talking with them in this case really helped them catch up with the class.

In cases where they really don’t have any questions, it’s a good opportunity to connect with them and strike up a conversation anyway, which can be a nice ice-breaker away from the strict instructor-student relationship. I think this is important so they feel comfortable talking with us as a mentor or a friend, rather than the thought of talking to another awkward and scary lecturer they most likely had experienced with at university.

4. Start with the why’s before the how’s

To help the students build a deep understanding on how things work, from experience and past feedback, I found that it is much more intuitive to start with why we do certain things before jumping straight in on how to do something.

Me trying to explain why relative URLs are used in web frameworks.

Since we only had realistically six weeks in the Python course, for beginners, at times it can feel like a big mishmash of topics being taught! In particular, since the course is aimed at those from non-technical backgrounds, the topics taught will take time for them to sink in. During that sinking in process, it is easy for them to forget things taught in previous sessions.

By starting with the why’s when introducing a new concept, and using the explanation to link back to concepts taught in previous sessions, it will help the students see the bigger picture and build a better mental model on how everything taught so far work together. This will then help them retain the concepts and apply them more effectively to their course project.

5. Follow up after the session

No matter how good our delivery was in class, from experience, not everyone would have understood everything at the time, especially when the topics covered start to move away from the basics. Sometimes, perhaps the explanations I gave could have been better, and that’s where following up after a session can help to clarify.

At other times, the topics covered were just too much for some to click straight away in the session, since we all learn at a different pace. The students hit the they-don’t-know-what-they-don’t-know phase to ask you any questions in the session. In those cases, based on past feedback, the students have found that following up with a mini, brain-teaser exercise halfway between two sessions have helped them understand what was taught better.

Personally, due to the limited time we have in class, I also like to slip in small things they may not have seen in class before in these brain-teasers, so they get to learn new ways of doing things too.

Do you have any other tips on teaching others how to code? If becoming a CF:G instructor sounds interesting to you after reading this post, and/or if there is anything else that I’ve learnt after being an instructor you’d like to know, let me know in the comments!

Will you take a paycut for a supportive work environment?

Darren Vong — Tue, 28 May 2019 00:18:14 +0000

It is not uncommon nowadays for jobs in tech to come with full of perks and benefits. But, the main one I don't see enough discussions about (and is sadly seen as a taboo): pay/salary.

To add to the question in the title, a supportive environment can be:

One where you feel comfortable asking for help;
One where they invest in you to improve yourself by allowing you to go on training courses and conferences;
One where you feel comfortable voicing your opinion and it really counts;
One with flexible working hours and where working over time is not expected/the norm

And as a follow-up to the main question, how much of a paycut (5% from your current pay? 10%?) are you willing to take before it is too much of a sacrifice?

Follow-up 2 to the main question - since it can be hard to determine if a new work place will be supportive, although often there are telling signs during the interview. The bottom line is, they are paying more; will you take the offer even though your current work environment is supportive? In other words, by staying, you are effectively taking the paycut. Or vice versa!

In an attempt to get more points of views, I also shared this on Twitter (where some of you may have found this 😊) and encouraged discussions on there. You can find some of the responses in the following tweet thread:
Liquid error: internal