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.
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 Staying Average ForEver. 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 First Attempt In Learning. (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.
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.
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.
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.
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! 😊
