Advice for Beginner to Mid Level Developers

Authors
  • avatar
    Name
    Austin Howard
Updated on
shrug face

Here are some key pieces of advice for beginner to mid level developers from an active senior in the industry.

These tips are in no particular rank / order.

I will be adding to and modifying this list over time, I want this to be as useful as possible and go beyond things like “do these tutorials and then do leetcode” or whatever.

1. Build Things

I said these tips were in no order, but if they were - this would be #1.

If you take no other tips from this list, just let this be the one to focus on.

There are no simple shortcuts to becoming a better software developer.

You have to build things - consistently.

Start with something you’re interested in, it doesn’t have to be some new ground-breaking invention.

At first it can be really challenging to even know what to build. I can assure you for the rest of your development journey you will pick up projects, get bored, start something new, and repeat this many times.

But over time, as you build more and more things, you’ll actually make realizations about what is actually possible to build. Eventually you’ll get to the point where there are some many things you want to build but don’t have the time.

2. Read Chesterton’s Fence: A Lesson in Second Order Thinking (7 minutes)

Chesterton’s Fence: A Lesson in Second Order Thinking is a short read that I share with both new and experienced developers that I work with.

There are key lessons in Chesterton’s Fence that I wish I had been aware of before joining a development team and jumping into codebases of real products that had been around for years.

In short - the core lesson of Chesterton’s Fence in software terms is:

Before suggesting that a solution is bad or a change should be made to some system: first go and understand WHAT that system does, figure out WHY things in the system are the way they are, and if you can - get to know WHO came up with those solutions. Once you’ve done these things, THEN suggest changes.

This can mitigate knee-jerk reactions that developers commonly have when they jump into code that someone else wrote.

You might jump into a project and think, “wow this is spaghetti code and we should just refactor all of this or replace it completely - WHO COULD POSSIBLY UNDERSTAND THIS NON-READABLE nonsense”.

Sure, maybe the code and the implementations are actually in fact bad, which is fine.

But more than likely you think this because you didn’t write it and you weren’t around when it was written. You’re missing important context.

3. Seek Mentorship

Finding a mentor who has experience building real applications can be a 10x multiplier to your skills and career opportunities.

Experienced developers who are truly passionate about their craft are often excited about the prospect of bringing someone new into their world.

If there were some equation for calculating average time to get over the most common learning curves early on in development, finding a mentor would most likely decrease that average time.

If you’re looking for a mentor, first consider some of these sub-tips:

  • Often the best mentor-mentee relationships are those that manifest naturally
  • If you’re actively working on projects, showing prospective mentors the work you’ve been doing can lead to a natural relationship
  • Having more knowledge can help with confidence. Along with actually building projects (priority #1), is listening to podcasts, Youtube videos, etc as often as you can. There’s nothing like being able to hold a conversation with someone about interesting things.
  • People don’t want their time to be wasted. Showing someone that you’re willing to grind through problems, and that you’re dedicated to your side of the mentor-mentee relationship is the only way the relationship will last.

4. Embrace Failure

This is a big one. Fear of failure can be a paralyzing force especially in a first-time development job.

The harsh reality is this: the only way to build “good” software, is to build bad software long enough to learn what your definition of good is.

The earlier you can accept this reality, the sooner you’ll get over these fears.

The only real failure is not trying.

I’ll even put it this way - even if you were to make a REALLY catastrophic mistake that took down one of your company’s production applications - I’d consider that more of a success than being afraid and not trying at all.

Taking down prod is actually a big win, a lot of people never get that learning experience 😉.

As long as you never give up and you always give your best shot at the problems in front of you, you have not failed.

Always keep in mind this popular quote from Theo Roosevelt’s Man in the Arena speech:

The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows the great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.

5. Develop Your Own Opinions

Try not to only listen to the opinions of popular tech influencers. It’s really easy to latch onto the tech twitter hot takes of the week, but you should take all of that with a grain of salt.

What you really want to do is try building things yourself. Before checking the opinions of others or searching for a tutorial on how to do something - give it a shot yourself without any help.

By doing this, you’ll end up learning how to come up with your own unique solutions to problems. Afterwards, you can compare it to the solutions that others have come up with, and decide for yourself what is a good way to solve a problem.

Things like clean code and best practices are fairly subjective.

In general:

  • Try solving problems yourself without help
  • Develop your own unique opinion - thencompare that to others’ opinions
  • Come up with your own definitions of best practices and clean code

6. Don’t Be a One Trick Pony

Software development changes all the time. New languages, frameworks, database ORMs, cloud services, etc are popping up all of the time.

As much as possible you want to avoid becoming effective in only a few specific areas.

Here’s an example of a *one trick pony**- a frontend developer who is only comfortable with React.

That may be fine while React is popular, but what is going to happen when that’s no longer true, or this unlucky developer experiences a layoff at their company. Their options will be extremely limited.

Maybe this developer only enjoys working on user interfaces, and that’s fine. The suggestion would be, try learning Svelte, Vue, WASM, or work on getting a deeper fundamental understanding of how the web works.

Especially when you’re early in your career, try as many different things as you can - within reason of course.

Some things to try:

  • Built a web app with Next JS
  • Build a chat app with Nest JS
  • Build a mobile app with React Native and Expo
  • Build a REST API server with Golang
  • Build a CLI tool with Rust
  • Try some basic ML tasks with Pytorch
  • Trying building a server application in a language of your choice that does some batch computing tasks and schedule it with something like CRON (batch computing is common in many industries)

7. Don’t Take Computer Science Programs for Granted

This one is really for those who are currently or are considering pursuing a proper computer science or related degree at a university.

When you’re in a degree program, the stakes are low and it can be super easy to just kind of “go through the motions”.

Consider this a challenge to give your academic work your best shot.

Computer science programs will often take you from the absolute fundamental basics of computing all the way up to some of the actual interesting problems at the “cutting edge” of software and hardware.

Hot take 🌶️🔥: Most software development jobs are creating forms and lists for companies and interacting with REST apis. Most developers are doing 1 thing - translating business requirements into high level programming languages.

Remember this hot take and if you’re currently in a computer science program or you’re considering it in the future:

Take full advantage of the resources provided to you during your time in academia.

Some of the most interesting and fun problems you’ll encounter might be during that short time.

Popular Posts