- Posted by
Scott
on
March 31, 2008
-
-
A few days ago, I read a great article about creating a Great Place to work for software engineers.
It covers the newly tried and successful 4-day work week, Working from home on Flexible time, profit sharing, and overtime. I do have a few thoughts on this though. The 4-day work week is an amzing feature, I love the idea of this and would hope that all companies would either implement the 4-day work week or the 20% Google Time. I would love either one to be implemented. The work from home and Flex time is an amazing feature and I have personally written to my companies Vice President for a request on this one along with the 20% time. She only said that she forwarded to HR. This makes me sad. Profit sharing and overtime, I agree that there should be no profit sharing, because this income only allows the company to grow and push out into more fields of their prospective market.
I would like to add two more requirements to the list.
1. Two monitors that measure at 19" or bigger.
2. A very comfortable High Back chair. The current chair I would in is high back, but it doesn't support my back the way it needs to. I honestly think very little research went into these kinds of chairs.
Before I would ever get hired by another company, these two things would be requirements on my part.
Scott Pio
- Posted by
Scott
on
March 28, 2008
-
-
Hello and welcome to another session of why do I document code. Today's contestants are:
1. The Software Requirements Document otherwise known as the SRD - This valuable little document tells the developer what to develop. Is was started by the Carnegie Mellon. It is used as a contract document between the developers and the customer. The customer starts the document by what they expect the program to do. Everyone knows that the customer always changes their mind, well if you use the SRD, they are held by a legally binding contract that specifically states what to develop. You as a developer don't develop anything else except for what this document states. Therefore if the customer changes their minds, well you can either point back to the SRD or decide to charge them more money.
2. The Database Maintenance Manual otherwise known as the DMM - This handy dandy contestant describes every little feature about your applications database. IT describes the tables, the columns, the attributes of the columns, the generated script of the entire database, the user logins, the ways too install and upgrade the database on another machine, the DTS and last but not lease etc... This basic manual describes in detail every single part of the database. The reason for this is if you had a total hardware melt down and nothing works, well you now have a copy of the database that can be recreated using the script that was generated and put inside the file.
3. The Software Design Document also known as the SDD - This massive document describes all the methods, namespaces and functionality of the Code. IT also describes the developers thoughts and opinions to why they code the application one way compared to another. When I say everything, I mean everything. This document has all the developers thoughts and opinions when they were designing and developing the code. Thank god most comments can be extracted via an XML parser. The XML parsed comments can even put it into a nice little help file just like MSDN.com. Where can you learn how to write one, well let me tell you. Our good friends(Not really at all) at Bit Formation has made a great tutorial on how to write one.
4. The User Guide - The user guide plain and simple is the thing users use to get around the application. Every little thing that was EVER created by man has some sort of user guide attached to it. These are a no-brainer, but long and tedious to write just like the other documents listed here today!
Now that you know our contestants, lets find out why you would do such a thing.
Alright, enough with the game show. I thought it would be a good starter. I completely agree that all the documents though rather tedious and considered a time waster by developers is a necessary part of life. Developers need to both COMMMENT CODE and write documentation. That is the way it should be and should end up. Documents are there in case you as the developer get into some kind of horrific accident and are no longer able to continue on. They must find someone else to keep going. Sorry, but that's the way life is. You are writing the documentation incase you have to be replaced. I currently work on a 20 year application and I know for a fact that I will not be working on this same application for another 20 years. I just won't do it. It is too boring and mundane. I do know that some day, they will hire another guy or girl who will have to continue my work and when that day comes, the documents are there.
Ladies and gents, just think of documents as another day in the life of a developer. Things must be documented.
Scott P.
