"Customary" died a long time ago. The requirements of your position are spelled out in your Employee Manual, which in the states is treated as your employment contract, unless otherwise explicitly specified. Left coast states don't have a requirement to give notice, either by employer or employee, before terminating employment. Some companies stipulate notice. The bottom line is that employment is a reciprocal arrangement. You've had the experience of being told to "get out", which defines nicely your reciprocal responsibility for notice, loyalty, etc. The Fair Labor Standards Act (FLSA) has no requirements that a company must give notice to an employee prior to a termination or lay-off. Check your state department of labor for specific state requirements.

As has been said, what ever works. I have one caution, though. It is always very tempting to equate no complaints with no bugs or no problems. That is almost never true. TDD has the strong advantage that to some measurable, repeatable degree you can verify the behavior of your code. You can document what has been tested at least somewhat automatically. Then when the complaints come, or when changes are made, testing, regression and anticipation of problems can come naturally in a planned framework. My rule of thumb: if no one is actively looking then no one will find any problems.

blah, blah, blah James W Taylor

The challenge is always the jujitsu of using the bureaucratic mindset for good, i.e. to the bureaucrat there is no difference between the cogs in the machine. So by title or by project if anyone needs a tool, everyone does. For example, define a necessary toolset for the desktop of a developer in the project plan; copy 1 of a new tool is performance evaluated and is added to the list if it pans out, budgeted as "engineering tools, misc.", as needed. I've been on the other end too often. "You *really* need a compiler to do your job?" (as a software developer) - "how 'bout next year?" (for a hot project), or worse, "just use this (old, incompatible) version." Bad enough, from accounting or finance, couple of times I got that from my boss. Clue #1 that I had the wrong position, but that's a different thread.

What brought you to look at the code? If obfuscation hides functional problems, start refactoring. If I've more time, I work deeper than strictly necessary - often I see problems not apparent when I started. A bigger issue you allude to: "What if only part of the team has the tool?". If you're in the same code base the team needs access to the same tools. Period. Hopefully they all have access to the same training and materials, if need be. Nothing worse than being second class citizen in a project, or worse, having to supplicate the gods of the team, just to get the days tasks done.

My best short definitions, in order of generality: Mathematicsis the discipline and language of precisely defining and proving assertions. Computer Science (sic) is the art and mathematics of the linguistic description of problems and processes. Computer Engineering is the art and engineering of programming languages and machines which "execute" those languages as instructions Programming is the skill involved in creating syntactically correct statements in a programming language. Arithmetic, algebras, "higher mathematics", etc. are all exercises in mathematics, and are the first steps in exercising something that a mathematician might call mathematics. Mathematics in general, expresses the clear a complete definition of a problem, and rigorously proves that a particular answer is true and complete. Exercising discipline and insight is a good start in solving problems at any level in the computer world. More necessary than mathematics in most engineering is the willingness to analyze a problem; box it in, put bounds on it, do the back of the envelope calculation. This is also a separate pseudo-mathematical skill, which should be applied constantly in all projects. Understanding the limits is one of the more important activities that will distinguish any engineer. For example, see: http://www.cs.bell-labs.com/cm/cs/pearls/bote.html[^] http://www.codinghorror.com/blog/2005/07/gigabit-ethernet-and-back-of-the-envelope-calculations.html[^]

modified on Tuesday, July 19, 2011 7:57 PM

Remember Chernobyl. No matter the quality of the design, it doesn't work if switched off.