Hello builders! I hope you all had a fantastic week. Mine was a bit more laid-back. I decided to turn off my "build mode" and dive into some reading. I picked up two books: one technical and one non-technical (though still focused on NFTs). In this post, I'll share some of the insights I gained from those readings.

Agile Software Development

I've been continuing my journey through "Agile Software Development: Principles, Patterns, and Practices." This week, I delved deeper into design principles and a few key patterns. For the purpose of this TWIL series, let’s quickly explore the SOLID principles and a crucial truth about software engineering.

SOLID Principles

The SOLID principles are a foundational set of guidelines in software development, comprising:

• Single-Responsibility Principle: A class should have only one reason to change.

• Open-Closed Principle: Software entities should be open for extension but closed for modification.

• Liskov Substitution Principle: Subtypes should be substitutable for their base types.

• Interface Segregation Principle: Clients should not be forced to depend on methods they do not use.

• Dependency Inversion Principle:

  • High-level modules should not depend on low-level modules. Both should depend on abstractions.

  • Abstractions should not depend on details. Details should depend on abstractions.

There’s plenty of resources available online to dive deeper into these principles, so you’ll have no trouble finding detailed explanations and examples.

However, my personal advice is not just to understand what these principles are, but also to know when to apply them. In real-world scenarios, you might need to balance these principles against each other or against other considerations. Being aware of the potential trade-offs and the alternatives available can make a big difference in your decision-making process.

Don't Blame the Requirements, Blame Your Code

Besides the SOLID principles, another key takeaway was the realization that software requirements rarely stay constant—they often evolve, and that's completely normal. This means that software needs to be designed with flexibility in mind, able to adapt to changing requirements.

While this might sound obvious, I had a handful of guilty moments reflecting on past experiences where I found myself frustrated with the rigidity of code structures I had written. At times, I even caught myself grumbling about the constantly changing requirements. Moving forward, I’m committed to keeping this truth top of mind and striving to write more maintainable, adaptable code.

The Everything Token

I finished reading "The Everything Token" by Steve Kaczynski and Scott Duke Kominers. It’s a solid resource for understanding the principles behind successful NFTs, with plenty of real-world examples. If you’re interested in exploring what NFTs can bring to the business table, this book is a good place to start. I'll be sharing a more detailed review in an upcoming post, so stay tuned!

Conclusion

That’s it for this week! I haven’t decided whether I’ll stay in “Read-For-Fun” mode or switch back to “build mode,” but either way, stay tuned for the next post of the TWIL series. Happy hacking! ☕️