The Road to True Expertise: More Than Just Tools

In modern programming, languages and tools have made it easier than ever to code. You can create a web project without spending four to six years buried in textbooks and lectures. I believe I could teach anyone the basics of web programming in just six short months. However, don't mistake a quick education for mastery. True expertise is earned through years of work, endless failures, and a constant thirst for knowledge. It takes years of practice, study, and engagement with the broader community to truly become an expert in our field. Have you ever tried to explain a difficult concept to an inexperienced developer? Described a solution to a complex problem? Lead group of developers? Documented your code in a way that empowers your colleagues to build on your work? Simply spending time in the industry or having a successful Youtube channel doesn't make you an expert. True expertise comes from deep knowledge and the ability to communicate effectively.

People who are intelligent and experts in their field, tend to question everything with an open mind and come up with logical reasoning. People who are inexperienced or lack knowledge often have strong opinions and beliefs and are not open to new ideas or ways of thinking. Approach problem-solving with an open mind, question assumptions, and follow the evidence. This is what leads to success in any field, not just intelligence or experience alone.

Don't Start Your Project by Picking a Framework

As software developers, we are constantly bombarded with new and exciting tools that promise to make our lives easier. While frameworks can be useful tools, they can also lead us down the path of technical debt if we're not careful. The problem with frameworks is that they come with a lot of assumptions about how your application should be structured and what features it should have.

Write code around the core of your business idea, also known as business logic, rather than around the tools. Let's say you're working on an e-commerce project. Your first concerns should be related to product pricing, inventory management, order processing, and shopping cart. You don't need to worry about user authentication, authorization, or email sending at this stage. By building your foundation around your business logic, you can choose whatever tool or framework you prefer for the infrastructure or UI layer concerns.

Another example is a social media application, where your focus should be on user profiles, messaging, and content moderation, without concerning yourself with error reporting or caching. Understanding this concept will help you see tools as replaceable parts of your project. It's important to keep in mind that framework creators tend to market their products as must-have tools, and their documentation and tutorials often emphasize using their specific tools for project creation. But with a solid understanding of business logic and the needs of your application, you can choose the right tools to support your project and bring it to life.

That's where abstraction comes in. Abstraction is the art of simplification - of breaking down complex systems into simpler, more manageable parts. By abstracting away the details of your application's implementation, you can create a more flexible, adaptable architecture that can evolve over time. When we build our application around a framework, we are essentially taking away this flexibility and building on a set of technical debts that we may not fully understand.

Rapid Application Development Doesn't Solve All Your Problems

Rapid application development is encouraged in some communities, such as the Laravel community. They show examples of small teams or solo developers making a lot of money. Tempting. However, this doesn't mean they are creating high-quality software. They usually sacrifice good architecture in order to start their business quickly. And, as they're solo developers, I completely understand. It is effective for them. The problem is that they promote this approach as the way to go! Being a good software architect is not the same thing. It's important to remember that simply knowing how to code does not qualify someone as an industry-leading expert. As I previously stated, anyone can learn the basics of web programming in as little as six months.

Some people may think that building an application based on business logic is slower than using specific tools. But, it's not always the case. Although it may take some extra time, to begin with, it makes it easier to maintain the code in the long run. Also, you don't need to hire a specialized developer who knows a specific tool, any good developer can understand and work with your code. This saves time and increases flexibility.

Another benefit of this approach is that the developer will better understand your business. This helps them to contribute better to the project and become a partner in your business's success. Although it may require a little extra work at the beginning, prioritizing business logic over specific tools can have many advantages in the long run.

In the initial stages of a software project, it's crucial to define the problem you're trying to solve and the objectives you aim to achieve with your solution. By asking these fundamental questions, you can shape your architecture effectively. To this end, it's essential to identify your use cases. A use case is a particular scenario or situation in which your software will be used. This technique helps to ensure that your software satisfies the unique needs of your users, thereby enabling you to create high-quality software that meets their expectations.

What's More?

As you are, I am also a learner. Every day, I'm eager to learn what the best approach is. Trying, not to have strong opinions and question everything objectively.

I am planning to create a series of articles with a lot of code examples. Additionally, I will provide a solid open-source project that you can explore to see how those examples fit into a real project. Let's stay connected!

Meanwhile, I suggest you read Screaming Architecture by Robert C. Martin (Uncle Bob).

Thank you for reading! If you enjoyed this article, let me know your opinions in the comments section! You can follow me on https://twitter.com/akmandev and https://www.linkedin.com/in/ozanakman. I'm trying to regularly share insights on software engineering that can help you improve your skills and stay up-to-date with the latest trends in the industry. I appreciate your support and hope to connect with you soon!