Did You Know?

An applications programmer produces computer applications (in the modern world of development, they work as part of one or multiple teams tasked with a very orderly, thorough process):

Determine requirements (what will the program(s) do?)

Map out the program architecture and who builds what (usually the final program is termed a Project until it is finished) will satisfy the person(s) paying for it, and when it’s approved in final form [or sooner, depending on the shop], then it’s typically called a [generic, marketing or specific meaningful name] (Program).

Code is often, but not always, first mocked up in a theoretical version called pseudocode in order to discuss particulars and to dial in later-stage plans of how it will be built and used.

Some effort is applied to important basic tasks the program(s) or application(s) will perform, with particular attention paid to how users of differing skill levels and tasks desired for processing by the application are proposed, discussed, and designated as critically-important, potentially folded together into a smaller set of requirements by re-imagining the application based on business requirements, which may or may not be negotiable with the client paying for it/them, or potentially eliminated if too costly to build. Lesser-importance considerations (often called more program features) are discussed and perhaps added or removed to adjust the expected development timeline.

The preceding pseudocode is aligned with the requirements to ensure that the proposed code fully and successfully addresses all of the agreed-upon requiremements. The most granular full list of these individual interactive instances is called the set of use cases.
The detailed coding tasks required to build the most general to most specific use cases are arranged in a basic structural form by the project architects and/or coders.

Modern programming conforms to accrpted best practices, and is normally based upon a user-centered design model.

Coding is built in stages and in the required set of modules by teams of programmers. These types of development are discussed in great depth on hundreds of thousands of sites that break it down into very-specific roles (types of developers who do some specific type(s) of work individually, and then help each other by testing each other’s work, re-strategizing the work if necessary, re-coding, re-building), and of course repeating these cycles until testing proves 100% successful.

The tested modules are next assembled into the project. As errors are encountered, they’re logged [documented] and fixed. The technical term is they are handled in code. If necessary, previous steps are repeated to refine and perfect the architecture and code, to ensure that virtually or exactly every type and instance of such error(s) are accounted for.

Now the entire project and/or application(s) begin(s) to take shape. Unit testing is done to iterate through the use cases comprehensively. Sometimes part or all of the testing is done concurrently with the detailed code/module development.

More testing may lead to design improvements and change orders (just as in physical facility construction). Then more rebuilds. The cycle repeats until the person(s) in charge sign off on the code, meaning they assert it works exactly right (according to the earlier agreed-upon plans). Just as in commercial building construction, change orders may be large or small and cheap or too costly.

If all goes well, the project is wrapped and deployed on servers or delivered to the customer(s) for those final steps.

(Source: Your Career)

Applications Programmers do the actual coding needed above, and compile the Builds.

They often work alongside the Project Architect and Requirements or other Specialists.

Because their work is very technical and often time-dependent with high expectations of accuracy, consistency and the ability to endure long workdays and challenging work conditions (like smarty-pants bosses and co-workers who may be quick to argue), they often get compensated well.

Starting salaries for degreed pros in the U.S. could be $75k, and many top, proven programmers often earn well over $100–200k annually.

 Many companies prefer to hire such expert workers on hourly wage or short-duration periods (like 3–6 month development cycles).

However there is often turnover in such positions, meaning little job security, especially at smaller companies. These employment factors are tied to contracts, consumer (or funder) demand and specific needs for certain programmers’ best areas of expertise.

Specific areas of expertise may include anything in the programming world, such as computer systems, networking or communications, digital/analog audio/video, web, database, or other specialty.

Often programmers have multiple specialties based on their work history or goals. No one programmer could do anything with equal aptitude compared with a specialist who has far more relevant experience.

There is no magic formula for learning the most in-demand languages or skills. Therefore specializations tend to evolve organically based on luck, demand and applicable experience. Employers seek certain personality types and other traits to limit the candidate pool sizes for such work. Be aware that if you are starting out, you may be subject to exploitation unless you see it coming and stand up to it directly.

If you are considering such a career, my advice is consider doing an internship prior to entering into a long-term position. It may or may not suit you. That way leaving need not be traumatic, or maybe you’ll find a more suitable niche in the development arena by shifting to another role or specialty.

(Source: Quora)