Ultimately, you must know your project, your needs, yourself, your skills, and your team. Only you are responsible for your project. So trust your instincts, fellow architect, and don't Shakespearize 🙂
The nature of our jobs as software engineers is such that we must deal with externalities. Hardware will crash. Services will auto-scale up and down. Garbage collection will occur. Humans will make mistakes and use our software in ways we did not anticipate. Someone will write configuration instructions for you on how to setup your dev environment, and they might not apply perfectly to your setup.
Monorepo makes sense under some circumstances and makes no sense under others. A set of related features with related code, similar security, performance, and scalability profiles belong in a single deployable service. Services that are functionally related and have a closely aligned release cycle belong to the same monorepo.
Though Java was my primary way of earning a living from about 1997 to 2015, it has long outlived the problems it solved. Java’s issues are being solved now by modern tools like Docker. Except for a few niche use cases, I no longer use Java for my projects.
There is no such thing as one grand unified full-stack programming language or a full-stack developer using a single tool. As a SaaS software architect, I certainly do not see some holy grail from my vantage point. We need to use tools that best meet the needs of the task -- and the needs and the skills of developers who use them.
The only way I could wrap my head around this code was by printing it out, taping printed sheets together, spreading it on the floor, and crawling over it using a highlighter to annotate blocks of code.
Developers should feel empowered to configure their environment and development tools to their liking and contribute to the shared team standard. They should know the libraries they picked and why they picked them. They should be able to articulate why they like one programming language over another. As part of their job, each developer should be able to state clearly and in actionable terms how they’d like to work.
My pet UX peeves described above all seem to fall under the same category: each app thinks it is the only app running on my phone, and it is the only app I am using. It boils down to the developers’ respect for my time.
Telecommuting in and of itself isn't the end — it is the means to a more flexible work arrangement. In a sign of changing attitudes in the enterprise world, Gizmodo is reporting that Salesforce would "allow its employees more freedom in choosing how to structure their work lives going forward."
For many years I couldn’t understand what software architects do. Early in my career, I thought they were useless. As a young developer, I felt that I could do the job of a business analyst, software architect, and developer all at the same time. Now, seventeen years into my post-college career I am one myself. I am trying to learn what it means to be a good software architect, and I hope to be one myself.