On debugging

Dear new developer,

Debugging systems is a key skill to have. Here are a few thoughts about it.

Try to get the problem to be as simple as possible. Start with the problem and keep isolating and removing pieces and see if the problem persists. Modern systems are complex and the less you have to think about, the better.
Keep notes about what you’ve tried. These can go into a chat system if the debugging is high priority (on a production system during an outage) or in a private text document if the debugging is not (a bug you’re trying to understand).
Think about recent changes to the system if the bug is new. This isn’t always the cause, but it’s often part of it. Rarely does a system just degrade spontaneously.
Write an automated test to illustrate the bug (if possible). This will
- speed up your fix because it gives you a tight loop of run test, make change, run test, make change.
- ensure that your change actually fixes the bug as opposed to something else.
- provide a regression suite that will prevent this bug from popping up again.
Start at one end of the system or the other when you are trying to isolate the issue and see where it appears. For example, for a user facing web application, start with either the browser or the data store.
Minimize impact to users. If you are working on a production bug, ideally you can test on staging (right?) because this gives you the most latitude. However, if you do that, make sure that staging and production are exactly the same, otherwise you will chase your tail. Even if you have to test on production you can print debugging statements only for certain users (you or admin users) or to comments.
Start with a hypothesis and work to continuously disprove or prove it, refining it as you know more information.

Sincerely,

Dan

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.

Context is king

Dear new developer,

I put this image in almost every presentation I do.

pumpkin-boat

There are two reasons.

It’s a striking picture, and funny.
It reminds me that context is important. In some contexts, a pumpkin is a decoration. In others, food. In others, a frickin’ boat.

On that note, I recently posted my letter on admitting weaknesses in a shared slack. Some of the feedback was that this would be counterproductive to your career if you’re a minority or female.

Whenever you get advice, whether written or verbal, it is always worth considering the source. Here’s some context for me: I’m a white, heterosexual cisgender male. I have been a developer for 20 years. I have worked in the metro Denver area for my entire professional career. I have worked about half of my career in consulting companies and half in product companies. I have worked about half of my career as a contractor and half as a full time employee. Though I have worked for companies as large as Oracle, the vast majority of my experience is in companies with under one hundred employees.

What that means is that if you are looking to join Facebook, or if you are a female person of color, my advice may not be useful. While I still hope you find some nuggets of usefulness, some of it may be less helpful.

You wouldn’t ask a doctor for legal advice or a developer for medical counsel. It’s always worth considering who is giving you the advice and where they are coming from.

Sincerely,

Dan

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.

Are you ready to work remotely?

Dear new developer,

Remote work is fantastic. You avoid a commute, have control over your work environment, and save money on lunches. However, it has downsides. You need a fast internet connection, you must be disciplined, over communicate and stay on task. You have to be OK with relative solitude.

My desire to work remotely has changed over time. Frankly, for my first job, there’s no way I would have been happy working remotely. I enjoyed the collaboration, the camaraderie, and a place to go every day where there were interesting people. Even now, with Slack, Zoom and other modern tools, I’ve seen some new developers have similar concerns.

I do think that 100% remote work is different than “work from home once a week” or “work from home when you need to”. 100% remote work requires a different workflow, communication mechanism and concept of availability than those other options. Both of the latter options are really about providing flexibility and showing trust. They are great, low cost benefits for any software company to provide to developers.

Here is a one question test for anyone considering remote work. You can ask yourself this question and if the answer is yes, a remote position will likely work well for you. If the answer is no, then I think you’d be happier with an onsite position. By the way, some people are never going to want to work remotely for a variety of reasons, and that is no big deal.

That question is: “Are you comfortable asking a dumb question in public?”

You must ask questions that appear dumb when you get up to speed in any new company. Developers of all levels do this. Often it’s two levels of questioning. The first is “who can help with this?” and then the second is the actual question.

In a remote company you’ll have to accept that you are “interrupting” people and/or asking questions into a Slack channel. I have observed that both of these are more difficult when I can’t see the mental state of other people (as you can in an office).

You’ll need answers. So you have to be prepared to do ask these kind of questions, in public or interrupting someone you think might have the answer, over and over for the first couple of months of your remote job. Public questions are better for the team but harder on my ego.

If that thought of asking basic questions in public makes you uncomfortable, congrats, you’re human. But if it makes you want to run away and hide, then perhaps you aren’t ready for remote work. If you are interested in the flexibility and freedom of 100% remote work, wait a few years, practice asking questions and internalize the fact these kind of questions may feel dumb, but actually are just part of the process at any job.

Sincerely,

Dan

A bunch of career advice from a new developer

Dear new developer,

This post has a lot of great career tips including how to select companies to apply to, what to do in an interview if you don’t know the answer to a question, and how to challenge yourself in a new job. This piece of advice in particular resonated with me:

Show how you think

Most interview questions are there to see how you think. So show that! Explain your thought process, draw diagrams, write out the intermediary code, explain pitfalls in your approach, etc! Be vocal, and ask clarifying questions. That’s part of being a good developer after all!

When I was hiring, especially for newer developers, I really wanted to hear how people thought through a problem. That process is important in two ways beyond actually solving the problem. The first is that it shows how you handle something tough that you haven’t encountered before (which happens almost every day on the job). It also shows an interviewer how you communicate. Since a lot of the challenge of building software is communication, learning how potential team members do it is crucial.

The whole post, “The Career Advice I Wish I Had” is worth a read.

Sincerely,

Dan

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