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

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

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

You can do this.

This is a guest blog post from Kyle Coberly. Enjoy.

Dear new developer,

You can do this. There’s a lifetime of stuff to learn and it will seem intimidating, but if you keep doing it, you’ll get better. Teenagers, career changers, and retirees all have done this, and they weren’t any smarter or more naturally talented than you. You’re in the right place.

Make stuff. It’s easy to get lost in a bunch of theory, especially when it’s dressed up as “the fundamentals.” You can learn theory any time. Seriously. Learn what you need to learn to make something that interests you, and you’ll learn a lot and get enough fuel to get to the next station.

Participate in the software community. Go to meetups, join a community forum or chat group, go to conferences. There’s a lot of people exactly where you are, and a lot of people who were there not so long ago and want to help you get better.

Sincerely,

Kyle Coberly

Kyle Coberly is the executive director of the Develop Denver conference, co-host of the Sprint UX Podcast, and serves as the Technical Lead for Health Scholars. Previously, he was the Faculty Director for Galvanize’s Web Development Immersion program.

Get used to failure

Dear new developer,

I was chatting with someone I met at a meetup who was about to graduate from a bootcamp. I asked him what his advice to a new developer would be. He said that it would be “get used to failure, and get used to working through it.”

I thought that advice was great.

I often tell colleagues that “if it is easy, someone would have already automated it”. This means that when you are working on a software problem, the problem by definition hasn’t been solved within your organization (that you know of; I’ll come back to that). This means that you’ll most often be failing. Just like scientists who try to narrow down their scope of inquiry so they can have useful experiments, you’ll try to narrow down the problem and pattern match and research so that you can have a working solution. But just like the best planned experiments fail, so will you, often.

There are two additional complexities that software developers have that scientists do not.

The tools that software developers use are themselves software and are being developed. Imagine trying to build a house when the hammers and saws that you are using are themselves changing at a rapid pace. This means that the solution that may have worked in the past is suboptimal.

And the real world that scientists operate on and try to understand doesn’t often change daily. The business world that software developers operate on and try to understand can change on the whim of a person in authority. This is an essential complexity of software development.

This experience requires you to get used to failure, both at the micro and macro levels. And to keep going. You just need to be tenacious and realize that you’ll solve the problem. Also, recognize the frustration and realize that everyone is going through it. A coach once taught me that running is hard for everyone, whether you are running a 5 minute mile or a 10 minute mile. The same is true for development. Learning something new is difficult and frustrating, whether it’s your first programming language or the intricacies of a build and deployment process that is new to you.

Get used to failure and remember that everyone else encounters it.

I mentioned I’d return the caveat that problems you tackle haven’t been solved “that you know of”. Back in the dark ages before the internet was widespread, distribution of software knowledge was slow and driven by email, bulletin boards, journals and books. Now we have google and stack overflow. This helps with coming up to speed on external software that will help you solve problems. I’ve yet to see an internal system that works well for sharing knowledge, but it is incumbent on you and your teams to search out solutions within your organization.

Once you have a problem defined (even partially), resist the temptation to dive in and start building a solution. Rather, pop your head up and ask around and see if anyone has solved your problem. Or even one third of it. You may or may not re-use their solution, but it will inform your solution even if you don’t.

Sincerely,

Dan

Write that down!

This is a guest blog post from John Obelenus. Enjoy.

Dear new developer,

Even when I was a kid in school I hardly wrote things down. That’s why we had textbooks after all! I was baffled by other students in college furiously transcribing every word that came out of the professor’s mouth. Now I have a career in the world of software where we track everything. Git holds all the code commits, email is never really deleted, and project management and issue tracking tools keep track of what we’re doing and have done. How could anything go missing?

I constantly looking for things and cannot find them. I get a bug report, look at the code and say to myself “That is obviously wrong, let’s fix it.” I look at the offending commit that introduced the bug (of course it was me). But what is not there? The reason for the change. So I look at the project management tool we use. And someone definitely asked for a change, but, I’m still not sure why. So I search through my email for the few days before I made the change, and…nothing. I still cannot really figure out why we all decided to make a change which introduced a bug.

Or, worse yet, someone asks for a change. All well and good. Then a month later, someone asks to change it back. So you shake your head and make the change. Then someone is confused why this is happening, and calls a meeting and invites you to help figure it out. What are you going to bring to this meeting? Did you write anything down? I never used to. Now I do.

Now I have a notepad next to my laptop. And I have a notebook on the shelf. I make better use of git messages and write down who asked for changes. When working on a feature, or a bug, and find something…“interesting” I make a Github wiki entry explaining it. I write a comment in the code base explaining it. There are two kinds of documentation — useful documentation, and redundant documentation.

No doubt many people have told you to comment your code. I hope many people have told you never to comment a loop with // loop over the array. That is not increasing clarity, its just duplicating what the code is doing. Adding noise, not signal. My contention is that comments are rarely useful for explaining “What this code does…” but rather, explains “Because of X, we are going to do…”.

Future you is going to be very happy if you start documenting the intent behind what you’re doing. Good code is easy to read. Bad code is capable of being understood with time. But code doesn’t tell you why you’re doing all this work in the first place. Maybe something has changed and you don’t even need this code anymore — deleting code is the most satisfying feeling. But you won’t know unless you know the intent, the purpose, of the code. And the rest of the folks you’re working with are going to be very happy as well.

If you write everything down (and make it public), they won’t need to tap you on the shoulder when you’re in “The Zone” to ask. When someone wants to set a meeting to understand why things are “The Way They Are” you already captured that information. You can send them the link and kill the meeting (Ok, maybe killing meetings is more satisfying than killing code).

We only have so much time in our life, and we already work long hours. Let’s make future us happier by writing things down, so we don’t have to figure it all out again. We figured it out once when we wrote the code. So capture the knowledge in that moment in time. And Write It Down!

Sincerely,

John Obelenus

(Previously published at Medium)

John Obelenus solves problems and saves time through software and crushing entropy

 

J

Be a Just in Time Learner, part II

Dear new developer,

I previously wrote about being a JIT learner and talked about it in the context of a Just In Time compiler.

Just in time has another meaning, that relates to manufacturing. Delivering the right parts to the right plant at the right time revolutionized manufacturing. Just in time learning means that you focus on what can give you the greatest bang for your buck, and that you learn it when you need to.

The world of software is immense and as you navigate it more, you’ll begin to see patterns. When I see a new dependency management tool, I know it’ll operate roughly like the three other dependency management tools I’m experienced with. It will have:

  • a dependency tree, likely stored in text
  • a central repository or multiple repositories, where common code resides
  • a way to have a private repository for proprietary code
  • commands to update individual packages or an entire system

So, I don’t really need to master each dependency manager, because I can do the mental mapping between the ones that  I know (like maven and bundler) and the ones I’m less familiar with (composer, npm). I learn just enough to do what I need to do. I do this to avoid being overwhelmed by each new tool.

In a similar manner, you can apply the same thing to software development in general. When you start to get overwhelmed, you can focus on one task at a time, and learn just enough to do that task. Now, I think you should try to understand why you are doing that task and not just copy pasta code, but there’s a balance to be struck. You also may need to have a deep stack to do this (watch out for yak shaving), as you’ll be pulled from one task you don’t fully understand to another.

The way to defeat this is to continue to build the mental model. Try to understand the smaller pieces of a site or application before moving up to the medium size pieces and then to the larger pieces.

An example. When I’m starting a new project the first task I always try to understand is how do I get this running locally. Running a project locally is glorious! Even if the project isn’t under version control, I have absolute control of the local environment and can tweak and break things with abandon. The next task I try to understand is how does this software get deployed to production. Here obviously I can’t break things with abandon, but I learn what the architecture is like. Finally, I’ll try to make a small change and see if I can get through the deployment pipeline. This assures me I know how to connect the two key environments (local and production).

You can do the same thing with the first months of a new job. Map it to other jobs or schooling you’ve had. Think back to what worked in the past for learning new tasks.

In short, be a just in time learner. Focus on what’s in front of you, and learn that. Build models between what you know and what you don’t. Don’t fall into the trap of trying to understand everything.

Sincerely,

Dan