Web APIs for new developers

Dear new developer,

Chances are high that you’ll be working with other code as a developer.

I remember when I was first starting out and saw the acronym API everywhere. I had no idea what it stood for. In case you are in the same boat, it means Appliciation Programming Interface. What that means is it is a defined way for your code to call into another piece of code.

One of the most common ways to do so in an interconnected time is via a web API. A web API (as I define it) provides significant functionality for your application, across the internet, over HTTP. You may or may not control the API, and you may or may not use an SDK to access the API. (There are, of course, many other ways to integrate other functionality into your application, depending on what you’re doing.)

This article does a good job of discussing some of what you should be aware of when you are accessing web APIs. In particular:

First, a clarification: the term API is used to refer to lots of different things, and its emphasis has shifted a great deal over the years. If you’ve learned anything about Object Oriented development, you may be familiar with APIs as code components that have well-defined interfaces, allowing “customer” code to access the features and functionalities within a system. These APIs usually involve objects and methods / functions. This is not the type of API we’re going to talk about in this article. 😅

In this article, we’re dealing with the kind of API you use to manage access to data and services over the web. If you’ve come across the terms HTTP API or REST API, that’s what we’re talking about. With this type of API, client apps make requests to endpoints to carry out operations on data. An example would be a database for a shop that has a web app and a mobile app – with an API managing access to the data from both apps.

The article goes on to discuss different concerns you should have as a developer interacting with web APIs.

The power of web APIs is that you can gain access to a quite complicated system via a simple API call. Examples of this include:

Looking up stores or restaurants that are close to you (Google Maps)
Making a charge against a credit card (Stripe)
Sending a text message (Twilio)

These all used to be tremendously complicated tasks, sometimes taking weeks to months to set up. Now you can access them and put together an application that does all three in hours. We stand on the shoulders of giants, indeed.

You don’t just benefit from the API integration one time. The API provider has an incentive (especially you are paying them in data or money) to improve their service. And often you can get the benefits of that improvement without lifting a finger.

If you have a large task that you want to do as part of an application, it’s worth googling around a bit to see if someone has already encapsulated it in an API.

Sincerely,

Dan

Learn to type quickly

Dear new developer,

Coding is so much more than typing into a computer. Other things that matter:

knowing who to talk to
what to build
when to discuss high and low level concepts
other processes like testing and documentation
communicating progress
course correcting when a project goes awry

These are all skills you need to be a great developer.

However, just like knowing the command line and a text editor, knowing how to touch type will make you more effective. Touch typing is the ability to type without looking at the keyboard with all 10 of your fingers (if you don’t have use of all your fingers or you use fewer, you can still type quickly).

Typing well is especially important because many forms of communication are text based (slack, email, ticketing systems). But even for plain old coding, being a touch typer will help you be more effective. This is because you’ll be able to implement things more quickly. You should learn your keyboard shortcuts for commonly used programs too.

You can Google “practice touch typing” and check out several sites (paid and free) to improve your speed. There are also competitions out there like typeracer. I was lucky enough to learn to touch type in school, so I haven’t had to try any of these out.

However, a big caveat. If I had the choice between being a fast typer who didn’t understand a problem space or a slow typer who did understand a domain, I’d pick the latter. Often, the best code is no code. So, focus on understanding and then solving the problem. Make sure you make your fast typing skills work in service of solving the correct problem, so you can be the fast typer who does understand the problem space.

Sincerely,

Dan

Talk first, code later

Dear new developer,

The more experienced I get, the more I realize that the hard part of software development (for the kinds of software development I do, primarily business web applications) is not the coding. It’s the communication.

You need to communicate, often among shifting parties over weeks, months or years:

why you are building something (to motivate people)
what you’re trying to build (to make sure builders have the same vision)
how you’re building it (to make sure that builders’ various components work together well and are cohesive)
when it will be done (so that all the follow on pieces of work–sales, marketing, etc can be scheduled)

Whew, that’s a lot of communication. But it’s important.

This piece, “Talk First, Code Later”, talks about the same problem from a different viewpoint. From the post:

After we all got on the same page, we made a plan, the other team abandoned their original change, and we agreed on the way forward. In one case, we shipped the new feature that unblocked the other team. In the other case, we coached the other team on how to implement the change in a way that we could accept the pull request.

It also has some handy tips on how to maximize communication when you are making a change to a system with which you have minimal familiarity.

The whole post is worth a read.

Sincerely,

Dan

Listen to podcasts

Dear new developer,

Depending on what your life looks like, you may have some time where your body is occupied, but your mind is not. At least not 100%. Tasks like doing the dishes, running and driving all fall into that category.

In this extra time, you may want to listen to podcasts. Most smartphones have an app but you can install your own (I like PodcastAddict). Good podcasts:

expose you to new ideas (so you don’t remain an expert beginner).
reveal new technologies and tools.
are a source of wisdom and experience.

I think there are three categories of podcasts that you can listen to that will help your development career (I’m omitting lots of great podcasts by adding that clause).

Domain specific. If you work at a startup disrupting the real estate industry, listen to a podcast or two about real estate. Car insurance? Fashion? In each case you can find podcasts that are focused on your domain. You don’t need to be an expert in your domain, but the more you understand of it, the more able you’ll be to implement software in that domain and communicate with subject matter experts (SME) about the nuances of the problem space.
Technology specific. If you are writing code in Rails, listen to podcasts about Ruby and Rails development. The same for JavaScript or C or Erlang or Lisp or … These podcasts will be helpful in terms of helping elevate your development skills in the particular language. They’ll also be helpful in making you aware of tools and libraries which will make you more effective. I like to email myself notes when I listen to these kinds of podcasts.
General software development. These podcasts talk about software development in general. Some are more technical and cover architecture or other interesting problems. Some are less technical and discuss the human side of software development. But these are the podcasts you are least likely to unsubscribe from when you switch jobs, because the topics are broad enough.

Don’t feel that you have to listen to every podcast episode. For these types of podcasts I don’t listen to every episode of any podcast, because no podcast is specific enough to what I need. I pick and choose based on the show notes and the guests. And don’t feel bad about unsubscribing when you switch industries or if a podcast is no longer of interest.

Sincerely,

Dan

Skill stacking

Dear new developer,

I found this post, “How to Become the Best in the World at Something”, enlightening. The author is arguing that if you pick one area to be the best in, you’re going to have to be very very good at it. For example, if I wanted to be the best in the world at building websites with Rails, I’d have to work very very hard at it.

If you, on the other hand, pick a few things to be excellent at, you will have an easier time being the best in the world who can do all those things well. For example, if I were to be the world at building websites with Rails for CSA farms in the USA with ecommerce and email functionality, I’d have to understand and be good at:

building websites with Rails
knowing the needs of CSA farms
understanding ecommerce
knowing email strategies

I’d need to know a lot about all of these, but I wouldn’t need to be world class in all of them to be world class in the overlap between them. The post has some nice graphs illustrating this.

Here’s a great quote from the post:

Let’s run some numbers on this. If your city has a million people, for example, and you belong to the top 10% of six skills, that’s 1,000,000 x 10% x 10% x 10% x 10% x 10% x 10% = 1. You’re the number one person in your city with those six skills. Bump that number up to 10 skills? Boom, you’re the best in the world at that combination of 10 skills.

This is another way of saying what a lot of business advice says: nicheing down is an effective business strategy. By nicheing down, you are decreasing the number of people that you are competing with and also making it easier to market yourself to people who need you. It’s a lot easier to focus on CSA farms who need ecommerce websites with email and to gain excellence in understanding their problems and potential solutions than it is to gain excellence in all things Rails. (I wrote about this a bit in deep vs wide experience.)

The whole post is worth a read.

Sincerely,

Dan

What is the best surprise of being a new developer?

Dear new developer,

I was asked recently at a talk I gave about what was the best surprise of being a new developer. I was talking at Turing School, and had discussed some of the things that surprised me when I was starting out.

There are a lot of great things about being a developer. For all that is wrong with the software industry, when you are a developer:

flow happens
you are doing office work (typically)
there are smart people around you
you are paid well (compared to many many jobs–median pay for any job in the USA is 32k in 2018 and for software developers it is 105k)
you get to learn all the time

So all in all it’s a pretty great job.

But the best thing and what surprised me a bit as new developer (and makes me sad) is how much developers are listened to. Or, rather, how little folks in other professions are consulted and listened to (based on anecdotal evidence and conversations, sorry no hard data).

So, being a developer (in a healthy team and company) means that your opinion is heard.

Sincerely,

Dan

How to succeed at a larger company

Dear new developer,

This Ask HN is worth a read, as there are some good tips on how to succeed in a larger company.

I’ve been here for about a month now and still feel like I’m mostly just in free falling trying to figure out 95% of what anyone talks about or how to do things. It seems like everything works fundamentally differently than it does for a smaller scale company.

Some of the advice:

Take always a notebook and a pen with you. Whenever there is a word, or process, you have never heard of or are not sure what it consists of, write it down.

Now every few days schedule a meeting with a member of you team, reviews the list, and request explanation/clarification.

Take additional notes for future reference. That’s it, in a few weeks you’ll feel at ease with what is happening around you.

This is a gradual process, you’ll keep learning in the months, years to come.

This is a good tip for any new job. Take notes, make sure you try to get a bit better every day. Even at a super small company, while you may feel pressure to deliver right away, reasonable people will expect some spin up time. When I was at a small consulting company, I was expected to start really understanding things in about a month, not in the first week. Give yourself some time.

But do take notes and find out when you should ask questions. Some teams will want you to ask questions as they arise, others might want it more structured. If you can, document for the future (wiki, github READMEs, etc) so ask about doing that.

(Side note, in my experience, if you succeed in delivering anything in the first week that is going to be a feather in your cap. I remember delivering working code in the first day or two of a contract at a large company where I was hired as a senior developer and having the product owner be suprised.)

Another commenter mentions that there is more communication overhead in larger teams.

As you are noticing, there is a lot of communications overhead for large teams.

I have spent most of my time at smaller companies, but have worked for a few big ones (> 50k employees). It’s a different world, in my mind, one where ability to communicate becomes even more important. This is true for everyone, both the individual contributors (ICs) and management.

Sincerely,

Dan