Reflections on Programming

There are four general types of people who become programmers: There are those who enter the fray by their inherent tendency to tinker, who tinker so much that they suddenly realize they are qualified for jobs. Then there are the money chasers who hear that “coding pays well” and who either put themselves through a Computer Science degree or a programming boot camp so they can “rake in the dough”. One of the most common types is those who simply find programming interesting and choose it as their college major and naturally find themselves programming professionally thereafter. But then there are those who wake up in programming one day and wonder what the hell happened. How did I get here? Who am I?

I would consider myself in the fourth category. Although I’m not in the mood to recount the story in detail, I always want to credit God for how it all fell together. I’m sure people who don’t believe in God think I’m crazy for saying this, but my route into programming has to be the absolute least-straightforward story of entering the industry that I’ve ever heard. There’s really nothing about the path I’ve taken that I would recommend to anybody else, in large part because I’m not sure how you replicate it, and also because it is not the most intelligent route to follow, assuming you have control over that sort of thing.

Every year or two I come across somebody who wants to “get into coding” because of the money. They’ve done their research and they know what the salaries out there are. They want to know how hard it is to get into. It’s always an awkward conversation because it’s painful talking to somebody who is only thinking about the money. I want to say, “Yeah, sure, you can become a programmer. But it comes at the PRICE OF YOUR SOUL!!!”

In “The Wealth of Nations”, Adam Smith even speculated that the apparent differences in wages was an illusion created by the effort required to enter and remain in a given occupation. That while one occupation may pay much more than another, it comes at the price of skill, which is really just the price of time. So yeah, doctors earn a lot, but only after spending a ridiculous number of years making hardly anything as they build their skills. Ditto lawyers. Now, I don’t remember everything in that section of the book (it’s a huge book), but I do know supply and demand also play a role in this, and the failure to realize the power of supply and demand is the primary reason under-employment is so huge today. It’s a misnomer, by the way: there’s no such thing as under-employment, there are simply those with skills that people want to hire and those with skills people do not want to hire. I’m not trying to be a dick, I think there is a role for studying all sorts of things, but if you think you should have a job just because you have a degree, it means that at some point you failed to realize the relative worth of your skills to an employer. Who to blame is unique to every situation, but usually it’s an amalgam of factors, and don’t I know it: I spent far too many months unemployed after graduation.

Software, these days, is one of the top fields in existence, with high demand and a rather instant shot at a middle class life. Sadly, what’s frequently overlooked is the fact that if you want to become a programmer, you’re going to be studying it for a loooooong time. Occasionally, some developers are placed at great jobs where the technologies are nice and modern and their skills naturally build as they go along. But most jobs are not going to teach you everything along the way. My first software job got me into the industry, but it really did nothing to help me become a good programmer, largely because so little programming was actually involved. I spent those years feeling like a fraud. Sure, I knew how to build webpages manually, I’d done some fun database stuff with SQL at my internship (at my own direction), and I’d learned enough Python to understand how programming generally worked, but I was bitterly disappointed when my daily work involved dragging and dropping boxes on a screen. And they wanted me to have passion for that! But I’ll talk about that later.

One of the hardest parts about programming, for me, is feeling like there is always so much more to learn. It can overwhelm you if you let it, and that’s partly why I sometimes feel very angry at programming: you have all these “industry experts” preaching that every developer should know X or Y or Z and you’re a shitty developer if you don’t. Really the message is that you’re a shitty developer if you don’t know as much as they do.

In short, the software industry is full of prima-donnas and wannabe-prima-donnas. But I guess you can say that of most industries. Except maybe logistics because who cares.

When I find something to study, either because it’s very practical or very interesting, I tend to get this Rocky mentality of needing to tackle it head-on, go all-in, push myself really hard to master it. I believe in doing things well, in improving, and in learning, but I’m also interested in many different things, and I tend to have more respect for the jacks-of-all-trades than the extreme specialists. So this Rocky mentality has burned me more times than I can recount. I suspect I’m also a very impatient person, and that may have something to do with it. You simply don’t “learn software extremely fast”. There’s a lot to digest, and your knowledge has to constantly be reintegrated. Maybe you know Javascript really well, and T-SQL really well, but at some point you’re going to have a Javascript function calling a C# API method, which calls a C# service, which calls a T-SQL stored procedure, and you have following existing conventions, which are completely undocumented. An experienced developer can make it happen. The copy of “Eloquent Javascript” that you read through in three weeks is not going to help you.

And I think that’s the part about software that I really enjoy. I have always been a “big picture” person, and software is very much a “big picture” field.

Some people are great coders. They know the programming language inside and out, or they know the Linux command line inside and out. They are very clever programmers, very logical, and very technical. I am not one of them.

I once had a report to generate using a PL/SQL procedure, but a previous developer had already done most of the work for it. I nearly went permanently cross-eyes trying to understand what the hell he had written. All these complex data structures, complex language features. I was genuinely impressed. How could somebody have learned so much in so short a period of time? But as I began to ask myself what REALLY needed to happen in the procedure, I came to realize that most of this highly technical code was fluff. It was completely unnecessary. It seemed written by somebody who was too busy asking whether he could to ask weather he should. I rewrote the procedure with about 1/3 of the code and it worked. And that was the first time I suspected that I might actually be able to grow into a good developer. It was almost like my lack of technical acumen might give me an advantage: being a less technically capable person is likely to produce code that can be easily understood by anybody else and is more likely to stay simple instead of becoming bloated and incoherent to others. How much I have succeeded at this I don’t completely know, but I do believe I have a knack for simplifying code.

If there is any role in programming that I’d like to grow into, it is that of Software Architect. At the farther ends of the software experience spectrum, your standard developers will often transition into a few different roles:

  • software manager – non-technical managers of technical teams often suck, so the ranks of technology management are usually composed of former developers. This is usually great for people who enjoy leadership or are otherwise tired of programming and the existential treadmill of keeping up with new technologies. Your old coding experience will still always be helpful
  • software consultant – when you don’t want to become a manager and you have a taste for job independence, you might choose to become a specialized consultant. Just make sure you have insurance and know how to fill out a 1099
  • software architect – one of the most critical roles in any software company is the architect(s). A poorly constructed software product can bankrupt a company in a few short months. The architects guide the structure of the product and determine the course of its future. It helps to have years of experience seeing what does and does not work. Your decisions are important and will often be very difficult to change, so you’d better be sure you are making good decisions

The appeal of being a Software Architect comes from the fact that, in a small way, I’ve actually had to do software architecture before. The open source project I’m building for some people in Nepal was not something I had any guidance on. I had to design the database, design the application, design the layout, and make all sorts of critical decisions in-between, such as logging, authentication/authorization, deployment strategy, etc. Those first few years where I learned things I had never worked with before were brutal, scary, and intimidating. And yet, this little program is very close to actually being released now. I can’t believe it! But this is the sort of thing I want to do to help others: to build programs from scratch to help the people who are taking huge risks to make the world a better place. If I can improve as a software architect, then I can help these people more by building robust systems that can easily be updated and modified by other developers. The companies could even hire somebody else to make those changes! But only a good architect can pull that off. So that’s why I want to be one.

Sure. When I get to the end of my life, I’m not going to care that I wrote a lot of code. But I will care about the people I may have helped simply by turning up and writing code in the first place. That’s kind of what’s driving me now. But I’d better not try to go ‘Rocky’ on this, because that will just burn me out and piss me off. I think for years I’ve needed a more nuanced vision that isn’t in such a damn hurry to do everything at once. This is genuinely hard for me.

What scares me sometimes is that you could spend your whole life doing something and still have more to learn. But I think it’s wrong to feel like you’re not good at something just because you haven’t attained “perfect knowledge” of it. Most software architects have 20 years of experience in the industry. I have nowhere near that amount of experience! But does that mean the system I’m building for these people isn’t good, simply because I “don’t have that much experience”? No. It certainly needs some improvements, but the feedback has been very positive so far. It’s important to be humble, but your lack of experience does not prevent you from making a difference or even simply being good at what you do.

So this is all fine, but it’s definitely skewed toward what I want to do, and not quite as much to what I’m doing.

A lot of my bitterness toward the industry comes from the state of modern software jobs. My first job had me fill out all sorts of goals for the coming year, going so far as to break things down into quarterly, and at one point even monthly goals. What are we, in elementary school? You want me to write a class mission statement, too? If I could go back in time, I would tell myself that every single one of those goals should be focused on getting my next job. There were good things about that place, and there were bad things. But they wanted you to be a great developer, so long as you didn’t do any real development. I wanted to do advanced programming, I wanted to learn all sorts of things, but none of them were very relevant to what we did there. Which should have been my cue: prepare for your next job.

A long time ago, some jackass probably wrote a paper, or one of those cheesy business self-help books, detailing how setting goals improves productivity, and the HR folks got their hands on it, and now our whole world revolves around goal-setting, not for you per se, but for the productivity of the company. Any company that expects you to have passion for your job is likely going to underpay you. Tell me if you experience otherwise, but people doing work they are passionate about are usually more willing to be paid less.

I dream of the day I would be so qualified for other jobs that if someone so much as asked me in an interview what my goals are for the next five years, I would just stand up and walk out. I’m kind of joking, but kind of not.

Ditto performance reviews. “What did you achieve in the past 3 months?” I did my job, which is exactly what you paid me to do. Are we done, now?

This frustration is what has lead me to think of myself as a sell-out. I’m just not interested in all the bullshittery that goes into modern “careers”. And the bullshittery is very strong in programming.

I almost escaped the goal-setting. I was so close, but the ball finally dropped, and it looks like even my current job will require me to lay out goals for the next year. FML. “Where do you see yourself in the next year?” One year closer to never needing to tell another person where I see myself in the next year. Probably wouldn’t go over so well, huh? (I mean, my current company is pretty cool and laid back, but I’m still disappointed to see just how ‘default’ this junk has become for everybody)

Really, my challenge right now is to make sure that my frustration with the industry doesn’t blind me to the good things I can still accomplish with programming. It makes a huge difference to me that programming is also something that I can use in my own life. Not every job or industry has that privilege. In most forms of manufacturing, your skills probably won’t translate very clearly to your personal life, so those skills are kind of “locked-in” to your employment. And that’s not to pick on manufacturing, I just needed an easy example. With programming, the opportunities are endless. You just have to survive the longue durĂ©e and not sweat the small stuff.