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.

Learn SQL with sqlite

Dear new developer,

I wrote a post about learning SQL a while back. I posted the link in Lobste.rs, an online community, which generated some interesting comments.

One of them was that sqlite was a better way to learn SQL than using PostgreSQL or MySQL. This is due to the fact that there are some administrative tasks that could lead to possible confusion with those more powerful SQL databases.

I downloaded sqlite and agree that it is a super simple, low risk way for new developers to learn SQL. It’s a single zip file and you can create tables and run through tutorials without having to worry about what port something is listening on.

The flip side is it won’t be as applicable to your on the job experience. There are definitely people out there building wonderful solutions with sqlite. But I think for most typical new developers, an experience with a client server relational database like PostgreSQL or MySQL are more likely.

Here’s the download link, you most likely want the tools precompiled binary. And here’s a quickstart guide.

Sincerely,

Dan

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.

Listen to podcasts

Dear new developer,

Depending on what your life looks like, you may have some time where your body is occupied, but your mind is not. At least not 100%. Tasks like doing the dishes, running and driving all fall into that category.

In this extra time, you may want to listen to podcasts. Most smartphones have an app but you can install your own (I like PodcastAddict). Good podcasts:

  • expose you to new ideas (so you don’t remain an expert beginner).
  • reveal new technologies and tools.
  • are a source of wisdom and experience.

I think there are three categories of podcasts that you can listen to that will help your development career (I’m omitting lots of great podcasts by adding that clause).

  • Domain specific. If you work at a startup disrupting the real estate industry, listen to a podcast or two about real estate. Car insurance? Fashion? In each case you can find podcasts that are focused on your domain. You don’t need to be an expert in your domain, but the more you understand of it, the more able you’ll be to implement software in that domain and communicate with subject matter experts (SME) about the nuances of the problem space.
  • Technology specific. If you are writing code in Rails, listen to podcasts about Ruby and Rails development.  The same for JavaScript or C or Erlang or Lisp or … These podcasts will be helpful in terms of helping elevate your development skills in the particular language. They’ll also be helpful in making you aware of tools and libraries which will make you more effective. I like to email myself notes when I listen to these kinds of podcasts.
  • General software development. These podcasts talk about software development in general. Some are more technical and cover architecture or other interesting problems. Some are less technical and discuss the human side of software development. But these are the podcasts you are least likely to unsubscribe from when you switch jobs, because the topics are broad enough.

Don’t feel that you have to listen to every podcast episode. For these types of podcasts I don’t listen to every episode of any podcast, because no podcast is specific enough to what I need. I pick and choose based on the show notes and the guests. And don’t feel bad about unsubscribing when you switch industries or if a podcast is no longer of interest.

Sincerely,

Dan

Learn SQL

Dear new developer,

It’s a good idea to learn SQL (which stands for structured query language). This is the language that the vast majority of data is stored in for most companies. The reason for this is that relational databases (which is what SQL is the main interface for) are very good at a wide variety of data storage. Sure, at the edges of speed, scale and functionality there are other solutions, but you should reach for them when the relational database falls short, not at first.

You don’t need to be an expert at SQL, though it’s a mindbending way to interact with data, so you might want to put studying it on your list. Instead of being procedural or functional, SQL is set based. I confess, I’ve been using it for decades and still haven’t mastered it.

If you are using a modern language, there are often frameworks that sit between you and the database (for example, ActiveRecord for Rails, Hibernate for Java, SQLAlchemy for Python). These are helpful because they make simple operations simpler. If you want to look something up via primary key or a simple query, these tools can help. But if things get harder (joining across multiple tables, database specific functions) the abstraction breaks down. This is where knowing some SQL can be helpful.

There are also times when you are running queries that are punishing using a framework. For example, if you wanted to sum across a set of orders in a day to get a daily total, a naive framework would have to load all the data for the orders and then sum up the order value in memory. A more sophisticated framework would be able to generate SQL summing up the values in the database for you. Unfortunately, it’s hard to know whether the framework you are using is naive or sophisticated. But dropping into SQL will always work.

I have also found that some systems have a lot of non intuitive operations, but that at the end of the day, the magic is built on code and data storage. By looking at the data storage, you can understand some of the operations that these frameworks take care of for you. For instance, for a long time, rails migrations were magical to me. When I took a look at the database, it became clear that a fundamental piece of rails migrations was the datetime portion of the migration name stored in the database. When I got into a weird state because of running migrations then switching branches then re-running migrations, this understanding of the data structure behind them helped me out.

Some good resources to learn SQL:

One final note. People have very strong opinions on the type of SQL database they use (a commercial offering like SQL Server or Oracle, or an open source solution like MySQL or PostgreSQL). As a new developer, you want to learn whatever your company is using. Honestly, the difference between them at the basic SQL level just isn’t that large. They start to differ in more advanced SQL functions and other performance and administration concerns. But that’ll matter later in your career.

Sincerely,

Dan

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.