🧠 I Code Differently Depending on These 5 Project Types

There are a lot of articles out there talking about best practices, patterns, principles, etc. When I say a lot, I really mean an overwhelming soul crushing amount of articles. But few of them talk about when these practices should be applied.

Even worse are the debates on social media about best practices and anti-patterns that are also without context.

It's the context that is missing and is so important in making these decisions.

Context is King! 👑

Do I Really Write Code Differently?

Absolutely. There's a quote somewhere that goes something like this:

"A Junior Developer knows not of design patterns. A Senior Developer knows when to apply design patterns. A Master Developer knows when not to apply those design patterns." -- Unknown Author

There isn't a single design pattern that has a rule that says it should be used in 100% of scenarios. But sometimes we treat them like they should be.

With all codes, patterns, practices, use your best judgment.

Project Types

There are a few ways I classify the projects that I work on. The project type usually determines how I design the software.

This is by no means an exhaustive list and may include overlap. Your list may be different.

Proof of Concept

A Proof of Concept (PoC) project's priority is development time. A PoC project should be created as fast as possible.

You may be tempted to write the code in a way that could be re-used if the project moves out of the PoC phase, but you would be sacrificing the main priority, which is speed of development.

Do you struggle with flex grid when you could bang out a <table> in 3 seconds? Okay, use a <table>.

Would setting up React take too long when you could do the same in jQuery in a minute? Okay, then use jQuery!

Redux vs a Global? Okay... you get it now.

Testing, Logging, Metrics, Monitoring, Performance, Scaling? Not in the PoC. Just make it work.

Whether it is successful or not, this code should be mostly discarded.

Personal (Pet Projects)

This is my favorite type of project because there are no rules. The project's priority is me! Do I want to go with a functional (FP) design? I'm gonna go for it. Do I want to learn a new technology? Hell ya!

This is usually where I explore. I find some new technology and I explore it as much as I can in my own personal pet projects.

I typically apply more care for readability (compared to a PoC) in my Personal projects because I tend to pick them up again after years and still want to be able to understand them.

I don't care too much about testing or design patterns. I'm usually just exploring here.

I also like to include a README.md to remind me how to start/debug/deploy the project. This has saved my ass more than once.

Open Source

The priority of an Open Source project should be readability. The audience of this project is people who will use the code as well as people who will read the code.

You will be judged by the quality of your source, so keep it tight, clean, and well documented.

The higher the code coverage the better on an Open Source project. Give contributors the confidence of seeing green tests to know they didn't break anything. Also give yourself confidence to merge requests.

It's good to have some design patterns and practices laid out in a CONTRIBUTORS.md. This will clear up how contributors should write code and give you something to point to when a merge request deviates from the standard.

Code should be crafted with consideration, care, and impact.

Libraries

Library code should focus on the developer experience.

The focus should be on creating documentation and example code. The projects I love all have great documentation.

I also spend a little extra time to focus on input validation and verbose Error messages. You don't know what values a developer is going to pass into your code. So a little extra attention at this step can go a long way.

The focus on input validation can be the difference between good errors and bad errors.

// ❌ Error: Cannot read property 'toString' of undefined
// ✅ Error: Options must include a 'url' property. more info: https://<url-to-docs>

I try to optimize the code since I do not know how or where the code will be used and don't want to be the bottleneck in someone's application.

I also consider supporting TypeScript types. It's nice when you type dot and the editor will IntelliSense complete your code.

Enterprise Applications

The main focus of an enterprise application is uptime and performance.

Extra time needs to be spent to catch bugs before reaching production. This means unit tests, integration tests, cicd, etc.

Logging, Metrics, Monitoring, and Alerting all become critical to identify and debug issues.

Care must be taken when handling API keys and other secrets which could be leaked from source code.

Deployments tend to be slower due to the coordination and QA involved. So it's nice to be able to change configuration values without redeploying the application.

There is a lot of care that goes into an enterprise application to make sure it's always up.

Summary

It can be overwhelming reading and navigating tech articles today. Take them all with a grain of salt and context. There are times to use them, there are also times to not.

There is no one size fits all. It all depends on the context.

Cheers 🍻

• Join my 📰 Newsletter
• Subscribe to my 📺 YouTube, JoelCodes
• Say hi to me on Twitter @joelnet

Photo by Markus Spiske on Unsplash