On mid-career challenges

Dear new developer,

I really liked this post on mid-career challenges. I know you’re new, but you’ll be mid-career before you know it!

I’m in a position right now where I have to figure out what comes next for me and how to navigate the challenges of getting there. I made it to senior engineer, I wrote a book, I spoke at a bunch of conferences, switched from ops to dev back to ops again — so now what? For some people, mid-career looks like figuring out what your next set of career goals might be, what you might want your next 10 years of work to look like. For others, it might mean changing careers — you might be in a position where you’re quite senior in terms of core skills such as communication, team dynamics, and project planning, but you came into tech from another field so your coding skills still have leveling up to do.

As you get your legs under you as a developer, it’s worth peering into the future so you can set yourself up for success. Setting goals is part of that. So is learning from other’s experiences.

As usual, the whole post is worth a read.

Sincerely,

Dan

Contextual advice for new developers

Dear new developer,

A few months ago I asked Marie Chatfield, a front end developer and advice columnist, what her one best piece of advice for new developers was.

She wrote a great response. From the post:

For the self-taught programmer: I am amazed at your dedication and perseverance and ability to learn from different resources. Remember that other people have valuable things to teach you, too, and seek out trusted mentors or role models when you can. You will never stop learning in this industry, and you have shown already that you are ready and willing to put in the work. That’s going to take you far.

For the one who doesn’t see themself represented anywhere: I am so glad that you are here. I hope you can stay here for a long time. I hope you find communities that make you feel welcome and safe and included. You get to make the right choices for you and your health and safety, even if it makes others uncomfortable or disappointed. You don’t owe increasing the representation of a space with your presence to anyone. You belong here, and you should get to focus on doing the kind of work you want.

What I like most about this is that she gave contextual advice. New developers share many characteristics but are by no means a homogeneous group. The bootcamp grad who was a marketing guy previously is different than the computer science graduate who is starting her first job after college. They both differ from the kid who has been coding since they were twelve. I write these letters from a certain perspective, but know that everyone will read them from their own place.

I really also appreciated her advice to everyone:

 

  • It’s okay to fail. Everyone makes mistakes.
  • It’s okay to look things up. You don’t have to remember everything to be a good developer.
  • Everyone is nervous about interviews. They’re kind of awful. But you get through them.

 

I asked Marie for one piece of advice, but she gave more than ten. I enjoyed reading her advice to new developers and I hope you will too.

Sincerely,

Dan

PS She also has written some other great posts.

Leveling up tips from Chelsea Troy

Dear new developer,

I found this video from Chelsea Troy about how to level up as a developer interesting (I love watching YouTube videos on 1.5x speed to save time):

A few tidbits I found interesting:

  • the distinction between leveling up passively (which we all do as we learn in our daily work life) and leveling up actively (with a goal)
  • the importance of routine in this deliberate leveling up process
  • the idea of commit tracing as a way to learn a system (yes, version control is important)

You can also read the transcript.

This section about reaching out to experts also resonated. If you take the time to craft a good question, you can get the attention and help of even busy people.

Third, if I am struggling to find the answers to my questions in literature, I find myself asking, who can help me? I think it’s easy, especially in tech, to feel like you’re alone and you need to be able to solve problems yourself. But I have found that not to be true. Sometimes it’s a matter of reaching out to a coworker or colleague to get another set of eyes on whatever I’m working on. If that doesn’t work, then I’ll ask an expert. And I have been repeatedly surprised by the generosity of experts. The first time I ever needed to implement Spring Batch in something, we had a complicated use case and I somehow just couldn’t get it to go. So I reached out to the team, and one of the Spring core contributors pair programmed with me to get the thing working. Another time, I was working with XGBoost, which is a machine learning library that relies on a particular, custom-crafted data structure called a DMatrix. But I couldn’t find anything online about how the data structure was built, so I reached out to a developer advocate on LinkedIn, and she gave me an insightful answer.

I’m not saying her system will work for you wholesale. Whenever you’re learning what worked for someone else, you want to evaluate the methodology from your perspective. But she definitely has great ideas (she blogs on leveling up a fair bit) and I’d suggest you listen and try out the ones that excite or interest you.

Sincerely,

Dan

Things good engineers do

Dear new developer,

I found this post covered some things that good software engineers do. It doesn’t focus on the technical aspects, but on other aspects of software development. Things they do:

  • Ask for help
  • Work on one thing at a time
  • Prioritise unblocking

My favorite quote:

In software development we rarely have the luxury of a todo list with a single item on it. Despite this, we are not able to work on two things simultaneously. Every time you work on one thing and change to another you pay the cost of mentally (and sometimes in development environment) context switching. As a result the most efficient way to work is generally to take one task to completion before starting another task.

These are all key things for engineers to do. The first makes sure you aren’t beating your head against the wall unnecessarily. The second makes sure you can focus on one thing and avoid context switching. For many kinds of development work, this is the most efficient way to accomplish a task. The third acknowledges that you should optimize for team productivity over individual productivity.

Three great pieces of advice. Worth reading the whole post, “Some Things Good Engineers Do”.

Sincerely,

Dan

A bunch of career advice from a new developer

Dear new developer,

This post has a lot of great career tips including how to select companies to apply to, what to do in an interview if you don’t know the answer to a question, and how to challenge yourself in a new job. This piece of advice in particular resonated with me:

Show how you think

Most interview questions are there to see how you think. So show that! Explain your thought process, draw diagrams, write out the intermediary code, explain pitfalls in your approach, etc! Be vocal, and ask clarifying questions. That’s part of being a good developer after all!

When I was hiring, especially for newer developers, I really wanted to hear how people thought through a problem. That process is important in two ways beyond actually solving the problem. The first is that it shows how you handle something tough that you haven’t encountered before (which happens almost every day on the job). It also shows an interviewer how you communicate. Since a lot of the challenge of building software is communication, learning how potential team members do it is crucial.

The whole post, “The Career Advice I Wish I Had” is worth a read.

Sincerely,

Dan

The care and feeding of developers

Dear new developer,

I thought this post from 2012, about what software developers want, was penetrating and relevant. This passage resonated for me:

And here’s the real crux of the problem: software engineers aren’t builders. Software engineers are creators. Building is what you do when you buy a piece of furniture from Ikea and get it home. The instructions are laid out and if you go step by step, you’ll get that comically small table you wanted. Creating is a different process, it’s birthing something without direction or instruction. It’s starting with a blank canvas and painting a masterpiece. Software engineers don’t get into coding because they want someone to tell them what to do, they get into it because they discovered they could create something useful. Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked.

Even as a new developer, you’re constantly making small creative decisions (naming a variable, for example). This is part of what makes software development so fulfilling and fun. Any place where you are solely an order taker with no opportunity to add your unique perspective is a place I wouldn’t want to work. (Such a place would remind me of L. Bob Rife’s plans. And if you haven’t read Snow Crash, highly recommended.)

The whole post, “The care and feeding of software engineers (or, why engineers are grumpy)”, is worth a read.

Sincerely,

Dan

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