Essentially, engineering is all about cooperation, collaboration, and empathy for both your colleagues and your customers. If someone told you that engineering was a field where you could get away with not dealing with people or feelings, then I’m very sorry to tell you that you have been lied to. Solitary work is something that only happens at the most junior levels, and even then it’s only possible because someone senior to you — most likely your manager — has been putting in long hours to build up the social structures in your group that let you focus on code.
So, about this Googler’s manifesto – Yonatan Zunger
The Second Law of Consulting: No matter how it looks at first, it’s always a people problem.
The secrets of consulting (1985) – Gerald Weinberg
Anyway writing software is hard, but unfortunately is the easier part.
Everything starts with a simple CRUD, you add the migration on the database, create the entity, insert a controller, a couple of views and everything seems fine. Then one feature after another the controller begins to grow, and begin to be more and more complicated and difficult to understand.
Rarely the software you are developing is just a CRUD, even if initially seems like this, every business domain has its own set of rules more or less complicated.
Then you realize that the framework architecture is not really perfect for your software, and you are right, because your architecture and your framework architecture are not the same thing, design your software is much more than deciding if some lines of code should be in a model or in a controller. You probably need classes to represent the concepts of your software domain, that are not pages, database tables and routes (that are the domain of your MVC framework), but maybe invoices, taxes, cost calculations or whatever your domain is about.
There are a few presentations that helped me to understand better how to put in practice these ideas: