Tag: senior developer

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.

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.

Be a great developer today

This is a guest post from Tim Tyrrell. Enjoy.

Dear new developer,

New developers are making mistakes. They are making mistakes every day. As a new developer, one’s job is to recognize one’s mistakes, implement a change in behavior, and help others implement that same change when similar mistakes bubble to the surface of one’s awareness.

Software has clearly identified patterns. Observer, mediator, singleton, bridge, and abstract factory to name a few. Some patterns that are less popular include active mentoring, maximizing pairing interactions, and self-imposed code review. These patterns represent a few of the necessary actions required to fast-track one’s rise from junior to mid to senior and beyond. We are all guilty of exhibiting some of the best and worst behaviors as new developers— myself included.

Say Yes to Everything

This may seem daunting, but it will force a new developer to continue to claw at the boundary of their own comfort level.

They might ask: “How can I say yes to a task if I’m not sure if I can actually accomplish said task?”

Generally, software developer === problem solver. One isn’t required to know everything when one walks in the door, but one is expected to leave work each day having laid a few more bricks on top of an ever expanding foundation.

One way to level-up quickly is to say yes to tasks that managers either (a) do not have time for or (b) assign to test one’s level of grit and determination. This will show superiors that one has the bandwidth for complex assignments and that one is willing to accept challenges outside of the expected range. Time spent carrying out these tasks is less important than clearly communicating progress, outlining steps taken towards accomplishing the tasks, and reaching out frequently to resources at one’s disposal in order to avoid impasse.

Once a developer begins to set a precedence for clear communication, progress, and accomplishment, managers and senior developers begin to trust that developer at their word, and they take setbacks as a sign of high complexity or fluid acceptance criteria rather than a gap in skill-set or effort level.

Does one’s team participate in local developer meetups? Have they asked you to come along or give a talk on a project one recently completed?

Say yes.

Are one’s peers interested in a hack-a-thon this weekend?

Say yes.

Does a recruiter want to talk to the new developer about a position that might be a good fit?

Say yes.

Not that interested in the position?

Say yes.

Not that interested in the company?

Say yes.

Interviewing is a skill that needs to be practiced like any other to achieve mastery. Better to improve this skill before one is in need of utilizing said skill.

Do Not Waste the Time of Senior Developers

Developer time is consequential and incredibly expensive. When a developer with more seniority takes the time to pair with a junior they are undoubtedly losing time they could be spending doing a number of other tasks that are all vital to the health of their team. Before asking for this highly valuable time, I encourage new developers to ask themselves a few questions.

  1. Do I clearly understand the components at work and how they interact in the system in question?
  2. Have I spent ample time reading about the nuances of my problem on Github, StackOverflow, Medium, and other outlets? Did I google my error message?
  3. Am I making assumptions that I haven’t been able to prove? Have I written any tests to prove these assumptions?
  4. Have I replicated my issue multiple times, so that I can clearly outline my process when the time comes to explain it to the senior?
  5. Have I taken time to write out my current questions and investigate them on my own?
  6. Have I asked relevant questions on our messaging medium — generally Slack — and taken time to investigate answers provided to me in this written medium?
  7. Have I taken a break, walked around, done some push-ups, absorbed some sunlight, and come back to this problem with fresh eyes?
  8. Have I clearly identified the gaps in my knowledge and exhausted all other resources on my quest to fill these gaps?

Each of these questions probably deserves its own article, but developers — myself included — have ceaseless amounts of work to do and a limited number of hours in the day.

One must understand how the pieces of the puzzle fit together and communicate at their synapses. What is each piece’s objective? Is it doing too much? Have I identified the failure down to the line number?

Do this before asking a senior for their time.

All of the previous questions lead us to researching our problem on the internet. If we are not first googling the error message and reading about prior encounters, then we can certainly improve our debugging process by doing so.

Do this before asking a senior for their time.

Assumptions have plagued me mightily in my first few years as a developer. They have been at the center of many of my mistakes. Writing tests represents a fantastic way to test assumptions at a fundamental level of input and output of specific methods. If one’s team doesn’t have any tests around the components one is interacting with, then add them. If one does have tests, then run them and use them to help step through the code and check the data at each intersection.

Do this before asking a senior for their time.

We must make sure we can clearly replicate behavior numerous times or at least replicate inconsistent behavior until it becomes inconsistent. If the process is large and requires many steps then start writing them down. It is possible that one’s process is the problem. This feeds back into avoiding assumptions. Do this to ensure that the maximum amount of time can be spent analyzing the problem in question instead of searching for the unknown problem.

Do this before asking a senior for their time.

Don’t ever be afraid to ask questions. But ask them in an order similar to this: 1. Ask the internet. 2. Ask oneself. 3. Ask the internet again. 4. Ask a developer that worked on the code most recently. 5. Ask in the team messaging channel dedicated to questions.

Do this before asking a senior for their time.

Get up from one’s desk. Go for a walk. Talk to other developers near the water cooler. Don’t stare mindlessly at a screen during this time.

Do this before asking a senior for their time.

Check and make sure steps one through seven above have been carried out. Still have questions? Go ahead and make sure that one can clearly articulate every step in the process necessary to explain the problem at hand.

Now, and only now, should one ask a senior for their time.

Be On Time and Be Present

Every meeting, event, stand-up, or retro takes up precious developer time. It’s a new developer’s job to gather the maximum amount of information available, ask questions to clear up confusion, and add input where they have it. If a new developer shows up late then that developer is a disruption instead of an addition.

Let me tell all new developers a secret; they aren’t valuable enough to be distractions. Don’t be one — ever.

Use these meetings to show initiative and communicate clearly. Do not allow one’s distractions to eventually become a nuisance for other team members. Eliminate distractions and engage completely with the team and with the current discussion.

Engage Fully in Code Review

This begins with reviewing one’s own code with precision, accuracy, and a level of criticism reserved only for oneself. Where did one make trade-offs? Comment on that line and explain why the code was implemented in this way. Where did the new developer choose performance over readability?

Start the conversation.

Own the work.

Explain why.

If one isn’t aware of the why around these decisions yet, then be prepared to be taken to school by the senior developers until one does understand.

When the new developer code reviews their own work then they once again save time for those spending their precious attention and finite cognitive energy reviewing that code in the future. Follow conventions. Check that one’s CI/CD build passed. Do not ever ask for the time of other developers without a thorough pass through from oneself.

Add a video to the PR that show’s the functionality that has been developed. Show one’s test suite running. Show the level of detail needed to be a great developer.

Review the team’s pull requests. Ask questions about code that doesn’t make sense, but not before asking the internet.

Ask about patterns.

Ask about performance.

Ask about refactoring.

Ask about trade-offs.

Ask about testing.

Ask about anything that doesn’t look like it’s been written with the utmost care. This will push one’s teammates to improve and iterate upon their work, and they will thank one for it as they level-up.

Start Mentoring

“But Tim, I’m the one that’s new here. I need more mentors! Not the other way around.”

The above statement represents a faulty mindset within many new developers. One of the most efficient ways to solidify one’s skills as a new developer is to explain known skills to others who have yet to master them. This leads to personal mastery of the subject being taught. The subject can be related to environment, shortcuts, workflow, data types, performance, logic, tools, and just about anything else.

I guarantee the foundation of a new developer’s knowledge includes skills that even seniors do not possess. Share these skills with fellow new developers and expand both network and knowledge within this process.

Did one go to a boot-camp or university to acquire one’s skills? Go mentor students.

Spend at least an hour a week doing this.

Is one in a boot-camp or university currently? Mentor more junior students.

Spend at least an hour a week doing this.

Is there anyone more junior or at a similar level — within a year — of experience at one’s current workplace? Pair with that person and offer them one’s help whenever they ask for it.

Spend at least an hour a week doing this.

Giving back will not only help a new developer achieve mastery and network expansion, but it will also help them experience happiness via altruism. This type of happiness compounds over time, and it will lead to fulfillment one never imagined.

Start Making Changes Today

Don’t wait to be a great developer. Be a great developer today. Then be a better developer tomorrow. Then share the secrets of success with other new developers.

Imagine the world that we can build together with this mindset.

Please reach out to me personally if I can help with one’s developer journey.

Be kind.

Learn hard.

Do good.

Repeat.

– Tim

This post was first published on Medium.

Tim Tyrrell is a Software Engineer at Crownpeak and Current Mentor and Mod-0 TA at Turing School. He is also a Game of Thrones conspiracy theory enthusiast/Repulsed by Flat Earth conspiracy theorists/Pun loving guy/Helper of people willing to put in the work.