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

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

The right way to ask a question to get an answer

Dear new developer,

I already covered the right way to ask questions, but this post was so good that I wanted to share it. (I found it on hackernews.) Mike Ash gives advice on how to get answers from the internet.

Tips like “explain everything up front”, “post your code” and “follow up after you get an answer” will make it more likely that when you post a question on a forum, you’ll get some kind of help. The whole thing is worth reading, but here’s an excerpt that really resonated for me:

Many conversations I see indicate a subtle, buried belief that the list or chat is some kind of answer machine, and the key to obtaining a good response is to hunt around until the precise required format for the question is found.

It’s not a game, you’re talking to real live people. Treat them just as you would treat people you’re talking to face-to-face, and you’ll get much better results.

I have been one of those newbies under pressure to get something done. I’ve seen comments on github that lead to statements like this. It’s easy to forget that the folks helping you are

a) people

b) not getting paid by you

No matter how obvious the bug seems, or how much it is impacting you, you have to treat people helping you kindly. (You should do that even if you are paying people, by the way. If your boss doesn’t respect you, find a new boss.) Anyone who has run a volunteer organization knows that respecting the volunteers is the first step to getting anything done. Every time you ask a question on an internet forum or mailing list, you are essentially tasking a set of volunteers. Treat them right.

Sincerely,

Dan

Letters to a new developer from Joel Spolsky

Dear new developer,

Looks like Joel Spolsky has written a number of blogs posts aimed at new developers. Every post is tagged with the date so you can be aware of any old posts that may have dated advice. But I’ve been following Joel since a colleague emailed the Joel Test around our workplace in 2000 or 2001. He’s founded a couple of great companies (including Stack Overflow) and has lots of great advice, written pithily.

A sample:

Here is why I like duct tape programmers. Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use multi-threaded COM apartments, your app will be 34% sparklier, and it’s not even that hard, because he’s written a bunch of templates, and all you have to do is multiply-inherit from 17 of his templates, each taking an average of 4 arguments, and you barely even have to write the body of the function. It’s just a gigantic list of multiple-inheritance from different classes and hey, presto, multi-apartment threaded COM. And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever classes constructed entirely from multiple inheritance from templates, without a single implementation body at all, and it’s going to crash like crazy and you’re going to get paged at night to come in and try to figure it out because he’ll be at some goddamn “Design Patterns” meetup.

And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”

I’d give them all a read.

Sincerely,

Dan

Reflect on your mistakes

Dear new developer,

This post called “Leveling Up Skill #10: Reflecting on Mistakes “, part of a series on leveling up as a programmer, provides a good solid process for reflecting on, learning from, and moving past mistakes.

I liked two parts of this in particular. The calling out of the “it’s ok to make mistakes” trope:

Before we do, though, let’s address one more thing: senior developers from privileged groups talk about this a lot already. “It’s OK to make mistakes!” “You should make mistakes!”

I cannot recommend making mistakes like that.

Maybe some mistakes have more benefits than drawbacks for the senior guy who is already reputed to be technically competent.

For a junior person, or for an engineer from an underrepresented group whose authority and ability are constantly questioned and downplayed throughout their career, screwups are costlier because they feed other peoples’ confirmation bias. “Oh, yeah, she’s hit or miss. Really botched that database refresh last quarter.”

This is part of the reason I recommend overindexing when you start out. But she raises some really good points about the difficulties folks who are not senior white guys have with making mistakes.

The other part of this post that is really solid is the four steps to process the mistake and incorporate it. I won’t name the steps, go read the article! But suffice it to say that mistakes are part of life, just try to make new ones.

Sincerely,

Dan

What is fulfillment?

Dear new developer,

Stephanie Hurlburt tweets some amazing stuff. Definitely worth the follow.

Here’s an interesting post from her about fulfillment. From the post:

I threw myself at helping others and was absolutely shocked to find myself not really that fulfilled from this work. I couldn’t figure it out, was something wrong with me?! I upped the amount of people I was helping, started doing even more work– was it the wrong kind of work? I tried different kinds. Wasn’t helping others my mission? I felt dismayed and empty.

Sometimes what you think you should be doing is wrong. The post has some thoughts about how to tease out what you really want to be doing.

It’s always worth some time to think about where you are going. But it can be overwhelming. I asked my father about that once, and his advice was to pick one or two constants you wanted in your life and orient yourself around them. I have found that to be a great way dealing with the paralysis of choice that can affect you in modern society.

Sincerely,

Dan

Justin Kan on whether you should work at a startup

Dear new developer,

Justin Kan has deep experience in the startup space, including at an accelerator called Y Combinator. He gave a talk about why you should work for a startup, and why you shouldn’t. Here’s the transcript,, and here’s a blog post based on it. If you’re looking for good management, avoid startups:

The management at startups generally sucks. I wish I was joking, but sadly it is very true.

On the flip side of that:

At a startup, you will get access to jobs that you are completely unqualified for and you might not be able to do well (yet).

(Possibly the two are related!) There’s a lot more good advice in there, well worth the read.

As a new developer, you may have a risk profile that allows you to work at a small startup. If you can swing it, you’ll never have an opportunity to learn more about how to build a business. The first few years of your career are precious and should be spent carefully. The more experienced I get, the less risk I want to take (all other things being equal), and I’ve seen that be the case for most of my colleagues.

How can you choose the right place? I’m no expert there, as I’ve fallen into several great jobs. But I’d recommend:

  • working at a place with no jerks
  • optimizing for learning

That’s about it. Yes, make sure you are paid market rate. Yes, make sure you are being challenged. Yes, don’t get taken advantage of. But for the first few years of your career you have the opportunity to take positions at pay levels and in areas that may be closed off later in your career.

Choose wisely.

Sincerely,

Dan