if I may chime in -

It is the nature of the corporate-beast which has changed.

When I was starting out in the 80's and even through the early 90's network eng 
and sys eng went hand in hand.

Today it is far more silo'd. NetEng, SysEng are very *distinct* and as a result 
different groups today from an operational standpoint.

NetEng deals with tcp/ip(without having a clue as to how apps interact with 
tcp/ip (generally speaking!!) and the opposite applies to SysEng(once again, 
generally speaking!)

 So, programmers with network engineering skills and vise-versa are a 
rare-commodity to say the least.

I don't think it has anything to do with who is *inherently* interested in 
network eng or sys eng.

In the end:
upto the "$Employer". Know what you are *really* looking for, give them the 
opportunity to expand their horizons and you will have found your-network 
engineer/programmer(you will still find people who are willing to learn - that 
is you greatest asset!!)

( I used to script, write; maybe a few lines of C many many years ago....as a 
Sr. Network Engineer. Haven't done that for years because $employer doesn't 
want it as a part of my job: and to $employer, I The "Sr. Network 
Architect".....<lol>

My 02c's worth wrt this thread.

./Randy

--- On Mon, 3/5/12, Alain Hebert <aheb...@pubnix.net> wrote:

> From: Alain Hebert <aheb...@pubnix.net>
> Subject: Re: Programmers with network engineering skills
> To: nanog@nanog.org
> Date: Monday, March 5, 2012, 7:18 PM
>      About (5
> thru 6)
> 
>      Hard to keep a straight face in
> front of a customer when, after 
> assigning him a IP in our 192.172.250.0 range...
> 
>      ... He ask why are we NATing using
> private IP's.
> 
>      We also had plenty of experience
> with ppl getting confused about 
> 16, 17.
> 
>      Your could add L2 Trunking and VRRP
> to your list...  I spent many 
> hours explaining those to no avail on many occasion.
> 
>      Sad.
> 
> -----
> Alain Hebert             
>                
>   aheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770     Beaconsfield,
> Quebec     H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.net    Fax:
> 514-990-9443
> 
> 
> On 03/05/12 21:36, Jimmy Hess wrote:
> > On Mon, Mar 5, 2012 at 6:09 PM, Justin M. Streiner
> > <strei...@cluebyfour.org> 
> wrote:
> >
> >> Admittedly we (the 'network guys') don't always
> make it easy for them. RFCs
> >> get obsoleted by newer RFCs, but the newer RFCs
> might still reference items
> >> from the original RFC, etc.  This can turn
> into developing for something
> > Yes, this is problematic.    The preferred
> result should be one specification
> > for each protocol,   with references
> only for optional extensions.
> >
> >> Other common, but misguided assumptions (even in
> 2012):
> >> 1. You will be using IPv4.  We have no idea
> what this IPv6 nonsense is.
> >> Looks complicated and scary.
> >> 2. 255.255.255.0 is the only valid netmask.
> >> 3. You are using Internet Explorer, and our web
> management interface has
> >> ActiveX controls that require you to do so.
> >> 4. You will be assimilated.  Resistance is
> futile.
> > Add some additional misguided assumptions:
> >
> >     (5)  Any IP address whose
> first octet is 192.  or  1.  is a private
> IP.
> >     (6)  Any IP address whose
> first octet is not 192.  is not a valid LAN IP.
> >     (7)  Any IP address whose
> last octet is .0  is an invalid IP host address
> >     (8)  Any IP address whose
> last octet is .255 is an invalid IP host address
> >
> >     (9)  If my DNS service
> supports DNSSEC validation, even with no trust anchors
> >       
>    configured,  it's cool to go ahead
> and send all queries with
> > the CD and DO bits
> >           set to 1
> >           and
> perform no validation;  it's even cooler if I only
> > support SHA1 keys and
> >           no
> RSA/SHA-256.
> >
> >    (10)  Everyone enters their
> NTP,  and AD servers by IP address, so it
> >           is best
> to  have a textbox that only allows IPs,  not
> hostnames.
> >
> >    (11)  Nobody actually uses SRV
> records, so don't bother looking for them.
> >
> >    (12)  Once a DNS lookup has been
> performed, the IP never changes, so
> > it makes sense
> >           to keep
> this in memory  until we reboot.
> >
> >    (13)  Nobody has more than 1
> recursive DNS server,  1 NTP server, 1
> > LDAP server,
> >           1 Syslog
> server,  and  1 Snmp management station;
> >           so a
> single IP entry text box  for each will suffice.
> >
> >    (14)  Nobody has more than 2
> recursive DNS servers, so just allow
> > only 2 to be entered.
> >
> >    (15) 30 seconds per resolver seems like a
> good timeout for DNS queries, so no
> >          need for a
> configurable timeout;  just  try each server
> > sequentially, make the
> >          UI hang, the user
> will be happy to wait 5 minutes;  also make
> > the service
> >          provided by the
> device temporarily stop --   users likes it
> > when their devices
> >          stop working, to
> remind them to get their first DNS server back up.
> >
> >     (16)  The default
> gateway's IP address is always 192.168.0.1
> >     (17) The user portion of E-mail
> addresses never contain special
> > characters like  "-" "+" 
> "$"   "~"  "."  ",", "[", 
> "]"
> >
> >
> >
> >> jms
> > --
> > -JH
> >
> >
> 
>

Reply via email to