Think first about what problem this is solving and for whom

This is a guest post from Kate Catlin. Enjoy.

Dear new developer,

Welcome to tech! Wow, I remember those days– Confusing, exciting, challenging. Nothing is certain except that you are in for a wild ride. Hold tight!

The advice I’m writing to share with you today is this:

Before you write any code, think first about what problem this is solving and for whom.

As a little background, I’ve spent my whole career in tech. I’ve had two stints writing code (once in Android and once in Ruby) and neither lasted long. The rest of my career was a journey through Community Management, Sales, Startup Foundership, and now Product Management. While I love code, I love understanding people’s problems and figuring out how to solve those as well. That side always sucked me back in.

Even in my roles where I wasn’t a developer, I’ve always interacted with developers. Many of them were new to the industry, just like you. The ones who have since excelled in their careers were the one who embodied the advice I just shared.

And so, every time you pick up a new Jira ticket or sit down to complete a new requirement, I suggest that you ask yourself the following questions:

Who does this solve a problem for?
What is the problem they’re trying to solve?
How does this ticket solve it?

There are three reasons this is going to help you out.

First, it will keep you motivated.

I think software development is one of the closest real-life professions to having superpowers.

Why? Because your job is to use skills that most don’t have or understand in order to solve someone’s problem.

Some of the problems you’ll solve may be big– Maybe you’ll work on an app that facilitates financing for renewable energy and measurably reduces climate change emissions. Some problems may be small– Imagine someone quarantining alone who misses their grandkids and has tried not to cry all day. Perhaps they have a slightly-less-frustrating time ordering a gift to send someone because you fixed a bug in a website’s UI.

The world is a tough place to exist sometimes, especially in a pandemic. As a software developer, you get to use your powers to help make life a little easier for people. Remember that! Focusing on the problem rather than other things (like the shiny tech) will help you do so.

Second, because you can start to push back if you see an easier way to solve that problem.

A few months ago, I prioritized a new feature for CircleCI that would allow software developers, our users, to import Environment Variables from one project to another. I wrote up a long list of acceptance criteria involving multiple screens and checkboxes.

The junior developer who picked up the Jira ticket for that feature was someone who regularly practiced user empathy. He paused, thought about it, and then suggested a simplified approach.

The simpler version worked! We were able to ship the feature in half the time, and it still resulted in a measurable lift to organizations adding new projects. This was good for the user, good for the developer, and good for the company.

This is just one example of many I can name where by embracing user empathy, our team has solved more people’s problems faster. And so can you!

Third, because it’s how you advance in an organization.

Product thinking is so important at CircleCI, it’s a skill we specifically review our developers for during our annual review cycle. A minimum-threshold rating is necessary for a promotion.

This is obviously not true of every organization, but in no case will the mindset not serve you well. Leaders simply need to understand why we’re building what we’re building for our users. How else could they help us achieve the future we’re working together to bring about?

I would love to hear how a user-empathy mindset works for you.

Everyone’s path is different, and every organization values different skills. You can find me on twitter at @Kate_Catlin, and I’d love to hear from you!

Sincerely,

Kate Catlin

Kate Catlin is Senior Product Manager of Growth at CircleCI.

Why and how to improve your writing skills as a software developer

This is a guest post from Allie Cooper. Enjoy.

It’s one thing to be able to write good code, but professional written communication is something else entirely. The ability to efficiently and authentically communicate using written language is an often ironically underrated skill in software development.

This is something that new developers need to get over very quickly. “Obsessions with patterns and algorithms don’t serve anyone’s mission by themselves,” explains engineer and career coach Minh Pham. “While coding might be your latest skill set, it is by no means an engineer’s only skillset. Remember that at the end of the day, it doesn’t matter if your code is ugly, fancy, verbose or concise – the value you create matters. Strive to be an excellent communicator, a quality teammate, and an outstanding human.” In today’s increasingly digitized workplace, achieving these qualities means honing your professional written communication skills.

Writing is Essential to Software Development

Any veteran developer can tell you that non coding-related writing is part and parcel of the daily grind, which includes writing tons of bug reports, notes for yourself, documentation for co-workers, and other technical discussions over chat or e-mail. You might also be tasked with explaining technicalities in ways that can be easily understood by clients. And as Inc points out, all of this generates a permanent record of any and all significant ideas, incidents, and other facts pertinent to how you’ve handled the job. In software development, the way you write and communicate over work platforms defines a great majority of your work history.

While writing code defines your raw ability as a software developer, your written professional correspondence tells the story of your ability to work with others in an inherently collaborative and complex field. Today, the sudden digital migration brought on by the global health crisis has only made professional writing a more integral skill for thriving in the new and increasingly web-based workplace. This is as true for experienced developers as it is for those who are looking to pick up the skills necessary for the job, which brings us to our next point.

The Future of Coding Education is Written and Online

From basic coding courses to advanced degree programs, more and more future developers are learning essential skills through online means. And the pandemic has only increased their numbers. For instance, Code Platoon Coding Bootcamp online basic coding courses have allowed the U.S. Department of Veteran Affairs to continue offering software development skills training for veterans as well as their spouses. And for safety reasons, all classes have been moved online.

Meanwhile top universities have also made this switch to training software specialists online. Maryville University’s online masters in software development is an advanced degree program that’s 100% web-based as well, with the perspective of producing future software consultants, UX designers, web developers, and DevOps engineers. And while these programs do include video conferencing classes, the majority of the work is through written communication. As natives to online work, the developers trained in these online programs are already developing the writing skills necessary to thriving amid the current digital migration.

In short, the field of software development is only getting more competitive and web-based. And while there’s no shortage of genius code writers for companies to cherry-pick from online universities and coding courses, the combination of a great coder and a great online communicator remains rare.

Practice Makes Perfect

Whether you’re already coding for a living or still learning the skill, you already have plenty of opportunities to hone your professional writing skills. Strive to be succinct and straightforward with every chat message or e-mail before hitting send. Put yourself in other people’s shoes – think about how the message you wrote will affect you if you were the one to receive it. Remember that every unnecessary word only muddles already complex conversations about technical specifications. Grammar is important, but so is writing with the perspective of being as empathic and as concise as possible – which can also allow you to develop a writing style that won’t require grammatical gymnastics. Never play to your emotions and always write with a collaborative mindset. The better you can communicate with the written word, the more value you can bring to any software development effort.

Allie Cooper is a freelance tech writer who specializes in I.T. and software development. Her mission is to help software developers further their careers. In her free time she plays online chess and sails.

Understand the use case

This is a guest post from Christie Brandao. Enjoy.

Dear new developer,

It’s easy to get wrapped up in only focusing on the deeply technical aspects of your job, especially if many parts of the stack have technologies you haven’t worked with yet. As your career progresses over time, you will be improving the quality and readability of the code you write as well as your problem-solving skills. This takes deliberate practice, but you’re already used to this! At the beginning, it’s natural for all your energy to go towards getting up to speed with the codebase and learning how everything works together. My advice is to take some time to also understand the use case.

At the core of it, your job is to be building something that will provide a positive business impact through your development skills. Ignore the urge to dive right in and start coding and instead, take some time to learn the bigger picture. Focus your energy on gathering as much information as you can to start building your foundational knowledge of this area of the product. You can start small! When asked to build upon a feature, for example, don’t just take the ticket at face value. Ask questions (to yourself or others) about how the current feature is currently working. What are the difficulties people are having using this feature? How is this going to be an improvement to the current process? Once you have a good grasp on the ticket level, it’s time to learn about the bigger forces that impact larger business decisions. You never know, maybe your fresh perspective will offer valuable insight that no one else has brought to the table.

— Christie

Christie Brandao is based in Columbus, Ohio. She is a Full Stack Serverless Web Developer for Branch, a tech-forward insurance startup focused on giving instant prices for home and auto with just a couple questions.

Make the ask

Dear new developer,

I’ve been surprised by how often I get a response from people I consider “famous”. A few examples.

Brad Feld, a well known venture capitalist, was willing to do a sixty minute AMA for the Boulder Ruby group. (If you want to watch the video, it was recorded.)
I asked a question of Patrick McKenzie years ago about whether I should write a book about testing ETL jobs with Pentaho Kettle. (Short answer: no.)
The guest posts on this blog.

How can you get help from someone prominent? I’m going to assume that you have someone in mind who you want to ask a question or otherwise get help from. Let’s say you are working on a post about React and you want someone to give it a review to make sure you are on the right path.

Find out more about the person. This involves some research, because you want to ask them for help on a topic they are interested in. Many people have profiles online, so review them to tune your “ask”. Google plus social media is your friend here. You don’t have to do exhaustive investigation, but if you can tune your question to their interests, you are more likely to get a response. It can also really help if you reference anything they’ve shared that is relevant to the question. If they recently posted about Redux and how it is awful, mention that you’ve read it and make an intelligent comment about their argument.

Next, get their contact info, or find it. So you need to do some more research. Lots of people make their email addresses known; that’s a good signal that they want to respond to email. I’ve had some luck with Twitter direct messages, Slack DMs, and LinkedIn messages. I’ve not had luck with public outreach (@ing someone on Twitter, for example). Find out how this person responds to others. I haven’t run into this, but I suspect there are certain people for whom Youtube comments, Tiktok messages, or Twitch DMs are the best form of contact.

Interact with this person before you make the ask. Follow them on Twitter. Share one of their posts to an online community. Comment on their blog. If they write a newsletter, subscribe to it. Even better, respond to one of their newsletters; even if someone has 10,000 subscribers, the number of email replies they receive is for each email is nowhere near that number. If you respond with a cogent comment, you’ll begin to build a relationship with them. Put in some work and you’ll also have a better idea if they are even the right person to ask.

Make sure your request is reasonable. Asking for feedback on your post is fair. Asking for 30 minutes of face to face video chat to discuss ideas is less so. Requesting someone promote your post to their followers is lame.

When you make the request, make it easy for them to both understand what you are requesting, the timeline, and the means of fulfilling the request. Here’s a good request:

Hiya <name>,
Would you be interested in reviewing my blog post about React deployment strategies? I have a blog focused on React front end development.
I was thinking that something on this topic might be up your alley. I saw your rant on Redux on Twitter and thought it had some great points. But one thing I wasn’t clear about: Redux sucks, but what is the alternative?
I’m looking to get this blog post published in the next week. If you are interested, I’ll send you a google doc (unless you would rather some other format; let me know). If not, no worries, and thanks for sharing your thoughts on React! I have learned a lot.
Thanks,
Dan

In this note, I have a single, reasonable request. I outline the timeframe; this makes it easy for the recipient to determine if they can possibly fulfill it. I let them know that I know who they are and their opinion on this technology, as well as that I’ve actually read and understood some of their opinions. It’s also important to make it easy for people. Google docs work for a lot of people for reviewing documents, but not everyone.

What a note like this does is encapsulate everything that this person might need to know about the request. There’s no back and forth about when the review would need to be finished. This makes the decision easier, which is what you, as the asker, should aim for.

Pick people at the right level of prominence. Don’t ask the creator of React to review a basic blog post. But if you saw someone speak at a local meetup about React, they’d be a good choice for this request. If, on the other hand, you’ve written an in-depth piece about the performance of React deployments in various scenarios and haven’t seen anything else like it, that might of more interest to someone more prominent, possibly even the creator. As long as you are thoughtful in your request, asking prominent, even famous, people is fine. I’ve been surprised at who has replied to my requests.

Next, follow up once or twice, but don’t bug them. The more prominent the person, the more they are pinged. (This is another reason to ask someone less prominent; they’re more likely to respond.) I always follow up a week later. Give them plenty of chances to say no. I always like to say “feel free to tell me to buzz off if this won’t work for you now.” But don’t give up after sending just one message; we all deal with overflowing inboxes. Patrick replied in 24 hours; Brad responded quickly but it took months to have schedules line up. If they say no, you can thank them, ask for a referral to someone else who might be able to help, or ask if you can follow up in a few months.

Finally, if they say yes, make sure you follow through on the request. For the React blog post example, make sure you send them the google doc, incorporate their feedback, and publish it. Send it to them with a note of thanks after you’re done. This completes the loop and lets them know you didn’t waste their time.

Asking someone prominent to help you out is not as hard as it sounds. Make sure you do your research, make a thoughtful request, and follow up. Not everyone can help, but some definitely will.

Sincerely,

Dan

Interviewing at a FAANG in the Midst of COVID

This is a guest post from an anonymous FAANG engineer. Enjoy.

Dear New Developer,

In 2020, one question lurks in all of our minds: What the hell is going on? And yet, for many of us, life not only goes on, it presents exciting new opportunities. Towards the end of 2019, after six years of working as a software developer, I felt it was time to leave my second job. The familiar faces were rapidly disappearing, and I just wasn’t finding the work fulfilling anymore. I entertained a couple calls from FAANG recruiters, but I wasn’t particularly excited about any of them. I assumed I was going to find The Perfect Startup™ at which to spend the next phase of my career. I was complacent. I had endless excuses for why this wasn’t a good time and why my job wasn’t so bad. I could spend another year there.

Little did I know that the “another year” in question was going to be the craziest year the world had ever seen.

For personal reasons, I did not interview at all for the first month and a half of 2020. I even scheduled a phone screen with a FAANG, but due to a family emergency I rescheduled it and then forgot about it until the night before. Oof. I pride myself on my algorithm skills, but three years without interviewing is enough to make anyone rusty. I didn’t fail the phone screen, but I didn’t pass it either – instead, I was asked to try again. That was a wake-up call, and it made me really want to succeed at the interviews that I had previously not cared about.

My first tip, for anyone interviewing in 2020 or any other year: Grind LeetCode. I cannot understate how important it is to build muscle memory for the coding portion of your interviews. You don’t want to spend fifteen minutes thinking about whether you should use a Queue or a List (as I did), you want to spend that time solving the actual problem. Anyway, after that experience, I practiced every night (and some days) and easily passed all of my phone screens.

Less than a week later, COVID struck and my office asked me to work from home until further notice. All good, this should just make it easier for me to spend time on interviews, right? I assumed it would just be a temporary exercise for the next two weeks. Little did I know, all the companies, FAANG and other, which I was interviewing at would soon close their doors as well. I started panicking – what was to come of my on-site interviews? Well, some of the smaller companies didn’t feel comfortably hiring remotely, so those processes were dead in the water. All the FAANG companies assured me that I would get the full on-site interview experience through the magic of videoconferencing. I was not happy about this at all. I’ve always prided myself on my ability to connect with other people, so I feared that this would be lost over video. I shouldn’t have worried. All my interviewers made an extra effort to connect with me due to the circumstances, and I actually felt more comfortable than I ever had for an in-person interview. Thus, my second tip: Relax. Yes, times are extremely weird right now, but they’re weird for everyone. Have fun and enjoy the process.

I went into the interview process with a pretty good idea of which FAANG I wanted to work at. Based on what I knew of the internal culture, the company’s impact on the world, and my expected daily happiness, I had already decided where I wanted to be. However, if I didn’t receive an offer from that one, I was more than happy to work for any of the others I was interviewing at. Thus, I treated them both as practice interviews and as high-stakes challenges. Ultimately, I aced all of the interviews, received offers from all the companies, and immediately accepted the one I had been thinking about. I could not have been more thrilled. I attribute my success to two things, preparation and routine. Preparation was already mentioned in my first tip – grind those practice problems. I did over 100 problems on LeetCode in the month leading up to my interviews, and I even wrote up solutions on that website as a way to practice my ability to explain to others.

As for routine, my final tip is this: Build a stable routine. This is something we software developers struggle with even in years that are not 2020. When the lockdown first started, I felt lost. I worked until midnight because there was no reason to stop. My diet and exercise slipped. However, once I turned that around, I felt the ability to compartmentalize and plan. I set a regular bedtime and waketime. I started cooking myself meals at regular times to replace the ones from the office. I ordered a pull-up bar for my doorframe so that I could exercise any time I passed through it during the day. Once my life and health were in order, it was easy for my brain to focus on the fun part: passing those interviews.

— Anonymous

Learn in public

This is a guest post from Shawn Wang aka swyx. Enjoy.

Dear new developer,

If there’s a golden rule to learning, it’s this one.

You already know that you will never be done learning. But most people “learn in private”, and lurk. They consume content without creating any themselves. Again, that’s fine, but we’re here to talk about being in the top quintile. What you do here is to have a habit of creating learning exhaust. Write blogs and tutorials and cheatsheets. Speak at meetups and conferences. Ask and answer things on Stackoverflow or Reddit. (Avoid the walled gardens like Slack and Discourse, they’re not public.) Make Youtube videos or Twitch streams. Start a newsletter. Draw cartoons (people loooove cartoons!). Whatever your thing is, make the thing you wish you had found when you were learning. Don’t judge your results by “claps” or retweets or stars or upvotes – just talk to yourself from 3 months ago. I keep an almost-daily dev blog written for no one else but me.

Guess what? It’s not about reaching as many people as possible with your content. If you can do that, great, remember me when you’re famous. But chances are that by far the biggest beneficiary of you trying to help past you is future you. If others benefit, that’s icing.

Oh you think you’re done? Don’t stop there. Enjoyed a coding video? Reach out to the speaker/instructor and thank them, and ask questions. Make PR’s to libraries you use. Make your own libraries no one will ever use. Clone stuff you like. Teach workshops. Go to conferences and summarize what you learned. Heck, go back to your own bootcamp to tell alumni what’s worked for you. There’s always one level deeper. But at every step of the way: Document what you did and the problems you solved.

The subheading under this rule would be: Try your best to be right, but don’t worry when you’re wrong. Repeatedly. If you feel uncomfortable, or like an impostor, good. You’re pushing yourself. Don’t assume you know everything, but try your best anyway, and let the internet correct you when you are inevitably wrong. Wear your noobyness on your sleeve.

People think you suck? Good. You agree. Ask them to explain, in detail, why you suck. You want to just feel good or you want to be good? No objections, no hurt feelings. Then go away and prove them wrong. Of course, if they get abusive block them.

Did I mention that teaching is the best way to learn? Talk while you code. It can be stressful and I haven’t done it all that much but my best technical interviews have been where I ended up talking like I teach instead of desperately trying to prove myself. We’re animals, we’re attracted to confidence and can smell desperation.

At some point you’ll get some support behind you. People notice genuine learners. They’ll want to help you. Don’t tell them, but they just became your mentors. This is very important: Pick up what they put down. Think of them as offering up quests for you to complete. When they say “Anyone willing to help with ______ ______?” you’re that kid in the first row with your hand already raised. These are senior engineers, some of the most in-demand people in tech. They’ll spend time with you, 1 on 1, if you help them out (p.s. and there’s always something they want help on). You can’t pay for this stuff. They’ll teach you for free. Most people don’t see what’s right in front of them. But not you.

“With so many junior devs out there, why will they help me?”, you ask.

Because you learn in public. By teaching you they teach many. You amplify them. You have one thing they don’t: a beginner’s mind. You see how this works?

At some point people will start asking you for help because of all the stuff you put out. 80% of developers are “dark”, they don’t write or speak or participate in public tech discourse. But you do. You must be an expert, right? Don’t tell them you aren’t. Answer best as you can, and when you’re stuck or wrong pass it up to your mentors.

Eventually you run out of mentors, and just solve things on your own. You’re still putting out content though. You see how this works?

Learn in public.

— swyx

p.s. Eventually, they’ll want to pay you for your help too. A lot more than you think.

This post was originally published here.

swyx is a Senior Developer Advocate at AWS and author of The Coding Career Handbook.

Your network increases optionality

This is a guest post from Karl Hughes. Enjoy.

Dear new developer,

I was in your shoes in 2011. I was finishing up a degree in mechanical engineering that I would never use and looking for a way to join a startup as a software developer.

Maybe it was the entrepreneur in me, and maybe it was just naivety, but instead of applying for jobs, I decided to start emailing interesting companies instead. I made a list of technology startups in the education industry and emailed each of them my pitch.

Two of them got back to me and one (Uloop) had an office three hours away in Nashville. I drove to meet their CEO and after a few conversations, they brought me on as a freelancer. When I graduated a few months later, they offered me a full-time role managing their blog and writing custom WordPress plugins.

Since then, I’ve worked at three different edtech startups and never once had a formal “job interview.” Every company I’ve worked for has hired me because I met someone there and stayed in touch for months. When a job opened up, they reached out to me to see if I was interested.

My first job hunt showed me that your strength as a software developer is not in your resume, your knowledge of algorithms, your ability to keep up with the hottest frameworks, or even your problem-solving skills. The most powerful tool you have is your network.

The Employer’s Perspective

As a job-seeker, you know that looking for a job is scary, but from an employer’s perspective, hiring is scary too.

After sitting in the hiring manager’s seat several times in the past few years, I can tell you that I’m as scared of hiring the wrong person as you are of screwing up the job interview. If I make a bad hire, I look bad to my boss, and my team’s productivity will suffer. Having to fire someone kills morale and hurts the manager’s reputation, so nobody wants to do it.

This fear is why managers look for people in their networks or work with recruiters. The very last place employers look for applicants is the cold resume bin.

How I Built My Network

If you want to avoid the black hole of submitting your resume online, you need to build a network. I don’t know you well enough to give you a perfect formula for your situation, so I’ll just tell you how I built my network. I hope some of these ideas resonate.

First, I started as a freelancer before I ever had a “real” job as a programmer. Most people don’t recommend this approach for new developers, but it forced me to learn to “sell” myself really well. When I started with Uloop, I often had no idea how to accomplish a task, but I bet that I could learn it before they discovered I was making it up.

After getting that first job, I started attending meetups and conferences regularly. Uloop was a small company, so there wasn’t much opportunity to network within the organization, but I had moved to Chicago, where there were plenty of programming meetups and tech events to attend.

I tried meeting people at these events, but it was hard. I’m not that outgoing, so instead, I would email the event’s speaker or organizer afterward and invite them to a one-on-one coffee or lunch. Some of the people I met like this are among my closest mentors and friends today.

As I attended more meetups and got to know speakers and leaders, people started inviting me to give back. I was little more than a junior developer at the time, but I was asked to speak at bootcamps, meetups, and even a couple of small conferences because of my network.

Naturally, I was nervous the first few times I got up in front of a group to share my experience. I knew there were people in the crowd with decades of experience on me, and I expected them to stand up and call me out if I made any mistakes. I found that practice and gradually increasing the stakes helped me. By trying a talk out at a local meetup and slowly working up to larger audiences at a conference, I gained confidence over time.

Giving a talk at a meetup or conference is a lot of work, and you don’t typically get paid for it. That said, I knew how helpful it was hearing developers who were more experienced than me back when I was first learning to code, so I have always enjoyed the opportunity to give back.

One side effect of speaking is that you get even more opportunities to increase your network. At some point, I switched from being the one asking speakers to meet with me to the one that attendees were asking to speak with. I always enjoy these interactions with new developers, and the opportunity to encourage or help others is my primary motivation for speaking and writing this letter.

Keeping in Touch

Everyone who talks about networking tells you to go out and meet more people, but that’s worthless if you don’t keep in touch with anyone. As I started to meet more people in Chicago, I realized that I needed to come up with a way to have more encounters with each of them.

“It takes on average about 3 encounters — and by that I mean intentional rather than passing interactions where you’ve gotten together primarily to just hang out — to really see if there’s potential for a relationship with someone.” – Brett McKay

The first step was to start a spreadsheet of people I wanted to keep up with. Most of them were more experienced than me, but many were peers or newer developers I “clicked” with or found interesting.

Next, I made a reminder to reach out to 1-2 people on the list every week. I’d ask how they were doing and see if they wanted to get lunch or coffee sometime. I tried to find organic reasons to connect (birthdays, an article related to their industry, etc.) and ask them questions about their lives. One of the easiest ways to make someone like you is to get them talking about something they like. People love talking about themselves.

While this sounds calculated, I do genuinely enjoy these conversations. We’re all busy, but having a system like this ensures that I don’t forget to maintain my network. If I ever feel like I’m no longer getting along with someone, I remove them from my list and no harm is done.

The reason most people don’t do this is that it takes a lot of time. I still spend 4-6 hours per week keeping in touch with or expanding my network. It may seem like a lot, but the investment has paid dividends and afforded me many interesting conversations and relationships along the way. This strategy of intentionally staying in touch with people has led to friendships, co-workers, job offers, and clients.

Make It Yours

No career advice will work for everyone.

I didn’t write this letter to give you a formula for networking, but rather to let you know that unconventional approaches can work. My network has been an invaluable asset, but luck and privilege played a huge part too.

If I hadn’t been able to drive three hours to take a meeting with my future boss, would he have hired me? If I needed to be home after work to help care for a family member, would I have been able to network at Meetups? If I weren’t a white male in an industry dominated by white males, would people have taken the time to meet with me?

I don’t know.

I have no idea what your career path will look like, but I hope my story gives you the courage to build a path that works for you.

Signed,
Karl

Karl is a former CTO and freelance writer. He’s currently the founder of Draft.dev where he helps companies create content that reaches software developers.

Influencing outcomes through output

Dear new developer,

“Outcomes over output” is one of my favorite letters on this blog. In it, Mark, a guest poster, talks about what business actually values (outcomes) over what developers often focus upon (outputs).

Outcomes are things like:

more sales
happier customers
publicity
less customer churn

Outputs, on the other hand, are things like:

more features
test coverage
flexible code
customer retention analytics

The reason that I focus on outputs is that is what I can control. Outcomes, except in rare cases, are outside of my control. For instance, at a startup a while back, I wrote a lot of code, but couldn’t control how the sales process was going. I felt whipsawed between building things as fast as I could when sales seemed to be happening at a snail’s pace.

It’s important to recognize that business, like life, is a long game. You are the result of choices you (and those who have influenced you) have made.

So, also, are the outcomes upon which you are judged in your career. To square this circle and relate outcomes to outputs as best as I can, I do the following:

Recognize the tension. All I can control are the outputs; I can only, at best, influence outcomes. But people pay for results, not for effort.
Find best practices. If others have completed tasks or created outputs which produced desired outcomes, learn about them. I don’t follow the same paths uncritically (cargo culting) but need to know about them to make informed choices.
Be methodical. When I choose to produce an output, make it good. How good depends on the audience and possible payoff: a script to load data once deserves less care than code that will be run thousands or millions of times. But, I strive to make anything I do excellent.
Find ways to incrementally improve outputs over time. These can include automated tools, checklists, and incorporating new practices. I can also choose to stop. This is a strategic choice that shouldn’t be considered every day; once in a while, though, I ask myself if I need to keep producing this output.
Experiment. Tweak outputs and see if the outcomes change. Sometimes this is easy and quick, other times I’ll need months to see changes. This requires patience.

What can you do if you are in a situation where the outcomes and the outputs are totally divorced from each other? Where your effort isn’t going have any effect on desired results?

That’s a tough place to be. I would feel ineffectual and frustrated. I think if you are in this situation, you need to sit down on a weekend and spend some time thinking about how you want to spend your life. Of course, there are valid reasons to hang tough:

Desired outcomes might be shifting
New outputs are being tested
Your role is changing

If that is the case, hang on if you can; sometimes a job is stormy but it is better afterwards and therefore worthwhile to see through. After all, outcomes aren’t just hard for you to influence, they are hard for everyone.

But if you do some thinking and find that your efforts have been disconnected from outcomes for a while, and that your nerves are frayed, change the situation. Whether that is leaving a job or moving to a different town, changes can reset your life. And hopefully put you in a position where your outputs are more in line with desired outcomes.

Sincerely,

Dan

Always leave the code better than you found it

Dear new developer,

I’ve spent a lot of my time maintaining working code. I think that is more typical of software developers than working in greenfield development. Yes, there are definitely jobs where you are writing more new code than maintaining, upgrading, bug fixing and improving old code (startups without product market fit being one, consulting being another) but in general code is expensive and folks want to run it for a long time.

Often you’ll jump into code to fix a bug, investigate an issue or answer a question.

When you do so, improve it. This doesn’t mean you rewrite it, or upgrade all the libraries it depends on, or rename all the variables.

You don’t need to transform it.

But you should make it better. Just clean it up a bit. Doing so makes everyone’s lives just a bit better, helps the codebase in a sustainable way, and assists the business by making its supporting infrastructure more flexible.

What are some ways to improve the code when you are in it?

Document

Whether that is a comment that explains something tricky, a larger piece of documentation external to the code which explains how to interact with it, or fixing a typo, trustworthy documentation is key to interacting with code. This is a good way to start improving a codebase because it has minimal impact on the actual code. Therefore it is low risk. But if you’ve ever had a great comment explain a confusing bit of code, you’ll appreciate the time this effort can save.

You can also help documentation by removing old, crufty docs. If you see a comment that doesn’t apply, remove it. If there’s cut and paste documentation which doesn’t apply, get rid of it. That cleans up the code for the next person to come along (who might be you).

Write a test or improve a test

Tests help you write maintainable, extensible code that others can change fearlessly. If you run across code that isn’t tested and you have time and the supporting framework to write one, do so.

Even if it tests simple functionality such as “can I instantiate this object” or “how does this function react when I pass it two null values”, an additional test will help the robustness of the code.

Refactor it

This is one of the most flexible improvements. Refactoring code can range from renaming a variable to be more true to its nature to an overhaul of an entire module. Start small and don’t get wrapped up in perfection. Make the code clearer in intent.

It’s easy with refactoring to get wound around an axle and make too many changes and end up with broken things. Timeboxing is one technique I use to avoid, or at least minimize, my tendencies toward this when refactoring. If all I have is 30 minutes, I’ll make my changes smaller in scope.

A warning about refactoring. Don’t refactor what you don’t understand. Don’t drive by refactor. Discuss your plan with someone more familiar with the code; git blame is your friend. Especially if the code is not well tested, you want to make sure you don’t do more harm than good.

Upgrade a dependency

It’s sometimes a winding path, but upgrading your dependencies regularly is a good way to maintain the code. I remember working in a fork of struts. It was an important application for the company, but we didn’t spend the time upgrading the dependencies, because it was too painful. Eventually, parts of the code became harder to update. The entire application couldn’t benefit from newer technologies and paradigms because of the older dependencies holding it back.

It never feels good to spend time updating a dependency; to me this always feels like running in place. But if you don’t do so, eventually dependencies will end of life and you’ll be forced to update. That’ll be even less pleasant.

How to do it

Based on feedback (this comment, among others), I added this section on Nov 28.

When you are making these changes to improve the code, you’ll help out code reviewers and your future self by making changes that are improving the code separate from changes that add functionality. Whether you do this in separate pull requests, tickets, or commits depends on your team culture. Ask about that. But such separation will make it easier for people who aren’t familiar with the changes to understand them and give feedback on them, whether that is a code review this week or someone reviewing this component two years from now.

Why do it

All of these actions not only help others because they improve the quality of the code, they also provide examples to other developers on how to do so. For example, it is far easier to write the second test in a suite than the first. You can cut and paste a lot of the setup code and tweak only what is different. The first bit of documentation will inspire more.

Code isn’t everything, but it is an important work output. Whenever you touch it, you should strive to leave it in a better place that it was before you did so.

Sincerely,

Dan

Save off context

Dear new developer,

A key part of software development is being able to pick up where you left off. You are going to have interruptions during your day, and you want to be prepared for them. Whether you took a break to rest your eyes, stepped away for lunch or have left for the day, you’ll want to capture the context of whatever you were working on.

This is especially true if you are being interrupted in the middle of the day to help a teammate or go to a meeting. These tasks are crucial to being a good team member, but often halt progress on a technical problem.

We all have to handle this type of timeslicing, but it can be difficult to remember where we were just before we stopped. Oftentimes if you are building or debugging something, you need to remember many small bits of knowledge: how pieces of a system fit together, what that blog post recommended, what tasks remain to be done.

When someone says “Hey, gotta sec?” a lot of this knowledge gets evicted from my short term memory.

It’s worth taking a minute or two and capturing the most important pieces of information so that when you return to the task, you can jog your memory easily.

The first thing I do is prepare to make time for this. If a co-worker pings me on slack to see if I have a second, I’ll reply when I see it with “sure, give me a few minutes, please”. Side note, I am a big believer in turning off notifications for slack, email and anything else. I always provide my teammates with my cellphone number and ask that if there’s anything urgent, they contact me there. (Haven’t been called yet.)

When you know an interruption is impending, plan for a context recording buffer. For example, if I have a meeting scheduled, a few minutes before the meeting, I’ll stop what I’m doing to capture the context.

Next, use that time to record what you’ll need to pick the task back up. I like to do this in a few different ways. I sometimes write things down in a paper notebook. This is great because it is free form, portable, works when I’m away from the computer, and quick. However, my handwriting is atrocious and I’ve definitely peered at notes I’ve written trying to decipher them.

I’ll also open up a text document and write down a couple of lines of context. These could be tasks I need to undertake, something I need to research, someone I need to talk to, or something I know is half working and needs to be looked at. I often do these in standalone files, but have also put them in comments in the code as well. I usually save these off, just in case my computer crashes. I could do this in a Google doc or slack message to myself, but find that a local text file is durable enough.

You can also capture this context in a more formal manner, by writing a failing test. That way, when you return to the problem, you can re-run your tests and move right to the work in progress. This is great if you are in the middle of code, but doesn’t work so well for other types of knowledge.

Another formal way to capture the context of whatever task you are doing is to use a checklist. Write it initially, modify it as the task progresses, and keep your progress up to date. If this is a complicated, multi day task, I’ve found a checklist to be useful, but if it’s an hour long task, I find the overhead of keeping the checklist up to date outweighs the benefit I receive.

These notes, by the way, aren’t designed to be your knowledge base. They don’t need to be authoritative. You aren’t going to consult this later. This isn’t full fledged documentation, these are scrawled notes which will be tossed as soon as you pick the task back up. So don’t stress over capturing everything in a way that someone else could use. Doing so will take too long for the value you’ll get.

Now that the context of your current task is saved off somewhere more durable than your poor neurons, take care of the interruption. Help that teammate. Go take that walk. Attend that meeting. Head home for dinner.

When you return, whether in 15 minutes or after a week vacation, return to the flow as soon as you can.

Re-read your notes, re-run your tests, review your checklist. And get back to it.

Sincerely,

Dan