Kevin Cameron

Many organizations I've worked in get bogged down in guaranteeing than things are not going to break, but at the same time have quite bad/fragile code. Small fixes to remove technical debt are often too expensive for engineers to try. These days I would recommend automating testing for check-ins and leverage the flexibility of git to sandbox and test changes. I.e. it should not be possible to check in something that breaks a release build, but you achieve that by layering and testing, not by arbitrary rules that stop check-ins.

This is really performance or time taken to compute. The complexity is likely to go up in order to bring the time taken down. I.e. simple list processing is usually O(n), but you usually want O(log(n)) when dealing with a large "n", so the complexity is increased by adding hashing or binary search. The actual O(rder) can be difficult to calculate, but you normally judge by where code is stuck in profiling, and then just try different techniques to make it go faster. I.e. start with the simple approach and go back and fix it later if it becomes a problem. I use bubble-sort a lot since it's easy to implement, and good enough for a lot of applications. I was told it took about a decade to get the Linux QuickSort bug-free.

Staying current just puts you in the same place as everyone else, to innovate you need to be ahead. Ask people to do things they don't have a background in, and there's some chance you'll get a better perspective, and head in a different direction. In AI, LLMs are all the rage, but spiking neural networks are probably where you want to be going, nothing in LLM research will help you with SNNs, although asking ChatGPT might, it suggests - https://arxiv.org/abs/1901.09948

As an innovative person, I'd say few of the organizations I worked for did anything to encourage it, the closest thing is asking people to file patents, but that's actually a pretty bad deal if you haven't nailed down your position in the company. I was recently recommended the book - "Zone to Win", which takes onboard that your production folks have to focus on delivery, and R&D guys can get a away with failing (according to the person that recommended it). This was most obvious at Altera, who badly botched a software release ~ 2000 and then refused to consider doing anything vaguely adventurous ever again. Innovation is not for the risk-averse or hubristic. Companies that take no risks, will fall to the ones that do (eventually).

I'm not sure the landscape changes that quickly, transistors got smaller, Unix became Linux, VMS became Windows, C evolved into C++ (with reluctant adoption). RTL is RTL, humans are still quite predictable. The skill needed is probably presenting change without it looking like change, nobody likes going back to school.

I'd say that, for a CTO, that's being aware that the product has to fit the market, customers will not make a lot of effort to come to you. I see a lot of good point-tool solutions, but a lack of good go-to-market strategy on the technical side. A couple of CEO/CTOs I've worked for have been very rigid, and refused to do (small) lateral moves to where there was money - a strict focus on developing the tech will get you into trouble.