How to Develop Expert Intuition

This is a guest post from Kim Schlesinger. Enjoy.

Dear New Developer,

I know you worked hard to get where you are. You are self-taught, you earned a degree in computer science, or you graduated from a coding bootcamp, and your hard work helped you master the skills required to be a ‘junior’ developer. (I prefer the term early-career developer, but I’ll use the terms junior and senior developer in this blog post.)

Whether you are still searching for your first dev gig, or you’ve been at your first job for a while, you’re probably wondering what it will take for you to be a senior developer. There are lots of factors that contribute to being a ‘senior’, but the most important one is time.

It takes time to become a senior engineer because you are developing what behavioral economist Daniel Kahneman calls ‘Expert Intuition.’ Expert intuition is knowing how the story ends because you’ve read the book many times before. Expert intuition means that you can see a technical problem and you just know how it can be solved. Expert intuition is the difference between a junior and senior developer.

Kahneman says that the ingredients for this kind of expertise are

A Regular World + Many Opportunities to Learn + Frequent Feedback = Expert Intuition

Let’s take a look at what these things look like for a new developer.

A Regular World

A regular world is where there are a set of rules you can learn. For a new developer, that means a job where you can observe and begin to navigate your company’s culture. It also means having an opportunity to write code with a few programming languages, frameworks and approaches to deploying software. Even if your company’s culture isn’t great, or you’re not writing code in the language you prefer, your early experiences will help you figure out what you do and don’t like in a company, and if you’d like to specialize in a specific part of the software creation process, or remain a generalist.

If you’re still searching for a job, you can create a regular world by setting aside time each week to work through exercises on a learning path like Exercism, contributing pull requests to open source projects or civic hacking projects through Code for America and networking and applying for jobs.

Many Opportunities to Learn

As a new developer, your most obvious opportunity to learn is to write code and work on technical projects. Definitely do that, and know that another way to learn is to observe engineers that are more senior than you.

Pick one colleague you admire, and notice how they learn new concepts or technologies, how they ask questions in meetings, and what they do on a project before they start writing code. Ask to pair with this person, take them out to coffee and ask them what technologies they’re curious about, and how they approach writing code. As soon as you identify some of their signature behaviors, start to emulate them.

If you’re still looking for a job, find a streamer you like and copy their behaviors. I’m a fan of Coding Garden with CJ and Suz Hinton.

It’ll take time for you to make these behaviors your own, but being intentional with how your craft your developer habits and mindsets is a faster path to becoming a senior engineer than other, more conventional, learning opportunities.

Frequent Feedback

The final element that will help you develop your expert intuition is getting frequent feedback. You can get feedback from other developers through code reviews, you can get feedback on your technical and non-technical performance through regular 1:1s with your manager, and you can reflect and improve on your performance by keeping an end of the day journal where write down what you learned and how you felt during the day.

It Takes Time

In June of 2018, I took a job as an apprentice Site Reliability Engineer. Before that, I was a full-time educator, and part time JavaScript developer. I assumed it would take me a few months to figure out how my new company operated, and 6 or so months to get a grasp of cloud computing in AWS and Google Cloud Platform, Docker, Kubernetes, and the wide variety Continuous Integration/Continuous Deployment platforms.

I’m a year and a half into the job, and although I am more skilled than when I started, there is still so much for me to learn and do. Moving from web development to site reliability engineering is a big transition, and I underestimated hard it would be. I’ve made peace with the fact that it will take me years before I will be an expert. New developer, you’re starting a new career, and it takes years to grow into your professional self. It takes time, so be patient, and remember the ingredients for developing expert intuition.

Sincerely,

Kim

Kim Schlesinger is a Site Reliability Engineer at Fairwinds Ops. Prior to Fairwinds, she co-founded diversity, and was an Instructor, Developer, and Curriculum Designer for the Web Development Program at Galvanize, a codeschool based in Denver, Colorado.
In her spare time, Kim is a CrossFit athlete and the Head of Education and Content for Develop Denver, a 2-day conference for developers, designers, strategists and tech leaders.

Start the conversation

This is a guest post from Tae Kim. Enjoy.

Heyo!

So you’ve entered the world of… development? Software engineering? Programming? Coding? So many words for the same thing! I usually stick with “Software Engineering” for the resume because that sounds the fanciest, and fancy === money. But when my friends or family ask, I say that I do “computer stuff”. That usually works.

You’re probably thinking, “wow… what lame advice”. But you’ll see. You’ll see…

So about me! I’m Tae. At the time of writing this letter to my fantastic reader (YOU!), I’ve been developing for about 6 and a half years. I work at Airbnb in Silicon Valley. (If you haven’t seen the show yet (Silicon Valley on HBO), I highly recommend it. First season was the best, but you gotta watch ‘em all.) I primarily work in the Frontend realm, typing my 1’s and 0’s in Javascript and React. If you are still playing with jQuery… stop that and learn React. Trust.

But enough about me-self! Today I’m going to give you my one piece of advice. The one thing that I do that makes me successful at my job. It’s not coding really really fast. Nor is it knowing how to implement Quick Sort in O(n log n) time. It could be that my JIRA velocity is off the charts – but it’s not. No no no. It’s something far more crazy. Something far more insaneeee! It’s this…

When I’m at a good stopping point from my work, I step away from my desk, walk over to a random teammate (sometimes a random person), and ask, “Heyo, whatcha working on?”. Bat shit crazy right?!?

Well, the responses vary from person to person.

You sometimes get a short answer like “Oh, just fixing this bug. *turns back to monitor and puts on headphones*”. That’s totally OK, they are probably in the zone and you should slowly walk away. Try not to judge them too hard. *whispers asshole under breathe*

Other times, they have something super rad to show off like “Yo! I just fixed this crazy bug in IE. Check it out!”. These responses are awesome because you can dig in and learn something new. That same bug will show up in your work, it’s just a matter of time.

Then there are times when they say, “Yo… I have to fix this bug but have no idea what to do :sadface:”. That’s a great time to sit down and pair on a hard problem. Maybe you don’t know the answer, but you can be there for both support and as a Rubber Ducky (google: rubber ducky programming). Don’t be afraid to pull in other people around you and have a group brain sesh too, those are the best! #teamwork

These types of responses aren’t actually why I give this advice though. Learning and helping is great, don’t get me wrong! But this action is more than that.

You are being a teammate. You are building relationships. You are creating culture.

I know I know. How can a single question create culture? That’s nonsense!!! And I agree. But it’s a great start. It’s the doorway if you will. Once you enter, you then gotta walk the hall, turn into the dining room, sit down, and start eating. No really, grab a meal with your teammates too.

Sorry if that didn’t make any sense. I do that sometimes.

What I’m trying to say is that if you are genuinely interested in your teammates, they’ll recognize this. They will appreciate this. It’ll lead to way more than a simple IE bug fix. Hell, it might even lead to a new best friend!

I don’t think we join a company to sit at our desks alone, heads down, without wanting to speak to anyone. I think we’re just not comfortable making the first move.

But if someone begins the conversation, we’re very willing to reciprocate.

So start the conversation! Get people interacting! That’s what culture is. That’s what a fun work environment is. Ping pong tables? Those aren’t culture. Those are doorways to get culture (I know, the damn doorway metaphor again).

Airbnb has a slogan of “Belong Anywhere”. At first, I thought it was some cheesy line that our CEO preached. But I get it now. Especially in the world of developers, where it’s so easy to get sucked into your computer. It’s very easy to become siloed.

Nobody wants to go home thinking “Man, I don’t really have friends at work” or “Aw shucks, nobody said hi to me today”. That would suck.

Instead, what if they went home thinking “Oh man, I’m really glad I got to work with <insert your name here> today” or “Wow, I really love my team”. That would rock.

So be that spark. Create that culture. Because you are fucking awesome.

Tae

P.S. Say “Good morning” and “Good night” when you come in and leave. It’s better that way. Trust.

Tae Kim does computer things at AirBNB.

Cultivate the Skill of Undivided Attention, or “Deep Work”

This is a guest post from Josh Thompson. Enjoy.

Dear New Developer,

You know that there’s a chasm between your skill level and that of the mythical “senior software developer”.

If you build a list of topics you encounter on your job that, if learned to a deep enough level, would put you on the same level as a senior developer, you’ll end up even more demoralized than before compiling that list.

No need to assemble this list yourself! I’ve done it for you.

Here’s the list of topics that I’d need to dedicate significant time to, in order to close the gap between me and the senior developers on our team, that I’ve encountered in my last two days of work:

  • Breaking complex unknowns into simpler unknowns that can be further split into individual tickets
  • Adding tests to complex, legacy code, to guide further refactoring of said code.
  • Using `grep` to comb through server logs to diagnose a hard-to-identify-and-reproduce problem
  • Provisioning new servers
  • Building bash scripts to automate complex workflows
  • Digging into gem source code to can shed gem dependencies while maintaining certain features
  • Understanding indexing well enough to see that certain queries that we thought were using indexes were not, and fix this oversight index on the fly, without causing any blips in availability

Each of these line-items has many books written about the topic.

It seems like you could fill a bookshelf with books that address knowledge senior developers have available to them inside their own heads.

It takes me long enough to work through a single book, so imagining a bookshelf of extra-curricular reading is quite daunting.

It might feel daunting for you, too.

Leading vs. lagging indicators

The above list of skills is a lagging indicator of the underlying knowledge. We should not target improving lagging indicators, we should improve leading indicators.

Josh, what is this ‘lagging and leading indicator’ stuff?

Great question!

A lagging indicator is “evidence that something has already happened.”

If you got an A on a test, that is evidence that you learned the material.

A leading indicator is “evidence that something will likely happen”.

If you want to get an A on a test, you should study in a similar way as others who have gotten an A on that test. Maybe you need ten high-quality hours of study to get an A, so “number of high-quality study hours” would be a leading indicator of your grade.

We no longer take tests (phew. I hated taking tests.) but we get mini-tests of our knowledge, daily. We’re paid to solve problems, which often require learning new things.

Rather than focusing on a list of things other developers have learned, and targeting that list, I humbly propose that a leading indicator of acquiring this kind of knowledge is “hours per week spent in a state of intentional deep work”.

The above list of topics are lagging indicators of a high degree of technical knowledge. Someone acquires the knowledge, then, and only then, can demonstrate that they have it.

Leading indicators are “predictive”, in that if you can identify correctly those indicators, you can predict the outcome of the issue at hand.

In this case, the issue at hand is “become significantly more experienced in the domain of software development”.

I propose that a leading indicator of someone gaining these skills is the amount of time they spend in a state of deep work.

I’d encourage you to read Deep Work: Rules for Focused Success in a Distracted World. The author makes a case for deep work being a key role in the success of “knowledge workers” (which includes many types of work, including, of course, software development.)

If you’d rather not read the book, here’s the gist, from this summary of the book:

  1. In order to produce the absolute best stuff you’re capable of, you need to commit to deep work.
  2. The ability to quickly master hard things and the ability to produce at an elite level, in terms of both quality and speed, are two core abilities for thriving in today’s economy.
  3. “To learn hard things quickly, you must focus intensely without distraction.”
  4. “Your work is craft, and if you hone your ability and apply it with respect and care, then like the skilled wheelwright you can generate meaning in the daily efforts of your professional life.”
  5. “The key to developing a deep work habit is to move beyond good intentions and add routines and rituals to your working life designed to minimize the amount of your limited willpower necessary to transition into and maintain a state of unbroken concentration.”

Imagine two equally knowledgeable early-career software developers. They have the exact same skills on January 1, 2020. If the first software developer spends four hours a week doing deep work, while the second software developer spends fifteen hours a week doing deep work, their trajectories will be quite different, and that second developer will quickly gain technical knowledge and proficiencies.

So, if you’re an early-career software developer, track the time you spend doing deep work. That has you focusing on a leading indicator of growing in your skills.

At that point, you’ll benefit from Peter Drucker’s assessment:

What is measured, improves.

You’ll track how many hours you spend doing deep work, and by tracking it, you’ll do more and more of it.

In conclusion

Do more deep work, and over a year or two years, your skills will grow much faster than those doing less deep work. Eventually, you might find that you’re doing the work of a senior developer!

Good luck!

-Josh

Josh looks forward to being a senior developer some day. He’s only a few years into his career in the software development industry, but enjoys getting to bring knowledge and skills from his prior careers into his current role. He lives in (and works remotely from) Golden, CO, with his wife and loves to rock climb and read books, and can often be spotted in Denver-area climbing gyms or local crags.

Don’t be afraid to “fail”

This is a guest post from Cierra Nease. Enjoy.

Dear new developer,

“Failures” as a new developer are plenty — but you might be asking, why is “failures” in quotes? To fail something is dependent upon one’s perspective. The only true failure is to quit working towards success. Every failure brings a small success in that you learn what the right answer is not. How can you problem solve without a way of marking off solutions that do not work? A failure is simply a solution that didn’t work at that specific time.

We can all talk about how learning and growth come from having failures, but it’s hard to remember that when you feel like you are a failure. Failures do not inherently make the person a failure, and it can be hard to make that distinction in the moment. Sometimes we need someone else to remind us of this.

I’ve had a lot of people in life reiterate this concept to me. The most recent person was a fellow developer named Mike on the Denver light rail. It’s funny what will happen when people participate in communicating and interacting with each other, but that is for another blog post entirely. For now, let’s go back to Mike. Mike overheard me talking to another passenger about being in a bootcamp. When I finished my conversation, he handed me a card and said he’d love to answer any questions I have about becoming a developer. I elaborated on some of my bootcamp experience, which happens to be full of failures.

Mike expressed his number one piece of advice for any developer, telling me: “whatever you do, don’t be afraid to fail.” We started talking about this in depth, and it really resonated with me for the rest of the evening. As a new developer, you really only see senior developers’ successes. Each developer goes through their own learning process which does include failures.

The failures that lead to success don’t stop when you become a “better” developer. If you are looking for a point when you quit failing as a developer, then you are looking for the wrong thing. The more you fail, the more you learn. The more you learn, the more you grow. The more you grow, the better the developer you become.

As a newer developer, I look forward to all of the opportunities to learn, grow, and accept my failures as the wrong solution instead of accepting them as a personal characteristic.

Sincerely,

Cierra

Cierra Nease is currently studying software development. She blogs at Cierra Codes 101.

Three Mantras to Live By

This is a guest post from Dave Mayer. Enjoy.

Dear New Dev-

After 22 years of ‘production level’ experience in the real world, I’m writing to share three mantras that have led to more happiness and more success for us.

To be clear, these are DAILY mantras. Not weekly, not monthly, not annually. Daily.

They are:

  • Surround yourself with people smarter than you
  • Build community and give without expecting anything in return
  • Listen to your gut, without exception.

Surround yourself every-damn-day with people who are smarter than you

You’ll never be, nor should you, be the smartest person in the room. Confucius reportedly wrote ‘if you are the smartest person in the room, you’re in the wrong room’. Regardless of who wrote those words, they couldn’t be more true. Since high school, I’ve always known that I was smart, but I was also clear that I was not the best at everything and that everyone had something to help me learn or to help me become a better student or a better human.

I’m not suggesting you surround yourself with jerks with a ton of pretense who can’t stop talking about themselves and how smart they are, I’m suggesting that you learn to say ‘I don’t know’, ‘wow, that’s cool, tell me more’, and ‘yes, I could use some help’. Knowing that you will never have all the answers, that it’s okay to ask for help, and having an insatiable curiosity about engineering, life, music and anything that is important to you will get you far in life.

Build community and give without expecting anything in return

In 2006, going into the ‘Great Recession’ we sat in the back of the room at the Boulder-Denver New Tech Meetup and listened to Brad Feld talk about bringing people together and building community (in whatever area and subject that matters to you) with no expectation of anything in return. This idea of #GivingFirst was revolutionary to us thirteen years ago, and it’s been a life-changer for us. It’s a super simple yet elegant idea of walking into a room and asking how you can help someone solve their biggest challenges rather than where-do-they-work-or-what-kind-of-car-do-they-drive. We wrote a detailed article about this topic for CTO Lunches Magazine on page 29- give it a read. It’s truly been life-changing to help others and embrace that as a BUSINESS philosophy, not just a life philosophy. It will all come back to you, you just don’t know how or when, and that’s OK.

Listen to your gut, every day without exception

It sounds simple, but not everyone does it. Your intuition is always right, yet folks second-guess themselves, rethink things and question their own motivations. That’s all healthy, and yes, you should ‘sleep on it’, whatever ‘it’ is. Space gives clarity. In large decisions, I ALWAYS take at least 24 hours to think on what the right answer is for me, and to listen to my gut. It’s NEVER failed me and it will never fail you. I promise.

I hope you will consider even one of these three mantras. You won’t be disappointed.

– Dave

Dave Mayer is a long time community building advocate, and by day he’s CEO of Technical Integrity, a boutique recruiting firm focused on building diverse executive and technical teams for startups in Colorado and beyond.

Don’t try to change the tabbing / bracing style

This is a guest post from Andrew Rondeau. Enjoy.

Dear New Developer,

Don’t show up an a new job and immediately try to change the tabbing and/or bracing style. This is especially important if the codebase you work on has a very consistent style that all of the other developers follow.

Why? Tabbing and bracing styles are really a matter of personal preference. What’s important is that the codebase is readable, and keeping a consistent tabbing and bracing style is more important than having your favorite style. Furthermore, because tabbing and bracing styles are really a matter of personal preference, arguing with the more senior developers about this topic is a waste of everyones’ time. The senior developers, or your manager, will probably assume that you have poor time management skills, or that you get obsessed with details that don’t matter.

And, yes: An interesting discussion can be had over the merits of tabs versus spaces, or the merits of braces before or after the newline. The problem is that some people really get irrationally attached to whichever style they are used to. These discussions don’t fix bugs or deliver features that the business needs to survive; thus, don’t waste time and stick with whatever tabbing and bracing style your codebase uses.

When is it important to discuss tabs versus spaces, or bracing styles, as a new developer? When a codebase has an inconsistent style, especially if it doesn’t match a team’s style guide! Politely point out to your manager, or lead, that there is a lot of inconsistent use of tabs and/or braces; and suggest a tool that will automatically reformat the code. Perhaps suggest a style that a well-known open-source project uses, or a well-known style guide published by Microsoft or Apple. At that point, it’s your manager or lead’s discretion if your team will adopt a new style.

If your team does agree to change the tabbing and/or bracing style, don’t do it gradually. Why? Again, a consistent style is more important than being able to write code with your preferred tabbing or bracing style. Inconsistent code is harder to read, and confuses people about what the established style really is. It also tempts people to stick with their preferred style, instead of whatever the team agreed to. Instead, use an automated tool to reformat the code.

— Andrew

Andrew is the desktop client architect for Syncplicity, a file synchronization product. Here’s his LinkedIn profile.

Learn a Little Network Engineering

This is a guest blog post from Allan Wintersieck. Enjoy.

Dear new developer,

I realize that just trying to learn basic programming principles can feel daunting enough, but if I may, I’d recommend adding one more task to your list: learn a little bit about network engineering.

Networking underpins everything web and app developers do, since almost every web app communicates from the frontend to the backend regularly. Most developers understand the basics of making API calls and how data flows over the internet, but taking a small dive deeper will help you debug issues for years to come.

The goal is to build your underlying knowledge so that when you encounter related issues in the future, you understand enough about how it all works to intelligently tackle the problem. For example: the reason everyone complains about CORS (Cross-Origin Resource Sharing) being confusing is because it doesn’t make sense without first understanding the basic principles of networking and security.

A quick list to get you started:

  1. Read up on the basics of routing. No need to dive into how the protocols work, but understand why it’s set up this way and how internet traffic gets to where it needs to go.
  2. Read the basics of DNS, and understand how a DNS request is resolved.
  3. Read a brief rundown of the OSI model. Focus on understanding one or two examples of things you’ve dealt with in the past that exist at each layer.
  4. Review the difference between TCP/IP and HTTP, and why they exist at different layers in the model.
  5. Read up on the basics of what a “proxy” is.

An overall analogy that I find helpful: networking is like sending mail via the postal service.

  • Routing is the process of putting mail in your mailbox, having a postal worker pick it up, and it eventually reaching its destination.
  • DNS is the process of looking up someone’s mailing address so you can send them mail.
  • The OSI model is a fancy name for making it clear that there’s a lot of details the postal service takes care of for us. Most people understand how addresses and mailboxes work (let’s call that the equivalent to the Application layer), but don’t really understand all the internal details of how the postal service gets your mail to its destination. All those details are the first 6 layers of the model.

With that background knowledge in place, tackle some of these additional questions to lead you to more learning:

  • How do CDNs (Content Delivery Networks) work?
  • What’s the difference between “regular” HTTP and WebSockets?
  • How does SSL (HTTPS vs. HTTP) work, at a high level?
  • What can nginx be used for?

And as a last exercise, sketch out a complete picture of a work app or side project: what DNS calls get made, what servers are involved, are there any proxies, what protocols are in use, what OSI layer those protocols exist on, etc.

I promise that spending the first few years of my career as a network engineer only slightly biases me towards learning this stuff.

Sincerely,
Allan Wintersieck

Allan Wintersieck is the CTO and co-founder of Devetry, a software consultancy in Denver that provides strategic partnership for software architecture and engineering.