ian geckeler

Want to learn how I read 100 books a year?

    Don't be a T-shaped developer, do this instead.

    Jun 26, 2020

    I recently stumbled across Shawn Wang's work online. After loving his blog content and message to #LearnInPublic, I decided to go all-in and support by pre-ordering his book Cracking the Coding Career. I wasn't disappointed. Here's a preview of the top 15 takeaways I got from the book, but you absolutely have to get it and read for yourself!

    Learn In Public.

    Software engineers are professional learners, and Shawn has created the perfect framework to thrive as a professional learner: #LearnInPublic. The approach is very similar to that of Show Your Work and Gary Vaynerchuk's "document don't create". Learning in public means just that, sharing what you are learning to the world. By taking the extra time to document and share the output of your learning process, you have a perfect one-two punch of 1) building your brand and 2) solidifying your learning through teaching.

    We are all learning and Shawn suggests starting small... going from sharing 0% to 5% of what you learn to start. As we know, small habits can take root and become much more. A few twitter posts as you're reading through the docs of a new technology can quickly turn into a blog, a blog post can turn into a talk, and talk can turn into a new job opportunity. Understanding that you can do that all while creating value and helping others you are one step ahead of is why I absolutely love this message.

    Pick up what people put down

    The first habit of The 7 Habits of Highly Effective People teaches us that we should be proactive.

    99% of people consume content passively and only 1% consume actively. This reminds me of something I once heard: at a conference, many speakers will share their email and ask the audience to reach out, and only about 1% of the audience ever does. The same trend, perhaps even more drastic, occurs online.

    Don’t be that 99% of people, the passive and timid learners. One of the best ways to be in the 1% is to "pick up what people put down". The next time someone you admire puts out a course, a recommendation to check out a new technology, or gives a talk involving a new design pattern or technique, go out and proactively take their recommendation. Take their advice and build on it; incorporate it into a new app, summarize their post, do something with it and share your progress. In other words, be proactive and and show your work to the person who put it out the call to action.

    The worst case scenario is that person might not respond, the best case scenario is that they may see your proactivity and decide you're the kind of positive person they might want around in their life or company.

    "You can learn so much on the Internet, for the low, low price of your Ego" - Shawn Wang

    It's all about the people

    Ever heard that there are two types of people: “people” people and “things” people? Engineers are typically characterized as "things" people: introverted geeks who care more about systems and things than about flesh and blood humans. This an unfair characterization, but I can admit to undervaluing the importance of relationships in work and in life. The truth is, life is about people, the relationships we build, and the value we provide those around us. As much as it seems like code and technology is the end all be all in this industry, Shawn reminds us that our careers hinge more on people than any other factor.

    Your professional relationships will outlast your current job. The relationships you build on Twitter will outlast the latest hashtag fads of the day, maybe even Twitter itself. “Play long term games with long term people.” Surround yourself with incredible people and learn to provide value to them. It will work if you just do those two things.

    Subhead: How to behave on twitter

    A good rule of thumb: Keep it 90% positive, 90% professional. Your goal on twitter should be to GET OFF twitter... get out into the real world, turn that retweet into an email or phone conversation. Make a friend, build something together, meet at a conference. All the magic happens offline!

    Specialize in the New

    Not all technologies are created equal. As a former bootcamp grad, the power of specializing in the new is definitely something I can attest to. I've seen tons of bootcamp grads go on from zero experience in programming to a job in three months because they specialized in the right up-and-coming technology. It’s much easier to stand out and be competitive in a new technology. All of those job postings harping: “10+ years of software experience building production-grade apps in C++ at Google don’t make sense when the tech has only been around for 1 year. As software engineers you can stand out by specializing in the new.

    Right now Typescript and Node.js are to software engineering as software engineering is to traditional white-collar professions. It takes three years to become a proficient mid-level developer. It takes 5-10 years to become a mid-level lawyer or doctor. Likewise, it takes 3 months to find a job as a TS developer, whereas it might take more than a year to find a job as a C++ developer with no experience.

    Don't try to be a T-shaped developer, do this instead...

    When given a chance, specializing is better than generalizing because you will likely be a generalist by necessity anyways. It’s not like you can work on your app’s authentication system without partly knowing something about basic authentication patterns.

    Now Shawn never explicitly shuns the T-shaped developer concept, but I thought it would make for a heretical article title. Sorry Shawn if that mischaracterized your work!

    Instead he mentions that the real important thing is to have at least one sort of deep area of expertise, and to not restrict yourself to one area just to “fit the formula”. He mentions the possibility of becoming a PI-shaped developer (two areas of specialty) or “comb shaped” (multi-expert) developer as an alternative approach.

    After also reading Scott Adam's How to Fail at almost... realizing that the magic often happens when you combine two great skills.

    This approach has two key benefits that I can identify.

    • You are more anti-fragile to existential risks (you’re not screwed if your technology dies)
    • It’s just more exciting to have multiple areas of expertise and to diversify your learning

    Have a toy app

    This is the upshot of two important principles:

    1. always be learning
    2. if you want to make a habit out of something, make it as easy as possible.

    Shawn recommends having a toy app that you can easily edit and play around with new technologies to experiment with.

    Right now I'm considering creating a very simple to-do list or Trello-clone with the stack I've used the most in my career: React, Redux, Typescript, Node.js, Express, Postgres, with traditional cookies/sessions auth. And then experimenting forking that repo and playing around with it... how does this feel when I use Gatsby.js or deploy it on Lambdas, can I use Istio in the backend?

    With awesome technologies like CodeSandbox and Netlify that make deploying and testing apps easier and easier this really is a low-friction no brainer to try.

    5 types of developer career paths beyond IC

    Shawn does a great job of illustrating potential paths outside of IC in the section "Beyond the Senior Developer”. As a proponent of "beginning with the end in mind" I have been wondering how long I want to pursue the IC route and what possible paths lie open to me.

    Here are five major options Shawn outlines…

    developer relations - a great opportunity to build your brand and shake things up if you want to learn more into your marketing and people skills

    engineering management - an incredibly deep and rewarding field for those interested in leadership (not an irreversible path)

    product management - awesome way to get more high-level involvement and decision making in a business context while still having a foot in how things are built, great for those entrepreneurial minded

    entrepreneurship - a high risk high reward high autonomy move, but important to weigh out the high opportunity cost given the high developer salaries

    dev education - a great way to side-hustle and potentially gain financial independence if you are willing to take the risk and commit to building a brand and producing great content

    I came away with two main impressions

    1. how incredible it is to be a software engineer to have so many opportunities for growth
    2. None of these paths need be reversible, it’s technically possible to mix and match and in fact doing so might really provide even greater fulfillment and learning as you grow into each skillset

    Negotiating is the Highest ROI Skill You Can Learn

    This was something I was already aware of because I’ve experienced it firsthand. Spending one hour learning better negotiating tactics can likely lead to hundreds of thousands of more dollars over the course of your career. Needless to say learn to negotiate. Shawn's book and this article can help with that.

    Four Types of Learning

    Shawn has an interesting, 4-pronged approach to learning in public that he calls Learning Gears I would love to share here.

    Exploring - this is the low commitment type of learning you do when you are first starting out Learning in Public. At this stage you don't have any niche areas of expertise and are more learning to get the lay of the land, you spend your time sampling various areas for things that interest you. You can still share what you are learning, but your focus is more on self-development.

    Settling - at this stage, you may have identified a niche topic or area that interests you, here you commit to learning more about the topic and following the resources that experts in this area have laid out and sharing as you go along, the goal is to become proficient at the topic

    Connecting - (he recommends spending most of your time here) at this stage, you may know enough about your topic to be able to help other explorers. Now you shift your focus to producing content that is beneficial for others through talks, books, blogs, courses. Your focus is more on presentation and making your content valuable to others.

    Mining - this is a rare stage you may get to when you have become a pioneer or master over a topic. At this point, maybe a particular topic or subject has fascinated you and you find yourself well-poised to produce value that no one else has ever discovered. You now essentially go into a hole with the intention of coming out with a groundbreaking book, course, framework that can revolutionize your topic.


    Writing is eternal. Writing helps you think more clearly. Writing well makes you appear intelligent. Software engineers use writing for almost everything that they do. Remote work writing becomes everything.

    The value of writing cannot be understated. He recommends developing a writing habit every day. Even giving yourself a "DIY Ph.D" by writing a million words... that's 1000 words a day for 1000 days... you can do the math on the other ways to get there! I’ve personally seen how 50% of my job is writing code and the other 50% is writing English: design documents, coordinating with other stakeholders, writing and detailing tickets and documentation, project proposals.

    This book inspired me to make writing more of a regular habit.

    Sad but true Biases

    Two obvious, but important biases to keep in mind as a developer:

    1. Big company names on your resume can help you A LOT
    2. Your ability as a dev is often equated to the renown of the companies you work for

    How to hack your knowledge

    Shawn mentions his “Watch Later” on YouTube has over 400+ tech talks. This helps keep him sharp and inspires and gives him ideas for his own talks and blog posts. I absolutely loved this idea and am going to start compiling my own tech-talk backlog!

    The best way to onboard at a company

    Write tests. This was an incredible tip and an activity that greatly helped me ramp up in my most recent company.

    The main reasons to write tests are the following:

    • Writing tests can’t HURT, so they are low risk
    • End to end and integration tests will force you to understand broad swaths of the codebase
    • No one is going to complain about it
    • It’s an opportunity for you to work with your peers and gain tips on the codebase from them
    • It markets you as someone who cares about code quality

    Identify and ride the mega-trends

    We've already discussed the importance of being ahead of the curve. So much in the tech world relates to timing. For that reason, Shawn recommends keeping tabs on mega-trends: i.e. cloud computing, AI, low/no-code, to make sure that you are positioning your career to catch the wave of disruption rather than get shipwrecked by it.

    Two great proxies he recommends are to:

    1. focus on consuming people not news - follow individuals who have great vantage points: CEOs, CTOs, tech bloggers and other developers you trust. Keep your head to the ground by paying attention to these quality sources and let them screen out the signal from the noise for you.
    2. watch for big-company adoption - if a large company has adopted a new technology, you can bet they've put a lot of thought and effort. They are putting their money where their mouth is and you can also count on greater support for the tech moving forward. Think about the following: MongoDB, Kubernetes, React, Typescript. These have all been spun out and or adopted by mega-corps.

    Stages of keeping up with new technologies

    Shawn recommends four buckets to place potential new technologies in:

    Adopt - adopt means you use this regularly in your work/side-projects, you are making it an active area of specialization. These are technologies that you are in for the long-haul on and can build your career around

    Trial - these are technologies you fiddle with in your free-time and explore. Maybe they are adjacent to your space and are up and coming but not proven yet. It might be good to subscribe to good sources of knowledge or podcasts in these areas and play around with them and test them out to see if they should make it into your adopt category

    Assess - these are technologies that you are keeping tabs on. Maybe they are further out from immediately impacting you, or are far outside your area of expertise. It might be good to consume news on these occasionally and keep tabs once a week or month, but not let this consume too much of your time or energy

    Hold - you're not worrying about these too much. maybe they are way too early in the hype cycle or just are too tangential to your career.

    Personal branding 101

    I think Shawn's tips on personal branding come down to two core factors

    1. stand for something unique
    2. be consistent and shout that message and shout it from the rooftops

    From the 22 Immutable Laws of Branding: the key to branding is to be a category leader. To be a category leader you have to create your own category.

    Shawn recommends finding what exactly you stand for. You can start by paying attention to what other people might say is unique about you. Otherwise take your best guess and plant the flag in the ground. You can always change it later. It’s just important that you PICK SOMETHING.

    I certainly have this problem. I have so many different passions and areas of interest and that makes it hard for me to have focus, but I know that focus is crucial to developing a perfect brand.

    Shawn provides two great templates for you to provide a personal brand:

    1. What you do + who you do it for
    2. Identity + Opinions

    If I were to try this:

    1. I’m a software engineer obsessed with distilling lessons from the very best role models and resources.
    2. I'm a software engineer who thinks that the best way to become a successful engineer is to spend time around successful engineers.

    Needless to say, I have a long way to go, but it’s a start, which is more than I had before this book!


    Seriously though there was so much value in this book, I've provided not even 2% of what is contained in this beast of a tome. Thank you to Shawn for an incredible read and I look forward to sharing more of my learning in public journey. Thanks for reading, and BUY THE BOOK.

    Want a better brain?

    Learn the exact techniques I use to read 100 books a year.

      Unsubscribe whenever you please, I won't be mad.

      Hi! I'm Ian Geckeler. I read 100 nonfiction books each year and share the best of what I learn! I'm also a Software Engineer at Hello Alfred. Previously Growth at CoEfficient Labs and B.S. Computational Math at USC. Follow me on on Twitter!

    • Github