Over the last year, I've trained a few people who have never written code before (one of which transitioned from a design to developer job), and worked with relatively new developers. Below are a few of the topics that have come up in that time.

Readable code is better than clever code.

If you won't be able to understand it 6 months from now, rethink it. Consider these two versions of the same function:

function a(b,c) {
    return a+b;
}

function sum(firstNumber, secondNumber) {
    return firstNumber + secondNumber;
}

By looking at the first function name and its argument list, it isn't 1) immediately obvious what the function does or 2) even hint at what it does. The second function makes it fairly obvious as to what it does without looking at the function's internals.

While this is an extremely simplistic example, you can imagine how this would apply to more complex code. This comic from Geek & Poke should drive the point home:

Less code is better.

The exception here is if it's contrary to the first tip above.

A higher line count of code is not the sign of a good job. The object of programming isn't to write a lot of code - it's to solve a problem, create something, etc. The less code you have to write, the better. Less code is usually easier to maintain and less complex.

Laziness can be an asset here. 🤓

Communication is required.

People aren't mind readers - you have to talk with your team. Need help? Ask. Have an idea? Share it. See an issue with the project? Speak up, no matter the size of the issue. A bug left unchecked can easily affect other areas of the code, and create bigger issues.

This is not unique to remote/distributed teams. I've worked with fully remote teams where the communication was great. We talked regularly throughout the day and got a lot of stuff done. Email, messenger, text, a phone call, Slack, Google Hangouts, etc. The form doesn't really matter (though some things are better suited to certain types of communication) so much as simply communicating.

I've also worked on completely local teams where communication was lacking. Inevitably, questions arose about who's doing what, what needs to be done, and what are our priorities. Lack of communication is one of the biggest hindrances to any team and its projects.

Communication is a must, regardless of how the team is structured.

Read other people's code.

This can be tough, especially when you're starting out. Don't give up though!

One of the benefits to reading other people's code is you get to see other styles and techniques. Code is as varied as people are. While there are good arguments for certain styles and techniques, there are equally good counter arguments.

In reading others' code, you'll discover a number of things that could help you write better code. Maybe a new design pattern, a new core function in your chosen language, or how part of an API is built. All of these (and more) can spark ideas of your own and help improve your own skills.

Ask for help!

When you get stuck and need help with a specific code problem, ask someone! Google is great for common problems, but when you're dealing with project specific tasks, you might need another pair of eyes or someone to talk through the issue. You'd be surprised how often that helps.

And for those career, industry, design, etc., questions - reach out to those offering to help or answer questions. Personally, I find a lot of joy in teaching people and answering their questions. I know a lot of other developers that do, too.

In my experience, the majority of developers are happy to help others. The community on dev.to is an excellent example of that.

One of my favorite Twitter threads was started by Stephanie Hurlburt.

The list of people that are willing to answer questions is amazing. Even more so is the variety of skill levels and backgrounds of those willing to help.

A lot of people want to help in whatever way they can - don't be afraid to ask!

What are some of your favorite tips for new devs?