I found my notes from my experience as a web developer at Shazam! It was the first tech job I ever had. Learnt a lot about myself. I'll be sharing what I learnt in this post.
Update: Part two has been published
Brand building
Say yes to opportunities which can build your brand e.g. conference talks. Offer to write technical blogs, which helps your company of course, but then bam. Wanna write for CSS Tricks, TutsPlus, smashingmag in the weekend? Now you have a sample article you can refer them to (see here for more info on my personal journey).
🧠️ Knowledge sharing in the form of tech articles often gets neglected at companies, so your peers will find it useful. Tech writing also gives you a feel for developer evangelism which is an extremely rewarding area of being a web developer.
If you've not done public speaking before, speak about the technology your company uses at a free evening meetup, then ask work for time off in lieu. This way, you can learn public speaking and get paid for it, if your job is getting decent exposure, this should be a fair trade.
Hackday
Push for hackdays. With so much to constantly learn, it's worth getting your job to support you, e.g. 20% projects to learn new skills and build things which are related to the company. And no, it's not 20% time to fix technical debt that never gets prioritised.
Motivation for hackdays
Hackdays were one of the best things for my career. Better than a free weekend to learn whatever. Why? Because there was a whole floor of colleagues waiting to see what I had built (during a "demo day") and who were always positive, no matter what I was showcasing.
Here's an example: it's where:
- I originally visualised 1 billion Shazam's: https://umaar.com/blog/data-visualisation-with-1-billion-shazam-music-recognitions/
- And where I did the original version of this globe: https://umaar.com/globe/?time=past-1-hour
Deciding on technology for hackdays
Normally the product drives the tech, but with hackdays, I could let the tech drive the product. E.g. "I want to learn more websockets, time to make a real-time visualisation", "I want to learn design priciples, time to craft a landing page for something I made".
1:1's
That's enough about hackdays, moving onto 1:1's: when it comes to 1:1 meetings with the boss, here are some tips, end with Action items in a google doc, e.g.
- Boss: seek approval for Pluralsight membership
- Umar: Pair with the backend team for the next website feature
- Boss: Support Umar on journey to learn new programming lang
I've been privileged with great bosses. Our 1:1's were mostly about how they could help me, rarely the other way around. Only if they welcome it, offer advice on how they're doing as a boss e.g "I appreciate how you deflect the politics in the company so I can focus on coding".
Document everything
Document everything e.g.:
- What's the command to run a unit test in isolation
- What steps are needed to deploy to production
- How do I book holiday
- How do I go about asking for a pay raise.
- When appropriate, contribute this back to your docs at work so others benefit
If the steps seem wonky, provide feedback to your HR/line manager etc. Allowing them to learn how employees benefit from more effective information hierarchy is highly valuable.
Being valuable in other specialisms
Learn other parts of the stack in your organisation. You'll be more valuable, and be able to help others. When I first joined I saw the CI server (something like Travis) was unusably slow. When I got home, I installed the CI tool on a $5 VPS to understand more on how it works
This gave me a certain confidence from a dev ops perspective, the feeling that I could configure (if it was needed) the tool, offer assistance when it's down etc.
Being on-call
If there's something you're uncomfortable with at your company, don't be afraid to say no. There was once an attempt to try on-calls. They asked for my phone number and I respectfully declined, explaining my reasons and justification. There's more to this however.
Is it fair if your team mates are on-call and you're not? In my case I explained: I wouldn't have taken the job had I known on-call was a possibility, and that I'd be happy to communicate to my peers my reasoning behind this.
My very helpful boss at the time ended up using her own number and said "we'll cross that bridge when it comes to it". Anyway on-call rotations didn't go ahead (except for some critical roles I think).
Team lunches
At your workplace, be confident in spending lunch break by yourself, if that's what you prefer. I felt peer pressured to do team lunches. Truth be told, the mental + physical benefits of going to the gym were better for me instead. After all, I was already spending 7 hours a day with the same people!
That being said, I've been at companies where everybody ate at their desks, there wasn't even a kitchen table. It felt a little dire, so if you have peers/colleagues who get along, benefit from it! Even if it's a lunch once a week. Find something that works for all of you.
Don't want to do team lunches? Find other ways of connecting. Pair programming, afternoon walk around the block, bouldering after work, or even during work if the whole team agrees. At a few places I've been, we successfully asked HR for an allowance for such a fun activities.
Supporting others
Support interns & juniors, even if you yourself are one! Juniors supporting juniors. wat? When I was starting out, other junior devs gave me confidence to openly question things in the wider team e.g. 'Why do we have to make that change in 3 places'. However, request frequent feedback and check-ins from those more senior, it'll help keep you on the right track and stop you going down rabbit holes.
Network
Networking isn't just for high-level corporate jobs. When I was working on some Google+ integration for the web, I noticed a free Google+ workshop was running in London. I went and met @mrscripter. Much later, while at Google I/O, he arranged for me to have a tour of Google HQ!
Proactively check for free workshops and meetups that you can attend during work time to diversify your skillset. Obviously try and justify it and explain how the company will benefit!
Seeing it through to completion
At least once, try to take a feature through to completion. Examples include:
- Requirements gathering
- Design
- Development
- Testing
- Security
- Deployment
- Evangelism
At each stage, communicate with the relevant specialist (e.g. the designer) for ongoing feedback. However:
You're probably not an expert with all those things, which is why I say seek permission since it could take double or even triple the time for you to deliver such things. Not working in a silo will make this easier though.
Sit with specialists to understand how things work elsewhere in the stack. For example you could sit with operations to learn how a new container gets deployed through kubernetes. Document as you go along.
A developer environment for prototyping
At your company, request your own developer sandbox. For example: I had my own umar.shazam.dev URL which I could deploy my HTML and CSS prototypes + experiments to.
Deploy your work there, or even better, deploy your branches there and share them with others for ongoing feedback.
Code reviews
Code review tip: When you are reviewing code for peers, if appropriate, ask the individual for any feedback, such as:
- How can I give better reviews?
- Am I focussing on the right areas?
- Am I explaining/justifying my points well enough?
Reviewers need feedback too!
Drinking culture
In 5 years, I went to the pub once. Not drinking meant I had to find more creative ways to spend quality time with the team. Talk to them, find out what other activities you can do together (see the note on team lunches for more on this).
Help people to help you
Help people to help you. When I got stuck, I'd create a Codepen that clearly shows what I'm trying to achieve. It'd give others a chance to look at it in their own time (or together in-person if they'd prefer).
For example, for a quick question on Slack, I'd post an annotated screenshot to explain the bug and would try to provide avenues for quick answers such as:
Here's the problem, I tried this, do you think I should continue down this potential rabbit hole, or start checking the backend logs?
Your bug is fresh in your mind, but not their minds, so provide recaps when appropriate. E.g.:
Yesterday someone suggested I tried this . This morning I raised this
Attend conferences during company time
Here are some personal lessons I've learnt while getting approvals to attend conferences through my employers. https://twitter.com/umaar/status/941755764405948417
If speaking at a conference which benefits your employer, limit how much personal/unpaid time you spend on it! I'd request paid time off for the travelling, the conference days & time to prepare my talk. If I were getting paid for the talk, this would all be on my own time.
Go and read part two!