- 45% of FSA grads are employed in 90 days
- 70% of FSA grads in 180 days
- median salary $80k
- top 15% >$100k
- top 5% >$120k
The difference between the 50th percentile and the 95th percentile is $40k, or 50% more pay. note: money is not a good sole metric of outcome, also 30% dont even get jobs.
i am no authority nor a paragon of success but i find myself thinking a lot about how people should position themselves to do well during a career transition into tech. Note that if you’re average you’ll already have an extremely high chance of getting a job so I won’t bother addressing that. I thought I should write these thoughts down in the hopes of better structuring them for an alumni panel tomorrow. None of these things are at all required if you want to have an average life in tech, but I think each of these things help improve your odds of being in the top quintile of outcomes.
7 rules for the Intermediate Developer
- Learn in public
- Know your tools
- Clone, don’t build
- Open Source is an audition
- Specialize in the new
- Use your unfair advantage
- Networking in Dev Twitter
1. Learn in public
If there’s a golden rule, it’s this one, so I put it first. All the other rules are more or less elaborations of this rule #1.
You already know that you will never be done learning. But most people “learn in private”, and lurk. They consume content without creating any themselves. Again, that’s fine, but we’re here to talk about being in the top quintile. What you do here is to have a habit of creating learning exhaust. Write blogs and tutorials and cheatsheets. Speak at meetups and conferences. Ask and answer things on Stackoverflow or Reddit. (Avoid the walled gardens like Slack and Discourse, they’re not public). Make Youtube videos or Twitch streams. Start a newsletter. Draw cartoons (people loooove cartoons!). Whatever your thing is, make the thing you wish you had found when you were learning. Don’t judge your results by “claps” or retweets or stars or upvotes - just talk to yourself from 3 months ago. I keep an almost-daily dev blog written for no one else but me.
Guess what? It’s not about reaching as many people as possible with your content. If you can do that, great, remember me when you’re famous. But chances are that by far the biggest beneficiary of you trying to help past you is future you. If others benefit, that’s icing.
Oh you think you’re done? Don’t stop there. Enjoyed a coding video? Reach out to the speaker/instructor and thank them, and ask questions. Make PR’s to libraries you use. Make your own libraries no one will ever use. Clone stuff you like. Teach workshops. Go to conferences and summarize what you learned. Heck, go back to your own bootcamp to tell alumni what’s worked for you. There’s always one level deeper. But at every step of the way: Document what you did and the problems you solved.
The subheading under this rule would be: Try your best to be right, but don’t worry when you’re wrong. Repeatedly. If you feel uncomfortable, or like an impostor, good. You’re pushing yourself. Don’t assume you know everything, but try your best anyway, and let the internet correct you when you are inevitably wrong. Wear your noobyness on your sleeve.
People think you suck? Good. You agree. Ask them to explain, in detail, why you suck. You want to just feel good or you want to be good? No objections, no hurt feelings. Then go away and prove them wrong. Of course, if they get abusive block them.
Did I mention that teaching is the best way to learn? Talk while you code. It can be stressful and I haven’t done it all that much but my best technical interviews have been where I ended up talking like I teach instead of desperately trying to prove myself. We’re animals, we’re attracted to confidence and can smell desperation.
At some point you’ll get some support behind you. People notice genuine learners. They’ll want to help you. Don’t tell them, but they just became your mentors. This is very important: Pick up what they put down. Think of them as offering up quests for you to complete. When they say “Anyone willing to help with __ __?” you’re that kid in the first row with your hand already raised. These are senior engineers, some of the most in-demand people in tech. They’ll spend time with you, 1 on 1, if you help them out (p.s. and there’s always something they want help on). You can’t pay for this stuff. They’ll teach you for free. Most people don’t see what’s right in front of them. But not you.
“With so many junior devs out there, why will they help me?”, you ask.
Because you learn in public. By teaching you they teach many. You amplify them. You have one thing they don’t: a beginner’s mind. You see how this works?
At some point people will start asking you for help because of all the stuff you put out. 80% of developers are “dark”, they dont write or speak or participate in public tech discourse. But you do. You must be an expert, right? Don’t tell them you aren’t. Answer best as you can, and when you’re stuck or wrong pass it up to your mentors.
Eventually you run out of mentors, and just solve things on your own. You’re still putting out content though. You see how this works?
Learn in public.
p.s. Eventually, they’ll want to pay you for your help too. A lot more than you think.
writing notes: maybe insert a bit about only helping those who ask for help
2. Know your tools
You missed a lot in your bootcamp. I’m not talking about compiler theory from computer science courses. I don’t mean algos. I mean a lot of basic knowledge of your tools is lacking. “A poor craftsperson blames his tools”, they say. But you. You’re no “craftsperson”, you’re still a novice. You don’t even know your own tools that well. You haven’t built that much with them, and you still freak out when things go wrong. It’s not your fault, but it’s in your power to fix your gaps. The bootcamp gave you a head start, now you have to go the distance.
If you’re a frontend dev: Learn Webpack. Learn Babel. Learn what the CSSWG and TC39 do. Heck, learn Javascript and CSS all over again. Did you know you can use the Chrome Devtools as a profiler and an IDE? Learn bash. Learn git. Learn CI/CD. Learn frontend testing. Learn Docker. Learn AWS, and Firebase. OPEN NODE_MODULES. Yeah, it’s a lot, and I don’t truly know some of these things either. I’m workin on it. Equally important is figuring out what is ok to miss. I have my list, I’m not sharing it. But there are some things you will use daily in whatever career you end up in, and some other things are sexier or seem important but are really just nice-to-have. Figure out the difference. Tech is a house of cards a mile high, abstractions atop abstractions. Lower levels of abstraction have a longer half-life than higher ones. Kyle Simpson says you should learn one abstraction level below where you work. I think that’s directionally but maybe not literally correct.
The subheading for this one is avoid FOMO. Your favorite thought leader says you should check out ReasonML, is Javascript dead? Why the hell do people want to kill Redux so bad? Is CSS-in-JS literally the devil? Vue passed React in Github stars, should you pivot to Vue?
I dunno, do you get paid in Github stars?
Fill in -your- gaps. Focus on you and your needs. There are so many opportunities in tech that you can pretty much pick out your turf and play entirely within it AND be completely ignorant of all the other stuff AND still do great! Don’t get me wrong: I’m a big fan of playing the meta-game. It is possible to make strategic blunders but it’s also impossible to avoid them altogether. Stop trying. It’s much better to focus on the “good enough” and be directionally but not literally correct. The goal is to be accurate, not precise. Try your best to be right, but don’t worry when you’re wrong.
There’s more to knowing your tools than just knowing what they are. There’s also the why and the who. Who made the paradigms we live in now? Who’s maintaining it today? Why is the API the way it is? Why did it change from past versions? (If you’re feeling adventurous: how does the tool work under the hood?) Let your intellectual curiosity carry you and fill in your lack of experience with research that nobody else bothers to do. Guess what? There could not be an easier subject matter to research, this stuff is literally all online and version controlled with git, and all the people involved are still alive and easily contactable.
And when you’ve filled something in, when you’ve found something cool in your research, write it up.
p.s. Learn in public.
3. Clone Open Source Apps
You already know you should be making projects to learn things and potentially add to your portfolio. You’ve read your Malcolm Gladwell, you know that you need 10,000 hours of deliberate practice. Given you’re just starting out, I have a slightly contentious suggestion for you: DON’T make anything new.
Your decision-making is a scarce resource. You start every day with a full tank, and as you make decisions through the day you gradually run low. We all know how good our late-late-night decisions are. Making a new app involves a thousand micro decisions - from what the app does, to how it should look, and everything in between. Decide now: Do you want to practice making technical decisions or product decisions?
Ok so you’re coding. You know what involves making zero product decisions? Cloning things. Resist the urge to make your special snowflake (for now). Oh but then who would use yet another Hacker News clone? I’ve got news for you: No one was gonna use your thing anyway. You’re practicing coding, not making a startup. Remember?
Make the clone on your own, then check the original’s source. Now you have TWO examples of how to implement something, so you even get to practice something only senior devs get to after years of experience: understanding the tradeoffs of technical choices!
You’re lucky. You live in an age where companies and teams open source their entire apps. There’s Spectrum and Codesandbox and FreeCodeCamp and Ghost and if those seem like waaay too big of an app for you (they are huge) go look at the side projects of your mentors (see above). Ryan Florence has planner and Kent Dodds has TIL! Make a clone, then show it to them! You are guaranteed to get free feedback.
Here’s the subheading: put a time limit on it. Deadlines work wonders. Also you’re not going for a pixel perfect clone of something that teams of people, way more experienced than you, have made. You want to have a set amount of time, get as much of the interesting features as possible, and then ship it. This guarantees that you will be freed up for the next clone, and the next. Different projects let you try different libraries and stacks, and figure out what you like there. Also you get to practice one of the hardest software engineering skills of all: Project Estimation. You’ll create many, many opportunities for yourself to see what you can do in a set amount of time because you’re deliberately practicing making things on the clock. And none of that time is taken up by product decisions!
When you’ve done enough and start feeling bored, it’s time to let your freak flag fly. You’ve earned the right to make your app because you’ve made others. You know what things cost and you have used your tools well enough to get there. You’re still learning in public, though! Package up your experience into a talk. Livestream yourself coding. Blog about your game plan, then blog some more as you execute it. Developers who can communicate are in far more demand than developers who can’t.
p.s. All this will be a lot easier if you Know Your Tools well.