How to be a successful junior engineer

Dear new developer,

I enjoyed this post from Hanah Yendler on how to succeed as a new developer. Note that she is working at Eventbrite, a larger company (1100 employees according to wikipedia), so some of the advice may be a better fit for new developers at bigger companies.

A few of the pieces of advice really resonated with me:

Take responsibility for something that seems slightly out of your reach. One of my previous managers at Eventbrite told me that he wants me to be sitting just on the edge [of] fear because that’s where intense learning happens. I have a huge fear of failing, but taking responsibility means pushing yourself and growing as an engineer.


It can be tough to get a subject matter expert (aka an engineer more senior than you) to explain things on a level that you can understand –especially when they have very intimate and in-depth knowledge of a system or complex subject. This is where asking questions becomes essential. You can use questions to help guide them to the answer you are searching for.

Both of these pieces of advice are true when you are new to the industry and true when you have decades of experience. (Pushing yourself to the edge of your comfort zone is how you grow, and asking questions is one of the fundamental ways to learn.)

The whole post is worth reading.



Balance Questions With “Banging Your Head”

This is a guest blog post from Don Abrams, lightly edited. Enjoy.

Dear new developer,

When starting out, the hard part is balancing two things:

  • Asking questions
  • Banging your head against the wall

Additionally, as a new developer you’ll likely be encountering something for the first time: a codebase that is really really large. Like large enough no one knows all of it. You’ll want to learn how to navigate the codebase ASAP. Every place is different. If you can checkout all the code and get the product running in less than a day, you’re at a world-class shop. If it’s more than a week, I’m sorry.

After you learn to navigate the code, my recommendation is then to learn and copy the patterns that other team members use. So your questions should mostly be “how did someone solve this before?” or “hey, have you seen anything like this before?” If you look at the code they referenced and still have questions, then bring it back up ASAP.

If someone offers to pair, DO IT! Tip on pairing as a junior: be the keyboard and basically have them tell you what to do. You’ll learn how they think about the codebase and learn to navigate it better. You’ll feel stupid when they tell you “just” to do something, but those are the things you need to know. (“just XXX” signals that XXX is complex thing that you’ll take for granted soon– documenting those will really help the next junior).

I also recommend reading a LOT of code.Then, as you get a better command of the codebase and team patterns (3-6 months), you can start asking questions like “why did someone solve this before this way?”

That’s when it gets fun.


Don Abrams

Don Abrams has over 10 years of software development experience and recently moved to France.

Work for a place where people care

Dear new developer,

Every company has its warts (aka issues, aka problems). I have never met anyone who worked for the perfect company.

So, go in with your eyes wide open and choose what warts your company has. You may be able to help fix some of them, but some will be permanent.

One wart to avoid: an indifferent team. One just punching the clock, trying to get through the day.

If a company is full of people who don’t care, then you’ll have trouble fixing any other issue. Customers will be an after thought. And work will drag. (Yes, places like this exist.)

That’s not to say that a place where people care will be unicorns and roses, but at least people will want to fix issues and serve customers well.

How can you tell from the outside if people don’t care? Ask questions like “how do you improve processes” or “what do customers love about what you do” or “what changes have you all struggled with over the past year” or “how do you keep up to speed on the newest technology”. If the answers to these indicate a lack of caring and empathy, then I’d shy away from that place of work. If you are already in it, make plans to leave.



PS You also want to avoid people who don’t care.

The best code is no code

Dear new developer,

It’s paradoxical, but sometimes the best thing you can do is not write code. Remember, the value you provide is to solve the problem you are faced with (the outcome), not to write code. Custom code has value, but comes with costs. It needs to be deployed, maintained and upgraded. It has bugs. It requires a developer to change. It also has opportunity cost. Writing custom code to accomplish task A means that you won’t have time to accomplish task B, which may be either more urgent, more important or both.

There are a couple of ways in which you might solve a business problem with out writing a lick of code.

  • Use a library or framework. For instance, I worked at a place where they had written their own database connection pool. Why? I never got a great answer, but it wasn’t clear to me that one of the open source solutions wouldn’t have worked. You need to have an awareness of such libraries to be able to propose this.
  • Use a third party SaaS tool. I’ve seen people run their own in house git repositories. There may be good reasons to do this (including security or privacy concerns). But Github is going to give you a far better experience and unless you have a big team, probably better security and privacy. You need to know what the problem, the solution and the cost are to make an effective suggestion.
  • De prioritize the work. I was at a meeting with a CEO and we were talking about continuing an effort to integrate a set of outside data sources. I asked why, and we discussed it a bit further. It became clear that the reason we were thinking about doing it was because of inertia. It became clear that there was no real business reason to do it, and we prioritized other work instead. A clear roadmap and the willingness to question requirements are helpful with this path.
  • Do it manually. I was working on a startup and we had the need to occasionally refund customers. I could have integrated with the payment provider and had this case be handled automatically, but it was much much easier to document the process and handle it manually. Refunds happened rarely enough that there was no value in automating them. Here it is helpful to know how often the problem arises, how long it takes to fix manually, and how often it will arise in the foreseeable future.

Now, sometimes you may not understand the larger context of your work. You may propose a solution that isn’t the right fit, and there’s certainly nothing wrong with writing custom code to solve a problem.

In cases where I’m not sure I have full understanding, I always preface my questions with “I am not sure I have the full picture, but I think we could solve the business problem using solution A or project B, rather than writing custom code.” If you are working directly with the client, they likely won’t care, as long as the problem is solved. If you are on a team, the engineer or project manager running your project should have a good understanding of alternatives and why custom code might be the right solution. Most folks will be happy to share that reasoning with you.

In short, it’s better to keep your eyes on solving the business problem and be aware that custom code isn’t always the right answer.


PS No, this isn’t an April Fools Day post 🙂

Learn to use Google, and use it well

Dear new developer,


Tips for searching:







Avoid The Impossible Goal of Being a Know It All

This is a guest blog post from Rick Manelius. Enjoy.

Dear new developer,

Can you name all 50 US states? How about their capitals? Every city in the US? Every town? Could you list the GPS coordinates of every coffee shop?

Of course, you can’t, wouldn’t, and don’t. It would be absurd to spend the time and effort to memorize such a vast amount of information that you can Google within seconds. Yet developers often fall into the trap of over preparing and learning a myriad of facts and syntax trivia for a new programming language or framework before diving in and getting their hands dirty.

A personal example: When I landed my first contract as a web developer, I recommended Drupal for the client’s project. However, I was deathly afraid of not being able to address any questions that might come up. To satisfy my “need to know it all” before I put forth an initial proposal, I purchased have a dozen ebooks and read the more popular ones cover to cover several times. Meanwhile, I was only dabbling in writing code by following the tutorials.  Unfortunately, this was about as effective as trying to learn a foreign language without a practice partner. The information was forgotten almost as soon as I learned it.

I contrast this with how quickly my experience and skills grew when I started to give myself the permission to play, to test, to tinker, and to interact with the community through IRC and the issue queue. It was there that I would run into a blocker and use those eBooks as a useful resource because I had a specific purpose in mind. Moreover, when I couldn’t find my answer there or with Google, I could lean on others that were actively learning, growing, and sharing along their career trajectory.

Years later, I discovered this humbling infographic titled Becoming a Web Developer in 2017. I love this because it highlights the absurdity in trying to learn everything about everything in the web dev ecosystem. While all sites eventually roll up to HTML, CSS, and JavaScript, the number of underlying technologies used to support them is visually overwhelming.

A select infographic from The Web Developer Roadmap 2017

Each of the boxes represents a different subject matter. Each of these subject matters has additional, hidden complexity. Also, within that, there might be subsystems that maybe only a few core maintainers of that specific project would understand. Each box may take a day or a week to learn the basics, but perhaps months to years to master.

Trying to do that for every topic becomes an overwhelming investment of time for increasingly diminishing returns. It’s equivalent to learning the GPS coordinates of every coffee shop in the US.

To make matters worse, this infographic only represents the hard skills necessary to produce and maintain the software and its supporting infrastructure. It says nothing about the soft skills of how to participate and grow a high-performance team, how to make solid architectural choices, how open source governance works, how to handle change and release management, how to apply different project management methodologies, etc.

Before I overwhelm you any further…

…there is hope.

You don’t need to know it all. In fact, some of the most successful developers I’ve come to know are skilled searchers and askers. They may not know the information, but they know where it could be. They know how to parse documentation to find the salient details they need to accomplish the task at hand. They have a network of colleagues in other specializations that they can lean on for help. They are confident in asking even basic questions (gasp) in public, because while it may seem obvious for many, there is always at least 1 other person who has the same question.

Let’s look at the medical profession for inspiration. While they all go to school for 6-12 years to gain a base level proficiency, they can then either stick to general practice or hone in on a dizzying array of specialties. When we get sick, we start by going to our primary care doctor. Their goal is to identify and solve the problem there, or narrow down the answer space and refer you to a specialist. Unfortunately, even the specialists don’t always know what the issue is. This is why people sometimes need 2nd or 3rd opinions.

The good news is that in software we don’t need to go to a school for a decade to get started with experimentation or specialization. We are one tutorial and terminal prompt away from trying a new language or checking out a new library and testing it in a local sandbox where little to no damage can be done. There is so much power in this! And it’s also where it can be overwhelming given the 28 million public code repositories on GitHub alone.

Adopt a Hive Mind Approach

We live in a golden age of sharing and collaboration. Developers from all around the world ask and answer questions on Stack Overflow. They write tutorials and howtos on their blogs or Medium. In any given city, there may be anywhere from 1 to 20 tech Meetups a week. There are podcasts, Reddit channels, newsletter aggregators, and active conversations on Twitter.

By asking, discussing, and sharing openly in one or more of these venues, you are adopting a hive mind approach. You are both able to contribute to and receive ideas, perspectives, and solutions. It’s hard to overstate the importance of this strategy and mindset. In my experience, it’s many times more valuable than reading the 3rd or 4th ebook on a given subject (although these are often a useful reference). Beyond just discovering technical solutions, interactions with other developers often result in friendships that can last well beyond the burning framework question you had when you first met them.

So my advice (take it or leave it) is to abandon the lone wolf, know-it-all approach to software development. Instead, learn to contribute to and draw from the collective skills, talents, and experience from our fantastic community that is literally all around you IF you are willing to connect with them.

Final point. I stayed isolated for years until I broke into the Drupal community. Once I did, my career rapidly transformed. I wrote about that here.

So get out there! And good luck!

– Rick

Rick Manelius is an MIT engineer turned web developer turned startup CXO (operations, product, and technology). You can connect and learn more on his personal blog and his LinkedIn profile.

Tips from a recent bootcamp graduate

This is a guest blog post from Jesse Ling. Enjoy.

Dear new developer,

Be comfortable with being uncomfortable. You’ll never know all the things. And that’s ok.

Ask questions – at the right time. There’s a fine line between reaching out for help too early and too late. Struggling is imperative to growth, but reaching out for answers too soon significantly hinders it. You’ll better understand where that line lives over time.

“Stand on the shoulders of giants.” More than likely, your problem has already been solved. Don’t be afraid of trying other’s solutions if it makes sense for your implementation. But do take the time to fully understand why and how it works.

Be persistent. Programming is difficult and often times frustrating. Don’t give up. The feeling of figuring things out after a struggle is amazing.

Network. Talk to devs at, below, and above your skill level. Opportunities can present themselves in mysterious ways. Utilize your network to not only help yourself, but more importantly to help others.


Jesse Ling

Jesse Ling is a motivated and relentless problem solver, and a recent Turing School graduate seeking web development opportunities.