Opportunity Cost and the Internet

Dear new developer,

Seth Godin writes every single day on a variety of interesting topics. He’s been blogging for years and years. Definitely an interesting person to follow.

I saw this post on opportunity cost in my RSS reader (you should use one) and thought it was an interesting take on all the free content out there. Of course, the content is free in terms of money but not in terms of attention.

From the post:

And the internet has raised the opportunity cost of time spent.

Our access to the world of learning and online resources means that the alternatives are far more valuable than they used to be.

You’re about to spend 11 minutes perfecting an email to a customer. You could do a 90% ideal job in one minute, and the extra 10 minutes spent will increase the ‘quality’ of the email to 92%.

The alternative? Now, you could spend that ten minutes reading a chapter of an important new book. You could learn a few new functions in Javascript. You could dive deep into the underlying economics of your new project…

What are you doing with your free time? Are you conscious of how you are spending it? Are you aware of the opportunity cost of say, reinventing the wheel, learning a new technology, responding to a off base comment in an online forum?

Time is your most precious resource. Where you invest it when you are starting out will compound over the years.

I’m not saying “Don’t have fun.” I’m saying understand the consequences of your choices and accept them with your eyes wide open. Realize that the cost of learning a new skill has plummeted due to the Internet, which means the relative cost of anything else has increased.

Sincerely,

Dan

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

Outcomes over output

This is a guest blog post from Mark Sawers. Enjoy.

Dear new developer,

As a software engineer, it’s easy to take our eye off the ball. The ball we really want to pay attention to isn’t the stuff we focused on in college. The ball is improving business/organizational outcomes. There isn’t a course of study or advanced degree on this, because it’s bespoke and custom to every organization.

You are on a team in your organization’s grand game to help the underserved, make money for shareholders, find some cure, save the planet or whatever its mission. A software-intensive system improves information access, automates task, entertains, etc. You pair with your business discipline in conceiving, building, testing and operating systems that advance the game.

Your real value to your organization is in improving outcomes. Not directly in how well you wield language X, tool Y, process Z. Not in how many features you add in a sprint, how many bugs you fix in one day, how much code you reviewed yesterday, how many answers you posted in slack, how many documents you wrote last month, and so on. Those are just means to an end.

Yes we need to constantly develop and hone technical skills (analysis, modeling, diagramming, programming, unit testing and others) and tool knowledge (languages, frameworks, utilities, operating systems, and more), but don’t mistake this for the end-game. Yes we should measure productivity; we do care about efficiency and throughput. But more product features, the latest tech, continuous deployment, two-factor authentication, and so on are not the goal. More is usually less, in my experience as a user. Isn’t that yours as well?

The goal is not output; the goal is outcome. The outcome is more revenue, more profit, more users, more product availability, happier users … right?

So, wait, isn’t that someone else’s job? What do you know about forecasting and measuring profit, anticipating user needs? Isn’t that on the product owner? The product manager? Marketing? And isn’t uptime the operations team’s responsibility? And finding problems the QA team’s responsibility?

You are on a multi-disciplinary team. You have at least one vital role to play on this team. Engineering is your trained discipline, and likely you focused purely on development. The smaller the company/business unit, the more hats you will wear. Yes your main contribution is technical, but in service of the bottom line. But don’t stay in your lane! Different perspectives are essential to this game. Your product owner doesn’t have a patent on designing end user features. And she may not be thinking about measuring success. Help her define the metrics and build those collection and reporting tools into the product. After you deploy a new feature, assess its success; don’t immediately move on to the next feature.

OK, so do I eat my own dog food? I try. The tech side requires lots of cognitive space, and so outcomes are easily short-shafted. Also, I have found this holistic perspective difficult to practice in large organizations. There is lots of specialization. It fragments responsibility. Incentives are set along discipline silos. My suggestion is to play your organization’s games (don’t leave that bonus on the table!) but bring your enlightened perspective as best you can.

Good luck,
Mark

Mark Sawers has been practicing software engineering for almost 25 years, as a developer, architect and manager. You can find his blog at http://sawers.com/blog and his LinkedIn profile at https://linkedin.com/in/marksawers .

Join an online tech community

Dear new developer,

A big part of your job is keeping up to date with new technologies and happenings in the tech world. This can sometimes be a distraction, because there is all kinds of new stuff coming out all the time, whether from big companies releasing new tools or platforms, people publishing interesting code or articles on their experiences, or marketing from smaller companies. I avoid this distraction by relying on a community to do some filtering for me. Obviously that means that you need to find the right community, otherwise the filtering won’t be effective.

If you know the exact type of technology you want to focus on (say React Native or Haskell for web development), you can sign up for an email list(s) related to the projects. Or you can go to github and start to follow the issue lists. Or if you know people involved in the project, you can follow them on Twitter. Matt Raible, a prolific developer and blogger, once mentioned that he learns a new technology by unfollowing everyone he is following on Twitter, then following only people talking about the technology, so that his Twitter feed is rich with focused information.

However, if you aren’t sure exactly what to focus on, a more general community might be a better fit. These ebb and flow over the years but they also cross pollinate, so if you join one and a few years later it feels like it is not as active, be on the lookout for the up and coming community to jump to.

Slashdot was the first focused online web based community one I ever took part in. I enjoyed the discussions and linux focus. Recently I’ve moved on to Hacker News, which has a nice mix of technology, science business and politics that I enjoy. But there are other great options like Reddit (where you can find any subgenre you want, but you may want to stick with the big reddits like /r/programming), Stackoverflow (for programming q&a), and lobste.rs (which is less business and more technology focused).

Whatever community you join, whether it is a specific project or a general link sharing site like Hacker News, make sure you actually become a member of the community. Just like the value of a meetup is in who you meet time after time, visiting an online community just once is unlikely to be valuable. And be especially wary of self promotion (this Reddit page has some great guidelines about how to be an effective member of an online community, but seek out such guidance wherever you land).

Once you find and join a community, take part in it. Comment, submit links that you find interesting, and visit it. Be ready to be offended or hurt by some comments, especially if you say something dumb. I have definitely said dumb things or spoken on topics that I wasn’t fully informed about. I feel a flush of shame, leave the community alone for a few hours,and then come back and apologize or acknowledge my mistake. It’s unpleasant but part of the package.

The more pleasant part of the package is being exposed to new things. If it solves a problem you see, you may want to discuss bringing a new technology or piece of open source software into your work. Your work may have policies around new technology, but it never hurts to bring it up and discuss whether it may be applicable. You also may find interesting commentary and perspective on the technology you are already using at work, and sharing that can be a good way to help the team get better with it.

It’s also fun to occasionally submit something, whether an interesting open source project, an article on your blog, or something else you’ve seen. I’ve done that a few times and it’s nice when a submission blows up and becomes popular. It’s also a nice way to say “thank you” to someone who has written something interesting and help them out–I can think of multiple submissions that were interesting articles written by people I knew and when the submission got popular, the people were thankful I’d posted it.

In summation, find an online community, participate it in, and you will reap the rewards.

Sincerely,

Dan

Patterns for managing up

Dear new developer,

Design patterns are common ways to implement solutions that can be repurposed across different systems and domains. This post proposes patterns for handling organizational situations.

Some really good excerpts:

No matter how amazing you are at your job, you will sometimes get feedback about things you could be doing better. It can be difficult to hear, especially if you are someone who works really hard all the time. When it comes to negative feedback, it is important to reframe the conversation. Feedback isn’t a bad thing. It is a gift, and you should always adopt a growth mindset and see it as a chance to improve.

I have received negative feedback about how I managed (I was managing how I would want to be managed, not how the employee wanted to be managed). It was really good to hear because it let me improve, but I definitely had to hold down a “wait a minute, you don’t understand” thought. If I hadn’t, I would have both lost that opportunity to learn, and possibly many more. If you react negatively to feedback often enough, people will decide that it isn’t worth giving to you.

And this is a good one too, about how to handle a problem you created:

When problems occur, there is a natural instinct to hide or deny that the problem is a problem, or that it is even happening at all. We want to minimize the problems that are our responsibility because, after all, a big part of our job is to make sure problems don’t happen. When you are proactive about sharing and fixing a problem, however, it is actually an opportunity to show you are an asset to the bosses.

Going to a boss and saying “I screwed up” is terrifying, especially the first time you do it. But going to the boss and saying “I screwed up and this is how I am going to both fix it now and make sure it doesn’t happen in the future” is terrifying but empowering too. The other alternative is to just hope that you are never found out, which is a miserable way to work (who wants to hide things? what happens if the problem gets bigger?). If you screw up, take a deep breath, come up with a plan, and solve the issue.

The whole article is worth a read.

Sincerely,

Dan

Learn the command line

Dear new developer,

I remember the first time I saw a senior engineer struggle with the command line. He was a new hire and was getting up to speed on a new project. If memory serves, he was trying to get his IDE set up for a java project.

I noticed him with the command line open, trying to remember how to move around directories, and wondered why he was having such trouble. (Probably I felt the same way some developers feel about me when I struggle with CSS or cutting up a PDF or reading C–“how could you be a developer without understanding this?”.) I never talked to him about this, but it cemented in my mind why a new developer should learn the command line inside and out.

It’s a baseline.

The command line interface (CLI) will always be available. Wherever you are (unless you are on an old mac, pre MacOS X, in which case, why?).

Unlike some of the skills I mention above, knowing how to navigate the command line will make your life easier as a developer no matter where you work or in what platform or capacity. It’s a general purpose skill, like understanding how to use version control or learning a text editor.

Understanding the command line and being able to use it has the following benefits. Let’s take a simple task–I need to move a file into a directory, change the permissions on that file, then look through the file for a certain phrase (say, “rosebud”). With a CLI, I can:

accomplish the task in less time. I can move files, change file permissions, and look through files far quicker with command line tools than I can with any GUI (graphical user interface) tools. (There are any number of other tasks I can accomplish more quickly, as well.) The kicker is, of course, the first few times I do this, I will be slower on the command line than I would have been using a GUI. This is because you have to learn the CLI and the cues to help you do so are minimal. You of course also have to learn a GUI (anyone who’s ever shown someone a GUI for the first time know that) but there are more cues on what is the right behavior in a graphical context. But once I have it down, the typing the commands will be much quicker than moving the mouse.
make tasks repeatable. If I’m trying to move a file, change its permissions, and see if it contains “rosebud”, I can do this once easily in the GUI, using the mouse and menu commands. But doing this task regularly, whether once a day, once a month or once every time a piece of software is released is quickly going to get tedious. I can, on the other hand, do it once in the CLI, and then take the CLI commands and put them into a script (a text file that becomes executable). Then that same set of commands will be run every time I run the script. This may not matter if task is simple (as is my example of only three commands is), but if it is complex, getting it right once and having it run perfectly every time thereafter will be a huge time and energy saver. If executing the task is common, then you will save time because you will run it often. If executing the task is rare, you will save time with a script because you won’t have to remember how to run the command.
share tasks with other people. Yes, you could record a video of yourself clicking through a GUI to move the file, change its permissions and look for “rosebud”. Or you could document the actions in detail and send the doc over. Or if you are colocated, you could show them. But it’s much easier to just send someone else an executable script or set of commands that they can examine and run. As long as they have access to the same command line programs, you’re going to get the same results. (Beware different versions of the same command line program, especially if you are using esoteric commands or working on different operating systems.)

Hopefully I’ve convinced you to learn the command line. Now, what are good ways to learn it?

I think that one path is to just jump in. Find the “terminal” program if you use a mac, or the “cmd” program if you use windows. Open it up. Then google for “command line tutorial <platform>” and work through one of those. I always work best when I have a real task, so think of something you do often (for example, opening up a number of files for a project, moving files to a backup directory) and do it once in the GUI. Then do it once in the command line. Then make a script for it. See how that feels. If you are scared of messing up your computer, install a VM or boot up a cloud server (most cloud providers will give you a small server for free for a while). You can’t screw up a VM that you just started, and if you do, just destroy it and start a new one.

Another option is to think about mapping between the GUI/IDE and the command line. Every time you do a task in the GUI or IDE, drop down into the command line and try to replicate that. From something as simple as moving a file to something as complex as a full fledged deployment or compilation of a large project.

As you get more advanced, you have the option of sharing your keybindings between your editor and your shell. Just google “keybindings <editor> <shell>”. I use vi keybindings for my bash shell and it lets me move around the command line with ease and speed. And every time I learn a new way to move around the editor, my CLI usage gets better.

The command line is underneath almost every computer. Learning it will save you time and let you leverage knowledge. Well worth the effort.

Sincerely,

Dan

PS I would be remiss if I didn’t link to this essay about the command line.

What Mitchell learned in his first two years as a software developer

Dear new developer,

It’s great to see what other developers have learned, especially when they are just starting out.

This is a post covering Mitchell Irvin’s lessons from his first two years as a software developer. Now, I don’t know Mitchell at all (but I guess I am connected to him in the third degree, according to his LinkedIn profile).

But his lessons resonated with me. Here are his lessons:

Your relationships with your coworkers (interpersonal/leadership skills) and your technical prowess (hard skills) are equally important
Your ability to influence others is most prominently determined by your ability to help them reach the same conclusion you did, on their own
It is the mark of a great problem solver to ask many questions before beginning to think about a solution

Each of these is worth a blog post, but I’ll let you click through to see how Mitchell arrived at each of these–some good anecdata.

However, I think that the bigger point is not what Mitchell said, though he has good points. There are two interesting meta points:

Mitchell reached me without me knowing him, or knowing anyone who knows him. This is the power of writing, especially a blog. You never know who you’ll connect with.
I checked his arguments against my experience and found it resonated. This is a great way to judge new data that comes at you (and, as a software engineer, a lot of information will flood toward you). But you also need to be aware of your innate biases, and think about how the points in any post or article could be false. You also should consider the source. Mitchell has worked at a couple of large companies and his experience may not be applicable at a different type of company.

Being an information consumer and producer is a key part of being a software developer. You should work on your writing to produce information. And you should be thoughtful about your information consumption.

Sincerely,

Dan