So, you’ve graduated from school and are starting your software development job. Will you be spending 100% of your work time inside of emacs and Eclipse? Definitely not. I suspect you’ll spend less time in emacs and Eclipse than even your lowest estimation. Is that bad? Not necessarily. It depends on what your employer really wants from you.
Generally, as a software developer you are hired to do more than just write code. I would expect that if an employee did nothing more than just write code, their career path would be pretty short.
Here is a list of tasks that a software developer may be involved in during a product cycle (this list is off the top of my head, is not complete):
- identify market opportunity
- identify customer requirements
- identify competition
- obtain funding
- scope product function
- identify user scenarios and roles
- identify existing technologies to fulfill needs
- acquire or research missing technologies
- size the items in the product plan
- determine other project plan elements such as milestones and dates
- acquire employees with needed skills
- build infrastructure for development and test
- identify high-level architecture
- identify mid-level architecture/modules
- organize the development team
- develop the code
- resolve merge conflicts
- report to management/funders periodically regarding the progress
- respond to changes in customer requirements
- respond to changes in competitors’ products
- respond to changes in technology shortfalls
- prepare the code for internationalization and accessibility
- add diagnostic capability (ie, logging)
- develop functional test case plan
- write, run, and debug functional test cases
- do the same for the performance test cases
- identify performance bottlenecks and implement optimizations
- create customer documentation
- create and test install scripts
- verify release candidate install images
- create live demos
- give live demos to first potential customers and analysts
- triage customer problem reports as product bugs, customer mistakes, or environment incompatibilies
- recreate and fix product bugs
- create and package fixpacks, update product documentation
- identify long-term support plan
- provide in-depth training and documentation for support staff
- respond to customer issues that support staff can’t handle
- respond to requests from high-end customers to add customer-specific features to the product
- participation with standards bodies
- interfacing with lawyers regarding writing patents, embeding/licensing technology from other organizations, avoiding source code contamination, etc.
Did you notice how only one of those items says “develop the code”?
You may think that most of these items will fall to someone else in your organization. While that may be true in some respects, you will still be affected. For example, the item “obtain funding” may fall to you in the form of “build a mockup demo that the boss can show to potential customers/funders”. The item “identify competition” may fall to you in the form of “figure out what this competitor’s product does to see if really does what it looks like”. The item “organize the development team” may fall to you in the form of “figure out what everyone else is doing so there are no holes, no overlap, and that the interfaces will connect appropriately”.
Another surprise for most people: if products are being well supported and used by organizations, the cost of support is greater than the cost of developing the product. Yup. The first time I heard that I was really surprised. The majority of the cost is in supporting the product, not in building it from scratch. You may take shortcuts in support to drive that cost down, but recognize that as a shortcut that may eventually cause that customer to defect to a competitor.
Understand that software has a lifecycle, it’s not just about “develop”. It is going to need a team, infrastructure, and processes. You will be involved in those things. That is most likely part of what you are being paid for, and is important to your employer and customers.