What do software developers know that computer scientists don't? Well, sometimes nothing. There are, no doubt, many who just Jump In and Do It. That's an effective strategy if you can get a product to market in less than six months. Do what you do best, for people who want what you want, and hope that the profits buy you enough time to develop your next project. You might earn $10K to $30K per year with a successful small Macintosh application. User and reviewer suggestions will help you develop additional products for the same market, multiplying your income. After developing your customer base, you could consider expanding as a software publisher or distributor.

I don't recommend that you publish your own software initially. Shawn Amir (Loop Software) says in a W/S '90 BMUG article that publishing is a complex, full-time job. A large publisher may pay 12-15% of gross sales (after 40% distributor discounts) to the developer, keep 15% as profit, and spend the remainder on operations and advertising. As a one-product publisher, you would spend 90% on operations -- so you get less profit along with incredible hassle. Profits increase as you market more products, but a typical three-year life cycle will keep you busy programming if you want six products in the pipe.

If you can pinpoint your customers, though, you may be able to sell direct. Vertical markets have mailing lists, publications, and trade societies that you can use. Software developed for one customer may be of interest to others, and a solid consulting or beta-test relationship with one or more large customers can help pay for research focused on real-world needs.

The custom/semi-custom/mass market decision depends on your product, of course, but it's possible to make a living anywhere along the scale. Just develop, package, and price the product appropriately, then market to the target population. (Once you've chosen a market, it's much easier to stay with it than to switch. If you must spin off products to other markets, license them to other companies.) Mass markets have the highest payoff, but high advertising, inventory, and operating costs also generate the greatest risk.

Verify that your market and marketing channel exist before you write code. Mock up some screen displays and have your publisher critique them. It wouldn't hurt to write the user manual first, either. (Most programmers can't write. Can you afford to hire a technical writer? Can you afford not to?) Make sure that your product does it first, better, or cheaper.

There's not much I can tell you about the coding itself. Choice of source language may be critical in some applications, irrelevant in others. (C and C++ are currently very hot.) Ditto for design methodology, platforms, and links to other programs. Just be sure you produce what your customers need -- or, better yet, what they want. Get the product out the door quickly, without polishing it to perfection. You do need to go through beta test, of course, but users with varying hardware, operating systems, and background processes will soon find bugs in version 1.0. Be prepared to issue free bug fixes and low-cost updates. Keep your customers happy if you expect to keep selling to them.

Getting a high-paying job as a professional developer could be more difficult than starting your own company. Like most industries, software companies hire young/cheap workers for routine development. Hot new projects, such as object-oriented databases, may be staffed by recent students continuing their graduate work (with occasional input from consulting professors). Other state-of-the-art algorithms are likely to be acquired rather than developed in-house, so your best bet is to develop a product -- patented, if possible -- and then sell out.

Either consulting or contract programming may be a way to exploit your technical knowledge. I don't have much experience with these, but I imagine that off-site consulting arrangements make software managers nervous. Telecommuting is possible in vertical markets, but it wouldn't hurt if you live near several potential customers. (You shouldn't work simultaneously for competing companies, but sequential employment is no problem. Each company gets your best efforts -- short of revealing trade secrets.)

If you really want to be a salaried software developer, look around for a company using the systems, languages, and methodologies you're familiar with. Product line doesn't matter much -- you're unlikely to have the right specific expertise in any case, and you may have to switch projects at any time.

Management of software development is not an entry-level position. If you want to work your way up -- as opposed to being a specialist or wizard -- you must demonstrate special skill in areas other than programming and research. Develop contacts with customers or other developers, and read management-oriented literature when you get the chance. (Reading more than one scientific paper per year may be a waste of time.)

Now, back to my original question: What do developers know that computer scientists don't? They have to know the market and the competition, of course. They also have to know what resources are available. I'll mention a few that are offered in the April issue of APDAlog, a quarterly catalog for members of the Apple Programmers and Developers Association. (See ads in the monthly MacTutor for developer's resources not offered by Apple. And don't order from APDA without checking prices at the mail-order houses that advertise in MacUser and Macworld.)

If you're just getting started, Apple recommends the following bundle: Getting Started Developer Resource Guide; AppleLink Kit; subscription to Apple's "develop" magazine (including a quarterly CD ROM); subscription to APDAlog; course catalog for Apple's Developer University; and the new Macintosh Directory of Development Services (technical trainers, contract programmers, product testers, etc.). AppleLink gives you a direct line (email or bboard-style) to other developers/consultants/VARs/etc. and to Apple technical publications, press releases, market research, utility programs, and support personnel. You pay $12 per hour plus about $.10 per page, $12/month minimum. "develop" magazine includes code fragments to help you keep up with the latest operating system changes (e.g., 32-bit color). The Developer University offers short courses in Mac programming, object- oriented programming, and specific application environments (HyperCard, MacWorkStation, MPW, etc.). Self-paced video courses are also available.

C programmers may want an additional bundle: the THINK C compiler (including object libraries); Dave Mark's Macintosh C Programming Primer (two volumes); Scott Knaster's Macintosh Programming Secrets; and Apple's Human Interface Guidelines (160 pp.). There's a similar bundle for Pascal programmers, and a variety of support packages for Common LISP, PROLOG, FORTRAN, Smalltalk, Modula-2, BASIC, V.I.P., and other languages. Also for 4D and other database systems. THINK C and THINK Pascal are the favorites of small developers; large developers needing version control and integration of multiple languages will generally opt for the Macintosh Programmer's Workshop (MPW) environment.

You can also buy source-code examples, books on programming practice, and monthly updates to Apple's technical literature. A CD ROM (E.T.O.: Essentials, Tools, Objects) gives you quarterly updates to most of the MPW development environment -- assembler, Pascal/C/C++ compilers, MacApp object-oriented framework, debuggers, and documentation -- for $995 initially, $300/year thereafter.

One way or another, you will have to become familiar with the five-volume Inside Macintosh reference set. (It's available on floppies and on CD ROM. The Mac Zone may be the cheapest book source.) Application generators such as MacApp can save you time, but first you have to take the time to learn them. Tutorials, cookbooks, reference books, short courses, and user groups are available, of course. The same is true for HyperCard and for MacWorkStation, a Mac-like graphic user interface and connectivity tool for non-Apple micros and mainframes.

Most importantly, you can buy libraries of subroutines. Why write your own dictionary, database, networking package, numerical tools, graphic interface, or plotting package when you can buy them off the shelf? (Failure to incorporate standard packages is the single greatest weakness of academic software.) You can generally get source code if you need it, and you can override subroutines with experimental versions. Package vendors will help you avoid conflicts with popular INITs and with Microsoft's nonstandard hacks.

If all this is more than you can absorb, you may need to join a developer association. There's the MacApp Developers Association (MADA), Symantec Programming Languages Association (SPLAsh), MacShare (for MacWorkStation programmers), MacIS for information-system professionals in organizations with at least 100 Macs, and the Software Entrepreneurs' Forum. Then there are the developer SIGs of the 1,200 regional user groups: Apple Corps of Dallas, BMUG, Boston Computer Society, Los Angeles Macintosh Group, MacTechnics--Ann Arbor Computer User Group, Seattle Macintosh Downtown Business Users Group, Washington [DC] Apple Pi, etc. (Call Apple's User Group Referral at (800) 538-9696 x500 for help in locating a group near you.)

And then there are Apple's hotlines for software licensing, developer support, developer training, VAR and dealer support, and the Apple Consultant Relations Program. And equivalent resources from other major software-tools companies. Once you enter this world, your mailbox need never be empty again.

This is all specific for the Macintosh world, but equivalent resources no doubt exist in other environments. (The OS/2 and Windows 3.0 style manual, for instance, is IBM's "Common User Access: Advanced Interface Design Guide.") In many projects, you would need familiarity with more than one software environment. The world of a developer is no simpler than that of a researcher. Commercial software development is a full-time career.