You wake up late in the day and rush into a scrum developer meeting to update your status on the current project to your team members often arriving late and surprising others that you just made it at last. A developer (SDE) friend will then ask about the LINQ code that you wrote last time, a tester (SDET) asking what changes you last made that broke the UI automation code, a Program manager(PM) asking you how much the risk is in meeting the deadline you committed before, your developer lead talking about the amazing project and actively watching how he could cut out newly arriving requirements to avoid an ever changing design. Jumping from one meeting to another meeting, trying to deliver the design documentation and arguing about which technology to use for the project, going through a bunch of code reviews in late afternoons and squashing active bugs with focus after flying around the kitchen area (to stimulate the self with a Starbucks caffeine) are the day to day activities of most developers at Microsoft.

Microsoft has so far been a place where one could say with a full mouth that they have had a United Nations meeting; thanks to the great diversity with colleagues coming from all walks of life and culture. If you pick one team randomly, it is highly likely that it has people coming from all continents. It is possible that an African developer works with a Chinese tester on a project that is being managed by an Indian whose code review is being done by an Australian and whose manager is from Europe and all reporting to a group manager from Latin America. That is the composition of most teams at Microsoft in different order. This diversity makes it fun to work here and enables everyone to feel at home at anytime, either in the team meeting or during lunch time. Despite such cultural differences and all kind of differences in the work place, one thing that glues teams together is the desire to solve problems and come up with a solution that satisfies the basic requirements of our customers.

Basically the life of a developer starts with a problem for a new project and/or a list of active bugs and new feature requests to an existing project. Developers usually prefer to work on a new project for it brings with it the flexibility of using new technologies and the possibility of knowing the details of the whole project first hand. The start of the project is where the fun is with so many new ideas flying around, going through a list of ideal designs to be downgraded to workable pieces as time goes on. Once the design starts, the managers will be hitting hard to get the developer estimates of the whole project. For the developer, the costing is an art for it is hard to determine the complexity of the whole piece and requires at least a draft design documentation showing the various pieces along with their level of complexity.  With small to medium sized projects, it is even tempting to forgo the design piece and start coding from scratch and write the design documentation on the go.

Once the project is in development mode and the focus is on, it is tempting to finish the whole thing and get over with it even though it is unrealistic. That is when developers start staying late in the office and arriving late in the morning scratching their head and thinking about the problem they could not fix last night. The focus to work on the new features almost consumes the whole time, and sometimes forces the developer to bypass some of the key deliverables in software development cycle, one of the most famous being "Unit Testing". A very good and experienced developer who thinks about having less trouble fixing bugs in future always starts working on his unit tests along with the main code base despite the overload. The payoff for this approach starts to come when lots of change in design starts to be introduced and all the unit tests start to fail signifying pieces of code that require developer’s attention. Had it not been for the Unit Tests, changes introduced late in the development cycle might create a lot of semantic bugs that could not be caught by the compiler or the human eye for that matter, and are very hard to find easily.

No matter how big a project is, the code base of the first iteration is usually a throwaway. It is from this throwaway code that the developer will learn a great deal about the system under development, it is from this throwaway code that the current design will be reassessed to come up with a better one with good and “lasting” modifications, it is from this throwaway code that some unclear requirements will start being more clearer. It is at this stage when the developer feels at ease and has an idea on how to approach the problem and when it is possible to deliver the basic deliverables.

Once the software is developed and all feature requests are implemented, it seems like the work is over for the developer, "the beginner developer". However, having all features working is the first deliverable. At the same time, more deliverables are expected to be worked on at the same time and be delivered. Developers are expected to produce an extensive unit test that has a very good code coverage (around 70%) which by itself is a big code base comparable to the main code under testing and is easily runnable in one box despite the complexity of the system. An automated deployment MSI (engine for software installation) for deploying the solution is another deliverable that is expected as part of code complete. A solution without a means for monitoring the health of the application once in use is not a complete solution hence developers are expected to provide SCOM (System Center Operations Manager) packs (or MOM (Microsoft Operations Manager) packs) that will alert the users of the application when something goes wrong.

So the work of a developer is as much stressful as it is fun, it is as much joyful as it is frustrating when a though out solution to a problem does not work out forcing the developer to go into thinking mode the whole time before and after work. Development as described above is more than providing a solution, it is about providing a very good solution, that is easily testable, predictable, monitorable, and deployable. This has been my observation so far in my short stay at Microsoft and I continue to learn new processes.