Programming Jobs that are not "Puzzle Solving?"

[Gilberto de Piento]

My job involves a fair amount of programming but I'm tired of and not very good at the kind of programming that frequently involves lots of googling a mysterious problem and then testing various workarounds until I get a cobbled together solution or fail. As in, "OK, maybe if I install this version of this package and run it on this particular server and put a colon here and a comma here it could work. Nope, that didn't work, same cryptic error message that I can't find anywhere online. What if I swap the comma for a period? Nope, didn't work, no error message at all now but it still doesn't work. What if I try a slash?" and so on. Are there any programming jobs where I just code something and it works without massive puzzle-solving googling projects? I am tired of being frustrated and failing at weirdo problems.

Car mechanic analogy: I don't want to track down intermittent electrical system bugs in uncommon, poorly documented cars anymore. Are there jobs where I can replace brake pads and rotors instead? If so, can I get one of those jobs with a non-CS background and atypical programming experience?

[jacob]

https://earlyretirementextreme.com/star ... sting.html (first part)

Less pay, more competition at the technician and mechanical level.

If okay with solving smelly human puzzles (management, sales) the pay can be substantially higher despite the lack of technical skills.

[SavingWithBabies]

I think some of that is inherent to any programming task however I think there is more of that on some projects than on others. I usually find myself having to do some of that at first but then you pave over the problems and/or have a pattern and the rest is just repeating the same pattern to some degree.

That said, I think some communities are more focused on "from first principles" than others. I think it tends towards languages which are not as popular and don't have a huge community behind them yet. I'm thinking of Clojure (and perhaps Erlang and Elixir). I guess these are all functional languages and the nice thing about those is the functions are way easier to test. The expressiveness (and complexity/denseness) does not lend itself to the type of programming that is so common in other languages where it feels like gluing together existing code modules. There are modules/packages in Clojure but somehow it's not the same as far as I could tell. Clojure is a lot more working from the basics (first principles) up and the code-as-data philosophy keeps it in that direction. That said, the hairy JVM along with Java interop is right there for people to start using so some code bases might be not as exciting.

It used to be hard to find Clojure jobs and I think it still is a bit as there just aren't as many. But it might be worth looking into it to see if it's more to your liking? You would have to get over the hurdle of getting Clojure running but I think these days it's a lot easier than it was in the past. Also, if you haven't used functional languages before, you might not like it at first however it really takes a couple weeks of using it a lot (or more time if less hours per day perhaps?) to get over the hump and see if it's your thing.

Stepping back though, I'm wondering if what you're looking for exists too. What I suggest above might not be far enough in the direction you want. I thought at first maybe switching to some sort of academic support programming position would help but really that is just changing the trees -- same problems in the end. So other thoughts:

- go into management and delegate this work to others
- if you're spending a lot of time doing this, figure out why and just say no/avoid to the tasks that lead you to this work
- specialize in something for which your hourly rate is high enough that hopefully the client will mostly have their team do the grunt work (but I think typically, the client is hiring for your skills and won't know but at least there is the potential to delegate particularly if agreed upon before taking the contract/work)
- become an architect and leave these problems up to the rest of the team (requires working for a larger company which has enough work to have a full time architect otherwise you run the risk of a blended role of architect and implementer)

I sympathize with your problem because I've realized I might have maxed out my contract rate by working at a lower level than I should be (I wrote the above before Jacob posted, reading that, I'm doing too much at the technician level and not enough at the developer level). The tricky part here is most of my problem is in communication, framing and management of my work (ie proactively scheduling meetings instead of other people working their angles scheduling the meetings in which the framing is that you're a resource). I'm going to go read Jacob's post and mull this over too.

[GandK]

In my (admittedly 8 yrs outdated) experience you have 2 big options apparent to me: either move toward UI work, or move toward a user liaison role.

In the former, your IDE tools will be more comprehensive because a LOT of people who do front-end work for apps and web sites could not code with a gun to their head. Drag and drop coding abounds in UI, and you will be miles ahead of a lot of the competition if you can actually solve the occasional coding problem.

In the latter, in large organizations with their own IT department, there is high demand for the IT guy who can do the hand-holding... who understands what programmers and code are doing, and can communicate it to business users and other stakeholders without a lot of jargon. This can also involve things like attending a lot of meetings and writing proposals and help files and such.

[jacob]

I get the impression that the trials and tribulations of software development (dealing with unwanted complexity) is a metaphor for humanity as a whole. As such ... this is highly interesting to watch.

[mountainFrugal]

If so, can I get one of those jobs with a non-CS background and atypical programming experience?

The opposite direction would be to turn your non-CS background into a project that tries to understand the googled solutions more deeply and move up a level or two in software engineering making your current problems more similar to changing the rotors: https://teachyourselfcs.com/

[SavingWithBabies]

I'm torn on the recommendation for UI work. Unfortunately, it often doesn't get a ton of respect. It's one of my favorite parts of working on a modern web app because of how straight forward it is to put things together once the groundwork is in place. I also think it's easy to work on but harder to do well in a way that can be maintained longer term (ie how things are put together) but due to that lack of respect, it often gets half-assed and is less fun to work on. But getting it setup involves a lot of those troubleshooting steps. As does keeping it up to date assuming you're working in JavaScript with node modules (a fairly safe assumption these days). But if someone else is responsible for setting it up and keeping up with security patches, it would be not a bad way to go? If you want to do contracting, there is a lot of React-based work. I bet on React and that has worked out well for me personally.

I missed the non-CS background. For me, doing a CS undergrad degree filled in a lot of blanks in how some things worked (well, typically more why they were done the way they were done). I think that common CS background makes things easier in the long run. So I do agree learning more in that area would pay off. Not suggesting going back for a degree. I'm not sure how I would go about that. One course that really pulled things together was the operating systems course with how context switches work (along with a lot of other things of course) and doing some basic assembly programming on simple CPUs. The compiler course was also helpful in understanding what patterns people use to create programming languages and the tooling around the programming languages. We wrote a compiler to JVM byte code which was a lot of fun. A security class was interesting with a web project but I found the later experience of writing an HTTP server (as an apprenticeship project) to be more informative. I suspect a lot of non-CS people have made some roadmaps to productively explore and learn CS topics.

[Blackjack]

The opposite direction would be to turn your non-CS background into a project that tries to understand the googled solutions more deeply and move up a level or two in software engineering making your current problems more similar to changing the rotors: https://teachyourselfcs.com/

eh, respectfully disagree for the situation which is described by GDP. The 'trying to grok the solutions from google' falls apart to some degree when you are just needing the right version of a certain library which runs on this one particular box which for some (probably good) reason is now using a new type of repositories that are the new way of doing things but the box was stood up on and previously doing the old way of doing things, and you need to switch it back to the old way just long enough to grab the package versions you need then shift it back to the new supported repository type*. No reason to spend 600 hours understanding the architecture and current direction of the company making this tool that i use for 1 minute every year just in case they change how the tool works again (and likely it wouldn't give me any more insight about how it would work anyways, and I would just need to google for their docs again anyways).

i.e. trying to understand a one in a million issue on something that doesn't really matter at all is pretty useless when you are dealing with a cobbled together solutions set called an "operating system" that has had dozens or hundreds of people working on it full time. Because you can't scale that knowledge base enough in your own time to even be able to understand the underlying issues for the whole system (and even when you do start to understand the systems, someone pulls the rug out from underneath you by changing how everything works).

If you are working on a specific application in a specific language, the above is much less likely to apply, and it IS worth digging into problems to understand how the language works better as you say @mountainfrugal (growing a sphere of knowledge, etc). GDP If you are okay with these types of language specific issues, be sure to look for a dev job which is specific to one lower level language and doesn't involve building the infrastructure or tooling to more easily test or deploy or deal with the application.

To answer the OG question though; I don't believe there are many software jobs that don't involve figuring out why the things things you build are constantly broken, except maybe software architect, which is generally only gained through fixing so many problems you gain an unnatural sense of intuition of how to go about solving problems when you don't know what is causing them, and having so much specific experience in a company that you know all of the nice little quirky ways things usually tend to break.

* literally what i did for 4-8 hours sometime last week.

[mountainFrugal]

eh, respectfully disagree for the situation which is described by GDP. The 'trying to grok the solutions from google' falls apart to some degree when you are just needing the right version of a certain library which runs on this one particular box...
If you are working on a specific application in a specific language, the above is much less likely to apply, and it IS worth digging into problems to understand how the language works better as you say @mountainfrugal (growing a sphere of knowledge, etc).

Agree with this. Working with different containers/environments across package releases can be maddening work. I was just offering a non-nuanced alternative view of things for someone without a CS background that might help *some* of the issues (as you point out) with an increasing depth of knowledge.

[fiby41]

Technical writing.. documenting code others have written.
Tech support.. knowing where the problem is comming from.
Customizing old code for new requirements.
Using low/no-code tools, creating proof of concepts, prototyping, wireframing.
Not all programmers do creative work, some are required there to maintain the codebase after the actual development has been done.

[Sclass]

Yeah documenting. I have a bunch of friends who passed through Google over the years. Their job was documenting and cleaning up spaghetti code that was in use but unmodified the moment it worked. Really mind numbing stuff like going through and renaming variables and commenting other people’s code.

From their description there was kind of a class structure in the sw engineers. About 50% fell into this proletariat of mop up crew. My friend paid his mortgage with it but he said it was soul destroying work.

[bostonimproper]

Not really. This is pretty part and parcel with the role.

You can mitigate the frequency of this sort of thing by having preconfigured standardized environments that your team shares. So if someone is like “x didn’t work with y, so I did z” you can benefit from that. But then you trade doing everything yourself with petty fights about which point version of this package you should really be on.

I’ve seen colleagues at multiple companies, as a way to sidestep complex package dependencies, home roll their own versions of extremely standard libraries. All I’ll say is: please please please don’t be that guy.

[ducknald_don]

I’ve seen colleagues at multiple companies, as a way to sidestep complex package dependencies, home roll their own versions of extremely standard libraries. All I’ll say is: please please please don’t be that guy.

On the other hand I've seen people pull in huge dependencies just for some trivial feature.

Personally I'm very reluctant to use third party code unless there is a really strong reason for it. If it's in the standard library then I'm happy but I have been burnt by third party code so many times.

[jacob]

On the other hand I've seen people pull in huge dependencies just for some trivial feature.

Yeah, what size executable does print "Hello World!" compile to these days?

[Scott 2]

Everything I can think of is either more junior or replaces the technical problems with people problems.

There's a trend towards smarter tooling, that can make the tedious problems easier to handle. Stuff like:

1. CI/CD and the associated automation
2. Orchestration to create your infrastructure with declarative scripts
3. Functional programming techniques, to reduce state management and push tedious problems onto your compiler

You could try to find a more forward thinking environment, that embraces such development strategies. It might make aspects of the problem more bearable.

However, I think you'll also find such an environment more competitive.

[fiby41]

Yeah, what size executable does print "Hello World!" compile to these days?

reminds me of the When programming languages print "Hello World" video

[ducknald_don]

However, I think you'll also find such an environment more competitive.

Yeah, there are two types of people in technology. Those that do the work and those that take credit for doing it. You should try and be in the first group because there is a lot less competition there.

[WFJ]

Every interaction I have with programmers is in either identifying a puzzle or solving a puzzle. The only roles I see outside of this would be in management where one decides who will create the program in hopes of avoiding puzzles or handholding very limited technology users (reset passwords, try different/update browsers solves 50% of the issues).

I am currently in a situation where a new program has caused a puzzle that has been challenging for any programmer to even define (interactions between a new system and two static systems). I have to redesign deployment to avoid the issue, as solving it is costing too much time, if even possible (new system has probably input some blocking/slowing feature as the new system is offering services provided by the two static systems, a planned puzzle).

I enjoy trying to find the puzzle, but this is only sporadic and not a main feature of my role. Not sure if I would feel the same if this was my only roll in an organization (stressful and sometimes puzzles are not solvable, but require creating a new system).

[zbigi]

My job involves a fair amount of programming but I'm tired of and not very good at the kind of programming that frequently involves lots of googling a mysterious problem and then testing various workarounds until I get a cobbled together solution or fail. As in, "OK, maybe if I install this version of this package and run it on this particular server and put a colon here and a comma here it could work. Nope, that didn't work, same cryptic error message that I can't find anywhere online. What if I swap the comma for a period? Nope, didn't work, no error message at all now but it still doesn't work. What if I try a slash?"

Have you tried statically typed languages with robust package (software dependencies) management - such as Java? These two features make programs you work with less of a black box.
A good anti-examples to avoid would be: Javascript, Python, any devops work.

[Gilberto de Piento]

Thanks for all the replies! Sorry I didn't get back to this sooner. I'm busy and tired lately. I did take some time to do some research on some of the points that were made.

You guys aren't going to like this, but part of the problem for me is that I'm not really interested and I don't see the ROI in doing more training to be able to switch to another programming language or role. I want to be done working (thus ERE), not getting a better job. Of course, it turns out FIRE any time soon is looking extremely unlikely for me (need to cover this in a journal post soon) so I probably need to embrace reality and try to make a career move. Unfortunately I'm also extremely risk-averse and I hate the job search process so that doesn't help. My worst fears are that I will get another job and either it will be worse than what I have or I won't be capable of doing it (a realistic possibility - I'm not as smart as a lot of the people on this forum).

Plus, in the past when I've tried to improve my career it hasn't worked out very and now I'm jaded about it. For example, I taught myself machine learning when that was super hot. I ended up taking a lateral move that pays slightly less than what I had before to get my foot in the ML door and get some experience. My plan was to switch jobs again into a high paying role doing ML work but I found it impossible to get any interviews, though I will admit I'm picky about jobs and not good at job hunting.

Trying to talk about this stuff here is frustrating sometimes because I don't feel like I can give all of the necessary detail to explain the situation because of my desire to keep all of my posts over the years and my financials separate from my real life. Sorry I can't give you more to work with.

I think my example threw some readers off, making it seems like I am a developer working on some high end work. I'm a jack-of-all trades doing programming, dashboards, analysis, data governance. I'm starting to think maybe that my role is part of the problem - I'm doing all kinds of loosely related tasks on all kinds of different projects.