Ask HN: Why do I exist as a sysadmin?

It's definitely the case that reading other people's code is much harder than reading your own. It's also the case that, if you write some code and let it sit around for a year, and then accidentally come across it, you're likely to wonder what kind of madman or idiot wrote it, until you realise that you're reading your own code.

It helps to keep your code so simple and peppered with comments than even an idiot (you) can understand it.

You don't learn to code by reading code, much like you don't learn to do math by reading equations, or carpentry by looking at houses. You have to get your hands dirty. Start with something "Hello World" level simple and add more bits as you go along. That's what we all do, really. The end result of such an iterative process will look inscrutable to others, but make perfect sense for you, because you made it.

Big dirty public secret: One guy's code being inscrutable to the next guy is why the next guy always argues for getting rid of the system that the previous guy developed. It's usually not because it's a bad system (your new system eventually becomes the next guy's "bad old" system, after all), but because no programmer thinks the same way.

Programming is very much a reflection of how a person thinks, of a mental model, and mental models are extremely individual things. Reading someone else's code is an exercise in empathy, and empathy isn't something programmers are known for. Programmers love to exist on their own little islands where everything works according to their internal logic. Teamwork means compromises. I once had to quit a job because I couldn't understand the internal logic of the team I had been hired to work with, as reflected in their codebase.

The main trait needed in a programmer is the ability to endure mind-bending levels of frustration. You have to keep hammering that nail until the problem is solved.

I have significant doubts on cost savings with either moving to the cloud or moving to an MSP. I've already commented a bit on the cost hike of moving to the cloud. I think there's a lot of benefits to MSPs (disclosure: I work for one) in terms of access to a larger resource base of IT professionals at the drop of a hat, but if you want a good MSP and a high quality of service, you are probably not saving money compared to hiring, since at the end of the day, you are still paying for the amount of employee time to solve the issues that crop up in your organization plus all of the management staff and profit margin of hiring an outside business.

> Has anyone had a similar experience and managed to push through the mental blocks associated with learning to program while having your own mind constantly working against you?

Yes, each of us.

I think you may be going about learning programming wrong. I've seen this several times (source: am DevOps/programmer) where my non-CS-degree sysadmin/IT coworkers will sort of "force it" when trying to learn programming. This includes things like reading technical docs way above their head, copy/pasting a lot from SO and not fully understanding things, and diving into complex code bases. It's a slog for the guys who do it this way, and I think its because there are some in-between steps that they skip over.

I usually suggest tutorials, but I get the impression from them that the tutorials they use are long, boring, and worst of all.. too easy. Then they dive into real-world work and get overwhelmed. I feel like this is akin to showing them how interlocking gears work for the first time and then asking them to fix my car.

What helped me was being in that setting where I would get small not-real-world problems to solve over and over. IOW homework, classwork, etc.. I think is what helped. Eventually I did enough small things that when I saw real-world code, I could pick it apart into pieces that I understood because I've actually programmed those pieces before. Having written it before was a huge help as well because I already had to be familiar with the concepts to get it to work... reading it was then a matter of comparing what they have to what I wrote in the past and incrementing my knowledge (rather than starting from zero understanding).

TL;DR I think there is a gap between beginner/intermediate tutorials and real-world coding. I think you may need to find yourself a path through this gap that involves solving a lot of practice problems and working your way up.

HTH and Good Luck

You know, I feel like the perfect person to answer this. I used to be a sysadmin, then a devops engineer, then a "VP of Infrastructure", and I'm currently doing some hands on work again as a "lead devops engineer".

Like you, I used to be frustrated at my inability to program, and I felt like I could never make sense of any of it. I spent years in my earlier career sticking to "sysadmin things" because of that limitation.

Eventually, as automation hit the industry, I started writing more and more ruby code (we were Puppet users) and eventually I took a full time job for a year writing ruby code.

It was never an inability, it was always a confidence thing. I was scared to try and fail. By taking a full time position as a developer I -had- to succeed, and I like to think I did. I found it's not nearly as hard as I imagined, and the fact I did not have sysadmin duties competing made a HUGE difference. I was able to dedicate all day to what I was doing, not fit it into the corners of my life.

From what you wrote above, it's pretty clear that your personality woes (anxiety probably is the big one here) is convincing you that you can't do this.

I wasted years convinced that it was "too hard", but in reality I just didn't have the motivation to push through my discomfort. I don't actually write a lot of code these days, but I'm no longer afraid to pick up some code and modify it if I need to because I know it's just a matter of being patient and figuring things out as I go.