Category: letters to a new developer

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.

Sincerely,

Don Abrams

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

Everyone, Including You, Has Something To Teach

Dear new developer,

I am happy and amazed when new developers help out other developers. I’ve seen several new folks go back and mentor at a bootcamp. Or present at a meetup. This is great, because everyone has something to teach.

You may think to yourself: “No! I am learning so much right now. I don’t know anything. There’s no way I could teach anyone something.”

False.

There are at least three ways you can teach something.

I will note that some people are less willing to learn from people they consider “new”, but some people have a hard time learning from anyone, for that matter. Always be aware that the first step in teaching is to teach in a way that the student can learn. That may be socratic, it may be by example, it may be by formal teaching methods. Also, it’s important to realize when you are just starting out that you are unlikely to have the full context for why a system or codebase got to where it is. Never trash code, even if others are doing this, because you just don’t know what constraints that code was written under. When I am new, I always couch my suggestions for improvement in terms of “This is what I think, based on my knowledge of the system. What do you [person who has been working on the system for longer] think?”

That said, here are valuable ways you can teach someone on your new team something.

  • Use your lack of experience to ask why things are a certain way. “I don’t understand” is a key phrase here. Questions like: why do you have only one server? Why are you using that language for data processing and this one for webdev? Why are we hosting git internally instead of using github? I always love when a new person starts at a company where I work because they are the antidote to the “fish in water” syndrome. Sometimes you live with systems for so long that you don’t remember why they evolved to where they are, and a new person can come in and cause you to re-think decisions. So by the simple act of asking questions, you are teaching others to re-evaluate the systems they may have become used to. Write down the answers.
  • Bring your new technology experience. “What do you think about trying XXX” is the key phrase for this tip. Chances are high that if you are a new developer you are trained up on new, popular technology, either through your schooling or through self study. (If not, this tip doesn’t apply.) New functional javascript frameworks, for example. Look to see where new technology or techniques may be helpful. Again, don’t proclaim “we should do it this way, this is how we did it at school”. That’s not helpful. But bringing your experience with newer ways of doing things is helpful. I met someone at a conference who worked with an old technology (Cold Fusion) but was introducing Test Driven Development for his own code, after discussing it with the team. This is a perfect example of someone bringing their own newer experience. The team may or not may be receptive, but that’s a different kind of problem.
  • Niche down. If you have the ability and the time, you can find areas of a codebase that are neglected and study them. You can ask other team members where poorly understood areas of the codebase are; the key phrase is “What parts of the code are scary?”. Try to really work through what is going on. (Bonus points if you write up tests.) Depending on the size and complexity of the code base, you may be able to in short order become an expert, or at least be ahead of anyone else. Then you can write up documentation to help other people understand this area.

Whenever you are new someplace it behooves you to be humble. You don’t know what you don’t know. But that doesn’t mean that you need to always be the student. Be delicate, ask questions, but realize you have something to teach as well as learn.

Sincerely,

Dan

What is HackerNews’ Best Advice to New Developers

Dear new developer,

I have previously written about joining an online tech community. My personal go to right now is Hacker News. I find it has a nice mix of tech, startup/business and other interesting content for me.

Here’s a thread from a few months ago with advice for junior developers. Here are a few of my favorite pieces of advice.

Lots more good stuff, including hundreds of other comments. Worth a read.

Sincerely,

Dan

Learn To Explain Concepts To Non-Technical Users

Dear new developer,

I taught technology courses for about a year and a half, but have been teaching folks almost my entire career in one way or another (everyone has something to teach), primarily through my blog.

One thing I’ve learned over time is that if you can’t explain a technology choice in a way that a non technical user can understand, you don’t understand it. It can be very easy to get caught up in jargon. Jargon in and of itself is not a bad thing. It’s a shortcut. If I say RDBMS to another developer, they know that this is a third party piece of software which provides safe, durable, transactional data storage. (See how jargon builds on itself? “transactional” is jargon as well.) But just like if you take one shortcut after another you’re likely to get lost, too much jargon can blind you. (Or at least put you in a fog.) AWS In Plain English is a great example of how the names of AWS services are confusing and could be improved.

So, learn how to think about technical topics in a non technical way. Then you can bundle it up in jargon later, when you have a clear understanding of it.

One great way to do this is to learn to explain things to non technical users. You can do this via writing (a blog), speaking (at a meetup), or just talking to someone in your life (parents, friends) about what you do for a living. Lots of people are mystified by software and are happy to learn more about it. You can start as small as you like (“what’s a directory?”). Go slowly and try to explain exactly what you do. An example for a site I worked on is “we pull information from a couple of different sources and publish it.” (I confess, I had to write slowly and rewrite that sentence because I used jargon.)

Other benefit of learning to do this is that as you continue your career as a developer, you’ll typically spend more and more time around non technical people. These folks make decisions that affect business and software, but they won’t always understand the latter. If you are well versed in explaining technical concepts, you’ll be valued and be able to be at the table when decisions are made.

So, if you can explain something non technical, you gain:

  • clarity for yourself
  • the ability to teach others
  • influence in your organization

What’s not to like?

Sincerely,

Dan

Writing Is An Undervalued Engineering Skill

Dear new developer,

This post discusses writing and how learning to write well can really level up your engineering experience. You can also view over 300 comments about this post on one of my favorite online communities, Hacker News.

The author has some suggestions on how to become better:

So how can you work on becoming better at writing? Writing clearly, concisely and in a way that is easy to read? As with every skill, it’s a matter of being aware of the fundamentals, practicing, getting feedback and repeating.

I haven’t read the books he suggests for the “fundamentals” (yet), but I agree that practicing, getting feedback and repeating are crucial. It’s why I think that a blog is such a great way to spend your time.

But I think it points to the larger issue, which is that writing well is a scalable way to communicate, and that communication is at important as writing code. If you writing the wrong code, you might as well not have written anything at all.

Worth reading the whole post: Undervalued Software Engineering Skills: Writing Well.

Sincerely,

Dan

Trade Money For Time

Dear new developer,

Don’t be penny wise, pound foolish. Your time is worth a lot, and it’s worthwhile to spend some money to accelerate toward your goals. I heard a client say once that their time was essentially free. I understood the sentiment, but the reality is that if you can be working on tasks that are higher value, it makes sense to spend the money.

Examples of ways to spend money that may not strike you as “worth it”.

  • Buying a book or video course instead of just reading the free docs. I remember one time for a consulting gig I needed to integrate with Stripe. I found a $30 technical ebook that I could read a few pages of and do the exact integration I needed (take money from a ruby on rails web application). The alternative would have been an hour or two reading the docs and figuring out how to do the same thing.
  • Buying and using tools. I use vim, but I know others who swear by IDEs like Jetbrains. Buying and learning these tools have saved them hours and hours of development and debugging time.
  • Opening a support ticket with a service provider. When I run into a strange situation, if I’m paying someone money, I open a support ticket. I had a colleague that had an issue with images getting corrupted across a number of places in an application. He spent a lot of time looking at our code, but eventually the issue turned out to be caused by the service provider.
  • Paying for commercial software. The alternative is to stringing together open source solutions. Now, open source is great and can often be a good value. But there are times when it just makes sense to pay for a solution. I often use the criteria “is this core to the business” or “what would happen if this paid service went away” to ward myself away from the idea that my time is free.
  • Paying for consulting or training. Sometimes a day with a consultant (even if it is expensive) can save you weeks or months. You gain the benefit of their mistakes and experience.

Now not all of these will apply to you, new developer. You may have no budget to spend at your place of work. But you can still apply this heuristic to your own choices. Get that subscription to Udemy or Safari. Buy that book. Explore that tool and see if you can recommend it.

Realize that your time is precious and you can leverage it through spending some money on tools.

Sincerely,

Dan

Mistakes Are Forgiven, Hiding Them Is Not

Dear new developer,

We all make mistakes. Yes, this is not news, but it’s worth repeating.

We all make mistakes.

I have made them, you have made them, your boss has made them, the person you are interviewing with for the job you really really want and need has made them.

The one thing about mistakes is: never never hide them.

Now, that doesn’t mean you should hang every mistake out on your blog or your LinkedIn profile. Just because we all should tell the truth doesn’t mean you should say every sentence you think.

But the people who need to know about your mistake should. Who needs to know depends on the scale and scope of your mistake. If in doubt about who needs to know in a professional setting, ask your mentor, your immediate supervisor or a trusted team mate.

Don’t take your time to do this. When you discover a mistake, you should immediately do the following:

  1. Confirm it is really a mistake. You don’t want to be the boy who cried wolf. So avoid making a mistake about a mistake. Take a look at the mistake from several different perspectives.
  2. Think of a plan for fixing the mistake. This may entail bringing in other team members, depending on the severity of the mistake. It may entail shutting some things down so a mistake doesn’t get worse. There may be an immediate plan to fix the emergency and a longer term plan to prevent the emergency from happening again (perhaps using an automated test).
  3. Think about who is affected and the scope of the impact.

Finally, tell who is affected about the issue and the plan to fix it. This may in itself require some planning.

It’s very uncomfortable. When I was at a startup and was writing billing software for clients, there were times when I made a mistake. I remember one time when I had to email or call each customer whose billing I had screwed up. It sucked. But they understood and appreciated the transparency and honesty.

What is the alternative? Hiding your mistakes and pretending they never happened? This means that you don’t get to learn from them. Your users or boss may discover the mistake on their own and bring it to your attention in a far more unpleasant manner.

Making mistakes is fine (though try to not to make the same mistake twice). Hiding them is not.

Sincerely,

Dan