I am not an explorer.
I don’t come home and yearn to keep up with the latest and greatest in technology and development.
I cringe when folks say, “Just build side projects!” I gag at #hustle culture. I hate most dev blogs.
If I could get away with it, I would never open VS Code outside of work. Don’t get me wrong — I thoroughly enjoy going to work (most) mornings. I get really antsy if I haven’t coded in a few days. But, I also really enjoy coming home and reading my obscure film criticism journal or practicing a new song on my mandolin.
I’ve been trying to find an antidote for workaholism in tech for a while now, without giving into complacency and pretending it’s all going to work out. I want to make one thing very clear:
I don’t believe that only coding at work is enough for most folks, especially for marginalized folks.
I believe we do have to invest time outside of work if we want to have good careers. The amount of time will vary based on the person. I’m aiming for 10 hours a week. But, even 1 hour a week can make a huge difference.
So, if you don’t come home after work and race to the computer to work on more code, but still want to get ahead in your career, hopefully this will help you find that balance.
I want to have a long career in tech. I’d like to maximize my options so I can maximize my physical and financial safety. It’d also be cool to have the opportunity to work on cool things.
For some folks, that privilege comes more naturally — from a prestigious degree and alumni network, or from having an appearance that leads to positive bias.
It doesn’t for me. I don’t regret any of the choices I’ve made about how I’ve handled my job hunts, but since there are so many factors I can’t control, I’d like to be amazing at the factors I do control. The best time to build up those skills is when I feel relatively safe.
Here’s a short list of some things that could go wrong if you confine your dev time to your 9-5:
- Your could get a new manager who is terrible and you feel like you have to quit.
- It turns out your CEO has been embezzling funds for years and now half of the engineers are getting immediately laid off without much severance.
- You get transferred to a new team, and it’s no longer a high-growth opportunity. You know in your heart and soul you will stagnate, and you have to quit.
- You putter along happily, and one day you realize you can never leave this company because the industry has moved on while your company has stayed in place.
- You could have to move and find a new job, and 99% of your network is now irrelevant and you have to restart from scratch.
This might sound a little paranoid, but I don’t know any developer who hasn’t been either laid off, fired, or pressured into quitting. I’m not that far into my career, and that’s already happened to me.
I would love to stay at my current company for years. However, I can’t guarantee that’s going to happen. I’d rather be able to jump into a job hunt confidently (which take around 3 months on average) and not have to factor in even more time because I didn’t study in advance.
If you’re with me so far, let’s talk about how to do this effectively.
The best way to curb workaholism outside of work is to severely constrain what it is we choose to study or work on.
I can’t give you the exact answer, because what you should work on varies drastically by field, job type, location, and seniority. However, I can present the questions I asked myself and the answers I came up with.
First of all, I think there’s two different categories of skills involved in getting ahead: job-hunting skills and actual development skills. You need to focus on both. I think a lot of explorer types will tend to ignore the first in favor of the second. Don’t ignore the realities of our industry in the vain belief that your raw development skills will keep you gainfully employed.
In order to figure out what the most relevant job-hunting skills are, we need to zero in on what industry and niche we want to work in. The easiest way to figure this out is to stick with the type of job you have right now.
I have decided that I want to be in full-stack web development at large tech-focused companies in the Bay Area for as long as I possibly can. This means I am putting zero effort into how to work at startups or how to work in the financial industry or how to find freelance clients.
I’ve read the job descriptions at large Bay Area tech companies, talked to folks who work at these companies, and read a lot about the process from blogs. Here’s how to find a job in my chosen niche:
- Get a way in through either your network or through a recruiter finding you on LinkedIn.
- Have your resume pass their filters and let you into the interview process.
- Pass an interview process that focuses on language fundamentals, algorithms, and system design.
I am constraining all of my focus to maintaining these skills. Notice that nothing on that list says “Have popular open-source projects,” or “Build a following through blogging.” This means I will refuse to do this, despite the fact that some folks have said that has been instrumental to their career. That may be true for them, but it’s not as much bang for my buck with 10 hours a week to spare.
This means my focus is on a maintaining a local network, keeping my LinkedIn and resume up to snuff, and practicing algorithms and system design.
Remember, it’s okay to say no. Relentlessly filter so you have the time to focus on activities that give you an amazing ROI. Despite this focus on job hunting for enterprise jobs, the leverage of being able to get offers from enterprise companies easily could help me get the startup job of my dreams. Being amazing at 1 thing gives you more opportunity than being just okay at 3 things.
Keep in mind that this process I’ve presented isn’t true for all folks in all industries. Ask around, read around, and figure out exactly what the process is for you.
If I was severely constrained on time (eg. 1 hour a week), I would focus only on job-hunting skills. In my case, I’d keep my LinkedIn up to date and practice 1 algorithm problem a week. Tweak as necessary for your case.
TL;DR: Decide on your niche/industry, and figure out how the hiring process works in this niche.
Figuring out how to develop programming skills is a lot less straightforward than maintaining job-hunting skills. You need to figure out what kind of developer you want to be, and then figure out what you’re lacking.
This can be easier if your company has an engineering ladder — your goal is pretty obvious: a promotion. You can then ask people at that level how they get there, and what they think the barrier is between you and them. This is even easier if you have a good engineering manager who is both responsible for this promotion and your best source of help in filling in those gaps.
But if you don’t have that, you can emulate that by befriending developers who you want to be like. This doesn’t have to be a formal mentorship, but if you need some tips, I gave a talk about How to Be a Good Mentee.
If you’re a mid-level developer at an agency and you want to be a senior dev at an energy startup, go to some meetups, meet some people who are senior devs at energy startups, and ask them lots of questions. Most folks are willing to answer good questions and have a conversation if you’re pretty human and aren’t asking them to hold your hand or hire you.
If you don’t know what you want, talk to even more people. Go to more meetups and conferences. Watch people in their element, talking about things they love, see who you admire and listen to that voice. You don’t need to have a 10 year plan, you just need to know what your next step is going to be.
NOTE: Most of the time, the developers you want to be like will naturally be very public people. I’d caution against following in their footsteps unless your goal is to become a more public developer. I’ve found that very public folks tend to be explorers and lean towards a very different style of work than I’m presenting here. You should find folks as similar to you as possible.
Once you figure that out, relentlessly filter, again. The skills that you’re lacking may not be as clear as the job hunting skills. Here’s what I’m lacking:
- The ability to be productive in new, large codebases without much context
- Knowledge about large-scale systems and patterns across enterprise codebases
- Building domain knowledge about both business decisions and large-scale code decisions
- Pretty much everything about testing
As far as I can tell, I am not lacking in raw technical skills or communication skills. This means that investing time in them is pretty inefficient right now.
But at this exact moment in time, I need to focus on how to work well with enterprise codebases and processes. That’s it. Focusing on anything else could help, but it’s far less likely to make an immediate impact.
If you zero in on one or two focused and specific things to learn per year, you will be very good at a small number of skills. If you do this right, those will be extremely high-impact skills. You may not know 10 languages, but you will know your main 2 languages inside and out.
TL;DR: Figure out what you want, and exactly what gaps you have between where you are now and where you want to be. Only focus on those gaps.
By the way, this is my rough learning plan for 2020. It’s pretty ambitious, so I don’t think I’ll be able to do it all in 2020. But, I’ve zeroed in on my weaknesses and documented them into very clear skills I need to work on.
If you’ve zeroed in on what exactly it is you want to study and how it’ll help you, you’re 80% of the way there. You probably won’t be wasting a lot of time and your relentless focus will pay off.
But, if you're learning in ways that don't work for you, you will definitely be slowed down. More importantly, you may lose motivation and burn out.
Deciding that most learning resources don't work for me has been difficult to accept. If you see 100 people say that, "This course/talk/book changed my life," and yet, every time you try and go through it, you fall asleep, you can't help but feel like you are the problem.
Think about your best experiences with learning. What were the commonalities between them? Are you the type of person who likes to just dive in, or are you the type of person who needs to read a lot before you can dive in? Do you hate reading, or hate videos? Note that the best experience isn't necessarily the fastest experience.
To me, my best experiences coding were when I went through a course or book, no matter how long it took, and never/rarely felt like I had to rewatch or revisit a video or chapter. It was so deep, so through, and had such good exercises, that it was ingrained in my brain forever. This leads to an absolute adoration of 30-hour video courses on Udemy that would make some people want to quit programming forever.
I've had inklings about how I felt about certain ways of learning, but I always tried to convince myself I could do a medium that doesn't work for me. One day, I finally just wrote how I felt about each medium so that I couldn't lie to myself any longer.
I hate talks, broad syntax-focused overviews, code-along articles, podcasts, and read-along-to-exercises. I can sometimes tolerate fast-paced screencasts, books, college-style lectures, and docs. I know that I love code-along videos.
So, when I field resources for learning something specific -- let's say OOP -- and Googling results in 100 different options: "This book changed my life!" "This talk collates 30 years of OOP knowledge in an hour!" "Let's build an OOP app from first principles over 20 hours." You know I'm going to click the third option first, even though in theory it'll take 20x longer. I'd rather spend 20 hours on a very thorough single resource than 20 hours on 20 different shallow resources.
But, that's just the way I learn. You could be the complete opposite, and prefer to just figure it out as you go. That's fine! You do you.
TL;DR: Figure out what learning styles work for you and filter learning resources to suit your preferences.
There's one theme across this entire post: listen to yourself and filter everything else.
If you spend a lot of time thinking about this, the learning process will be that much shorter, and you'll grow exponentially. It takes a lot of practice to turn a vague idea of a weakness you have into a clear learning path, but this is also exactly what mentors are for.
If you can continuously go through the difficult process of turning a vague weakness into an action to take, your focus will pay off in droves. For example, "I have a hard time understanding abstractions in my company's codebase," to "Abstractions are a fundamental OOP idea. I should learn OOP," to "I'm going to read POODR to level up."
That's it! Thanks for reading. This is something I've been ruminating over with more of a personal focus on my blog over the past few months. Feel free to check that out if you want to see the development of this thought.