Jobs that use programming which aren't in the technology sector [closed]

Question

In the last chapter of "Learn Python the Hard Way" the author says:

Programming as a profession is only moderately interesting. It can be a good job, but if you want to make about the same money and be happier, you could actually just go run a fast food joint. You are much better off using code as your secret weapon in another profession.

People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines.

Does anyone here work in or know someone that programs in a non-technology industry?

I kind of assumed after I graduated in Computer Science that I would work as a software developer but this has got me curious about what other opportunities there may be.

Answer 1

This depends heavily on what your interests are.

Mine are firmly in computers and computer science, so I wouldn't be happier running a McDonald's (assuming I could get a franchise).

Other people have other interests, and many of them can use programming.

Suppose you want to be a biologist. You can make yourself stand out by knowing statistics and programming. You need to be a biologist for this to work. Otherwise, you're a statistics and programming guy, and you get evaluated on that basis (which typically means you're nice to have, but the first to go if the grant money isn't immediately forthcoming).

The same applies to other professions: For many professions X, if you are an X who can program, other things being equal that makes you more valuable than an X who can't program, or (for many applications) a software person who isn't an X.

Answer 2

I would posit that the author is referring to the "code monkey" level of programmer. They get a task, described in very programming-related terms, and write the code that does it. He's right; this isn't much fun. You show up at 8, put your head down and code for 8-12 hours, then go home. Many at this level never see the "big picture" of what they do.

However, this is only the entry level. I would posit that entry-level accounting, the real "bean-counting" work, is just as dull, but then you get a CPA cert, work your way to managerial accounting where the numbers your clerks crunch are used to make guiding decisions about businesses, and the job becomes much more rewarding. Similarly, the guy pounding in nails to frame a house is probably not looking to do that for the next 40 years. Programming, as a profession, becomes much more enjoyable as the scope of your immersion in the field and your involvement with the entire SLDC increases. When you get to learn the "why", and how it translates to the "how" you've been doing at the lower levels, the job becomes much more satisfying, just like getting to be CFO of a business, or general contractor for a house. Everybody starts somewhere.

Further, even at the lowest level, programmers simply cannot work in a vacuum. There are managerial styles that try to separate the development team from the high-level demands of the business (and they're much appreciated), but you simply cannot program code to do something without knowing, or learning, how it would be done without the code. You can't write an accounting system worth anything to your users without understanding GAAP. You can't write simulation programs for biological, medical, etc processes without some understanding of how those processes really work. Even at the more meta-programming level, where developers write the IDEs, compilers and language specs (which is REALLY high-dollar stuff), the programmers have to know how other programmers want to use the tools being built. You cannot instruct a computer to do something you don't know how to do yourself.

That's a HUGE draw to this field. almost every industry on the planet benefits from using computers in some fashion. That allows you to take your skills as a programmer to almost any field, and while you're programming, you're also learning about that field. Stay in one field long enough, you'd actually be a fair shake at doing the job from the other side (with the probable exception of medicine; as much technology as there is in that field, I don't think there's really enough time to absorb all the information you'd need to be a doctor by writing medical programs).

Answer 3

I frequently told undergraduate classes that Computer Science is the best MINOR on campus. I think that what's getting at, and certainly what I was talking about is that it puts a major tool in your toolbox, regardless of your chosen profession.

Some examples:

• I know several physicists who use programs they've written to simulate experiments ... mostly as a rough guess before actually setting up, but in the case of some cosmologists as rich, full simulations ( figuring out what the simulation is suggesting is what makes them physicists instead of computer programmers )

• A friend of mine is an independent accountant whose knowledge of programming has helped him develop database systems and detailed visual basic macros that greatly simplify his day to day tasks, and allow him to take on more clients than he otherwise could.

• I have known of (theoretical) chemists use C programs to perform computations and calculations that would have otherwise been quite tedious. They use hooks into software like Mathematica to make it appropriate to their work.

Hope this helps

Answer 4

Maybe this isn't quite what you mean, but I work in the publishing industry; I'm a web developer for a magazine. I also have a friend who worked for an art museum; she wrote software to catalog "interactive" art exhibits, manage digital photos, and that sort of thing.

Answer 5

I work on the edge between technology and health care, healthcare analytics (analyzing numbers related to health care - patient satisfaction, patient outcomes, etc.). The company I was in used to think of themselves as a "technology" company, but we merged with a larger company that sees themselves as a "healthcare" company, but realized that they need a paradigm shift and bought out our company to help with the transition to being a "tech" company.

IME, companies that see themselves as technology companies or software companies actually respect programmers far more. They recognize programmers as the source of their business value. Companies that see themselves as another industry see programmers as serving the people who provide the "real" business value. This manifests itself in myriad, subtle ways. Programmers in non-technical business industries often find their programming skills end up outdated and wasted on maintaining their poorly-written software, or else they have to keep switching jobs to stay up-to-date. Some non-technical industry companies do "get it", I'm sure, but I can't think of one off of the top of my head.

I think the author of this statement might be speaking more towards research than business (and I include business R&D in "research"). I would find it plausible that in research there are many interesting research problems available in other fields that aren't that difficult for programmers to help with, and programmers may indeed be well-respected when they help solve those issues. Researchers deal with similar problems to programmers: They are always solving new problems, and while they can follow best practices, there is no infallible guidebook on how to do their job. Innovation is very important, and if you don't stay up-to-date, then your career could die.

A good path to these kinds of research positions would be: Get a BS or BA in either computer science or the discipline where you want to apply your programming skills. Then get a MS in the opposite (e.g., for mathematics, if you have a BS in Computer Science, get a MS in math; if you have a BS in math, get an MS in Computer Science).

Answer 6

If we're going over work-experiences and "outside the realm of a software house", I feel like my job would apply.

I currently work for a manufacturing house (short-run prototyping of parts made from sheet metal). My job is to use technology to improve and simplify the work-processes they currently perform. Sometimes that's making reports or live schedules, other times it involves writing plugins for Outlook or web applications the entire company can use. Basically, it boils down to automating.

Interestingly enough, automating for our company is different than most scenarios. In a more traditional sense (or how I perceive it) it's usually about getting an ROI through eliminating positions, overtime, etc. In my case it's more about expanding the capabilities of the crew we already have (making the ~50 employees expand beyond their normal capacity by making the more mundane tasks either eliminated or simpler). I honestly love my job and the ability to see the entire product life cycle.

Even cooler, though I don't do any "formal" usability studies, my clientele includes everything from CAD engineers who are more advanced users, to shop floor employees who can barely use email. Gives me a great opportunity to make sure what I devlope is both easy to use and robust.

Answer 7

I'm a computer scientist working in biotechnology, a bioinformatician if you will.

Reasons It Is Different

Where bioinformatics differs from "pure programming," is in its vast knowledge domain and focus on algorithms/performance (as @GrandmasterB mentioned). The disciplines it encompasses include: biology, computer science, statistics, math, and chemistry. Even when focusing on a narrow portion of the field, it isn't possible to know everything.
In regards to algorithms, this is a relatively new field with MANY unsolved problems. Biotech is always pushing the cutting edge and due to huge mountains of data, requires efficient algorithms.

Reasons It Is Not Different

In the above mentioned sense, bioinformatics is no different than any other career in Computer Graphics, CAD programming, etc. These are similarly algorithm/performance driven and have a huge knowledge domain to master.

The description given above is only true for about half of all bioinformaticians. There are also plenty of bioinformatics jobs that are more "pure programming". By this I mean not algorithm driven. These are things like setting up webpages, maintaining databases, converting prototyped algorithms into production level software code, etc. Many/most of these require very little domain knowledge to do a decent job and limp along.

My Answer

To conclude, I believe all the book's author is ultimately saying is that individuals with a strong domain knowledge and algorithm/problem solving ability may be considered of higher value than those without, which really isn't saying much. I think there are a variety of programming jobs with varying levels of excitement, but there are many in the technology sector that are interesting. Even bioinformatics has its share of "moderately interesting" jobs.

Small Side note: Software Engineering and code quality is generally VERY POOR in the biology/biotechnology world. Most programs are poorly architected and have a "one off" mentality. (They could use some "pure programming" lessons)

Answer 8

The U.S. Bureau of Labor Statistics is a good resource for this sort of question. I imagine other governments publish their own statistics, but the results are probably similar. There are programmers in essentially every industry, but some have better prospects than others.

I do think knowing how to program provides an advantage in whatever field you're in. I took a clerk temp job in human resources to tide me over once. I don't remember the details now, but they assigned me a mind-numbing task they expected to last a few weeks, involving going through a long, printed out list and typing certain extracted details into another list. It took me less than half a day with a little programming. You might be amazed at the brute force methods people use for data processing just because they don't know any better.

Answer 9

I've been the "the computer guy" at non-profits and I've been the "people-guy" in software companies. That's having a degree in Anthropology/Computer Science with an interest in community service and knack for public speaking will do.

What the author seems to be getting at is it is interesting to be a cross-trained resource. Being good in multiple fields is often better and more interesting than being an expert in one.

Answer 10

I'm not surprised by the author's statement. You might want to consider where he's coming from. In short, he didn't complete university due to running out of money, is somewhat polymathic, and has invariably been treated like a code-monkey by people who approached him. He's also quite known for expressing strongly opinionated rants. That would be yet another one of them.

On a personal note, I think he's not particularly wrong. Being a code monkey is kind of dull in the long run. It's a lot more fun to be something else and writing code for yourself.

I could never get myself to work in an IT department that is viewed as a cost-center in upper management spheres. But that's just me, really, and at the end of the day I've never actually tried it. Maybe it is comforting to work 9 to 5 and have a house in a suburb, a car, a wife and a dog.

Being an independent dev or a consultant is not hugely rewarding in my experience -- you're treated like a code monkey, but at least the customer tends to listen.

As to being part of an IT-based start-up. Well, bear with Zed for a moment. In his experience (again, a rather polymathic type who knows just as much if not more about the business side of things than the suit who addresses him as if he were a code drone), it's not exactly thrilling. Personally, I strongly relate to that. But I also know many coders who don't.

His message, in essence, is: if you want to fully enjoy it, make sure you're coding for yourself, rather than for someone else. But keep in mind, while reading it, that he's an entrepreneurial type.

Some programers are just thrilled to code without worrying about the bigger picture...

Answer 11

I think what he's trying to describe is the importance of domain knowledge. And he's right about that. Though I do question whether there's some clear line between 'techonology' and 'non-technology' companies. Does he really mean to say that companies that work in biology, medicine, and physics arent technology companies?

The point of using computers is to solve problems. Rarely are those problems specific to the computer science domain. You have compilers, and file systems, and routers, sure. But other than those limited cases, you're solving someone's problem in some other field. Knowing that field is as important as knowing about software development. A pure developer can collect specs from non-developers, but things are much more effective when you have someone that crosses into both areas of expertise. Thats where you get a lot of innovation - at the meeting point between software development and some other field.

Answer 12

I don't know if my job comes under "Technology Sector" for the purposes of this question or not - I work in the automotive industry.

Unlike many of my colleagues, I don't spend hours trawling through spreadsheets of test data looking for glitches, or the like, I write a parser in C++ using Boost with an appropriate rule-set and let that do the grunting (of course a bit of code reuse has made my life easier every time after the first). [As it happens I was only taught Modula-2 as an undergraduate and some PASCAL, then as part of my Masters I learnt some Matlab, but all my C and C++ is self-taught since I wanted to learn something that was widely, freely available and portable]

Writing and testing the parsers takes less time than trawling the data manually. Similarly, if I want to take days or weeks of data captured at millisecond intervals and summarise it I do this using a very similar parser, except instead of looking for glitches this averages and resamples the data.

Also, I have written test software that accesses Controller Area Network hardware in my PC, and thereby instructs controllers in a vehicle to perform a required action and then measures system response(s) from captured CAN data to automatically judge pass/fail.

I'm sure that if I was a "real" programmer that there would be some really neat ways to do the above with about 10% of the codebase, but I'm just a mechanical engineer ;-)

Answer 13

Does anyone here work in or know someone that programs in a non-technology industry?

As a consultant, I've worked on software including:

• Code that controlled a machine to assemble pliers in a hand tool factory
• Color analysis software to help people to pick curtain and cushion fabric that matches or complements their existing décor
• A calendar program that a digital stock photo company gave away to business partners to showcase their portfolio
• An art project funded by a grant from the French national government
• Components for a digital jukebox you can find in bars today
• The first all-digital financial trading room system
• The first commercial Monte Carlo simulator for evaluating financial derivatives for which no analytical formula exists

Interestingly, I'm a chemist and mathematician, but I've never actually written any chemistry software - at least, not since I was an undergrad.

Answer 14

This is an interesting topic. Here is my two cents.

I worked in the Medical Center of a large US university for some years. I first worked in a Computational Biology research group and then in a Clinical Trials setup, where I did some bioinformatics stuff. I have a PhD in statistics, but due partly to mistakes and miscalculations on my part, wound up doing mostly coding in these jobs. While I have nothing against software work, I didn't want to spend my whole time doing that.

I can second what David Thornley said. The way I think of it is, if you aren't part of the club, people don't respect you. So for example, if you are in a biology research group, and are not a biologist, you are not in the club. They may tolerate you if they see you as a equal, say a mathematician. Unfortunately, research scientists, at least the ones I have met, don't respect computer programmers. Ironically, as DNA Coder says, these same people don't have a clue about programming, and generally make a mess. (This is assuming they actually do progamming at all, and don't farm the work off to graduate students or contract workers of some kind.) Specifically, they have no understanding of design issues or the necessity of testing, and are often happy to take the results of some software program and stick it in their publications without further ado.

The reasons for this are clear. Academia does not reward expertise in software. What is important is journal publications. Code is just of interest insofar as it generates results for publications and grant applications. Historically, journals have not cared about software except in the marginal case where the article actually is about the software. However, this may be changing. See the Nature article linked below.

This is generally true across the research scientices, not just in biology. Disclaimer: I'm just one data point, and the people I worked with may not be the best. The clinical trials people were especially stupid. Maybe the really good scientists have better attitudes towards software engineering.

To put this in context, these days there is an increasing problem with reproducible computational research. Science needs to be reproducible, so researchers can check each others work. With the increasing importance of computation in the sciences, this means people need to be able to reproduce the results of software. However, if the software is a mess, this is not so easy. There is an interesting article in Nature on this topic. At the risk of adding more negativity to this post, some of these numbers sound very inflated. "Only 47% of scientists have a good understanding of software testing"? I think the number is probably 10% or less.

To sum up, anyone who is a good programmer and also has a good understanding of the domain area is very valuable, but don't necessarily expect the people who employ you to understand that.