A Person, Artist, Software Engineer, Geologist.

The bottom line for me is to provide something that others (we shall call them Users) find beneficial .  We take generic tools (languages, DB, logic) and hopefully turn it into a specific tool that solves some problem. The basic software stack contains the most generic code on the bottom with subsequent higher layers getting more specific (through business logic and APIs) until the most specific code resides in the UI, that hopefully solves a specific problem. The problem is that, as good little OOD engineers we just love re-use and generic all-purpose code.  We are always looking to making our logic, features and code as generic as possible because we just know that we may re-use it sometime in the future (yeah sure!).  Sometimes we try to push the generic code up through the layers and expose them in the UI, you know, because we love re-use and such.  It's in our nature.  Because we are sure the user will understand and love our code too.  We just have to convince them what

After what seams like a zillion years spent in development you pick up guiding principals to develop by.  One of these principals is to only spend time on efforts that either directly part of the development of the product and at most 1 step removed from the actual product.  Anything more that 1 step removed from the actual product development should be looked at with suspicion as to it's benefit. By benefit to the product I mean, if that process was removed could the development more or less still continue with the product will being completed?  Yeah, it's all subjective, as you will find developers always thinking that they must have this or that, or that the product would be "better" if their own testing framework was developed for their "special" needs.  Hummm, yeah right. Each step incurs it's own cost in design, coding, resources and more importantly on the timetable.  Time taken away from the direct product is time not getting the product done

When I was a young software engineer life was intense.  Code was moving fast, we all thought that our way was better than others and always wanted our voice to be heard.  Meetings way back then were a pain and mostly self inflicted. It has not been that way for a long time now.  It's interesting and educational to listen to others and not talk.  Most decisions will find their way out if everyone gets a turn talking and listening.  Almost all choices are not life or death in nature, with most in flux and subject to change.  The whole listening part is mostly for understanding others viewpoints.  Good choices will mostly rise to the top with poorer choices failing to gain traction, as long as everyone (kinda) does not have a personal vested interest in specific choices.  There will always be code to design and write.  Persons will personal goals or desires that conflict will the direction of the project will stick out and may get minimized in their weight or they will bear a larger