I Use Bing to Search, Google to Search Hard

My Bill of Rights as a Programmer

2. April 2008 02:53 by Scott in   //  Tags: , ,   //   Comments (14)

I have seen many lists of requirements programmers wish to obtain before they start the job.  I am no different for my company.  I have my own requirements before I start a new job and I wish to create a dynamic list of my rights as a programmer.

  1. Every Programmer shall have a quiet working environment.
    • This is essential in order to think.  If the employer cannot provide a quiet working environment, see Bill of Rights #2.
  2. Every Programmer shall have the right to listen to music.
    • The essential need for a quiet working environment or to be able just throw on music to down out the background noise is essential.  We as programmers work on brain power so therefore we as programmers need to concentrate.
  3. Every Programmer shall have a fast PC.
    • Developers are required to run a lot of software that requires tons of memory and speed to get the job done faster.  The Fast PC only ensures that the programmer is able to research on the Internet while developing code and upgrading the database all at the same time while keeping up on the essential work email.
  4. Every Programmer has their choice of both Keyboard and Mouse.
    • The mouse and keyboard will only allow them to develop faster and become skilled at both shortcut keys and mouse techniques.
  5. Every Programmer shall have a fast Internet connection.
    • This is the mother of them all.  The ability to research faster is required for faster development.
  6. Every Programmer shall have two or more monitors.
    • The research done on having two monitors (here, here, here and here) far outweighs the time spent on only having one.  So even before I get offered a job, one of my first questions is will I have at least two monitors?
  7. Every Programmer shall have a high back comfortable chair.
    • This is another question I ask before going any farther with interviewing.  It not only makes the developer happier, but it helps with poster and is good for the body.
  8. Every programmer shall have access to the right tools.
    • Would you rather develop in FoxPro or Visual Studio?  Would you rather develop on Dreamweaver that Visual Studio for .net Development?  Would you rather use SQL management 2000 or use SQL Management 2005?  IT is a requirement that the company be up to date on software development.
  9. Every programmer shall have the right to have admin access on the PC.
    • There is no need for a programmer to be in restrictions of IT experience because most programmers have more experience with PC's than most IT folks.
  10. Every programmer shall be allowed to attend a developers conference once a year.
    • If companies are willing to pay 60k-100k a year for programmers, they can fork over the other 2k needed for the conference.

All things listed here are the basic needs of a programmer.  They are the movers and shakers that make companies faster with both commerce and day to day operations.  Companies are expected to follow most of the these requirements.  If you are not getting the rights you deserve, ask for more or find another place to work.

kick it on DotNetKicks.com

If you liked this post, please be sure to subscribe to my RSS Feed.

What else do companies have to do to keep Software Engineers?

30. March 2008 22:09 by Scott in   //  Tags: , , , ,   //   Comments (14)

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

Why do I document Code?

28. March 2008 00:23 by Scott in   //  Tags: , , , , ,   //   Comments (59)


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.

kick it on DotNetKicks.com