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

Think about how things can go wrong

Dear new developer,

Think about the edge cases.

This is one of the primary ways you can add value. Think about what happens when things go wrong. It’s usually relatively straightforward to consider the happy path. Let’s take the example of a relatively simple ordering application. People can login, see their orders, and can change certain aspects of their orders (their address, perhaps) before a product is shipped.

Begging the question of why aren’t you using an open source solution like Magento or a off the shelf saas solution like Shopify, there are other things to be aware of.

  • What happens if the user wants to ship some orders to one address and some to another?
  • What does the user see when they login but have no orders?
  • What happens when they change their address?
  • What kind of validation is needed?
  • How do we know when a product is shipped? What do we do if a user wants to change their address but the product has shipped?

These are all edge cases around the happy path of login -> change address -> exit. But they are all going to affect the user experience, and so are worth thinking about.

I prefer to do it at the spec time, but any time to ask these questions is a good one. Otherwise, you’re either going to have:

  • the edge cases pop up and be handled poorly,
  • or developers making up the answers while coding

So, new developer, when you get a change to talk about a feature, think about the happy path, the expected path, to be sure. But also think about how things could go wrong.

Sincerely,

Dan

How to get the attention of a busy person

Dear new developer,

This post talks about how to ask for mentoring, but the principles apply to getting in touch with any busy person. Busy people are by definition busy, and get a large number of emails and requests every day. (Here’s a VC talking about the difference between ignoring and not replying, and how they look the same to a sender.)

The key is that you as the requester need to put in some effort. From the post:

In other words, when you asks for a busy person’s time for “mentorship” or “advice” or whatever, show (a) you are serious and have gone as far as you can by yourself (b) have taken concrete steps to address whatever your needs are and (optionally. but especially with code related efforts)(c) how helping you could benefit them/their project.

This effort on your part shows that you are serious. It qualifies you. Especially if you persist. (Now, you can’t persist to the point of annoying the person. There’s a line between persistence and bugging someone. I always preface any email I send to someone asking a favor with ‘hey, feel free to tell me to buzz off’, and I mean it.)

And

I hate to sound all zen master-ey but in my experience, it is doing the work that teaches you what you need to do next.

That doesn’t mean you can’t learn from reading (otherwise why have documentation or even this blog!) but that you need to actually try things outlined in docs. Even just typing the commands of a tutorial (instead of copying and pasting) will help you understand what you are doing.

The whole post is worth a read.

Sincerely,

Dan

How to be a successful junior engineer

Dear new developer,

I enjoyed this post from Hanah Yendler on how to succeed as a new developer. Note that she is working at Eventbrite, a larger company (1100 employees according to wikipedia), so some of the advice may be a better fit for new developers at bigger companies.

A few of the pieces of advice really resonated with me:

Take responsibility for something that seems slightly out of your reach. One of my previous managers at Eventbrite told me that he wants me to be sitting just on the edge [of] fear because that’s where intense learning happens. I have a huge fear of failing, but taking responsibility means pushing yourself and growing as an engineer.

and

It can be tough to get a subject matter expert (aka an engineer more senior than you) to explain things on a level that you can understand –especially when they have very intimate and in-depth knowledge of a system or complex subject. This is where asking questions becomes essential. You can use questions to help guide them to the answer you are searching for.

Both of these pieces of advice are true when you are new to the industry and true when you have decades of experience. (Pushing yourself to the edge of your comfort zone is how you grow, and asking questions is one of the fundamental ways to learn.)

The whole post is worth reading.

Sincerely,

Dan

Balance Questions With “Banging Your Head”

This is a guest blog post from Don Abrams, lightly edited. Enjoy.

Dear new developer,

When starting out, the hard part is balancing two things:

  • Asking questions
  • Banging your head against the wall

Additionally, as a new developer you’ll likely be encountering something for the first time: a codebase that is really really large. Like large enough no one knows all of it. You’ll want to learn how to navigate the codebase ASAP. Every place is different. If you can checkout all the code and get the product running in less than a day, you’re at a world-class shop. If it’s more than a week, I’m sorry.

After you learn to navigate the code, my recommendation is then to learn and copy the patterns that other team members use. So your questions should mostly be “how did someone solve this before?” or “hey, have you seen anything like this before?” If you look at the code they referenced and still have questions, then bring it back up ASAP.

If someone offers to pair, DO IT! Tip on pairing as a junior: be the keyboard and basically have them tell you what to do. You’ll learn how they think about the codebase and learn to navigate it better. You’ll feel stupid when they tell you “just” to do something, but those are the things you need to know. (“just XXX” signals that XXX is complex thing that you’ll take for granted soon– documenting those will really help the next junior).

I also recommend reading a LOT of code.Then, as you get a better command of the codebase and team patterns (3-6 months), you can start asking questions like “why did someone solve this before this way?”

That’s when it gets fun.

Sincerely,

Don Abrams

Don Abrams has over 10 years of software development experience and recently moved to France.

Work for a place where people care

Dear new developer,

Every company has its warts (aka issues, aka problems). I have never met anyone who worked for the perfect company.

So, go in with your eyes wide open and choose what warts your company has. You may be able to help fix some of them, but some will be permanent.

One wart to avoid: an indifferent team. One just punching the clock, trying to get through the day.

If a company is full of people who don’t care, then you’ll have trouble fixing any other issue. Customers will be an after thought. And work will drag. (Yes, places like this exist.)

That’s not to say that a place where people care will be unicorns and roses, but at least people will want to fix issues and serve customers well.

How can you tell from the outside if people don’t care? Ask questions like “how do you improve processes” or “what do customers love about what you do” or “what changes have you all struggled with over the past year” or “how do you keep up to speed on the newest technology”. If the answers to these indicate a lack of caring and empathy, then I’d shy away from that place of work. If you are already in it, make plans to leave.

Sincerely,

Dan

PS You also want to avoid people who don’t care.

The best code is no code

Dear new developer,

It’s paradoxical, but sometimes the best thing you can do is not write code. Remember, the value you provide is to solve the problem you are faced with (the outcome), not to write code. Custom code has value, but comes with costs. It needs to be deployed, maintained and upgraded. It has bugs. It requires a developer to change. It also has opportunity cost. Writing custom code to accomplish task A means that you won’t have time to accomplish task B, which may be either more urgent, more important or both.

There are a couple of ways in which you might solve a business problem with out writing a lick of code.

  • Use a library or framework. For instance, I worked at a place where they had written their own database connection pool. Why? I never got a great answer, but it wasn’t clear to me that one of the open source solutions wouldn’t have worked. You need to have an awareness of such libraries to be able to propose this.
  • Use a third party SaaS tool. I’ve seen people run their own in house git repositories. There may be good reasons to do this (including security or privacy concerns). But Github is going to give you a far better experience and unless you have a big team, probably better security and privacy. You need to know what the problem, the solution and the cost are to make an effective suggestion.
  • De prioritize the work. I was at a meeting with a CEO and we were talking about continuing an effort to integrate a set of outside data sources. I asked why, and we discussed it a bit further. It became clear that the reason we were thinking about doing it was because of inertia. It became clear that there was no real business reason to do it, and we prioritized other work instead. A clear roadmap and the willingness to question requirements are helpful with this path.
  • Do it manually. I was working on a startup and we had the need to occasionally refund customers. I could have integrated with the payment provider and had this case be handled automatically, but it was much much easier to document the process and handle it manually. Refunds happened rarely enough that there was no value in automating them. Here it is helpful to know how often the problem arises, how long it takes to fix manually, and how often it will arise in the foreseeable future.

Now, sometimes you may not understand the larger context of your work. You may propose a solution that isn’t the right fit, and there’s certainly nothing wrong with writing custom code to solve a problem.

In cases where I’m not sure I have full understanding, I always preface my questions with “I am not sure I have the full picture, but I think we could solve the business problem using solution A or project B, rather than writing custom code.” If you are working directly with the client, they likely won’t care, as long as the problem is solved. If you are on a team, the engineer or project manager running your project should have a good understanding of alternatives and why custom code might be the right solution. Most folks will be happy to share that reasoning with you.

In short, it’s better to keep your eyes on solving the business problem and be aware that custom code isn’t always the right answer.

Dan

PS No, this isn’t an April Fools Day post 🙂