Avoid Being an "Ivory Tower" Architect

January 30, 2023

#124 – January 30, 2023

In a recently published episode of Armchair Architects, the speakers discussed the relationship between software architects and the rest of the organisation. They detail how a successful architect can impact others by switching between going into the trenches and zooming into a tree and then being able to zoom out and estimate if that tree still fits into the forest.

Least privilege in the cloud is hard, but progress is achievable if you take a risk-based approach. Consider an attacker who obtained one of your developer’s credentials; what access would they have? By adding a temporal dimension to developer access policies, the attack surface can be significantly reduced for many security-breach scenarios. That’s where just-in-time access comes in.

How to write great software for very happy business owners without telling them how long it will take you to do just about anything.

Whenever an executive joins a new company, there is an awkward merger between the executive’s preferred communication style and the norms that organization has already established.

There are many genres of leadership theories. One of those is authentic leadership. Regardless of how leadership psychology researchers define it, the most common view of authentic leadership is leading while being true to oneself and acting according to one’s feelings, emotions, and values.

No more flakes and no more test maintenance. QA Wolf investigates every failure and sends only human-verified bug reports. Chat with QA Wolf about a risk-free pilot and reaching 80% automated test coverage in 4 months.

Leverage is a powerful tool that applies to many things, including the code we write. However, tech debt like all leverage, comes with interest payments. How do we know when to start spending bandwidth on addressing it? We'll look at a framework that can help us ensure we don't reach a point of insolvency with our codebase.

Back in 2018, when I first wrote about sizing engineering teams, I was surprised how much my advice rankled a colleague. He wanted to spin up a new engineering team of two people, which I thought was a bad idea. It would be a fragile team that would fall apart quickly if it didn’t grow. It would be missing the components we’d seen make other teams successful, like an engaged manager or ability to handle on-call if someone took a vacation.

newsletters