NYCPHP Meetup

[edward potter]

And when you think you got it all under control . . .

Everything compiles on the first try, you're 100% compliant, your
mistress is great, the kids get you presents, the rent is paid, the
bank account is overflowing, the STD test comes back negative, the new
guy that tears apart your code is caught flirting with the boss's
wife, ahhhhhhhh,  what else can go right!

then it's always time for that infamous refresher web check-in break!

http://deathclock.com/

January 23 for me, I suspect a serious cold that goes bad!  :-)





On 8/19/06, leam at reuel.net <leam at reuel.net> wrote:
> >From a non coder perspective...
>
> Welcome to the land of the enterprise! We are a business driven sector that seldom listens to technical reason. I've had serious compliance patching shot down by people that don't even understand the issues nor ask about them.
>
> However, all is not lost! Here are the guidelines I use as an SA.
>
> 1. I choose whether or not I do a good job. My boss decides what the objectives are and I will work hard to achieve those goals. If I can make something more useful *and* meet corporate objectives I do so.
>
> 2. A helpful person is better than a smart one. The office is full of people who want to seem smart. I prefer to explain and educate, hopefully helping my co-workers smarter than me so I don't get paged in the middle of my beauty sleep. When my operators solve issues my life is better.
>
> 3. This day will never return and your work has spent money on the assumption you have a current skill set. So set up a few minutes here and there to be learning something new or practicing rusty skills. Not only will it keep you fresh but you may need that skill down the road.
>
> I'll add Peter's great suggestions. Read "The 7 habits of highly effective people". My number 2 on the books most positively influential. After that read "What color is your parachute", number 3. You may want to better understand the work environment you thrive in next time you look for a job.  :)
>
> ciao!
>
> leam
>
>
> On Fri, Aug 18, 2006 at 09:52:14PM -0400, Peter Sawczynec wrote:
> > I have found and employed some valuable advice for when one must comment
> > upon (read as criticize or complain') about failed job tasks or fractured
> > plans in a non-specialist corporate environment.
> >
> > [But note that Dale Carnegie in his book "How to Win Friends and Influence
> > People, said "Remember the 3 C's: never condemn, criticize or complain."]
> >
> > When noting an ineffective office policy, a bad project plan,
> > under-budgeting, wrongheaded timelines, lack of peer cooperation -- it is
> > helpful to couch your comments as what I think of as "encased in third-party
> > effects".
> >
> > Don't criticize the faraway parent company or your local company office,
> > don't "gotcha" the manager, don't blindside an associate -- always "blame"
> > the system(s) only, and only with dispassionate third-party style
> > references.
> >
> > For example, say things roughly like so:
> >
> > "An under adherence to code commenting can cause decrease in access to
> > legacy knowledge base items and hard won baseline techniques."
> > or
> > "A missing backup policy that poses even minor data loss can stall any
> > project in any time frame at any facility and probably cost valuable company
> > funds."
> > or
> > "Distributed staffers experiencing communication lag -- and this can happen
> > at any fast-paced company like ours -- can derail a precision deadline
> > sometimes even by hours."
> > or
> > "Very valuable corporate monies can be lost when fast-start strategies don't
> > hold up under long term executions that demand larger perspectives and more
> > encompassing parameters."
> > or
> > "The predictable changeover of programming staff -- really any highly mobile
> > staff -- might benefit immensely from even the most schematic transferable
> > documentations that inform new team members, bringing all users up to speed
> > and saving critical company dollars as projects propel themselves more
> > effectively."
> >
> > Because no one likes to be attacked, but typically most people want to be
> > seen as fair minded, embrace this concept from the book entitled "How to
> > Deal with Difficult People". It is highly recommended that you couch
> > difficult recommendations with smoothing universal lead off comments such
> > as:  "It is fair to say...", "Likely most can agree...", "Third parties
> > might observe..."
> >
> > Warmest regards,
> >
> > Peter Sawczynec,
> > Technology Director
> > PSWebcode
> > _Design & Interface
> > _Ecommerce
> > _Database Management
> > ps at pswebcode.com
> > 718.796.1951
> > www.pswebcode.com
> >
> > -----Original Message-----
> > From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On
> > Behalf Of Ben Sgro
> > Sent: Thursday, August 17, 2006 9:51 AM
> > To: talk at lists.nyphp.org
> > Subject: [nycphp-talk] General Q; Programming Jobs & Expectations
> >
> >
> >
> > Hello all,
> >
> >
> >
> > I've been following the list now for a bit, lots of great discussion.
> >
> >
> >
> > I recently moved to NY from NH where I was doing php/mysql/c development for
> > a small start-up.
> >
> > We had very detailed specs, excellent coding styles (use of includes, small
> > modular procedures and plenty of comments).
> >
> > Software was engineered first through a specification and given at least
> > 'some' thought prior to implementation.
> >
> >
> >
> > Now, starting my new job in NY I am at a larger company that is much more
> > successful than my last. However,
> >
> > I am constantly running into files with no comments, spaghetti structure (or
> > non at all) limited includes (large amounts of duplicate code) and NO specs
> > what-so-ever on an extremely large project & database(s) with 100's of
> > stored procedures (again with no comments).
> >
> > This effects my work directly as it takes unnecessarily long to become
> > familiar with the code that is spread across multiple files and templates
> > with no comments or structure.
> >
> >
> >
> > So, my question is: Is it unreasonable of myself to have expectations of
> > 'engineered' code or is this (current job) just the way things are.
> >
> > Is it crazy to think I can change things from the bottom, by writing the
> > specs and speaking with the other programmers to reach a consensus on 'best
> > practices' and create 'grassroots' support? Should I just 'suck it up' and
> > put in my time, then move to another job?
> >
> >
> >
> > I've been consulting along with my fulltime work for about 2 years now, and
> > I believe that is what I truly enjoy, being my own boss.
> >
> > But I do need a paycheck every week, so this is not yet a viable
> > alternative.
> >
> >
> >
> > Thanks for your time, I am eager to view your responses!
> >
> >
> >
> > - Ben
> >
> >
> >
> >
> >
> >
> >
>
> > _______________________________________________
> > New York PHP Community Talk Mailing List
> > http://lists.nyphp.org/mailman/listinfo/talk
> >
> > NYPHPCon 2006 Presentations Online
> > http://www.nyphpcon.com
> >
> > Show Your Participation in New York PHP
> > http://www.nyphp.org/show_participation.php
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>