Develop empathy

Dear new developer,

Right now you’re probably a bit frustrated and confused. You’re learning a lot of things and you don’t really understand everything. Sometimes things click and it all makes sense, other times you’re confused and staring at what feels like a brick wall. Perhaps you just want to make things work and they won’t.

Good.

I say that not because I’m a sadist or dislike you. I say that because I hope you’ll remember the frustration you are experiencing right now. I think that will make you a better developer.

Why?

Because that is the state of 99% of your users. Whether they are a business employee or a person trying to use your app for personal reasons. They are just trying to finish a task and get on with their life. The software you are writing is the tool they are using to do that.

  • They don’t care about elegance of code.
  • They don’t care how much you love to develop.
  • They don’t care if you are learning and growing.

They just want to finish their job, complete their task, do their thing.

And, honestly, the tools we provide are frustrating. They’re buggy. They’re slow. The fact that they are amazing compared to what we could create a few years ago and that they are better than the alternative is beside the point.

I don’t write this to cause despair, new developer. Progress is being made. But it’s made one person at a time. Each person has to act with empathy toward their frustrated users. Understand them. Care about them.

And if you can remember the frustration you are currently encountering, perhaps you’ll have just a bit more empathy toward your end user, who is just trying to use your work product to get something done.

Sincerely,

Dan

Leveling up tips from Chelsea Troy

Dear new developer,

I found this video from Chelsea Troy about how to level up as a developer interesting (I love watching YouTube videos on 1.5x speed to save time):

A few tidbits I found interesting:

  • the distinction between leveling up passively (which we all do as we learn in our daily work life) and leveling up actively (with a goal)
  • the importance of routine in this deliberate leveling up process
  • the idea of commit tracing as a way to learn a system (yes, version control is important)

You can also read the transcript.

This section about reaching out to experts also resonated. If you take the time to craft a good question, you can get the attention and help of even busy people.

Third, if I am struggling to find the answers to my questions in literature, I find myself asking, who can help me? I think it’s easy, especially in tech, to feel like you’re alone and you need to be able to solve problems yourself. But I have found that not to be true. Sometimes it’s a matter of reaching out to a coworker or colleague to get another set of eyes on whatever I’m working on. If that doesn’t work, then I’ll ask an expert. And I have been repeatedly surprised by the generosity of experts. The first time I ever needed to implement Spring Batch in something, we had a complicated use case and I somehow just couldn’t get it to go. So I reached out to the team, and one of the Spring core contributors pair programmed with me to get the thing working. Another time, I was working with XGBoost, which is a machine learning library that relies on a particular, custom-crafted data structure called a DMatrix. But I couldn’t find anything online about how the data structure was built, so I reached out to a developer advocate on LinkedIn, and she gave me an insightful answer.

I’m not saying her system will work for you wholesale. Whenever you’re learning what worked for someone else, you want to evaluate the methodology from your perspective. But she definitely has great ideas (she blogs on leveling up a fair bit) and I’d suggest you listen and try out the ones that excite or interest you.

Sincerely,

Dan

Software is about people, not code

Dear new developer,

When I was starting out, I thought that software development was all about code. After all, that was the main thing I was working on. Well, maybe not the main thing, as I needed to know what code to write, how to interface with other code, what was the problem being solved, how to deliver it, the correctness of the code, and how it could be maintained.

But, the writing the code felt like the most important part of the job. It was certainly the most tangible and fundamental. After all, if the code doesn’t work, all those other things won’t matter, right?

This led me to focus on how to write code. I wrote up a style guide for the company. Researched new technologies. Read and commented in online forums. Learned how to decompile java bytecode to reverse engineer proprietary software. Argued about code formatting. Joined a design patterns discussion group. Attended meetups and blogged.

I undertook all of these activities to be better at writing code.

However, I eventually learned that people were far more important for the success of a software project than code. This crystallized for me after I saw a few very interesting (to me!) codebases abandoned for lack of a market or other business flaws.

This was a surprise to me, insofar as I’d assumed the code was the most important part of software development. But really:

  • Software and code is created for people and their purposes. It doesn’t exist on its own, isolated from human needs.
  • People will use the tools or applications built with code (or, worse, they won’t). This means that they have to be bought in to what is being built and consulted about functionality.
  • Most people don’t know or care about the code. (If they did, they’d likely be a developer.) They’re just trying to get something done. The most beautiful, well tested, flexible, configurable, documented, future proofed codebase that does the wrong thing is useless.

At the end of the day, code is a general purpose tool, just like accounting or research and development. Code must solve real world problems of real people.

Sincerely,

Dan

Things good engineers do

Dear new developer,

I found this post covered some things that good software engineers do. It doesn’t focus on the technical aspects, but on other aspects of software development. Things they do:

  • Ask for help
  • Work on one thing at a time
  • Prioritise unblocking

My favorite quote:

In software development we rarely have the luxury of a todo list with a single item on it. Despite this, we are not able to work on two things simultaneously. Every time you work on one thing and change to another you pay the cost of mentally (and sometimes in development environment) context switching. As a result the most efficient way to work is generally to take one task to completion before starting another task.

These are all key things for engineers to do. The first makes sure you aren’t beating your head against the wall unnecessarily. The second makes sure you can focus on one thing and avoid context switching. For many kinds of development work, this is the most efficient way to accomplish a task. The third acknowledges that you should optimize for team productivity over individual productivity.

Three great pieces of advice. Worth reading the whole post, “Some Things Good Engineers Do”.

Sincerely,

Dan

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.

  1. It’s a striking picture, and funny.
  2. 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