Get an external email address

Dear new developer,

When you are starting at any company, you’ll get a company address: dan@company.com. You’ll want to use that for all company communications.

You may have a personal email address: fuzzyguy@gmail.com (not my real personal email address 🙂 ).

But as soon as you can, you’ll want to get an external email address at a reputable provider like gmail or protonmail and have a professional looking email address, something like danmoore@gmail.com. If your fullname is taken, then add digits or variations: dannymoore@gmail.com, dan12@gmail.com, etc.

If you want to get fancy, register your own domain name and then set up an email address: dan@danmoore.com.

There are a number of nice things about having this external email address:

  • You can put it on your resume when you are applying for jobs and it will look professional. Though there are a lot of means of communication, email is still the major method of cross business communication.
  • You can have it for life, which means in ten years when you want to reach out to that one woman who was a linux kernel specialist, you can search for the message you sent to her. I have had my personal email address for almost twenty years. I don’t often search far back, but when I do it’s nice to have one place to go and look.
  • You can use it in your goodbye email to your company to keep in touch with people. (You will eventually leave the company, and while I suggest you connect to everyone on LinkedIn, some people don’t use it. Almost everyone has an email.)
  • You can use it as the email address of record for your “developer brand” accounts. These accounts will follow you for life and you don’t want them tied to any company email address. Things like Stackoverflow, github, or your online community accounts should all be tied to this professional, external email address.

Sincerely,

Dan

Learn two languages

Dear new developer,

Learn two languages.

When you know just one language, you can go a long way, especially if the language is dominant. In web development, that language is javascript. In system programming it’s C. Both of these languages will be around forever, and you’ll always be able to get a job writing them.

You can also know one non dominant language and get pretty far, though if that is your choice, you will probably be happier at a big company with supporting infrastructure. Something like ruby for web development or go or rust for systems programming.

But, knowing just one language is like living in the same town all your life. You can be happy doing that, but just the exposure to life in a different city will shake you and show you that what seemed like a universal truth was actually just an assumption.

I cut my teeth on perl and wrote a lot of it for my first professional job. Then I had to write some java. The first java I wrote was not idiomatic. Rather than use small custom objects, I just leveraged hashmaps and lists for my data structures. I remember one of the other engineers going over some of my code and saying “that looks a lot like perl written in java!”.

Specifically, learning a new language will:

  • let you see the strengths and weaknesses of your first language
  • let you bring concepts from language number two back to your code in language number one
  • make it far easier to learn a third language, should you choose or need to do so
  • make you aware of different approaches to common problems
  • may make it easier to implement certain kinds of problems. In my experience this is often due to open source libraries that may be available for one language that aren’t for another
  • make you less passionate. This may seem like a strange benefit, but learning another way to do things often helps you realize that a programming language is just a tool, and that different tools are of course better for different things.
  • let you build a mental map to apply to the new language based on the old language. “I know that there’s a way to iterate over a list in perl, so there must be a way to do so in java.” This will also help you learn common software terms (like “iterate”) which will help you in your searching.

These truths apply not just to languages, but other pieces of the software development process. Learn two of everything. Databases, frameworks, development methodologies. The increase in perspective and the ability will be worth the extra effort.

Sincerely,

Dan

Use LinkedIn, and use it well

Dear new developer,

Set up a LinkedIn profile and keep it up to date. This will serve as a public resume. (Yes, a github is great too, but you might not always have time to keep code up to date or an interest in a maintaining a large project.) Once a year, at a minimum, document what you’ve done in your profile. This is a low effort way to showcase your skills. LinkedIn has a vested interest in being at the top of the search results when people search for your name. And hiring managers will.

Also, used LinkedIn to record connections to people that you meet (at jobs, conferences, meetups or randomly). Folks have different thresholds for connecting (some people connect to anyone, some people want to meet you, some people want to have worked with you). It doesn’t hurt to ask; just don’t be offended if someone says no thanks. My threshold is “have I met you in person or engaged with you online”. This means that my connections are of varying strength–some connections I’d hire (or work for) with no question, others I met once and have never talked to again.

Recruiters on LinkedIn tend to be low value keyword matchers, unfortunately. But you never know, someone might be able to place you. If you do talk to a recruiter, be honest about your desires. Take what they say with a grain of salt, as when they are talking to you, they are trying to make a sale. Also make sure you ask them about their view of the job market, salary ranges for people with your experience, and good skills to gain. If they aren’t willing to share such information, they probably won’t be much good to work with.

As a friend put it, LinkedIn is a rolodex that someone else keeps up to date. This can be helpful when you are looking for a job. Troll your connections’ companies, and then ask if your connection and intro you. A warm intro is far more likely to lead to a conversation and interview than submitting a resume via a website. I offer that up to many people as it’s a low effort way to add value to someone on the job hunt.

Sincerely,

Dan

Use stackoverflow, and use it well

Dear new developer,

Stackoverflow (SO) is great for three different kinds of developers (and someone can be all three over time):

  • those who are looking for answers, usually via Google (searchers)
  • those who are looking to showcase knowledge, usually by answering questions (answerers), and
  • those who have a specific question to ask (askers)

Every developer can be a searcher (all you need is Google). But you can look for answers poorly or well. Do it well by reading all the answers, understanding the question that shows up in the search results, and voting up both questions and answers. The voting in particular is a low effort way to add value to the entire developer ecosystem (because you are providing value to other searches). I know it is easier to take the first answer and move on with whatever task you are trying to get done, but try to take a bit more time and help others.

But you should strive to be an answerer or an asker. See if you can answer questions or add comments to clarify them or point to other answers. If you have a question that isn’t answered on SO, take the time to build out a solid question. If you end up finding the answer to your question, self answer it to help other folks out.

It is true that SO is not the most welcoming community, but it’s the preeminent question and answer site and so worth having a presence on. Don’t forget, the smallest amount of help you provide to SO may resound for years. I only have ~3k reputation but have reached almost 950k people. And beyond helping others, it’s a great way to demonstrate competence without venturing too far out of your normal workflow.

Sincerely,

Dan Moore

Businesses will spend money to make money

Dear new developer,

Businesses will spend money to make money (or save money, which is essentially the same thing). This is what they are doing when they are hiring you, when they buy that shiny new office building, when they spend money on computers and other tools to help you do your job, and even when they pay severance. While you may not be in the position to spend money yourself, understanding that businesses will do so can clarify your understanding of what you are working on.

Making money is not the only reason businesses spend money. Sometimes they spend just because the CEO or other leadership want to, or for image reasons, or because of inertia. But in the long run, spending money for other reasons is bad for business.

Spending money to make money is rarely a sure thing. If the return was certain, then other businesses would notice and step in and spend money down (this is assuming a relatively free market–regulations are a whole different ball of wax). So taking bets with money is a key part of running a business.

What does this mean to you, new developer?

When you evaluate a project, think about the economics of it. How is it going to make money? What assumptions are there? Don’t assume you know all the answers to these questions.

Asking the people behind the project why they think this project is going to make the company money will help you understand why the project exists (it’s no fun to work on a pointless project), help you improve the project (perhaps there is a more economical way to achieve the goal) and increase your value to the company (someone who can execute the details while understanding the big picture is more valuable than someone who can only do one of those).

Sincerely,

Dan

Learn a text editor

Dear new developer,

As I mentioned before, the raw “stuff” of software is primarily text files. Actually, the foundation of software is ideas and information, but unfortunately a computer can’t yet run on those. So you will need to create text files.

Learning a text editor will serve you well in building software.

Why a text editor rather than an IDE? (An IDE combines a text editor with other tools that help development, including tools that help testing and tools that help debugging. It stands for “Integrated Development Environment”.) Text editors can be used for any language, whereas IDEs tend to focus on one or a few. Text editors can be run almost anywhere, whereas IDEs can only be run on your local system. And using a text editor will force you to become more familiar with the command line.

For those reasons, it’s better to become familiar with a text editor. There are many options, but two really good ones, with long lineage and a large amount of functionality, are vi and emacs. But there are plenty of good options. (Most text editors have extensions that help with certain aspects of development, and it’s worth spending some time research and installing them.)

What if you learn the wrong one? “What if I learn the wrong xxx?” is a question you’ll face many many times as a developer. Since you don’t know the future, you’re always gambling when you invest your time to learn anything. But every time you learn one thing (in this case, a text editor), you have more context and understanding about that “thing”. This knowledge makes it easier to pick up the next text editor, map its functionality to what you previously worked with, and get going more quickly. You also learn the jargon around the technology, which makes it far easier to use Google or some other search engine.

Text editors are easy to learn, but difficult to master. It is often easy to open a file, write something and save the file. But to be able to easily navigate between files, move around a file, or do a mass search and replace, you’re going to have to put in some effort.

But there is no better way to convert thoughts into files.

Sincerely,

Dan

Learn Version Control

Dear new developer,

If in doubt, put it under version control.

Version control is a way for you to keep track of the core nuts and bolts of code, which are files on the filesystem. Version control lets you make mistakes, err experiments, and roll back time to when things worked. Version control lets you see who made what changes when to which files, so that when you need to find out who to ask about the bizarre function in class XYZ, you can.

Don’t be surprised if that person is you.

There are many systems of version control. What you use depends on your needs, the most important of which is how many people are interacting with your system. But something, even a crufty old system, is far better than nothing.

There are plenty of free version control systems out there, so if you aren’t using something, set up one of the free ones (or better yet, use a hosted service) and give it a try. Github, bitbucket, gitlab, all are happy to walk you through how to store your code in their system. Learning one of the modern version control systems will help you integrate into any team, because running a software project of any size without version control is a foolhardy endeavor that only is typically tried once.

There are some items that don’t belong in version control. Large binary files belong on a storage system like S3. Secret information, like a password, is better kept out of version control and in a secrets manager or environment variables. Documents that are going to be edited by nontechnical users should probably use a shared document repository (which will likely have versioning built in, but hidden).

But everything else, all the source code and build scripts, all the infrastructure setup and documentation, all the assets and sql scripts, those should be kept in version control.

Sincerely,

Dan