NYCPHP Meetup

[Kenneth Downs]

inforequest wrote:
>> There are also complex political issues that serve to insulate decision
>> makers from the consequences of bad decisions.  An CTO cannot complain
>> that the vendor is handing him garbage because he'll lose his job for
>> picking the vendor.  The vendor has to protect the CTO by at very least
>> taking care of whatever issue may get him fired that day, and screw the
>> rest of it. It works great if you are at a VP level or higher, but for everyone else
>> its hell.
>>  
>>
>>     
> Well said.  And that came about not by design, but via evolution. In 
> order to survive, those managers developed that system of insulating 
> decisions and spreading accountability. What have the programmers 
> evolved in order to survive? Sometimes it seems like  dark rooms, and 
> poor social habits to keep the managers out of their caves. 
> Unfortunately that only increases the pressure to keep up, and further 
> helps commoditize the programmer's job (we never see him ayway, so why 
> not outsource overseas?).
>   
And well said as well.  In addition to your advice below I would add 
this, watch what the company is doing very carefully so that you can 
adopt these practices when you go out on your own.

What separated my employers from me, the reason I worked for them and 
not the other way around, was that the top guys were all salesmen of one 
stripe or another.  I realized that if I did not embrace sales I would 
not move out of where I was.  There were others, but the idea is to keep 
your eyes open, because if they are paying you then they must know 
something you don't, and there's no reason not to learn while you earn.
> Do your job and do it well and make sure you stay involved outside (like 
> NYPHP) and move alot and eventually you earn your rep and can choose 
> where to work. That seems to be the way. I definitely have not seen any 
> success evangelizing within the profitable corporation you describe, as 
> all you will be doing in the eyes of non-programmers is making waves and 
> increasing costs. Make sure that when there is an attack, it wasn't on 
> your code, and when they audit, your code comes clean. Anytime you find 
> you cannot do a proper job (time constraints, etc) find a way to 
> externalize the decision to leave it insecure... commonly known as 
> passing the buck/creating a paper trail. There's nothing wrong with 
> allowing the organization to make a decision that is not optimal from 
> any one perspective -- I think that is the definition of a compromise.
>
> -=john
>
>
>
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20060818/f4f20a1d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.vcf
Type: text/x-vcard
Size: 186 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20060818/f4f20a1d/attachment.vcf>