after 12th i did not go where most people around me went. i spent two years on a hardware and networking course at the institute of advance network technology.
switches. routers. subnetting on paper. crimping cables that did not work, then crimping them again. windows server. dns as a thing you configure on a machine you can physically touch, not a thing that appears in a dashboard.
by any career logic this was the wrong choice. the money then was in web development, and everybody knew it.
why it turned out fine
because i hit the cloud from underneath instead of from above.
most people learn aws top down. you learn ec2 as “a server you rent”, and then a vpc is a mysterious thing you must configure before the server works, and subnets are a form you fill in, and the route table is the thing you google when nothing can reach the internet.
i learned it in the other direction. a vpc is a network. a subnet is a subnet. a route table is a route table. a security group is a firewall rule with better ui. nat is nat. none of it was a new concept. it was the same set of ideas from the course, running on hardware i could not see, with a bill attached to it.
that is genuinely most of what devops is once you strip the branding off. the tooling changes every three years. the layer underneath has not changed in decades.
where the gap actually was
i do not want to make this sound like the course prepared me. it did not.
what i had no idea about, walking out of it:
that everything would be code. i knew how to configure a network. i did not know that configuring it by hand was the failure. terraform was the correction, and learning that your job is to describe infrastructure rather than build it is a bigger shift than any specific tool.
that reversibility matters more than correctness. the hardware mindset is get it right, because redoing it means physically going back. the cloud mindset is make it disposable, because you will destroy and recreate this stack fifty times.
that everything is billed by the second. an idle server in a cupboard is free. an idle server in a region is a monthly invoice, and the professional skill is noticing.
anything about software engineering at all. i learned that on client work, badly, in public, for the first two years.
the point
there is a version of this story where the unusual path is the lesson. i do not think it is.
the lesson is narrower: whatever you learn first becomes the layer you reason from, and it is worth learning something underneath before you learn something on top of it. people who start at the framework spend years working out what the framework is standing on. i started at the wire, so i never had that particular confusion, and i had a hundred others instead.
i started taking freelance devops work mid course. the first jobs were fixing deployments and replacing certificates. small, unglamorous, and every one of them made more sense to me than it should have, because i had spent the previous year on the boring layer.