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

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

Three Tips for New Developers

Dear new developer,

I ran across this post with three tips for new developers.

The tips were:

  • Develop broad expertise
  • Work in application support
  • Hone your interpersonal skills

This especially resonated with me. Note that the javascript frameworks indicate this article is a bit dated; I’d substitute React, Vue and Angular for jQuery, MooTools and Prototype, but the premise is the same. You can’t make an intelligent choice between alternatives if you only understand one of them.

To sum it up, I advise new developers to work with multiple platforms. For instance, C# developers should get familiar with truly open source alternatives like PHP or Ruby, and web developers should get to know more than just one JavaScript framework like jQuery — they should get to know MooTools, Prototype, and more. Another consideration is that doing consultant work often means working within the client’s environment and technologies, so the ability to dive into new (or new to you) technologies is a must.

I can’t argue with any of these. From a high level view, when you are beginning your career, you want to learn as much as possible from a variety of perspectives. This will inform your career in the future and let you make decisions from a position of knowledge, rather than assumption. So spread your wings. When I was a new developer, I worked all up and down the software stack, from server management to database administration to front end development. And I learned what I was both good at and enjoyed.

The other thing to be aware of is that you are more likely to be hired for potential rather than knowledge early in your career. That means that if you step into, say, an application support role and then want to move out of it, you can focus on what you learned or how you improved the company, rather than what you did. A senior application support developer who’d been working in that field for ten years would have a harder time making that pitch than a newer developer.

Finally, improving your “soft” skills of communication and team work will pay dividends in the future. Rare are the developer jobs that are 100% (or even 80%) focused on coding. Defining the problem is often the hardest part of the development process, and it certainly has the most value. (Which would you rather have, the perfect solution to the wrong problem, or the 80% solution for the right problem?)

The entire post is worth a read.

Sincerely,

Dan