The Deception of Learning to Code
It's not always the same in the real world
For those who know how to code, I invite you to think back to the very first coding you ever did. If your path was anything like mine, you were printing variables and prompting for user input. Your first months likely had you calculating tips, reversing strings, and recreating a simple game like tic-tac-toe. Should you continue studying computer science through college, you’ll actually find quite a number of similar experiences. Though the latter challenges are more difficult, in both instances, you typically find well-defined problems, known answers, and an emphasis on the learner to engineer their own solution. These problems can be fun to tackle as well, and the dopamine rush from solving them is what brings many to pursue software as a career.
But those who are well-initiated know that real-world engineering does not consist of simply solving tougher and tougher algorithmic challenges. Instead, the problems you face begin to expand orthogonally as you reconcile the realities of working in a larger system. In your first engineering role, your day-to-day challenges might involve discovering which version of a dependency broke your build or helping customers who can’t figure out why your software won’t work on their system. Engineering new features might look more like connecting already-written components rather than pioneering your own ideas onto a blank canvas. And you might find you spend more time in meetings talking about what to build rather than doing the building itself.
This isn’t a worse situation per se; many engineers will take the step from education to career and fully relish the experience. Indeed the notion of a job being dissimilar from the training is not new and many with the “engineering mindset” will find they simply enjoy solving problems of any variety. However, I’ve read a number of posts recently with engineers frustrated at the nature of their roles, some to the point of leaving their jobs for greener pastures. There have been increasing enrollments in both coding bootcamps and computer science programs in the US, many tantalized by the promise of a high-paying salary to seemingly do what they may already be doing for fun. So it feels more relevant than ever to broadcast this seldom-discussed difference between learning and industry.
So what should be done? My advice to people starting their computer science journey is to get involved as early as possible with activities that are closer proxies to real-world engineering. Internships, project-based clubs, and contributing to open source all give the true experience of working in an existing codebase with other people. These are also generally solid ways to improve your knowledge and also act as great items on a resume. And if what you find is that you do enjoy real-world engineering, congratulations! Enjoy a lifetime of a career you love. And if not, I don’t think this means you have to give up your enjoyment of coding. There are a few paths that can allow you to code without becoming a software engineer.
The first alternate route is to become an academic. In going through postgraduate studies and eventually becoming a professor, you’ll get to ask your own questions about a bleeding-edge area of your choice and devote as much time as you’d like to answer them. The coding experiences I’ve had in academia were all individualized and with a larger emphasis being placed on discovery rather than marketability. Another path is to do something tangential to engineering. There are a number of careers where having coding knowledge is beneficial but not a necessity. In these roles, you might be able to build a tool or script to optimize your workflow rather than having engineering be 100% of your job.
And lastly, if none of this suits you, you can always retain coding as a hobby. Just like a painter or baker, I personally hope that no matter what happens me I can continue to code until my fingers are no longer able to type the keys. Ultimately the most important thing is recognizing what you enjoy and not getting trapped into a role you don’t.
Author’s Note: Thank you for reading this article! If you like what I’ve written, please consider subscribing to my Substack. Doing so will get my ideas directly to your inbox and helps support me as a writer.