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