swyxio/1.md

## 1.md

      
    Raw
  

              1.md
            
          
    2019 update: this essay has been updated on my personal site, together with a followup on how to get started
2020 update: I'm now writing a book with updated versions of all these essays and 35 other chapters!!!!
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.

  
## 2.md

      
    Raw
  

              2.md
            
          
    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.md

      
    Raw
  

              3.md
            
          
    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.

  
## 4.md

      
    Raw
  

              4.md
            
          
    4. Specialize in the New

You already know the value of a niche - you go up in market value the more specialized you are in anything. So what do you specialize in?
There are many schools of thought, including ones where you could be a generalist that doesn't specialize in anything. I find one rule to be simplest and most effective above all: Specialize in the New.
Didn't we just agree to avoid FOMO? Well yes, thats an important distinction - don't specialize in everything new. Specializing means you have to say no to a lot of things. Just pick something new that fascinates you, and hopefully many others as well. Since you're learning in public, you'll know when you hit on a real nerve. Budget in the idea that you'll fail a few times before you find Your Thing.
Then the other big objection: There are plenty of jobs/money/etc in (fill in the blank older technology) too! This is usually followed by some big numbers and anecdata. "My brother's cousin's roommate's friend took this COBOL job and now he's earning six figures on the beach in Tahiti!"
If that works for you, good. Here's why I don't do it. It is far easier to rise up the ranks quickly in a new space than in an old, crowded space. You know how people rant and rail against companies who hire based on years of experience? That could go away tomorrow and you'd still have clients/employers silently comparing you with others based on your years of experience. It's human nature. But you know where it's impossible for someone to have 5 years' experience doing X? When X is less than 5 years old.
There's a practical element to it as well - technologies accumulate a LOT of cruft over time. Best practices form, some of which are total BS, but that is stamped by early experts as The Right Way To Do Things because Reasons. Books are written, careers are made. If you choose to play on their turf, you'll eventually need to read/deal with/overcome/win approval of all of that history. Even if you work twice as hard as the average developer you can only make up for all the context you missed half as slowly. You know where its possible to have read everything ever written about something? When it's new.
The subheading to this is: Focus right next to where others are investing heavily. Joel Spolsky notes that demand for a product increases when the price of its complements decreases. "Complements" are an abstract idea so I will try to draw an example for you. If you brand yourself as a Firebase consultant and Google keeps adding and bugfixing Firebase functionality, they are in a very small way working for you (as you are also adding value to them). (Side note: this is why the developer relations job is a very special one for a midcareer dev - you are essentially a designated person showing off the investment of a company and team doing the real work in the background. As a focal point and an amplifier, you will get disproportionate credit.) As a developer (and not a startup) you don't even really have to make the bank shot of figuring out the overlooked adjacencies next to an area of heavy investment; you can just make yourself all about that area directly and let the market tell you where gaps exist. What's broadly true is that heavy investment usually leads to the cost or "price" of that thing decreasing, as the usual plan is larger scale at lower unit cost.
I have an economics background so if I lost you there, it's my fault. But I really want to impress upon you that picking the right horse in this game of specializing for the new isn't that hard because the market is going to be fairly obvious about it. Why more people don't do it is because most people are busy being experts in other, older things. In this green field space, your "weakness" becomes a strength.
Plant your flag on fertile ground, and say, "this is what I do". It will carry you far.
p.s. Clone open source apps using your technology; demonstrate how it is better and make fixes where it is worse. "react-router" was built by early adopters of React who simply missed the old router from Ember.

  
## misc.md

      
    Raw
  

              misc.md
            
          
    https://jlongster.com/How-I-Became-Better-Programmer