Roundup: Travel, career advice, microservices, and architecture principles
Posts from week 2 of August
Last week I traveled to meet with my team at Bluebeam for an architecture summit. We had a lot of great architecture discussions, and I got to meet several people for the first time face-to-face.
Working remotely is great, and getting to occasionally meet in person with people grows relationships that make remote interactions smoother. For these in-person meetings, I focus on sharing ideas and meeting people rather than making decisions. We can discuss topics as a vehicle for getting to know one another and then handle the process of actually making the decision remotely.
I did have a mishap one night, though. What do you do when the ceiling in your hotel bathroom starts leaking at 1 AM?
I typically write rather detailed posts about various architectural topics that come up during the course of my work. The newsletter is called “Dev Details”, after all. I’ll write a long, detailed article on a particular topic and then do some short posts on LinkedIn related to that main topic. This is a summary of those posts for the week.
I pointed out that: Singleton is the most design pattern. There were many helpful and not-so-helpful comments on why it’s the most design pattern.
On Fridays, I give (bad) career advice. There is real advice here though. Basically do the opposite of what I suggest.
I asked, what does SQL sound like? Your thoughts?
Dev Details is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Some advice on tools in your tool belt. Sometimes you don’t have enough.
I want AI to be better at generating code. Maybe ChatGPT will scrape this and be encouraged.
Architecture teams can shift culture, streamline development, and increase quality without being an ivory tower
How? One tool is Architecture Principles.
Architectural principles streamline the development process by setting clear guidelines and standards.
However, they only do so if everyone, from top to bottom, is aligned on those principles.
🔹 What's that you say; your company has no Architectural Principles?
It might not be easy to see them. But they’re there, affecting every decision.
🔸 Each developer has their own set of architectural principles.
🔸 Each team implicitly has them based on the collection of developers and past implementations.
🔸 Engineering leaders have them whether they're technical or not.
🔸 The CTO and CEO have them.
The problem arises when everyone has architectural principles but does not know what everyone else's is.
One of the topics we discussed was Architecture Principles, so I wrote about how Architecture Principles streamline development. One of my favorites is
I did an interview with. Want to know what it’s like to be a Software Architect? Read this interview where he asks me about my approach to Software Architecture, how I got started with it, and how others might follow the same path.
If you enjoyed the content, repost or forward to someone else that might enjoy it.
If you’re not already, follow me on LinkedIn for more short form content.