Where I started?
Around the age of six, we got our first computer. The joy it brought me marked the beginning of my computer journey. I can’t remember the details on how or why we got our first computer, but I do remember one thing MS-DOS (Microsoft Disk Operating System), the command prompt operating system at the time. Most applications were installed, configured and run through this shell.
As a child, I felt the need to navigate the complex world of the command line interface, to be able run games like ‘Wacky Wheels’ or ‘Rise Of The Triad’. I often look back fondly on those days, cherishing the opportunity to navigate MS-DOS, occasionally break applications, and figure out how to fix them.
Without internet access, troubleshooting mistakes or errors was entirely up to me (we didn’t embrace the internet age in our household until we installed ADSL about ten years later). I learnt the ability from an early stage not to fear command line, and in essence not to fear the intricacies of technology.
Fast forward a few years, and I began my first career as a Network IT Administrator. I still feel this early experience prepared me to be a better technician and, eventually, a developer.
Future engineers won’t face the same early complexities and challenges, as technology has become much easier to use. While some students may have opportunities for computer classes, and there is a push in some schools to introduce coding to younger age groups, operating system user interfaces, game consoles, and handheld devices are becoming increasingly user-friendly and intuitive.
Additionally, Nvidia CEO Jensen Huang has predicted the end of coding, emphasising alternative career paths. This trend towards simplicity and ease of use highlights a move away from these foundational skills.
So, where will our technological troubleshooting and bravery be developed early on and how do we prepare our future engineers to not fear stepping out of their comfort zones?
The Transition I Saw in my Career
In my early professional years, the move away from the command line was promoted as a great benefit to user experience and productivity (aligned with the user desktop market); however, I felt it had affected our engineering experience and preparedness for modern practices like DevOps and Automation.
A moment during those years, I remembered being explicitly told installing Windows Server Core (No User Interface for Windows =O) was a bad move as it would affect productivity and the ability for other engineers to work on the system. Honestly, it may have been a bad idea, the automation ability may have been there; it was complex, and the practices were still not in place.
Though you still see it today, management (DCs, DHCP, File Servers, Print Servers, IIS servers) servers, cluster hosting servers (Running VMware and HyperV) are all still running the UI where Core would make sense, but why is this? I sense the motivation for our engineering staff and their comfort levels are still focused around User Interface.
Where are we Now?
DevOps, Site Reliability Engineering, and Automation are pushing a transition back to command line and flat file configuration practices. Tools like GitHub Actions, Infrastructure as Code, and Kubernetes are forcing engineers back to their ‘roots’.
A new fear of coding and commands is starting to peak. The more I see the need for these skills, the more I see engineers running in the other ‘manual’ direction. I can ‘hear’ the collective commentary of those reading this, “This has never been an issue, we use Linux, I have never even used a mouse! ”, but I keep running into this issue.
ClickOps is now the enemy of the state. To be a proficient engineer, understanding the commands around these new tools are needed, and having a good knowledge of Bash and PowerShell is now crucial.
So, how do we address these gaps in our teams and remove the fear?
Combating this Fear within your Organisation
‘Combat’ might be a strong word, it may be more appropriate to speak of collaboration and support, providing forums where teams can learn these skills whether it’s a veteran in the industry who hasn’t felt the need to write code or a new starter who hasn’t yet had the opportunity is crucial.
Organisations need to offer activities where everyone can learn and share their experiences:
- After Work Coding Classes, if automation and development teams can run after work coding classes, or if the organisation can squeeze in some time to run these classes during office hours, it would be so beneficial to start advancing those at least with the interest.
- A Theme of Automation, problem-solving is a natural theme in engineering, so why isn’t coding just another problem we need to solve and move on from? An organisation and their engineering teams need principles that promote automation first practices; more importantly, support these principles in everyday work. Automation first ensures ‘if it can be automated, it will be’.
- Hackfest Initiatives, while Hackfest is an ongoing initiative in many organisations generating innovation across the organisation, it’s a great way to promote good practices and, if you’re not doing it, why not? Building Hackfest teams with shared skills is an important aspect, ensuring that the knowledge is shared when they are working together.
Looking Back and Moving Forward
I’ve seen how technology has shifted from complex, hands-on interfaces to more user-friendly experiences. While these advancements make technology more accessible, they also remove the learning curves that once pushed young enthusiasts to develop crucial problem-solving skills.
Today, as automation and DevOps push us back towards command lines and coding, it’s clear that technical courage and curiosity are essential skills we must cultivate in future engineers. In our organisations, we need to make room for learning, experimentation, and support that empowers engineers to step out of their comfort zones and dive into technical challenges. Through initiatives like after-work coding classes, Hackfests, and a mindset that embraces automation, we can prepare the next generation of engineers to approach technology fearlessly.
Ultimately, where I started, with a simple MS-DOS prompt isn’t just a memory. It’s a reminder of how hands-on experiences build technical resilience and a call to reintroduce that foundational bravery into today’s engineering culture.
