DEV Community: Annie 🦄⚡

BenQ Screenbar Monitor Lights Review: Standard vs Plus vs a generic brand

Annie 🦄⚡ — Mon, 27 Jun 2022 03:01:39 +0000

As more and more people spend an increasing amount of time in front of the screen, reducing eyestrain can have a huge impact on comfort and productivity levels. Having suitable lighting is one way to achieve this your room might be bright but brightening the inevitable "shadowy areas" on your desk can make a big difference.

Cue, the screenbar. I've been using one for a while since my job went remote in 2020. What's a screenbar? Essentially, it's a desk lamp that clamps to your monitor, providing uniform lighting on your desk and reducing the glare you can get with traditional lamps.

Look at the difference a bit of extra light makes:

When BenQ approached me to test out two of their popular screenbar models the standard Screenbar and the Screenbar Plus, I jumped at the chance. The reason I even have a screenbar was because of these premium models.

Up till then, I was using the Quntis Laptop Monitor Lamp, which I bought in October 2020 for CAD$42.99. In comparison, the BenQ Standard Screenbar retails for about CAD$179.47, and the Plus model at CAD$200.

I tested the BenQ models for about two weeks each, and here are my thoughts.

Attachment to Monitor

Let's start with how the screenbars clamp onto the monitor.

Hands down BenQ's attachment is way more usable than Quntis'. It's very solid and has a really nice weight. You literally just put it on top of your screen and it balances perfectly.

In contrast, the Quntis clamp is less weighted and has tape to stick it to the back of the monitor. The whole attachment is just much less smooth and requires more manual finesse. The parts are definitely more "plasticky", making it feel easier to snap or accidentally break something.

Rotating the light bar to adjust where the light shines on the desk is also much easier with the BenQ than the Quntis.

Light adjustment controls

The Quntis Laptop Monitor Lamp has an attachment on the wire that plugs into the USB. Although this control wasn't the most aesthetically beautiful, it was small and practical. I found it easy to turn on/off and adjust the brightness or temperature levels.

For the BenQ lamps, the standard Screenbar has the controls built into the bar, while the Plus model has a separate dial attachment. This is the main difference between the two models.

The touch buttons on the standard screenbar are responsive but in order to adjust brightness/temperature, you have to long-press on the button. I found this a bit fidgety and not the most intuitive. It was a little difficult to have fine control. As a result, once I settled on a temperature and brightness level I was happy with for the majority of my work, I rarely adjusted them.

On the other hand, with the Screenbar Plus, you can control these settings very easily by selecting which option you want to adjust and subsequently rotating the knob. This way, you can go up or down instead of the linear one-way adjustment of the standard version.

The BenQ also features auto-adjustment/dimmer but I didn't really use this so can't comment on it.

Brightness and Temperature

An advantage screenbars have over most traditional desk lamps is that not only can you adjust brightness (something not available on all desk lamps), but also colour temperature. This is useful depending on what time of day you're working. I usually want cooler temperature during the day and warmer towards the evening, matching the natural ambient lightning.

The Quntis Laptop Monitor Lamp has 10 levels of brightness and three colour temperatures warm (3000k), natural (4000k) and cool (6500k).

By contrast, the BenQ Screenbars have much greater adjustment abilities. There are 14 brightness levels and eight colour temperatures, ranging from 2700k-6500k.

The difference in brightness levels between the two brands wasn't significant to me. During the day, I had them both at maximum brightness and they were both good.

However, I definitely noticed a difference in being able to adjust the temperature levels. The eight levels that BenQ provides are more than double that of Quntis's three. Practically speaking, three levels were usually enough in my day-to-day. However, I really appreciated the finer control BenQ provided when doing video calls, especially for conference talks.

Both brands of screenbars provided uniform lighting on my desk and there wasn't much difference in terms of coverage.

Build quality and design

BenQ's screenbars are incredibly well built. The aluminium alloy is a really classy finish and feels premium. The clamps are a very solid weight and unlike my Quntis, doesn't feel like they'll break easily during transportation. The chord is also thicker with a less fragile USB connector.

My Quntis screenbar just can't compare in terms of the pure beauty of the product design. It's like comparing the iconic Chemex pour-over carafe (displayed in The Museum of Modern Art) to a generic copy-cat brand. The designer in me is still fangirling over the how beautiful the BenQ screenbars are. Honestly, I spend so much of my time working, it pleases me to have something that not only works so well, but is also aesthetically pleasing.

After one month of testing

I started using the Screenbar Standard first. At first, because I had gotten so used to Quntis's adjustment control being at my fingertips, I thought I would prefer the BenQ Screenbar Plus.

However, after a couple of weeks of using the standard model, I found that it was no issue to stand and turn off the light. In fact, I prefer the light touch of the bar, compared to the more tactile dial of the Plus. This was quite a surprise for me. I also didn't mind being forced to stand up because I tend to get into a habit of just sitting.

Overall though, I prefer the adjustment capabilities of the dial so I'll be sticking to using the Plus version.

BenQ has a new model out the Screenbar Halo. it doesn't have any wires and the controls look more touch-friendly, similar to the standard version I like. Perhaps one day I'll be able to upgrade to this version!

My recommendation

I absolutely love using a screenbar/monitor lamp over a traditional one. It saves me valuable desk real estate, allows me to work more comfortably and is so easy to use. In fact, I'd go so far as to say I can never go back to working without one!

But do you need the premium BenQ model? Probably not. There are much cheaper generic brands out there, and you'll get the same benefits. Many now also have the same mechanism as the BenQ screenbars for attaching to your monitor, unlike my old Quntis one which was a bit of a hassle if I needed to make adjustments or move my monitor.

However, if you value the brand, quality and look and feel of the BenQ models, providing you have the budget, I can definitely recommend them. They will elevate any desk setup and sometimes it's really nice to invest in a few key items that can make a big difference in your life. I never work without turning on my screenbar!

3 Beginner Project Ideas to Get Started on your Front-End Portfolio NOW

Annie 🦄⚡ — Sun, 06 Mar 2022 21:40:16 +0000

You've heard it over and over again. Building projects is the BEST (and perhaps only) way to improve your skills, learn the learns and eventually land that highly coveted job in tech.

There are many articles out there with numerous project ideas, and they're all great and useful. However, sometimes getting so many thrown at you leads to analysis-paralysis, and you don't end up doing any of them.

I graduated from a front-end bootcamp 2.5years ago and here are three projects I've personally built that have helped me land my first job and get to where I am today: Front-end Engineering Lead at a B2B SaaS startup. Each project builds on the former so make sure you have a grasp of the concepts and skills there before moving on to the next one. This article has been packed full of tips and resources to get you on your way! 💡

Read on and let's get started.

The Three Projects

1. Fully responsive design to website

This is a great way to demonstrate your semantic HTML and perhaps use of a CSS pre-processor such as SCSS. You can get free photoshop designs from sites like Freebiesbug or Speckyboy.

Here is an example of a static design I worked on during my part-time Web Development class. My school bought the design and we were given a flat jpg of the layout and all the necessary assets (such as HEX colour codes and images).

🔗 See my implementation of the Cronus business website here.

As you're building out your user interface, think about things like accessibility, responsiveness and possibly delightful touches like transitions and animation.

As an accessibility note on animation, check out the prefers-reduced-motion CSS media query. It's an overlooked but important way you can consider users who experience symptoms like nausea, dizziness, and malaise when there's too much motion and animation.

Concepts to learn include the box model, semantic HTML, reusable styles and utility classes, and naming conventions (such as BEM). Explore ways of positioning elements through flex-box, absolute/relative positioning, margins and grid. Float still exists and it's good to know but you'll rarely touch it in modern web development. Here's also your chance to try Emmet as you're writing HTML.

Here's a quick analogy to help with the box model. (I had trouble distinguishing between margin and padding when I first started):

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

I like building my interfaces mobile-first. As blocks, the content stack on top of each other and I can add CSS to flex them as the layout expands to desktop. I find this helps me write less code and subsequently, fewer bugs. Knowing how to write CSS well will save you headaches in debugging.

Speaking of debugging CSS, this is one of my most-used browser extensions:

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

Before coding a full-blown layout, you can start by building out smaller user interfaces, such as the Twitter login form or the UI of an app you like. This is an incredible way to get comfortable with and focus on the concepts mentioned above. You'll learn how to write good clean code and styles that cascade correctly. As you progress, you'll be able to scaffold interfaces faster and more intuitively.

This was how I got started.

⚡️ Bonus Exercise!

Take a page or two from a magazine and attempt to recreate the layout through code. Some magazines can be very creative and you can use Google Fonts and images from Unsplash to match as closely as you can. Use Lorem Ipsum (or a similar dummy text generator) so you don't have to type out all the text. You can also automatically insert Lorem Ipsum using Emmet.

2. A JavaScript game

For my VERY first JavaScript project, I made this simple quiz below. JavaScript was so confusing for me, jumping into something difficult for my first solo project would probably have made me quit.

Your New Best Forest Friend🔗 Play "Your New Best Forest Friend" here

Your game doesn't have to be super complex, but something that demonstrates logical thinking is an excellent way to get you thinking like a programmer. You'll learn how to structure and componentize your code, DOM manipulation, render different parts of your game and work with programming functions like loops, if-else statements etc.

As much as possible, try to build it yourself without following a tutorial. Refer to docs or articles when you need to figure out how to solve something. Challenging yourself will really help build your problem-solving skills. Write pseudo-code to break down the game logic into small steps and work through solving each part step-by-step.

For example, this is my actual pseudo-code for my quiz. These days, my pseudo-code might look a bit different but I started like this:

/* Pseudo Code:
1. User clicks on “Let’s Get Started” button
2. Page scrolls down to the first question.
3. User selects answer.
4. Icon next to answer changes colour to show it’s been selected.
5. User clicks on “Next” button.
6. Page scrolls down to next question.
7. If nothing has been selected, error output “Please pick an answer!”
8. Repeat steps 3 - 7.
9. User clicks “Meet my new best friend!”
10. If user has scrolled down without selecting an answer somewhere and clicks on this button, error output “Please answer all the questions to find your new friend.” (Put required = true)
11. Page scrolls down to show new friend, dynamically.
12. Button underneath to re - start(clears all fields, back to top of page): “I want a new forest friend”
Logic Notes:
- Use.filter, .attr and.map to grab animals with correct name class.
- Function to say that if .bear.length > .rabbit return .bear
  - If class A.length === class.B.length return random
  */

Here are a couple of other games that I've made:

Dragons vs Unicorns🔗 Play "Dragons vs Unicorns" here

Word Wiz🔗 Play "Word Wiz" here - This was a pair-programming project and used an API, which you can read about further down.

⚡️ Game App Ideas

Tic-tac-toe
Hangman
Random compliment generator
Memory games

Pick one, any one, find a theme and run with it!

3. Something using an API

In your development career, you'll almost for sure be working with APIs (Application Programming Interface), unless you're in a very front of the front-end role.

There are a lot of public APIs out there, all differing in quality, documentation, and organization. To get started, I recommend working with RESTful APIs. REST(representational state transfer) is a set of organizational principles companies follow to build their APIs. The rules of architectural styles make developers' lives much easier.

⚡️ 10 Beginner-friendly APIs

The Official Joke API - Get a random joke or 10. You can also sort them by types!
Where the ISS at? API - Track the location of the International Space Station.
Poké API - A great one for all the Pokemon fans!
Numbers API - Learn interesting facts and trivia about numbers.
Datamuse API - A word-finding query engine, useful for rhymes and synonyms.
Shibes Online API - Returns random pics of shibe dogs, cats or birds!
The Dummy API - Provides fake user data including photos, comments and posts.
Weather API - Your one-stop shop for making a weather app.
Dictionary API - Get word definitions, etymologies, audio pronunciations, synonyms, antonyms and more.
Open Trivia API - A range of trivia questions across different categories and difficulty levels.

Have a look through the API documentation and think about how the data can be displayed. For example, if you're using the very popular, well-documented Poké API, you could build an app to search for and display Pokemon. Don't forget to think about how to handle errors- for example, if the user inputs wrong information or the API fails to return the data you're expecting.

As for me, in addition to the Word Wiz game you saw above, which uses the Datamuse API, I made a steampunk-themed newspaper generator, which gets data from the Numbers API.

The Absolutely Amazing Newspaper Apparatus!🔗 Get your customised newspaper here

While working with APIs, remember a few things:

Often you'll need to sign up for a developer account that will provide you with an API key.
You might need to register your app so they can confirm it's for non-commercial use.
There will most likely be restrictions on the queries allowed per day. If it's super limited, a trick is to save the data you get back in a file and hit that up instead while you're developing your app.

Here's a tip to keep your sanity while working with APIs:

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

4. BONUS! A CRUD application

NOTE: Although I built some CRUD applications as exercises, I ultimately didn't end up adding one for my front-end portfolio. So that's why this is a bonus fourth project!

CRUD stands for Create, Read, Update, and Delete. It's an acronym referring to the four functions considered necessary when working with databases. For this one, I'm going to recommend a To-Do app or some variation of it. One of the smartest developers I knew built a To-Do App for every new technology he was learning to get comfortable with the syntax.

A To-Do app sounds pretty boring though, so think about one of your hobbies or something you like and personalise it. For example, one of my friends is a drummer so his to-do app was a list of band equipment to remember when they go on tour. Another friend created a place where you can write your wishes on balloons that floated into the sky.

Your app should be able to do these four things:

CREATE a new entry - ie. add a new person
READ entries - ie. get a person's information from the database and display it on the UI
UPDATE the entry - ie. update the person's birthday
DELETE the entry - ie. delete the person

By the way, CRUD applications also use APIs. In fact, each letter of CRUD maps perfectly to an HTTP protocol method:

Operation		HTTP Protocol
Create	→	Post
Read	→	Get
Update	→	Put
Delete	→	Delete

Don't want to do a To-Do app? That's perfectly fine!

⚡️ 6 CRUD App Ideas:

Recipe app
Event/people management app
Bookclub or library app
Inventory system
Cinema/movie list
Online store

To get started with simple database storage, you can use Firebase for free.

⚡️ Bonus Tip!

For all your projects, get feedback on your code from someone more experienced. This is an incredible growth hack to improve your coding skills faster.

To Summarise

Today you learned three (+ a bonus fourth) project ideas for a front-end portfolio. These utilise a range of skills necessary in a front-end developer position:

Fully responsive design to website
A game with logic
Something using an API
A CRUD application (BONUS)

If you've built all of these, congratulations - you should come out the other end knowing HTML, CSS, JavaScript, how to work with APIs and a JavaScript framework, like React.

If it seems overwhelming, don't stress. Remember we all start from the same place; with zero experience. Take it a step at a time and focus on solving the problem immediately in front of you. The rest will fall into place as you progress. As they say, the best way to eat an elephant is one bite at a time!

For other portfolio tips, check out my Hashnode Talk on "Building an Effective Developer Portfolio". Feel free to ask any questions or drop your comments below. I read everything and I'll definitely get back to you. Good luck and have fun!! 🎉

Feeling social? Follow me on Twitter where I share tips, resources, and my coding journey!

Why I Turned Down a Six-Figure Salary in Big Tech to Stay at a Five-Person Startup

Annie 🦄⚡ — Tue, 28 Dec 2021 23:24:25 +0000

On paper, it was the dream job. Hell, it would have been the most "adult" job I'd ever had in my life so far. Stocks, bonuses, incredible benefits, prestige and an incredible all-remote team. It would absolutely sky-rocket my career; the name on my resume would open doors, opportunities and a path to further success. I would never have to worry about how to pay my bills again.

It took me six interviews and a take-home project to get this offer. So why did I decline it?

To turn down a role like this was no small decision, especially considering the financial implications. Personal anecdotes from others helped me to make my decision and I wanted to share my story and process too.

How it started

Who am I?

Hi, I'm Annie. I'm an Australian multi-disciplinary designer who graduated from a Canadian front-end development bootcamp in July 2019. I was also an English instructor in Japan, among a variety of other random jobs.

My first developer job out of bootcamp was at a small WordPress VIP agency, where I worked for a little over a year. I then moved to a B2B SaaS startup, Pastel, as their first hire in October 2020. (I'm currently the Front-end Engineering Lead here.) In July 2021, I got an offer from one of the world's biggest and loved tech firms.

It's been a wild journey.

That email

It's May 2021. I've just received an email from the manager of a large tech company, asking if I was interested in a developer advocacy position on their growing team.

I instantly think they've made a mistake.

Clearly, they didn't mean to email me. After the initial shock, I realise they've taken the time to fill out the form on my website. Slowly it dawned on me that yes, they did mean me.

At this point, I barely knew what developer advocacy was, but I was curious about it. They had found me through Twitter and the role sounded like it would involve a lot of the things I was already doing on the side. I mean, who wouldn't want to get paid for the things they do in their free time, right?

However, I was really happy in my new job and was initially going to turn down the chance to interview. I shared the news with a good friend, an experienced senior engineer I trusted. Long story short, he yelled at me in all-caps and reminded me to, "always be interviewing".

And that's how it started.

Deep-diving into Developer Advocacy

Over the next couple of months, I did my due diligence researching everything I could on developer advocacy/relations. I was keen to understand the role and what it would involve. I read many articles, including this very helpful Q&A with Angie Jones, a Senior Director of Developer Relations.

I was extremely fortunate to be able to reach out to current developer advocates through Twitter and my wider connections. I sought opinions from people with years of experience in the role. On calls and through messages, they shared growth ladders, salaries, experiences, expectations and the pros and cons of the position.

I scribbled notes on random pieces of paper and soaked it all in, trying to build an all-round picture of what my day to day might look like, both in the role itself and at the particular company in question.

The interview process

The first thing I did after talking to my friend was to schedule a casual call with the manager who had reached out. I got a good impression of what the team was trying to achieve and felt this was someone I could work well with.

I decided to proceed to the first formal step, which was speaking with the hiring manager. Here, I was given a high-level overview of the team and their current initiatives. It was a chance for me to ask more questions and get a feel for the people I'd be potentially working with. Afterwards, I had to sign an NDA before progressing any further, so I won't be going into any detailed specifics.

The next stage was a take-home project. I was given two weeks to put together a presentation for the company's Dev Rel team. I chose a couple of technologies and concepts, merged them together and added my own unique spin to teach and advocate for the platform.

I learned a lot for this presentation, as one of the platform's technologies I chose was completely new to me. To understand it better, I had to deep dive into several other concepts. Not someone to do things in half measures, I poured hours into this outside my full-time job — researching, content creation and presentation practice —and it paid off.

The presentation itself went amazing and was well-received. Surprisingly, I felt confident and had a lot of fun with it! I don't have much experience with public speaking, so this had been a concern of mine.

At this stage, I could choose to drop out of the rest of the interview process if I felt the role wouldn't be a good fit. However, it was at this point where it hit me - I really could do this developer advocate thing!

I decided to go all-in, and my final four interviews were scheduled for the beginning of July.

The offer

It took just over two months from when the manager first reached out on May 11, 2021, to when I got the formal written offer on July 14th, 2021. Suddenly, the decision was brought into sharp focus, and I had two weeks to sign or decline.

How I made my decision

Trust that either choice is a win-win

It was quite stressful to be in a situation where the choice I made would have a huge impact on my life over the next few years. I lost sleep and my appetite was non-existent for a couple of weeks while I agonised over it.

However, at the end of the day, I realized there really wasn't a bad choice. It all came down to which experiences I wanted to have.

When faced with tough choices, I always ask myself the question, "What would I regret less at the end of my life?" It might seem a bit extreme, but honestly, this question gives me big-picture clarity to decide what I want to do with the limited time I have on Earth. What meaningful experiences do I want to cultivate during this time?

If I chose to stay, I'd be able to dive deeper into software engineering, help grow and shape a small company, learn about and get involved in business and product growth decisions.

For a while now, my professional goal has been to become exceptional at front-end development, while building knowledge in the back-end and dev ops to supplement this. I was very excited about Pastel's company vision and direction, and I knew how I wanted to contribute to it. In a startup, things move fast. With my CTO, we had long planned out my growth trajectory there - the kind of responsibilities I would have, the things I would do and what that would look like.

If I chose to leave, I had the opportunity to be more visible in the community as someone from a non-traditional background, a person of colour and a woman. It would send a powerful message to others to know that this Big Tech company hires bootcamp grads and self-learners.

I would increase my breadth of skill as I learn about various tooling to share them with the wider community. Building my network and helping others get better at what they do would be part of my job. I would get better at presenting and be doing things similar to what I'd already been doing in my free time, but now with the support and formal backing of a large company behind me.

Know your values

Who do you want to be in a few years and what do you want to be doing? After the presentation, I knew I could do the developer advocacy role and do it well. Years of design work, teaching/mentoring experience and diverse overseas living would give me some particularly unique advantages here. Plus, as an extrovert, spending time with people is energizing for me and I love connecting with people and seeing them succeed.

Yet, when I thought deeply about my personal values, job stability, status and a desire for prestige isn't among them. These were some of the top benefits the new company offered. I crave novelty, I'm not risk-averse and at heart, I've always been a creator. I want to build cool shit with cool people and have fun along the way.

In a startup - especially one pretty early on - the things you do from one year to the next change. There is novelty here. It's easy to be swayed by big numbers but money itself has never been a singularly motivating factor for me throughout my life. I view it as a side effect of creating value. That's not to say I don't negotiate salaries or seek to improve my financial situation - I just see it as one factor in a larger holistic list of considerations.

Coming back to my core values helped me make my decision.

Content creation and creative work aren't new to me - I've had practice as a designer working on multiple projects. On the other hand, engineering is out of my comfort zone and doesn't come naturally. In life, choosing the harder things are often the most rewarding for your growth.

I also figured the offer wasn't enough to offset the loss of my engineering career capital. By switching into developer advocacy now, I would lose whatever momentum I was gaining by being in the trenches and repeatedly doing development work. At this stage, I wanted to focus on building depth of skill, as opposed to more breadth.

I also thought about impact and legacy. In a big company, you make a smaller impact on a greater number of people. In a small company, you make a greater impact on a smaller number of people. Neither one is better than the other - just different. The viable level of impact I'm able to have in a startup felt pretty meaningful to me.

For me, it ultimately came down to being a practitioner who occasionally teaches, versus a teacher who occasionally practices.

Side note: Shortly after I turned down the role, Kelly Vaughn tweeted this and it strongly resonated, making me feel like I had made the right decision.

Kelly Vaughn ☀️ kvlly.eth

@kvlly

It's taken me a long time to learn how to say no to potential opportunities that could be good for me career-wise but are not something I am truly interested in doing. The further into my career I go, the more I value my time.

14:17 PM - 19 Jul 2021

Don't let social clout cloud your decision-making

Having an online audience brings opportunities, but there's a cost to being in the public eye.

The developer advocate role is a fairly visible one, potentially requiring me to be more active on social media. I had not sought to "grow my Twitter following" when I first became more active on the platform and had concerns it might become difficult for me to untangle my sense of worth and value from the vanity metrics of social media. Not only that, I'm aware of the distractive impact of social media on deep work - something I value in my quest to get good at my craft.

At one point, when I seriously thought I was going to take the role, I had already imagined what sharing the news on Twitter would be like. Someone I knew had started a job at the company around this time and their profile had absolutely blown up as a result.

More than anything, something that played in my mind over and over again was sharing proof that big tech companies do hire bootcamp graduates and self-learners like myself. It felt like such an incredibly powerful message to get out into the world. It could change someone's life.

But at the end of the day, I had to do what felt right for me.

The grass isn't always greener on the other side

In conversation with a senior developer who worked at another big tech company, I realised what I had was rare and valuable.

At our startup, we barely had any company politics. With a lean team of only five people, Pastel currently has a very flat company hierarchy.

In a bigger company, many are vying for the kind of responsibility I currently have and struggling to be noticed by higher-ups. In another company, big decisions are made, signed off and passed down to be executed. Here, I'm an integral part of all roadmap plannings and product direction meetings. I have full freedom to handle and execute on the UI, UX and improve accessibility on the app. My voice and opinions are trusted and valued.

Second, to find a mentor who's deeply invested in your professional growth as an engineer, actively providing you with autonomy and responsibility, alongside a product you personally resonate with, isn't something you find every day. My CTO, as my professional mentor, has been coding since he was eight. He breezed through his computer science classes and turned down interviews with Google, Facebook, etc to work on his own thing.

True, in a few years, I could easily join another startup if I decide to move away from developer advocacy… but right now, I'm working on a product that lies at the intersection of design and development, much like my experiences as a designer/developer. Pastel speaks to me; it's a product I can get behind and it personally solves a pain point I've experienced myself.

Do your homework

As mentioned earlier, while trying to make up my mind, I reached out and spoke to a lot of people. Being in the middle of this seemingly momentous career decision, I knew there would be blind spots and biases I wasn't aware of. I wanted to make sure I had as much information as possible to make an informed decision that was right for me.

I spoke to numerous developer advocates to ask about their work and day-to-day. I spoke to people who worked at the company who made the offer. I spoke to people who had been in similar situations and asked how they came to their various decisions. I researched the new role heavily and by the end, I knew a lot about a path that had not previously been on my radar.

A notable point came out from one particular conversation with a very senior engineer, who had been a developer advocate for a while. While in that role, he would give talks at conferences and there would be people doubting his experience because he didn't have "engineer" in his current title. To give context, he's a white male who was fairly senior at that point. It gave me pause as to what people would think of me - female and without years of technical experience or a Computer Science degree.

Developer Advocacy is still a fairly new role in tech, and one of its hiccups is unfortunately people sometimes think advocates aren't as technically able as full-time developers or engineers. This is not correct. Those who do this work need to have technical ability, plus a range of other skillsets beyond that. Over time, I'm hopeful this mindset will gradually change.

Risk mitigation

Edit (Dec 29, 2021): Adding this section on risk mitigation, as a few folks were worried I'm getting paid peanuts or making a bad decision.

As with everything in life, whether you do one thing or another, there's some form of risk. These were factors I considered that reduced my risk of staying at a startup.

1. Counter Offer

Before you think crazy numbers, it must be stated that location plays a factor and I live in Canada, not America. There's universal health care here and salaries are lower than the American numbers you often see flaunted all over the internet. American tech companies have location-based salaries. To be transparent, while my offer was six figures in Canadian dollars, when converted to American, it would be five. Such is life.

If I was only making ~$55k CAD a year (the median salary of graduates from my bootcamp), leaving would have been a no-brainer. As it was, Pastel made a compelling counter-offer (which I negotiated) and this decreased the compensation gap between the two options. Hey, I'm all for building financial security in your life.

Many startups rely on investor funding without a market-proven product. Pastel is bootstrapped, runs on a subscription model, profitable before I started and growing. This decreased the financial risk of the company going bankrupt and me losing my job.

Additionally, while my title is still that of a developer, I negotiated the ability to dedicate 30% of my time doing developer advocacy work, should I choose to. I felt this was an interesting and calculated way to dip my toes into this world, beyond my side projects.

2. Long Term Game

If this was a straight choice between doing engineering at Company A vs Company B, the decision might have been easier. However, this wasn't a simple corporate vs startup decision. It was also a decision of the type of career path you want: Software Development vs Developer Advocacy.

You can absolutely build an incredible career through advocacy work. I know this through my research and those I see in the field. But this is also true for Engineering. Given that, when I compare the two career paths, truthfully I feel more excited about building depth in development than I do about organising and giving talks on it.

In his book, "So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love", Cal Newport shared an interesting idea; Control is one of the most powerful traits you can acquire when creating work you love. In order to keep that, sometimes you might have to say no to a raise.

What is the end goal here? To find work you love? Or to get a company name on your resume?

I also mentioned this briefly before, but it's worth reinstating; Beyond engineering, I want to learn about building and managing a business. At a startup, I'm on the ground shaping company culture, advocating for better product decisions, and possibly doing future hiring. I have greater say on how the company can make an impact in the world.

The learnings I'm acquiring in this process is no small thing and is worth a lot to me. I'll be able to take these skills, lessons and knowledge into my next role.

3. Professional Network

It's not a myth that people often get jobs through their network. Be it through a friend's friend, a referral or something else, many a job has been secured via a connection. Had I felt less confident about this aspect of my life, the company name on my resume would hold much greater sway over my decision.

As it is, over the past two years, I've slowly cultivated authentic industry connections I trust and value. Not for the purpose of getting work, but simply because I'm curious about who they are and the myriad of interesting things they're doing in the world. And yes, some of these good people work at FAANG and other big tech companies that shape much of our world.

When the time is right and if I'm no longer professionally challenged in my role, I'll think about my next move. Who knows, maybe full developer advocacy will be on the books.

Listen to everyone's advice... and ignore most of it

At the end of the day, your journey is your own. Oftentimes, you have a more nuanced picture of your particular situation than others. Do your due diligence but follow your gut and decide how your life plays out. Your values, needs and desires are different from others. Own your journey, and don't let others tell you what you should do.

About 90% of people I spoke to advised me to take the position- it wasn't easy to go against the grain and do the opposite.

Yet, only you can decide who you want to be.

Final thoughts

Ultimately, this was an incredible opportunity. But it just wasn't my opportunity. Through this whole process of trying to figure out whether to stay or go, when I finally made my decision, it felt right for me. It was a very intentional decision.

I very clearly understood what I was giving up by declining the offer. In many ways, it gave me a stronger sense of purpose, confidence and energy with the current path I'd chosen.

Do I feel sad about turning it down? Of course! It's hard not to. The people I met throughout the process were all extremely kind and welcoming. I could imagine how much fun it would be to work with them. I'm grateful to have had this experience and the learnings I took away from it.

It's not easy but I'm excited about getting better at engineering. At Pastel, things are still tough right now, but the deep work I'd be doing over the next year or so to consolidate the skills I'm struggling with, are going to compound. In a year or more, I'll have greater breadth and depth of knowledge to build, grow and shape a company and product. This is incredibly energizing for me.

Watch this space.

I want to personally say the biggest thank you to everyone who was there throughout this journey with me. Thank you for your support, for taking the time to listen, weigh-in and consider options with me. I am beyond grateful you made time for me. You know who you are and I deeply appreciate you.

10 Lessons to Help you Excel in your Developer Career

Annie 🦄⚡ — Fri, 02 Jul 2021 00:22:39 +0000

On July 15th, 2020, I celebrated my one year anniversary as an employed Front-End Developer. Reflecting on the process of getting here, there were things I had learned that I felt were important for me to remember. I spoke about these at a talk for Developer Student Clubs GITA and am finally writing them down in an article for posterity!

Some Background and Context

My name is Annie and I transitioned largely from a design and teaching background into web development. The information and insights I'm presenting here are specific to my experience in a fast-paced agency environment, where I worked on multiple projects.

From July 15th, 2019 to September 25th, 2020, I contributed to 23 different projects, including architecting the entire font-end of several websites from scratch. I'm now in my second job at a SaaS(Software as a Service) start-up, but the lessons I'm writing about here are based on my specific experiences from a web-development bootcamp and in this agency environment, as well as many conversations with other developers throughout this time period.

Without further ado, let's jump in.

The Ten Lessons

1. You don't have to remember everything

When I first started learning JavaScript, to say it was stressful would be an understatement. For some reason, I got it in my head that after a couple of times of seeing a function, a method, whatever, I should somehow just automatically know it. I don't know where I got this idea from, and it was frustrating to me that I was struggling so hard to understand things, let alone memorise them.

What I've since realised is: I'm not an encyclopedia. I don't need to hold all of the various JavaScript functions and methods in my head.

Our job as developers is to solve problems and to have an understanding of the tools we have at our disposal to do this. That's why we have documentation, Stack Overflow and Google. Even though I know how to use flex-box, I still find myself googling the exact syntax from time to time. There's no shame in taking advantage of the years of science and innovation that is the internet and drawing from it.

Many experienced developers have told me that they still Google things. The difference is they're much better at knowing what to google for.

🐬🍊 William J. Ghelfi

@trumbitta

@anniebombanie_ 20yrs career, I Google like there’s no tomorrow.
Difference with a junior? I know what to Google for 😆

18:21 PM - 05 May 2020

And that brings me to my next lesson:

2. Normalise failure & struggle as part of the process

Learning is hard. Struggle and failure is an intrinsic part of that process. You're not bad at something — you're just new at it. You need practice. Learning and growing happen when you push yourself beyond your comfort zone and expose yourself to new ideas.

In your comfort zone, you're safe with the things you already know. But safe might also mean S taying A verage F or E ver. I view that feeling of struggle when working through something difficult as your brain literally forming new synaptic connections.

I remember the first time I did that infamous Fizz Buzz challenge.

It was maybe my first or second day learning JavaScript at bootcamp. Things had started out well that day. But at some point, there was so much new information being presented that my brain was unable to take anymore in. When we had to work together with a partner to do practice exercises, I couldn't understand what "remainder" meant.

Unfortunately, my partner wasn't explaining it in a way that made sense to me. So I just sat there feeling dumber and dumber, thinking everyone else was understanding everything except me. I panicked at this point, to be honest. I had to leave to go to the washroom because I was so overwhelmed.

Yes, I can literally tell you that JavaScript has indeed made me cry.

Fast forward to months later, when I was going over the fundamentals again. I managed to do FizzBuzz in 5 minutes and it felt easy. (Later, I also found out that I wasn't the only person in class struggling through this lesson.)

The struggle rewires your brain. So try not to give up when it gets difficult. Failure is temporary unless you make it permanent. FAIL is your F irst A ttempt I n L earning. (And maybe your 2nd, 3rd, 10th... it doesn't matter.)

A little hack I like to use when I'm struggling is to add the word YET to the end of my internal doubts.

Annie🦄⚡

@anniebombanie_

Learn to add "yet" to your internal doubts.

I can't do this... yet.
I don't understand that... yet.
I'm not good at JavaScript... yet.

12:07 PM - 11 Jan 2021

Programming is a language and much like learning French, Japanese or Spanish, language fluency comes from constant use and repetition. The grind may be hard, but it's worth holding out for those feelings of, "I got it!".

Use those rewarding moments to keep you going.

3. Learn industry best practices and avoid hustle code when possible

On the topic of learning, I really advocate working towards industry best practices. You might have to write lots of bad code before it's good, but best practices are there for a reason - having consistent patterns, such as naming conventions, makes more code more readable and helps other developers. For example, generally when I see a function starting with is, can, will, I usually expect a boolean. Such as isLoggedIn = true. Or canEditDocument = false.

There may be many different best practices, depending on the specifics of the work you’re doing. Explore them and choose the ones the resonates best with you, but be open to what's used at your workplace. Best practices help keep your code cleaner, more readable and reduce cognitive strain for those trying to read your code.

Along with best practices, is the idea of avoiding "hustle code" when you can.

Working at a small fast-paced agency, things always need to be completed three weeks ago. Fixing bugs resulting from messy code costs the company and client financially and also costs you time.

When I built my first full-fledged website, it was my fifth week on the job. I was the sole front-end developer for an entire large American publication e-commerce site that I had to architect and build from scratch. And I had just over three sprints to complete it.

Which is to say, I had to build the site in roughly 6.5 weeks.

But even with that extremely tight deadline, I knew the cost of bad code. I took my time at the start to really think about how to structure the site, organise directories, name classes logically… all the many small things that would eventually add up.

And I'm so proud to say that this project, having moved to a monthly support package, rarely had any front-end related bugs during the time I was there. Most of the tickets I did afterwards for this client involved building out new features or micro-sites.

My planning at the beginning was a huge time and cost-saver.

If you pick up and practice bad habits early on, it's much harder to unlearn and break them. It's easier to practice good habits initially and let the momentum you've built help you continue doing them.

4. Share your learning by teaching & mentoring others

Research has found over and over again that when you teach others, you have to work harder to process and understand the material, recall it more accurately and apply it more effectively.

Sharing what you learn publicly and mentoring others also helps you to establish a level of authority in your work. Even though I sometimes feel what I share online is "junior", I've had people reach out telling me that I come across as a lot more experienced. Doing this has also brought many opportunities for me.

There are many ways to share your learning with others — writing articles, giving talks and content creation on your platform of choice. If you prefer to be less public-facing, things like volunteering to mentor those less experienced than you, pair-programming with other developers or simply helping your friends fix bugs all contribute as well.

Troubleshooting other people's code exposes you to different ways of doing things and broadens your overall knowledge. There's a difference between understanding something and being able to communicate it technically, so teaching is a great way to help you get comfortable with this.

To end this section, here's an idea I really like thinking about: If you help someone learn and apply new knowledge, they make the internet look better, run smoother, perform better, and be more accessible. They're contributing to a better web. The world is a better place for this. You win, they win, the world wins.

Annie🦄⚡

@anniebombanie_

Sharing your knowledge & helping others is a Win-Win-Win IMHO

⭐ You Win:
You have to deeper understand your material in order to teach others

⭐ They Win:
They learn how to better their craft

⭐ The World Wins:
Together, we're contributing to a better web for all

12:33 PM - 14 Sep 2020

5. You DON'T need to be passionate and code every weekend to be a good developer

There's a myth in popular culture that you should be "passionate" at your work in order to be fulfilled. I don't agree with this, especially at the beginning. Once you let go of the idea that you must be passionate in order to start something, it's easier to just start. I find curiosity a more helpful ally in the quest to get good at your job and eventually, possibly, fall in love with what you do.

Passion is like this huge encompassing all-or-nothing fire. You either have it or you don't. But curiosity is small. It's dipping your toes into the water before you jump. It's just trying a thing. The risk feels less, and it's more nuanced.

To add, I believe passion can be cultivated with experience and getting better at your craft. I am definitely way more passionate about programming now than I was at the beginning.

I take this trying approach in writing code so I don't feel pressure to be right straight away. Sometimes my ex-coworker would ask, "Do you think this will work?" And I'll say, "I don't know. Let's try? We can always control-Z."

To get good at what you do, you need to put the time in. But brain surgeons don't perform operations and lawyers don't go to court on their days off. Your job doesn't have to be your hobby unless you want it to. Why is it that sometimes, we as developers, feel that our weekends must be continuously spent on learning and side-hustles?

Hustle culture is detrimental to your health. There's a wealth of evidence linking it to burnout, sleep problems and even death from overworking. People need rest. Rest improves your creativity and allow time for your brain to make important neural connections between what you're learning.

Have you ever noticed that often some of your best ideas often come in the shower or late at night? You may not be working but your brain is still doing its job in the background, and rest acts like a switch that allows this to happen.

I love what I do. But I don't do it every day. I don't need to get to the end of my days and think, "Yes, I have a solid green GitHub contribution chart! I can die happy now." No, your career can flourish without that, and the best well-rounded developers I know often do NOT have solid green charts.

Annie🦄⚡

@anniebombanie_

I'm at my computer SO MUCH & since Covid, I rarely leave home. As a result, my body can get really sore as I no longer cycle to work.

These past few days, I've been hiking the beautiful Bruce Trail, Tobermory.

Life isn't abt a solid green Github chart 😉

21:21 PM - 05 Sep 2020

6. Advocate for yourself & be proactive in your career

Here's a hard truth: NO ONE is ever going to be as invested in your own career as you are.

If you don't let others know about you, don't complain if no one finds you. If you don't put yourself out there, share your work, have a portfolio or talk to others, how do you expect people to find you and know the awesome work you do?

Maybe as both a female in tech and a person of colour, I find it hard to "promote" or "assert" myself. Pre-existing biases exist, and the industry is working hard to balance out the playing field. If I don't have a voice, then I'm not doing anything to support these efforts. Self-promotion is awkward, but I try to do it in the most authentic way I can that makes sense to me, while keeping the larger picture in my mind. You'll find your own way too, I'm sure.

If it's hard to advocate for yourself, think about how you'd encourage a friend and follow your own advice. Someone at a meet-up I once attended shared this great idea:

Keep a running list of all your accomplishments and achievements. Every Friday, set aside some time to reflect on what you've achieved and write them down. When it comes time to ask for a raise, you'll have a solid bank of evidence to back up your value.

As a note, being proactive doesn't have to be specifically tied to advancing your career, per se - it can be improving the environments you're in to benefit others.

At my agency, we didn't have office snacks, so I researched snack budgets from my bootcamp alumni network and presented the cost and benefits to the CEO. It was an easy yes, and I was then responsible for buying monthly snacks. This was great because while I got everyone's orders, it also meant I could buy healthy things like nori, coconut water, veggie chips and 90% dark chocolate!!

7. Comparing yourself to others is normal

We often hear the advice, "Don't compare yourself to others!" While this is true and well-intended, we can't help our instinctive reactions, and we also shouldn't deny them.

Fear, jealousy, and anger are all innate human reactions designed to keep us alive and strive to be better. It's what we do next that matters. We can choose to use them to empower or disempower ourselves.

When you see someone's work and feel jealous, acknowledge that the feeling is natural. It's because we feel lacking that we feel jealous. Irrespective of that lack, if we can still genuinely praise the person for their achievement, the negative loses its grip. Over time, it becomes easier and easier to do!

Physiologically, fear and excitement are the same. Both emotions arouse the same elevated heart rate, sweat, etc, but one is negative and the other positive. I sometimes think of jealousy and inspiration as opposite sides of the same coin. If you can flip the feeling of comparing yourself to someone to make you feel inspired that you can achieve something too, it's a hell of a lot better than feeling small and disheartened.

Life is easier if you compare your current self to your past self; not your start to someone else's path further down. Others might also have different privileges and circumstances that you don't have access to. You can acknowledge this and think, "Right, six months ago, what did I know and where was I? Ok, where am I now? What have I learned? Where am I in terms of my skills, my network, my finances, and my peace of mind?"

And it's ok if things seem to go backwards sometimes. Life isn't a linear straight line and part of the process is learning to navigate the dips.

To end this section, let's not forget our old friend; imposter syndrome.

When we see other people doing great work, it's easy to imagine that everyone is better than you. I spent my first 3–4 months at work feeling like someone else was doing the work through my fingers and that I was going to be "found out" and fired. It was the strangest out of body feeling.

But y'know what? Even senior devs have the same struggles. Remember, when you compare yourself to someone else, you're only seeing the surface of the work they're presenting. Deep down, we're all just trying to figure this out together. And really, imposter syndrome is a symptom of our growth.

Santiago

@svpino

Welcome imposter syndrome.

If you feel inadequate, it means you are stretching yourself and growing. You don't know how to do it yet, but you will.

(People who are working on easy, irrelevant things have no reason to doubt themselves.)

09:01 AM - 24 Jun 2021

8. Disconnect your sense of worth from your work

Don't take things personally. It's often just business. Being able to ask for and take constructive feedback is extremely beneficial to you becoming better at what you do.

One of the most valuable skills gained from my years of art and design schooling was learning how to give, seek and receive constructive feedback. Over and over again, all the work we did was presented for feedback. Through this process, we got better and better at our craft.

Recognise that critique on your work is NOT criticism on you as a person.

At my first developer review, a point of feedback I received was that I wasn't using the inspector enough to debug. At first, I was annoyed; I use it all the time! But then I thought about it and wondered, "Actually, how can I use it better? Hmmm... I could use it to do X, Y, Z as well!" Incorporating that feedback made me better at my job.

Feedback is a gift to your future self.

9. Understand the larger WHY of the problem you're trying to solve

We're (hopefully) not hired to just push out code. Businesses have larger goals and needs, and if you can put yourself in a position to understand them, you'll become a lot more valuable. Zoom out beyond the ticket you're trying to finish and think about WHAT problem you're trying to solve here and WHY it needs to be solved. What is the user's pain point?

For me personally, my job also becomes much more meaningful beyond merely changing the colour of a component or fixing a UI bug.

"Success is not delivering a feature; success is learning how to solve the customer’s problem."

~ Mark Cook, VP Product & Engineering, Kodak

Sometimes clients are not really sure what they want, so it's always really useful to ask questions to get deeper into what they're trying to actually achieve.

As an example, I once got a ticket where the client wanted a big new button right at the top of a page. Upon questioning, it turns out they really just wanted an easy way for customers to access the booking system. We were able to provide them with a slightly more elegant solution with this knowledge.

10. Communication, connections & community are key to growth

Soft skills matters. We don't exist in a vacuum designing and building for ourselves. We work with other people, in teams and for clients.

It's better to over-communicate than under-communicate. When you get stuck and have spent a good amount of time trying to solve a problem, don't hesitate to ask for help and communicate what you've tried. From a business perspective, your boss would prefer for you to ask for help earlier than sit there for half the day struggling. You're costing them money.

Your connections and community matter.

It's no secret that people often get jobs through others they know. I've heard over and over again of developers skipping sections of the interview process simply because they know someone who can vouch for them and put in a good word. It's a very real and viable way of getting work as you progress through your career.

The Director of Operations & Finance at my bootcamp once told me something I'll never forget;

The most successful developers I've met have built a community and support system around themselves.

Having this means they have people they can reach out to and ask for advice when they need to. One of the best things you can do for your career is to get involved and be part of a greater community of people with the same aims as you; People who lift you up, support you and understand your struggles, so you're not alone.

A large part of the reason I chose a bootcamp over self-learning was for the community and network it came with. I got my first job through something called Industry Day, where our school invite potential companies and hiring partners to meet us and see our work. The agency I worked at previously didn't have an ad up for hiring. I would never have gotten this first break into tech as a developer otherwise.

If you're doing something similar and not taking advantage of this, you're losing out on a huge benefit.

Wrapping Up

Well, there you have it — 10 lessons that have helped me to get to where I am now. They're often easier said than done, and I have to periodically remind myself of them, but I hope they'll be helpful to you moving forward and thinking about your career.

Feeling social? I can be found on Twitter where I actively share resources, tips and my coding journey!

Comments or questions? Drop ’em down below! 😊

How Three Months of Pair-Programming Has Impacted My Developer Career

Annie 🦄⚡ — Tue, 02 Feb 2021 03:02:56 +0000

It's been about three months since I began consistently pair-programming. Although it didn't start off smoothly, I can definitely say it's been a valuable addition to my somewhat new developer journey.

Here's how it started, the progress, and what I've learnt along the way.

For context, I work at a start-up where I was hired as employee number one. This means, at time of writing, I'm currently 25% of our entire company, and 50% of the "Engineering Department". The pair-programming I do is with my CTO.

How It Started

I'd always been vaguely interested in pairing, but it wasn't something I had much experience of. My first developer job was at a small fast-paced agency. Everyone worked on their individual client projects, so it wasn't really a part of the company culture. I'd previously pair (and group)-programmed during bootcamp, and like most other students, being a new thing, we all found it a little awkward.

My interest was piqued by this (oh so timely!) tweet from James Tucker, a week before I started my new job:

James Tucker

@tucker_dev

1.5 years into my dev career and I think the most beneficial ritual I've committed to is frequent pair programming with a senior I jive with.

15:49 PM - 06 Oct 2020

During my on-boarding, I mentioned this to my CTO and he was open to giving it a go. We decided to incorporate it into our workflow and agreed that we'd slack each other whenever we wanted to pair.

However, this did not go to plan.

Neither of us were in the habit of pairing and honestly, I had so much imposter syndrome around being hired for the position (moving from a largely HTML/CSS role to a full-blown React/Redux environment), that I was hesitant to ask because I didn't want to reveal how "terrible" I was.

Two weeks went by with little pairing. The first week was fine; I was ramping up, getting comfortable, and working on small UI enhancements and bugs.

Then I started work on my first fully-fledged feature. This involved A LOT of things I was unfamiliar with; mainly dealing with multiple libraries, timezones, and JavaScript/React in general. In my week three one-on-one, I broke down and mentioned my struggles with the massive codebase, and the panic that had been gradually building up.

My CTO was very supportive and understanding. First, he assured me that they hadn't expected me to be React ninja from the get-go, and that an important and very valid part of my job was just to learn. They were aware of my abilities before hiring me. He then immediately came up with a game-plan, and we formally scheduled two weekly pairing sessions henceforth.

The relief I felt about how it was handled was palpable.

Annie🦄⚡

@anniebombanie_

I can't express what a weight off my shoulders it is to have a manager who says, "It's normal. We expect you to be learning a lot right now.. what can we do to support you?"

If you're in a position to be this person for your team, know that it makes a world of difference 🙏

2/2

12:28 PM - 12 Nov 2020

How It's Going

As the weeks went by, we've gotten more comfortable pair-programming with each other. For a while, our two scheduled weekly pairing sessions turned into four, as we started to ad-hoc slack each other to work together beyond our scheduled times.

Sometimes the sessions are short; I'll just need an extra pair of eyes on a bug, and sometimes they're a couple of hours or longer.

We'll pair on fixing bugs, breaking down and implementing feature work, and occasionally have mini-learning sessions. For example, we're slowly transitioning our codebase to TypeScript & my CTO talked through what he'd done so far, his learnings, and next steps.

I usually ask a million questions, take notes, and often like to repeat things back to confirm and check my understanding.

The Positives

Familiarising myself with the codebase has been a much faster process through pairing, and it's great to get immediate answers to any questions I have. I also figured out that I have an easier time understanding concepts when I hear them, as opposed to just reading. In debugging code together, I've also picked up on computer science concepts that weren't taught at bootcamp (such as race condition).

But an unexpected benefit has been that I've been able to observe and assimilate many of my CTO's habitualised ways of working. This includes small tricks with VSCode that I didn't know about, such as shortcuts and how to more efficiently navigate my way around the user interface.

Seeing first hand how my CTO, with his years of experience, approaches a problem has been immensely valuable. For the first time, I've really started to appreciate the importance of reading documentation. If there was something we didn't know, his response is always, "Let's have a look at the documentation…" 😅

I would also say that working together more closely (although we've never met in real life) has fostered teamwork and goodwill between us, both of which are important in building a positive company culture.

The Negatives

It requires a certain amount of vulnerability to pair with someone much better than you. I constantly feel "stupid" for not knowing or forgetting things. It's hard to admit how much you don't know yet, especially when you're trying hard, and want to show your best side in front of your employer.

Luckily, I don't get treated as such, however, it's an internal battle I face each time.

For the most part, it's also currently a one-way stream because our levels are so different. By this, I mean, I feel like I usually benefit more from the sessions. However, I once helped solve a CSS issue and made it even better than it was… that felt awesome! And my CTO has mentioned that pairing has forced him to examine how he's explaining his thought process, and so it's been beneficial for him too.

In Closing

Would I suggest adding paring into your workflow? Absolutely, if you get a chance!

It might take a bit of time to get used to but I'm much more comfortable with it now and have since paired with other devs to help them out. It feels great to pass on knowledge/tips you've learnt and solve problems together. Plus you get to practice speaking the language of your craft.

You can use any screen and voice sharing application to pair, and VSCode itself has some pairing extensions you can install, such as Live Share.

But if you happen to use a Mac, I can highly recommend Tuple for pairing. Ben Orenstein and his small team have done an amazing job with it, and are responsive to any feedback. They've also put together an excellent Pair Programming Guide to help you get started with it.

So hey, thanks for making it all the way down here! Hopefully, you've found this article useful and it's given you a better idea of what pair-programming involves. If you're into the social thing, I share tips and observations on my dev journey on Twitter. Comments or questions? Drop 'em down below! 😊

CSS/SVG Art & Animation: A Curated Collection of Useful Resources & Tutorials

Annie 🦄⚡ — Mon, 10 Aug 2020 12:17:34 +0000

Originally published as a thread on Twitter, I wanted to compile this list of CSS and SVG resources all in one place for easy reference. I’ve updated some of the resources and as a bonus, also added additional information and useful tools that were not on the original thread.

Annie 🦄⚡

@anniebombanie_

I often get asked CSS/SVG tutorials.

While there's nothing like that sweet sweet struggle of working on your own ideas 😳, they definitely have a place in my learning.

So, here are some resources I like!
🧵

16:55 PM - 13 Jul 2020

Who Am I?

I’m a designer-turned-developer who started my #100DaysOfCode journey in April 2020 with an aim to get better at JavaScript. Somewhere along the way, I got derailed by some beautiful CSS art I was seeing from other developers on the platform. It was a complete mystery but as I started to explore this new world, I found it a beautiful fit for my designer/artist side.

Annie🦄⚡

@anniebombanie_

I started my #100DaysOfCode journey to work on JS, but got mad sidetracked into #CSS art by @ellie_html 💜

This was new for me & the learning has been awesome!! A snapshot of some stuff I've made since I started.

Code is all on @CodePen
👉 codepen.io/anniebombanie

20:34 PM - 23 Jun 2020

On Twitter, people would often ask me about tutorials and how to get better. To be honest, I don’t really follow tutorials. I love working on my own ideas and googling as needed when I got stuck or needed to dive deeper to understand something. I think this is a great way of bringing your own ideas to life and keeps you challenged!

That said, tutorials & documentation play a HUGE role in my learning. So, without further ado, here are some resources I like. I hope they’ll be beneficial to you!

CSS art

A great place to start:https://www.creativebloq.com/amp/features/get-started-with-css-art
Great tutorial aimed at the beginner with a free video course:https://medium.com/coding-artist/a-beginners-guide-to-pure-css-images-ef9a5d069dd
Master shapes; They’re a cornerstone for creating CSS art:https://css-tricks.com/the-shapes-of-css/
How to draw with gradients:https://webdesigntips.blog/web-design/css-tricks/drawing-images-with-css-gradients/
Another insightful article on using gradients:https://fossheim.io/writing/posts/css-polaroid-camera/
How I created my one div iPad, with additional one div art resources:https://frontend.horse/issues/3/
Tips to get better as you advance:https://css-tricks.com/advice-for-complex-css-illustrations/

CSS animation

Understanding key animation principles will take you far:https://www.cgtarian.com/animation-tutorials/disney-animation-principles.html
w3schools has all the properties you need!:https://www.w3schools.com/css/css3_animations.asp
Great guide on CSS animation for beginners:https://thoughtbot.com/blog/css-animation-for-beginners
Incredibly comprehensive guide to CSS animation:https://blog.hubspot.com/website/css-animation
Complete foundation video series on CSS animation:https://www.youtube.com/channel/UC4QVZ552Q-dXIdMSc2cewcA
More tips & tutorials to help you level up!:https://cssanimation.rocks
Collaborative coding with great CSS animation live streams:https://www.youtube.com/keyframers

SVGs

Beginner-friendly guide on all things SVG:https://www.creativebloq.com/features/the-complete-guide-to-svg
Practical easy-to-understand guide to using SVGs:https://svgontheweb.com/
SVG (and CSS) properties, and how to use them:https://css-tricks.com/svg-properties-and-css/
Must-know on how to scale SVGs:https://css-tricks.com/scale-svg/
Understanding SVG filter basics:https://tympanus.net/codrops/2019/01/15/svg-filters-101/
Sara Soueidan’s excellent 49min video recording on SVG filters:https://www.sarasoueidan.com/blog/svg-filters/
Insight into how SVG filters were used to create an amazing animation:https://frontend.horse/issues/6/

Useful tools

Check if properties you’re thinking of using are supported cross-browser:https://caniuse.com/
A must for responsive border-radius:https://9elements.github.io/fancy-border-radius/
Easily create clip-paths with this indispensable tool:https://bennettfeely.com/clippy/
Refine your animation eases with this handy visualiser:https://cubic-bezier.com/
Optimise your SVGs for smaller file sizes:https://jakearchibald.github.io/svgomg/

Final words

You may wonder, what’s the point of CSS/SVG art or spending hours doing something that honestly, we probably won’t get paid for?

My response: “Great question! It’s helped me gain a deeper insight into CSS properties I don’t typically use & I’m able to sometimes apply those solutions practically at work as well.

But another answer is: What’s art good for? I do it for the pure process of creation & expression as well.”

Brené Brown shares an idea of “play” that I love: Where we do things that has no discernible purpose, and we don’t want to end. The benefit of doing this is that it exercises our creativity and innovation muscles, both of which are vital for the work we do. It might also help reduce stress!

Sounds pretty good right? And finally, in case you’re wondering, “So... how do I get better?”

Sorry, no shortcuts. Practice, practice, practice. I spend hours learning, trying, failing, refactoring, succeeding. You just gotta be brave enough to suck at something new. Good luck!!

Thanks for reading! If you’d like to check out my coding art projects, head on over to CodePen! Or follow me on Twitter where I actively share resources, tips and my coding journey.

Thoughts on the Current State of The World — June 2020

Annie 🦄⚡ — Sun, 07 Jun 2020 01:33:05 +0000

Personal musings on the Covid-19 lock-down, privilege, systemic racism and the work towards a better future.

I forget what week of lock-down it is now.

Week 11? 12?

It almost doesn’t matter does it? The weeks and days have all blended into one long Groundhog Day type story that has yet to end. I wonder how future historians will reflect back on these troubled times. 2020 has thus far proven to be a (excuse my language) shitshow for many of us.

I live in Toronto. And although easing-up a little, Ontario’s state of emergency declaration has been extended till end of June. But word on the street says it may be September or after. Unlike a number of friends & contacts I know, I’m one of the lucky ones to be able to work remote and keep my job. I’m really grateful for this. And I’m grateful to be privileged enough to have access to a space where I’m safe. I can read, work, think and spend time outdoors. I have food, clean water… and I have toilet paper.

My heart has been really heavy this week thinking about all the riots, violence and happenings in the US. It’s been really difficult to focus on other things. I’ve seen the videos, heard the voices, educated myself on why this is happening. (FYI, Twitter has been an absolute war-zone. Super stressful. Although the K-pop stans’ take-over of racist hashtags did help to temporarily lighten the mood somewhat!)

The ugliness of centuries of suppressed racial discrimination has ferociously erupted into public awareness like a wildfire. I can’t imagine police just breaking into my home (wrong home by the way!) and shooting me. Or sitting in my car an extra 5mins, because I’m cognisant that someone outside might feel threatened by the colour of my skin. Thus I wait till they’re out of sight before getting out. These realities are not mine and probably never will be.

But they are for too many others.

The book I’m currently reading (Thinking, Fast and Slow by Daniel Kahneman), indirectly supports the idea that racism is learned. Through popular media and outdated models of thought; both of which results in large scale unconscious biases. So it’s an effort for our conscious minds to challenge these deeply buried assumptions.

I’m fortunate that I grew up in a multi-cultured environment and my friends and contacts group is actually very diverse. Travel has exposed me to so many different people and cultures. And while I’m not perfect, I’m very intentional in my efforts to look beyond the colour of someone’s skin; to know them as a person and an individual for their personal hopes, dreams, beliefs and work they do. I’m not blind to their colour but I challenge my preconceived assumptions of them. And that goes both ways. Just because someone is White and successful, it doesn’t mean they “had it easy”.

Returning to the topic of media; I pretty much never watch TV but when I see the ads, they feature mostly White people in beautiful huge houses. Lots of appliances. Lots of clothes. Lots of “stuff”. In many modern shows, there’s sometimes a token Black, Brown or Asian person in a predominantly White cast. What messages does this send to the public at large? To young people of colour wanting to break into a field like that? What it means to live a good life? To be happy and successful?

I know there’s representation and there’s over-representation. In tech and government, there’s diversity hiring and filling quotas. It’s a huge, complicated issue and very difficult to navigate or know what’s the “right” thing to do. I don’t want to be hired because I’m a “woman-in-tech” or “person-of-colour”. I want to be hired for the merits of my skills and what I bring to the table. I want to be the right person for that role, not just to check off a box.

But until we get to a point where as a society, we can make better choices irrespective of the colour of someone’s skin, I understand these initiatives and systems are in place for people to try and do their best. And they will fail. They will be revised. And new initiatives will be proposed.

I think (most) people are trying.

We just all have different ways, some louder than others.

But the important thing is we’re all working towards a common goal. So be kind to yourself and those travelling in the same direction.

#blacklivesmatter

Message about the many lanes of a revolution by Cali Rockowitz (calirock) on Instagram

Hey, thanks for making it this far down and reading my meandering thoughts! If you wanted to connect, I’m pretty active on Twitter where I share my coding journey, thoughts and experiences.

Getting Your First Coveted Tech Job: Advice from Senior Developers, Hiring Managers & Industry Recruiters

Annie 🦄⚡ — Sat, 01 Feb 2020 22:47:55 +0000

Very shortly after graduating from a 9 week Immersive coding bootcamp at HackerYou (now known as Juno College of Technology), I spent no small amount of effort setting up coffee chats, attending panels and networking events, asking lots of questions at interviews and talking with smart, passionate people about the tech industry and what companies are looking for.

Transitioning into the tech field from another background (related or unrelated) can be difficult and a mystery. What holds true in one industry may be completely different in tech and again, within different companies and organisations. You just have to hold your breath and step off the cliff, not knowing how high it is or where you’ll land at the bottom. There’s so much conflicting information out there that it’s very hard to navigate, and what’s worked for one person may not work for another.

So in order to prepare myself as best I could, I reached out, offered to buy lots of coffee, wrote and asked many questions, took even more notes, listened to and did my best to integrate the advice of those more experienced than myself.

This is a compilation of what I learned.

Note: The information recorded here is meant for junior developers (and I’m specifically based in the tech hub that is Toronto), but I hope what’s written might be relevant for anybody at any level of their career.

Who are companies hiring and what qualities are they looking for?

Open and eager with willingness to make mistakes and learn. They listen and adapt to others, and are not stuck in their ways.
Team players who work well and can communicate with others. Being argumentative to get your point across, even if you are right, isn’t doing anyone any favours.
Positivity, being proactive and wanting to make a difference will take you far.
Culture fit/add was the biggest thing in all the people I talked to. Above technical skills, companies want to hire people that will add to the culture. Hiring is often a company’s biggest business problem. Your first interview or phone screening will often be to make sure you’re who you say you are and not a serial killer or a potato.
How up to date are you in the market with new technology? Being relevant is important. Are you willing to learn and expand your on current skill-set? (Right now at time of writing, we’re still seeing a huge demand for React.js)
Depending on the role, a fundamental knowledge of JavaScript is often important, as well as being comfortable writing code in general.
Make sure you’re good with the basics of version control as well.

Any tips for the job hunt?

The process can be long, gruelling and demoralizing. Don’t spend the entire day applying to job after job. You’ll be exhausted and probably develop tunnel vision.
Carve some time out each day (even just two hours) to do your research and send out your resumes and cover letters. Stop and do other things afterwards. This will keep you sane.
Do your follow ups but don’t link a lack of response or a rejection to a validation of you as a human or your technical skills. Sometimes companies are flooded with applications and just can’t respond.
Don’t underestimate the power of networking and optimising your online presence such as LinkedIn profile.
Optimise for opportunity/growth over cash. Graduating from a bootcamp, you’re pretty much going to make within approximately 10% plus or minus. Focus on the skills and the hands-on experience you’ll get.
Also, look for culture and something that will help you grow in your career. You’ll be much better off in a job that pays less but you enjoy spending eight hours a day at, than a job that pays more but you’re stressed out and working 18 hours a day.
Don’t discount your background as irrelevant to the field you’re getting into. One of my fellow bootcamp friends got her job because she was, in her own words, a “farmer” before. The agency’s biggest client was an agriculture company she had worked with as a Assistant Lab & Field Technician. The CEO specifically made a point to speak to her about this in her first week.
Not only that, playing up your strengths in your previous career will help you stand out and differentiate yourself from all other bootcamp students graduating at the same time as you.

You scored an interview! Awesome! Now what? Here’s some interview tips:

Don’t claim all the credit for work you didn’t do. Give credit where credit is due. (This was a top no-no from a Senior JS developer)
When white-boarding or explaining a tech challenge, discuss your thinking process. You don’t have to get the answer correct but your interviewers are interested to see how you approach a problem and the solution you come up with.
If whiteboarding or explaining tech challenges, do not be afraid to ask question to clarify something you don’t understand. This is something you’ll do in your job anyway, so interviewers want to see that you’re comfortable doing this.
Be prepared to answer what else you would do if you had more time for the tech challenge. (For me, I talked about extra features I would add to the app I was working on and some more advanced error handling I thought would be important.)
Remember, “No” is only a no for now, not forever.
It’s as much you interviewing them as they are you. Don’t be afraid to ask questions on their processes, culture, tech stack, code reviews and anything else that’s important to you.
At the end of the interview, send a thank you email (a lot of people don’t do this) with a personal note that will help them to remember you.
If you’re rejected, ask if they would mind sharing some feedback to help you be a stronger developer or candidate in the future. Maybe ask if you could keep in touch with them.
And my favourite, most valuable interview tip ever: “Be the kind of person you want to work with.” This tip allowed me to relax and be myself in my interviews. End of the day, this is who they’ll be working with and I want to show up as my most authentic self.

Photo by Chris Liverani on Unsplash

Tips for your on first job.

Ask lots of questions.
Be patient with yourself. You’ll probably feel like you need to know everything NOW but you don’t. Just relax. Remember: You got hired!!!
Don’t expect to be contributing right away. When companies hire, they know you’re an investment. It might take three months to settle in and the average time before you really start contributing is six months. (And according to Achievers, it takes two full years to reach the same level of productivity as an existing staff member)
You might feel like you should be working on coding-related passion projects after work and on weekends. DON’T. Many devs in their first job are put in an environment where there’s so much to learn and take in that they’re mentally exhausted after work. Self care is important.
Learn best practices. Think “cleaner code” instead of “hustle code”. In an agency environment with multiple tickets to complete, you might be tempted to fall into the mindset of just, “pushing to Dev Complete”. You’ll thank yourself later for the extra time and effort you put into writing clean code, when it comes time for bug fixes and client QA.
Learn how to add ‘yet’ to your internal self-doubts. “I can’t do this… yet.” “I don’t know how to do it… yet”. Once you manage to convince yourself you CAN do this, it gets a whole lot easier to start getting better.
Think about learning how to learn. Learn how to work with senior engineers, managers and other developers. How do you learn and ramp up on new frameworks or new libraries very quickly, to go to the skills that matter long term?
Even if your first job isn’t using the technologies you wanted to use, ask if there’s a possibility of using and implementing them in future projects. Also, remember: you’re not just learning technologies; you’re learning development processes, teamwork and other business related skills that you can carry into your next role.
Seek regular feedback. You might spend a lot of time thinking you’re doing terribly when you can actually just check in with someone you trust and respect, and get an more unbiased opinion.

What traits do you see in successful developers?

They have a large professional network of people and are involved in the community.
Puts themselves in situations that expand their skill-sets. People who make the most money might not necessarily be the best at everything but they know a lot, widely.
They have good mentors they can count on. Their mentors have probably been in the field a bit longer (although they can also be someone at a similar level with different skills from you) so can give you advice because they’ve been in your shoes.
How do you find a mentor? Think about who you want to ask a lot of questions to. A mentor can take many different shapes and forms. It’s generally someone whose opinion you value and want to reach out to when trying to get advice or make a decision on something.

What’s the main reason developers move on?

Lack of challenge
Not getting along with management
Getting an offer that they can’t turn down

What resources have you found useful in developing your skills in interviews, tech challenges or working in general?

JavaScript: Understanding the Weird Parts: Should be on every new developer’s To-Do course list
The Coding Interview Bootcamp: Algorithms + Data Structures: Udemy course to help you ace your next Javascript coding interview by mastering data structures and algorithms
Codewars: Highly regarded online game platform for developers to achieve code mastery through repetition and programming challenges
Cracking the Coding Interview: 189 Programming Questions and Solutions: If you want to excel at the kind of interviews they conduct at the Big Four (Google, Amazon, Facebook, and Apple)
Start with Why: How Great Leaders Inspire Everyone to Take Action: Before you begin, understand the problem you want to solve
The One Thing: Focus on one thing at a time, starting with what is most important
Atomic Habits: Build healthy habits to improve your life and your work by 1% everyday
Your Money or Your Life: Create a strong financial foundation, and learn what money really is

To wrap up, I’d like to share a personal anecdote that got me to where I am now. It’s hard to imagine where and who you could be in the future. And in this very moment, you might not even believe you‘ll ever get there.

I’ve felt this strongly.

Photo by John Baker on Unsplash

That famous quote, “A journey of a thousand miles begins with a single step. ” is very relevant. In my case, an empathetic doctor said to me, “If you want to walk to Vancouver (from Toronto), you need to take the first step. That time is going to pass anyway, regardless of what you do. Or don’t do.”

I’ve thought of these words many times during my most difficult periods.

I wasn’t able to look far into my future and predict how it was all going to turn out. Heck, I didn’t even know what I was going to eat that night. The stress of job-hunting, imposter syndrome and financial stability were all things that weighed heavily on my mind. I just focused on and did the one (or two or three) thing(s) I had to do that day and over time, those things accumulated and became the life I now currently find myself living.

I also remembered an important thing that my part-time Web Development instructor at HackerYou (now Juno College) said to me, “There are many types of developers in the world. If there’s something within the realm of coding that excites you, chances are, that job is out there for you.” When I heard this, I felt relieved I didn’t have to know every single Javascript function under the sun. I adopted an abundance mindset and didn’t see my fellow bootcamp students as fierce competition for a limited amount of jobs we all had to fight over. I just tried my best to help them get the job that was the right fit for them, and not the right fit for me.

So dear human, good luck in your personal journey!

I was very fortunate in my job search and had an offer two weeks after graduation so I’m (at time of writing) now an employed Front-End Developer for a small digital agency. It’s absolutely crazy busy but I’m totally thriving and loving the challenges!

Like what you’ve read? Connect with me on Twitter where I actively share resources, tips and my coding journey. (Or hey if you prefer something less tech and more personal, I often post stories on Instagram as well!)

On being a designer learning code and the challenges of re-inventing yourself.

Annie 🦄⚡ — Mon, 29 Apr 2019 04:00:00 +0000

I remember the exact moment I started falling in love with coding. And believe me, my former self would never would say that...

We so often define who we are early on in life. And in that process, it can be difficult to re-create yourself later on. Did you ever play that game where you had to think of adjectives starting with the same letter as your name to describe yourself? Well, I was ‘artistic’ and ‘adventurous’.

And my life had thus far reflected that.

I was the girl who drew dolphins and Disney princesses, went to a special Arts school and wrote stories. Later, while my friends were getting mortgages and climbing the career ladder, I backpacked and hitch-hiked solo around Canada, Europe and Asia. I placed a high value on independence and freedom over a stable income and routine.

In society, there’s a general idea floating around that you’ll be successful and love what you do if you follow your passion. But what if you don’t have one passion? What if you’re interested in SO. MANY. THINGS. I wanted to be a Disney animator! A jockey! A detective! All of the above! So that’s where it falls apart…

I’m of the school that says if you find something you like and get really good at it, then you’ll become passionate about it in the process.

Here’s my story.

The backstory (ie. Setting the Scene)

‘Artistic’ Annie saw me graduating uni with a BA in Multimedia Design. (Because it was art, but with computers = not a broke artist).

Working as a web/graphic designer, I had experience coding my own websites but always viewed coding as a necessary evil. At the time, it was HTML 4 and XHTML which I found messy and quite frankly, a bit of a dog’s breakfast. It was great being able to understand, manipulate and build websites, but using tables and other hacks for visual layouts was just so… ugh.

I worked as a designer for a few years in both my home country of Australia and also the second home to most Australians: London, UK. Shortly, after the financial crash of 2010, exotic Japan beckoned.

Photo by Agathe Marty on Unsplash

Like most foreigners, I ended up teaching English because when I landed, my Japanese was limited to, “Hello”, “Please”, and “Thank you”. In Japan, there’s this word; Karōshi (過労死) which scarily translates to ‘death by overworking.’ Um… no thank you. As a teacher at a private institution, I was able to set my own hours and took the opportunity to travel whenever I could. (Which was as much as humanly possible.)

Although I wasn’t designing, I utilised my creativity in how I taught and quickly became the highest evaluated and most sought-after instructor there. I loved the impact I was making on students’ progresses.

But there was no career growth.

I had long identified that being stagnant was one of my greatest fears in life. After six fun years, it was way past time to move on.

With my Canadian partner, we crossed oceans to Toronto and I decided to jump back into design.

A harsh reality-hit. (ie. The crisis)

I soon realised life in Japan had basically encapsulated me in a bubble. I was ill-prepared for how the design landscape had COMPLETELY changed. Not only that, the competition in Toronto was fierce. For the first time in my life, I wasn’t able to just walk into a job as a motivated skilled individual. It was time to up-skill or be left behind.

And thus begins “The Search”…

Photo by Corinne Kutz on Unsplash

As part of my research, I stumbled upon something called a ‘bootcamp’, which was different from the 150 burpees I used to do in Clapham Common, London. Schools were offering short, intensive full-time courses in desirable skill-sets, designed to help students get work afterwards.

At first, it kinda sounded like a scam; “Pay us $15k and after 2 months, we’ll help land you a $85k job!” So I did my due diligence. I scoured the internet for reviews and attended info nights and free classes all over Toronto. I talked to past alumni. And slowly, it dawned on me that this alternative education path was legitimate.

Web Development? UX Design?

Honestly, I wasn’t sure about getting into this “Web Development” thing… I hadn’t really enjoyed it that much previously and to me, a ‘developer’ just didn’t have the same ring as a ‘designer’…

I was actually leaning towards UX design. Reflecting on what I’d most enjoyed at uni, I was deeply interested in motion, interactivity, beautiful visuals, and the way people interacted with digital experiences. I was using the term user experience before it was really as much of a thing as it is now.

I remember not only had I designed and built an interactive narrative from scratch at uni, but I had also pushed my learning in Lingo (anybody still remember Macromedia Director??) because I wanted to do all these cool things in my project and couldn’t without it. Likewise, I used Actionscript in Flash the same way.

Hmmmm… put it that way, development sounded like it was definitely worth another look. Also, there’s no way that learning to code would be a waste. If in the future, I decide to transition into UX/UI, knowing my way around code can only be an advantage.

In my bootcamp research, one name kept coming up: HackerYou. I attended a free ‘Intro to Web Development’ class there and found the positive and welcoming learning environment very encouraging and more personable than some of the other schools. Not only that, the HTML/CSS landscape was now completely different from what I remembered all those years ago. Intrigued, I signed up for their part-time fundamentals and advanced web development courses.

THAT navigation colour change transition… (ie. The Climax)

I remember the exact moment I fell in love with HTML 5/CSS 3.

I had just coded and successfully troubleshot a button transition hover state. I was rolling over the navigation links. It seems like a small silly thing, but admiring the subtle fade in and outs, the ghostly effect enthralled me in a way I hadn’t felt in a while. I remember “back in the day” when we did button hover states; I had to give the developer the various states of a button as images. The fact that I can do the same thing now completely in CSS blows my mind. Oh, the POWER and POSSIBILITIES! It was late but all I could think about was what else I could do with CSS.

Geeking out over beautiful semantic HTML and CSS possibilities in my head, it was past 3am before I finally called it a night on coding. In less than a couple of hours, I had to get up for a 6am opening shift at a yoga studio I volunteer at, followed by a full 8 hours in the office. It was going to be a loooooong day…

Adulting… so hard to do on 2 hours sleep

Where I am right now. (ie. To be continued…)

After my part-time courses, I would often call my partner on my way home and chatter on about all the interesting, challenging and exciting things I was learning and how much fun I was having. I took this as a sign that coding could be a viable next career move.

I decided to apply for HackerYou’s highly acclaimed bootcamp… and got in! The imposter syndrome regarding me being a developer is very much there. But as I code, learn concepts and spend time with other determined developers-in-training, that title is starting to sit a bit more comfortably every day…

Maybe this personal account of my venture into Web Development has inspired you to give something you once disliked a second go!? You never know what you might just fall in love with…

Feeling social? I’m active on Twitter and usually post stories of plants and my silly cat on Instagram.