Bitnoise CTO and co-founder on his views on engineering, developers and the future of tech.
For me, being a CTO means trusting and delegating technology decision-making to the teams. It took me years to understand that leading a software development company means trusting the judgement of others, rather than micromanaging. Today I have the confidence that the choices of people I work with are often better than mine.
Having said that, I still have strong views about how technology should work and how it should serve people and businesses.
I strongly believe that finding the right equilibrium between a conservative, reasonable approach to technology and innovation is a must. While it is often the safest bet to use well-known, established technologies, a certain amount of novelty makes us happy and intrigued. Moreover it helps make the products of our clients competitive.
The vast majority of common functionalities and features can be created with all popular programming languages, frameworks or libraries. That’s why the choice of technology is not the single most important decision in the product life cycle. For the overall success of the project more important are coding quality, stability and orderly development process.
Standardisation is very important to me. Each project should be normalised in terms of coding and commenting practices and documentation to reduce ambiguity. Moreover, I think the code should be self-explanatory - any experienced software engineer should understand it without asking too many questions. This assures that any new developers joining the team need less time to take over.
Learning new skills is essential for the vast majority of people. In the workplace, this can be achieved by various means. While training, conferences and online courses have great merits, over the years I’ve realised that real progress comes from real challenges. As humans, we learn only in real life situations, not simulated environments. With this in mind I support learning opportunities in real, commercial projects. Whether it’s a small R&D project, a new library or tool I encourage team members to experiment and not be afraid to take a step back.
Will software development be fully automated in the future? That’s the fear of some engineers. I agree with this only to some extent. Many repetitive, mundane tasks will surely be automated or standardised. This means that engineers will have more time for real problem solving, analysis and decision making. Which overall is and will be a massive improvement.