Fog Creek Software
Discussion Board

Programming for fun -or- profit

Last week I made a presentation to a CS class at a local college, and afterwards I entertained at lot of questions from the students.  The subject that drew at lot of attention was career advice  I don't know if I'm really qualified to give any advice, but they're eager for info so I figure I'd give it a shot. I'm writing something up for the prof to post to the class mailing list.

I'm sure there are other ways to split up types of programming (as in Joel's 5? worlds), but for simplicity, I've chosen to split it between "low-level" programming and "business" programming because that's I categorize most of the people I know in the field.

In my job I write a lot of number-crunching type of scientific applications. I usually spend about half my time writing the initialitial code and half my tweaking the algorithms and inching out performance gains at both the C and Assembly level.

To me, this isn't really work - it's fun. In fact, most of my friends who do low-level (aka "hard") programming do it because we like the work, not *just* because it's a job. The people I put in this category are doing device drivers, embedded programming, game programming (graphics), and test programming for IC shops. Most of them are above-average to great programmers. Most of them program in C, C++, and Assembly.  The money is generally OK to good, but not great.

On the other hand, most of the other programmers I know do business systems programming. The people I put in this category are doing GUI applications - primarily enterprise database applications - both web and desktop. A few of them still enjoy it, but a lot seem to have an "it's a job" attitude. Most of them are average to good programmers, with a few in the great category. But I would definitely say there are more "average" programmers in this field. Most of them program in Java, C#, VB, and C++. One trend that I have noticed is that many that used to use C++ have switched to Java or C# for new projects. Also, knowledge of SQL is essential. The money is often good to great - especially those with 5+ years experience that are doing consulting.

So in summary, I would say that those that are drawn to the low-level stuff usually have higher job satisfaction, but lower salaries.  And those the are drawn to business programming have lower job satisfaction but higher salaries.

I realize that my circle of acquaintances may not map very well to the programming population in general. So, before I send my comments to the prof, I wanted to get some feedback. Any comments?

Relucant Advisor
Friday, October 31, 2003

My apologies for the typos and mis-spellings.  Re-reading my post above, I realize that I didn't proof read it *at all*.

Relucant Advisor
Friday, October 31, 2003

First, lose the whole "average" programmers perception.  They may not be able to do low level bit pushing with your skill and dexterity, but they probably are good in their problem domain.  How fast can you whip up a data analysis package that takes into account the foibles and ADD of the typical business exec?  To them, you're probably just "average" as well.  Frankly, the final result is that all programmers suck, sometime we suck less than others, but we still suck.

Second, as far as job satisfaction goes, it may just be the domains where your aquantinces work.  I did business programming for an aerospace manufacturer, and frankly I was bored to tears, writing mostly data collection and accounting apps.  I switched to working on healthcare related software, and frankly there is a lot of fun, interesting (to me) work to be done here.

So, my advice would be to identify what industries you like that are not necessarily all about writing software and learning about those as well as the computer science stuff.  A lot of programming does not involve being in front of a computer.

Steve Barbour
Friday, October 31, 2003

OK, I'll lose the stuff about average, good, great programmers.  What I was actually going to do was to put it in the context of a CS program.  The programmers I know who do low-level stuff know the OS's, architecture, algorithms, etc very well. So my point was going to be if you enjoy doing  and get good grades in the kind of stuff taught in the CS curriculum, then low-level stuff might appeal to you.  Former classmates of mine who did not do well in the curriculum, went on to do very well in business programming - but none did in low-level programming.  But in the interest of avoiding a pissing contest here, I drop that.

As far as job satisfaction - I'm only going by my personal experience.  None of my low-level programming friends complains of burn-out, and yet many of my business programming friends do.

Relucant Advisor
Friday, October 31, 2003

Sorry, didn't mean to get defensive.  I personally like the low level stuff, but was never able to find a job locally that required it and I'm not willing to move.

I do think it's important to figure out what kind of work you like to do though, and to prepare for the possibility that your ideal job doesn't exist or may very well change at some point in the future.

I think for a lot of people burn out comes from two main areas.  Boredom from solving the same problem over and over again, and stress from trying to move mountains with a tea spoon at a steam shovel's pace.  Both of which, I think, are more likely to occur in a business climate, but as you alluded to, business is where most of the work is.

Steve Barbour
Friday, October 31, 2003

You might also like to reconsider the way you describe advanced level work. It would be better to describe it as "high-level."

The low-level appellation reflects judgements by outsiders and, although it's entrenched, it's not the best term to use for advanced level work.

In companies, it lets non-experts skate around saying they're handling the high-level stuff, when they're actually handing the dumb stuff.

Friday, October 31, 2003

In my opinion and experience, the more difficult a job is, the more you have to value what you get out of it.  It's the old cost/benefit ratio: if I'm going to work hard at something (cost), the benefit needs to be correspondingly high.  "Fun" is a reward that makes difficult or unpleasant tasks and jobs worthwhile.

The folks like yourself who really enjoy programming, working on tough problems, get a lot of value out of just making something work -- and then making it work better is fun too.  You have a job that is satisfying to you.

The people who have an "unsatisfying" job doing business apps... some of them are coders at heart who want more fulfilling jobs, and a lot of them are just working for a paycheck.  They get fulfillment out of something other than their job.

So, bottom line: if you enjoy coding, try to get a job that will be satisfying (and if you can't, maybe contribute to an Open Source project that will give you an opportunity to satisfy you).  If you're in CS for the money... get a McProgrammingJob, make money, and find fulfillment and satisfaction in your life elsewhere.


Friday, October 31, 2003

I think the issue is barriers of entry.  Its not too easy for someone who isn't exceptionally talented to start writing device drivers, optimizing game algorithims, embeeded stuff.  On the other hand, theres a lot of grunt work in the "business" side of things.  You need people to write front end code, people to do database reports, to make simple applications...and thats pretty easy to learn.  Now, theres a side of business programming you don't really.  Thats high level architecture and development.  Its *not* easy to design a scalable, speedy, robust, enterprise application that has to integrate with x number of systems, and have a maintainable code base.  Heck, most people can't get *basic* e-commerce sites done right. 

Friday, October 31, 2003

"If you're in CS for the money... get a McProgrammingJob, make money, and find fulfillment and satisfaction in your life elsewhere."

I'm in it for the money. That is to say, I wouldn't do it if I wasn't being paid. And yet, I find the work fulfilling and satisfying too.

Guess I'm bucking the trend.

Dennis Atkins
Friday, October 31, 2003

"Its not too easy for someone who isn't exceptionally talented to start writing device drivers, optimizing game algorithims, embeeded stuff"

The flip side of that is that when you're writing drivers or embedded software, often your world is a very small world - a limited number of options and information to know to be the best damn hardware XYZ driver writer, or embedded software developer. I mean programming embedded microchips sounds amazingly complex, until you realize that it's the tetris arranging of some 70 or so instructions.

The easiest programming I've ever done was assembly, despite the myth that it is the most advanced environment.

Dennis Forbes
Friday, October 31, 2003

I can relate to that ... low level stuff is appealing because while at the computer science level is may be "complex", in the grand scheme of things it's amazingly simple.

It's kind of like it's just you and the machine, vs you and a metric ass-load of business requirements.

Sometimes I think being able to see the bigger picture is a curse ... it means you can never be satisfied in any job where you do have to deal with the bigger picture, becuase you see how abjectly you're failing. On the other hand, a low level embedded type job is probably great, because there is no bigger picture for you to worry about.

That's why I think some people find satisfaction there.

Sum Dum Gai
Saturday, November 1, 2003

"It's kind of like it's just you and the machine, vs you and a metric ass-load of business requirements."
Lol!  Thats a *great* quote.  Very well said. 

Saturday, November 1, 2003

I am a "business systems" programmer, but more specifically I am a programmer for IT systems as opposed to building commercial software that gets resold.

One of the frustrating things for me (and my colleagues that I talk to) is that you are not given the opportunity to be excellent at any one thing. So, I am not a crack C programmer, but I have used enough languages to make most resume filters. Jack of all trades, master of none. I can always count on a perl project every eight months, just long enough that I have to consult books to remind me of the perl trickeries. To the business, I am a problem solver not a [your language here] programmer.

Another funny thing about programming "business systems" is that businesses usually want to make a profit, so they rarely care about you taking the time to tweak algorithms when they can buy faster hardware. We have system administrators and dba’s babysitting these systems anyway, they just spend a little extra time (or more likely call the vendor) to stick in another stick of RAM. The theme of “business systems” programming is to make it just good enough.

The business usually wants, in order, the following (1) done by their specified date, (2) work properly, (3) all their specifications completed, (4) runs fast enough to not hear complaints, (5) easy to use, (6) is expandable (OO reuse... yea right!) and (7) well documented.

So, I do not have a lot of experience writing the most optimized solution or am not able to answer tricky C questions, but I do have experience getting solutions completed quickly for business problems. Sure, sometimes I don’t feel like a “low -level programmer” as you described and I get bummed out wishing for a better life. When I step back, I appreciate the variety of technologies I get to use and the many projects I have worked on. In the end the business makes a profit, and I can share in that profit with a higher salary.

Sunday, November 2, 2003

I feel that while systems programming is very logical, envolves a lot of math and information theory the business programming is more based on opinions.

While you do systems programming the domain is much more measurable, based on stricter formulas and facts, may involve some math and physics which do depend on CEO opinion about markets.

Business programming is more related to economics, which means that you have to learn more about subject you implement than algorithms or methods of implementation. Business languages usually focus on "that to do", rather then "how-to". And as I said earier lot of things are political and depend on your direct manager or client opinion. Prove this person wrong is always impossible.

With bussiness programming you very often have business pool "knowing better" how your UI has to act and your screen to look, which technology to use. Which is more than annoying. It usually leaves you with coding something that is deeply unacceptable to you as a software developer, but you have to obey or quit.

So I would say systems programming offers you more flexability (as your manager is scared of it as a hell) and more technical challenge. Business software more boring as more matter how quickly you can finnish it, not how nicely it looks, besides every manager thinks he is cleaver enough to "hit-and-run".

The WebSpeed Man
Monday, November 3, 2003

Sorry, second paragraph should be read:
"...math and physics which do NOT depend on CEO opinion about markets..."

The WebSpeed Man
Monday, November 3, 2003

I agree with your observation of low level programmers vs business types who do have "it's a job" hanging over their head.  When you like programming, I would say to keep focused on the fun and intrigue of programming no matter what level you are earning income at.

When you can do what you really like, even if it doesn't pay well, it's important not to lose that personal satisfaction aspect.


Jim Barnes
Saturday, June 26, 2004

*  Recent Topics

*  Fog Creek Home