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 Excel At Your Job As A New Developer

Dear new developer,

I think that there are only really four tasks you need to do to do a good job as a new developer.

  • Say what you are going to do, then do it. This is all about communicating what you are working on. You can do this explicitly (via face to face communication or slack) or implicitly (via moving cards on a Trello board or Jira). The important part is to keep other people (who likely will have a better idea of the big picture) in the loop. Oh, and then you actually have to do the work.
  • Ask questions. Don’t be afraid. This will help you do the work.
  • Don’t make the same mistake twice. Learn from any that you make. This will help you do the work better in the future.
  • Show up consistently. Sometimes you just have to grind. To do the work. (Is there an echo in here?)

If you can do these four things, you will stand out as a new developer. Why? It’s sad to say, but there are a lot of developers who aren’t very good. I’ve seen a few in my time. I’m not sure if they weren’t good because they were burned out, just didn’t care, didn’t have the skillset or the desire to learn, or were just in it for the money. Other times, I’ve seen developers get complacent, which is a foolish thing to do in this day and age (and a luxury that most new developers do not have). See also this comment thread on Hackernews about 20% of developers failing to be able to write fizzbuzz.

So, you don’t have to be brilliant to stand out. You do have to be good and consistent. And do the work.

Make sure you do all these, especially during the first few months, and you’ll gain a reputation as a delight to work with. This reputation will follow you for years and continue to help you.

Sincerely,

Dan

The Surprising Number Of Programmers Who Can’t Program

Dear new developer,

This came up in a Hacker News comment thread recently:

I’ve been working since the 90s and I never attempted to do FizzBuzz. Is it really relevant? Maybe to screen junior developers out of college?

And the response

So, as someone who spends maybe 20% of their time hiring, it’s still a very effective screen. You wouldn’t believe how many people can’t do it. People at big companies, respected places. It’s surprising.

I find it truly surprising. Here’s a post from 2007 about the same issue, so it’s been around a while. From that post:

…I’m starting to get a little worried. I’m more than willing to cut freshly minted software developers slack at the beginning of their career. Everybody has to start somewhere. But I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs.

As a new developer, realize that

  1. You are going to stand out among other applicants if you can program.
  2. If you can’t program, you need to fix that asap.
  3. There are some folks that are just not effective programmers who somehow are in the profession (or seeking employment). You may end up working with and for some of these people.

So, make sure you practice programming. My letters have been about some of the other aspects of software development, but if you can’t do the basic work, you’re going to have a tough time. That’s like a baseball player who can’t run. Doesn’t matter how good someone is at catching a ball or hitting, if you can’t run, you’re going to be fundamentally disadvantaged at baseball.

Sincerely,

Dan

No company is a monolith

Dear new developer,

When I was a new developer, or actually new to the business world, I thought that companies acted rationally.

They don’t.

I remember when an old timer at my first job talked about empire builders. Basically, his perspective was that above a certain level, there’s not much interest in actually doing things at many companies. Instead, people in power want to accumulate more power–more budget, more headcount, more influence. And this causes turf wars.

I have seen this happen with my own eyes. At one point in the mid 2000s I was hired as a contractor at a big company. Showed up bright eyed and bushy tailed ready to do work. Nothing to do. Asked my contracting company what to do–“bill 40 hours”. Asked my manager what to do–couldn’t get ahold of him. Asked employees what to do–no one wanted to give me any tasks (I never found out why). I believe the manager was just maintaining his budgets and headcount. I spent a lot of time browsing the internet.

I have never felt more useless in my life.

So the point is that there are factions in a company above a certain size (below a certain size, there are still factions, but they are more united because they are trying to make sure the company continues to exist, and there’s fewer places for bad apples who are not interested in the company mission to hide).

What does this mean for you? When you don’t have a job, realize that there are different people and departments that might hire you. Just because you were rejected from one position doesn’t mean you’ll be rejected from another.

If you have a job, it’s a good idea for you to gain an understanding of the various factions and players. Lots of times this can be accomplished by asking questions at company social events and drawing your conclusions. You can then determine which faction you want to be part of (a rising one seems to me to be the best).

I have no patience for this kind of stuff. I’d rather find a great boss and work hard to make him or her look great. That’s probably why I’ve spent most of my life at small companies.

But, the point is, if you’re working in a larger organization (more than say, 60 people) you”re going to want to be aware of the internal politics.

Sincerely,

Dan

Tips for using email well

Dear new developer,

Writing great emails is a key skill. For all the hullabaloo about slack, emails still rule the roost when it comes to cross organization communication. This is because everyone has email, it is auditable and uneditable once sent, and requires no special permission beyond knowledge of an email address.

Email is great at conveying information, but horrible at conveying context. It also can be unclear and ambiguous. Because email is asynchronous, ambiguity causes slowdowns and confusion more than ambiguity in conversation (where you can say something like “when you said tomorrow, do you mean Saturday or Monday, the next business day?”).

This post has some great tips on how to write great emails. From the post:

Avoid using only temporal adverbs/nouns like yesterday, today, tomorrow, two hours ago etc but include also the specific dates/times otherwise they might be misunderstood or require from recipients to check the email’s sent date/time to calculate the actual time.

and

Use bookmarkable links when you refer to something that would eventually require from the recipient to search for in another platform.

There are a number of other great tips for writing clear emails in this post. The author also provides before and after examples, which really illustrate the points.

Worth a read.

Sincerely,

Dan

Develop Denver Presentation

Dear new developer,

In a slight departure from the normal posting schedule, I wanted to announce that I’m speaking at Develop Denver on Friday, August 16. I’ll be talking about three things that surprised me when I was a new developer. There are a number of other interesting presentations across a variety of topics. Here’s the schedule (pdf). Lots of smart people, which will, among other things, let you have great conversations and break out of being an expert beginner.

You can still get tickets here. If you’re in the Denver area, hope to see you there!

Sincerely,

Dan

There are no adults in the room

Dear new developer,

One of the most shocking things I learned when I started working in a professional capacity is that there are no adults in the room.

That is not to denigrate everyone at your company, working hard to help make the place successful.

Rather, it is to say that no one knows everything and everyone is doing the best they can. (Well, most people, and it’s good to assume positive intent.)

If you go into a company expecting to be handed work on a platter and to have someone know exactly what is going on, the way that, say, a college professor knows how to teach physics 101, you are going to be disappointed. It’s much more likely that the folks who are senior to you are trying to stay one step ahead of the customer.

There are people who are more or less expert at the problem space, but I’ve only worked at one place in my life where someone was truly a master of almost every aspect of the business. And even in that place, there was a lot of uncertainty around new programs and a lot of “hmmm, will that work, let’s try it and see”.

(This isn’t isolated to the software industry, by the way. I know folks in other industries and they aren’t perfectly run organizations. Even in organizations that really matter, like hospitals, the chaos and uncertainty is there.)

So, once the maelstrom of chaos and uncertainty arrives, there are two ways to look at it

  • problem. Oh my god, no one knows what the heck is going on. What kind of place is this?
  • opportunity. Excellent, I can see that folks are grappling toward solving problems and need some help. Let me put my nose to the grindstone and see how I can help.

Of course, there is some level of uncertainty that you shouldn’t accept (anything that could damage your health, ethics or paycheck, for starters). But it was sobering to me to realize that there are no true adults in the room at any organization.

Just people trying to do their best.

Sincerely,

Dan

Write a brag document

Dear new developer,

You will encounter good managers and bad managers in your career. I’ve found that one common thread for all managers is that they are busy. Busy with meetings, busy with coordination with other teams or parts of the business, busy putting out fires, busy with helping team members. Busy busy busy.

They also will likely be responsible for your career. Promotions, compensation increases, title changes. A good manager will want you to be challenged and grow and learn.

However.

The only person who really cares about your career is you.

You can help your manager help you by helping them know what you do. Sometimes this feels like an undue burden. Surely your manager can keep track of what you’ve accomplished on their team. And some do know some of the stuff you’ve done, some time.

But what you want is to help them know everything that you’ve done that you’re proud of. This helps them understand what a great team member you are, and also gives them ammunition to fight for resources (money, projects) that you deserve.

One place to put this information is in your LinkedIn profile (more about my opinion on LinkedIn). Of course, make sure you don’t reveal any company secrets (projects, launches, technologies) in this.

Another alternative is an internal brag document. Julia Evans has written a great post on writing one. This outlines one way you can help your manager (and yourself) keep track of all the great work you’ve done. It can be far more detailed since it is internal and not limited in length.

It’s not just limited to project accomplishments. You can build a bigger story. From the post:

In addition to just listing accomplishments, in your brag document you can write the narrative explaining the big picture of your work. Have you been really focused on security? On building your product skills & having really good relationships with your users? On building a strong culture of code review on the team?

I haven’t written one of these (although you could consider my blog somewhat of a brag document, I suppose. Yet another reason to start a blog). But having some kind of record of your accomplishments that you can share with your manager will help them help you.

Sincerely,

Dan

Subscribe to a weekly link newsletter

Dear new developer,

I mentioned before the benefits of participating in an online community. If you aren’t interested in a back and forth, you can often join an email list where someone will capture interesting articles on a particular subject and email you weekly. (Examples that I’ve recently interacted with: API links, dev links, craftcms links.)

These are nice because they don’t take any effort (beyond signing up). And then once a week or so, you can get the newsletter in your inbox.

A few tips about these.

  • Pick and choose. There are so many of these (because it is valuable to have developers’ attention), so google around for a bit. Good terms to search for are ‘<subject area> weekly newsletter’ or ‘<subject area> email newsletter’.
  • Read the archives first. This will give you an idea of whether you’d enjoy the content and the voice of the newsletter.
  • You don’t have to read every link. It can be overwhelming. So just scroll through the links and click on any that are interesting. You can also share with an online community, your team or a former colleague if you see something interesting.
  • Use it to explore a new technology or area of software development. Such regular content will introduce you to both jargon and people writing about the topic.
  • Don’t be afraid to unsubscribe. Easy come, easy go. If you don’t use a technology any longer, or aren’t interested, don’t clutter up your inbox. You can always resubscribe if you miss it.

I find this kind of email list to be an easy way to get up to speed and be tuned into a tech community. (If you are looking for a newsletter for a topic and can’t find it, you can start your own too! Tinyletter.com is an easy way to do this. Just be prepared to spend some time finding and curating links.)

Sincerely,

Dan

PS You can also sign up to get “Letters to a New Developer” via email too, it’s in that right hand column.

 

 

Personal projects make you a better developer

Dear new developer,

I firmly believe that having a side project makes you a better developer. This kinda sucks, because when I get home from a day struggling at the office, I don’t want to sit in front of the computer for yet longer. But if you can make it happen, even if it is only an hour a week, you’ll learn so much from a side project.

This post covers some other great reasons for you to start up a personal project.

From the post:

[A side project] is like when you let kids color outside of the lines [because no one else need ever see the code]. You start to think and see things differently. Plus you get to try different things in the process. You could start learning a new framework and realize that you don’t like it and stop immediately. There aren’t any consequences in your personal projects.

I found a side project to be a great place to experiment with different tools and languages that I may not have used during my day job. For instance, I was able to play with a recommendation engine and a static site deployment tool.

The post also ends with tips on picking a side project, but my advice is: pick a problem that matters to you. When you are trying to find time to work on something between all the other demands on your time, you have to really want to do so, and the only way I’ve found to do that is to be really excited about the problem space.

Other tips from me:

  • You can start with a blog. If you don’t want to write code, you can just write prose. That can be a fun way to explore new technologies or business domains.
  • Don’t be pragmatic (unless you want to commercialize the project). At work you need to walk the line between beautiful code and delivery. Side projects let you focus on beautiful code.
  • Don’t be afraid to let the project go. I have done this. It’s painful, but if you aren’t enjoying the project, let it go. I’ve found a commitment of at least six months is good to ‘get over the hump’ that I encounter beginning anything, but if you’ve been doing a side project for at least that long and you find yourself avoiding it, give yourself a break of a month or two. If you aren’t interested after the break, let it go.
  • If you don’t have time for something yourself, find a project where you can help. Ask around on local slacks or meetups or check out codeforamerica.org for ideas.

The post I mentioned is worth a read in entirety.

Sincerely,

Dan