Emerging from university as a bright-eyed young Junior Developer, I quickly realised that I had a heck of a lot to learn. I knew how to code, but I didn't know how to do it properly or how to work professionally as part of a team.

Over the years I have picked up these lessons that I wish I knew when I first started developing professionally, which I believe every developer should follow.

1. Write Clean Code

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

-- Martin Fowler

Clean code is one of the most important aspects of creating good software. An aptly named book is available, Clean Code, which covers most of the things you need to know.

Without proper consideration you will end up with smelly spaghetti code wrapped in a big ball of mud. Messy software is expensive and best avoided.

I recommend learning the SOLID principles. Although they were invented with OOP in mind, I do believe the general principles can be applied to any paradigm.

2. Be Pragmatic

Sometimes we get so wrapped up in the little details, that we forget to actually ship anything! I am guilty of this sometimes too, and I need to remind myself to focus on actually building the thing before I get into shaving microseconds off a minor endpoint.

Stay focused on the goal, be aware of the trade-offs you make, and ship that software!

Tip: Every day before starting work, try to focus for a few minutes on the overall goal; think about the various stakeholders in the project and what their needs are.

3. Be Consistent

Every team should have a set of standards they follow. Consistency in code, processes and environments allows for a predictable, easy time.

If you join an established project, follow that project's standards. If the standards aren't good, properly communicate that with the team, and hopefully you can set aside time to fix it together.

One of my pet peeves is inconsistent code formatting! Set up a formatter such as Prettier and make sure you format before you push to the repository.

Another common inconsistency is naming. When you're creating a variable / function / whatever, the name should instantly tell the reader what it is for.

const d = 2; // BAD
const elapsedTimeInDays = 2; // GOOD

4. Decouple Everything

Ok, maybe not everything. Decoupling code and layers is fundamental to software architecture. Monolith architectures can be effectively decoupled, but these systems can become very complex as they grow. Service Oriented Architecture and microservices were invented specifically for this purpose, in which each service is its own little world and does one thing really well.

Having a clean architecture is not so important for smaller systems, but is critical for larger systems. The SOLID principles can also be used for architecture. Check out Clean Architecture, which covers this in detail.

5. Measure Twice, Cut Once

My dad always says: "measure twice, cut once". Translated to software development I believe you could read it as this: "If you understand your client and users, you will make fewer mistakes".

This is the philosophy behind Agile. One of the main processes in Agile is to regularly communicate with all stakeholders in the project, which results in getting feedback quicker and more often, so you will be able to deliver solutions that everyone will be happy with.

Tip: Use an Agile framework. I really like Scrum because it really brings the team together! If you're working solo, I would recommend Kanban.

6. Avoid Tech Debt

Technical Debt is created when you choose an easy solution instead of a better solution that would take longer. Tech debt creates interest, making it harder to implement changes and bug fixes.

Sometimes, it is correct to create tech debt. There exists a trade-off between shipping quality software less frequently and creating tech debt to ship more often. You really need to be pragmatic about the situation you are in and make the correct decision.

7. Keep It Simple

Simplicity is the ultimate sophistication

-- Leonardo da Vinci

Most of the time, the simpler solution is better because complex solutions can lead to bugs, cognitive complexity and expensive invoices. Misuse of design patterns and time pressure are two of the biggest contributors to overly-complex solutions.

Sometimes, however, complex solutions are required. For example, a simple algorithm or architecture may not provide the performance you require; or a combination of design patterns are needed to simplify the overall architecture.

By following these simple rules; writing clean code, communicating effectively, and taking a pragmatic approach, we can deliver exceptional software for our clients and users.