Leadership, Logic and the Occasional Kirk Moment

After writing my earlier entry on the influence of Star Trek on my thinking, I wanted to do a deeper dive into some of those aspects.

I've mentioned that over the years, Star Trek has probably influenced my thinking about leadership at least as much as many of the more conventional sources. Hopefully by now this doesn't sound odd (ok, maybe a bit), until you remember what the show was about: on the surface it was a science fiction adventure series, but underneath that, it was really a show about decision making under uncertainty. Every episode placed the crew in some unfamiliar situation: a new civilisation, a technological mystery, a diplomatic dilemma, or occasionally an alien entity with worrying godlike powers.

The interesting part was rarely the special effects, even though they were good for the era (yes, I'm looking at you Dr. Who!) It was how the characters approached the problem: the Kirk triangle. I think the most enduring element of the show is the dynamic between Kirk, Spock and McCoy. Spock represents logic and analytical reasoning, McCoy represents empathy and human intuition and Kirk sits somewhere in the middle, synthesising the two.

In modern management language we might call this balancing data-driven analysis with human context. In the show it usually involved Kirk listening to two very strong and very different perspectives before making a decision. It’s a simple model, but a surprisingly effective one: teams, not heroes!

Another thing the series gets right is something that’s occasionally forgotten in discussions of leadership: the captain doesn’t solve the problems alone. The Enterprise works because it’s a team. Kirk’s role is not to out-perform the team members in their own domains, it's to listen, integrate the information and decide on a course of action. That maps rather neatly onto the reality of running engineering organisations.

If you’ve hired capable people and ideally people who are smarter than you in their respective areas, your job isn’t to micromanage their work, it's to create an environment where their expertise can inform the decisions that matter. Large engineering projects tend to operate under similar constraints. Requirements evolve, environments change and occasionally something fails in a way no one anticipated. In those moments, leadership becomes less about having the right answer immediately and more about assembling the best available understanding and moving forward.

Kirk’s approach often involved a mixture of curiosity, consultation and occasionally a willingness to take calculated risks. It turns out that those characteristics translate reasonably well outside of television.

One other aspect of the series has stayed with me over the years. Despite all the futuristic technology, the show never pretends that technology alone solves the problem. The real decisions are always human ones. How do we treat this civilisation? What risks are acceptable? What values guide our choices?

Engineering organisations face their own versions of those questions: prioritising features, balancing delivery timelines with quality, deciding how to respond when something goes wrong. The technology matters, but the human judgement matters more.

It’s important to say that I don’t consciously think “What would Kirk do?” every time a difficult decision appears (ok, maybe sometimes!) But the underlying ideas from Star Trek have a habit of resurfacing: listen to your experts; balance logic with empathy; accept that uncertainty is unavoidable; trust the team you’ve built. And occasionally remember that even the captain of the Enterprise needed a good crew around him.

Not a bad leadership framework for a television show from the 1960s.

Java is dead again?

Every so often the technology press discovers that Java is about to die. This is not a new phenomenon and I've tried to address it in the past. If you’ve been around long enough, you begin to notice that Java appears to die on a fairly regular schedule, usually coinciding with the rise of whatever new language has captured the industry’s attention that year. Recently those candidates have often been Rust and Python. Both are excellent languages with strong ecosystems and very real strengths. They also happen to be fashionable, which inevitably leads to a certain amount of enthusiastic commentary about what they might replace.

The difficulty with these narratives is not that they’re entirely wrong, it’s that they tend to assume a level of universality that rarely exists in practice. Which brings me to another passion of mine: physics.

If you've done any physics classes or have even a general interest in it, you've probably come across Sir Isaac Newton’s formulation of classical mechanics. Newtonian physics gives us a set of equations that describe how objects move and interact at everyday scales. Whether it's cars, bridges, rockets or cricket balls, Newton does a remarkably good job of modelling them. However, as you delver further into physics classes or books, you'll learn that Newton’s model isn’t the whole story: at very small scales, the behaviour of particles is better described by Quantum Mechanics, while at extremely high speeds and large gravitational fields we need General Relativity.

However, this discovery doesn’t lead physicists to declare Newton obsolete. Instead, they do something rather more practical: they use the model that works best for the problem they’re trying to solve: if you’re designing a bridge, you probably don’t need a quantum mechanical treatment of the steel atoms!

OK so how is this relevant to Java? Well programming languages are tools and tools tend to be well suited to particular types of problems. None are universally optimal. For example, Python is widely appreciated for its rapid development cycle, readability and strong ecosystem in data science and machine learning. Rust brings impressive guarantees around memory safety and control over low-level system behaviour. Java, despite its periodic obituaries, continues to offer a mature ecosystem, portability and a runtime environment that has been tuned for large-scale enterprise systems for decades.

None of these attributes automatically invalidate the others. The reality is that modern systems frequently involve multiple languages and platforms. A machine-learning pipeline might be written largely in Python, a performance-sensitive component in Rust and the surrounding business services in Java. (Note, I'm not trying to suggest that high performance and Java are mutually exclusive, because they're not; this is an example.)

That arrangement isn’t a failure of architectural purity. It’s simply the result of using different tools where they make sense.

One of the more interesting transitions in a developer’s career is the moment when the question shifts from: “What’s the best technology?” to something slightly more nuanced: “What’s the best technology for this problem?” Architects tend to accumulate tools over time, languages, frameworks, design patterns and operational practices. The goal isn’t to become ideologically attached to any one of them, but to understand their capabilities and limitations.

A hammer is excellent for driving nails. It’s less effective when asked to tighten a screw. Programming languages behave in roughly the same way and this is where experience becomes important. Every technology carries trade-offs:

• performance characteristics.
• operational complexity.
• ecosystem maturity.
• developer productivity.
• long-term maintainability.

Ignoring those trade-offs usually leads to disappointing outcomes, whereas understanding them allows developers to design systems that deliver what customers actually need rather than what happens to be fashionable at the moment.

If you look beyond headlines about the “death” of particular languages, the industry tends to behave in a far more pragmatic way. Successful systems are rarely built around a single universal tool. Instead they evolve into ecosystems of components, each selected because it solves a particular problem well and in that sense, software engineering looks a lot like physics: Newton still has his place and quantum mechanics has its own domain. Both are useful, provided you remember which problem you’re trying to solve.

And if Java continues to die every few years while quietly running a large portion of the world’s infrastructure in the meantime, that may simply be another example of the same principle.