Rather than be a code monkey for either Microsoft or Google, I would suggest taking the following steps to a highly profitable software engineering career. This is so common in Silicon Valley, particularly in the chip CAD software industry, that it's practically the local pastime.
1.) Get a Master's or (preferably) a Ph.D. in computer science and/or engineering
2.) Make a tiny start-up with a handful of people (people who you'd want to have in your lifeboat if you were a passenger on the Titanic)
3.) Design a brief business plan that centers on being bought out
4.) Develop a piece of software around some interesting idea, perhaps a slightly improved placement heuristic for example
5.) Get bought out
6.) Rinse and repeat 2-6
This may seem outlandish to those not in the know, but it's actually a very common career path for many people in Silicon Valley who make more money in two or three years than the best code monkey makes in 10 years at Microsoft or Google. Importantly, rather than being escorted out of any building by security, you will be handed a check worth a small fortune to give away your start-up's IP.
Heh heh, actually they DO!:)
Those machines have _definitely_ been brutalized on more than one occassion.
I asked jeaton about this... so I've heard of some people having problems with running OpenAFS (not sure if it's performance or correct functionality issues). The Stanford LUG and a couple of other groups have mentioned some of these problems. Do you happen to know how good OpenAFS is compared to the commercial version? It seems like many major institutions/companies running AFS (with the exception of Duke, as an example) use the commercial version. I'm curious how OpenAFS and the Transarc (I guess now IBM Pittsburgh Labs) version compare.
Good point about OpenAFS. I've heard of people having some problems on the server and client side of things with OpenAFS though. Have you heard of any comparisons (performance, usability, installation, etc.) between OpenAFS and the commercial version?
seawall brought up a good point, and I thought it might be helpful to clarify succinctly the pros (+'s) and cons (-'s) of choosing either AFS or NFS. I definitely would encourage anyone interested to add to these lists because I will probably leave some things out by mistake.
AFS
+ Vice (servers) accessible only by administrators.
+ Cross-cell Kerberos authentication (in theory) allows file transactions across very diverse cells (e.g. copying a file from my Notre Dame account on/afs/nd.edu/ to my Michigan account on/afs/engin.umich.edu/).
+ Optimized callback routines lighten the load on the servers (Vice).
+ Disconnected operation extensions like CODA allow client machines to continue using accounts (in theory they are periodically cached from Vice to Venus) even when the central servers go down.
+ AFS stubs and related structures (fids, volume mappings, etc.) are optimally tuned to allow account access from client machines quickly while being somewhat fault-tolerant.
- AFS server software costs money (from Transarc), though you can get linux client software for free.
- Difficult to maintain without full-time administrators.
- Difficult to install and set up (or so I've heard).
NFS
+ Easy to install, set up, and maintain.
+ FREE.
+ Can probably find more documentation related to use/experience with NFS since more people use it (it's free after all).
+ Can also set up NFS servers that are "locked away" from the general user pool (like Vice in AFS).
- Not as fault-tolerant when you have centralized servers (NFS was originally designed to be decentralized after all).
- Not very optimized in terms of network bandwidth usage and especially server load (compared to AFS).
- May lack technical support (though I'm not sure off hand how good Transarc's support is for AFS).
- May be more difficult to set up NFS/Kerberos than AFS/Kerberos (for large-scale security).
You're absolutely right. In fact, DCO (the IT administrators for the EECS department at U. of Michigan) do exactly this. As you hinted at though, this isn't as good as using the CODA extensions to AFS, which allows disconnected operations. A few weeks back, the locked up NFS server on which my account resided on here at Michigan went down for over a week, leaving me totally unable to access my files. AFS/CODA would provide disconnected operation and is perhaps more scalable in terms of distributing physical volumes over more than one server.
The University of Notre Dame and University of Michigan both use an AFS/Kerberos set-up for large volumes of accounts.
Notre Dame offers accounts on their Solaris/SPARC machines to every student at the university. Michigan's CAEN is also an AFS/Kerberos system for the whole College of Engineering.
MIT's Athena project is pretty interesting (and also partially uses an AFS/Kerberos scheme), but it probably won't help you set up a quick public network of Linux machines since it focuses more on the research side of things (not to mention the fact that it's been actively worked on since 1983!).
In general, you will probably want to decide between an AFS/Kerberos set-up or an NFS set-up.
With AFS/Kerberos, you as the administrator would directly control a pool of servers ("Vice") which physically contain the data in every user's account. The client machines ("Venus") would get temporary "tickets" from the central Kerberos server (which you also control) to access their accounts which are stored on Vice.
In the NFS scenario, the physical location of accounts is totally decentralized and distributed across all the machines that users actually work on. This means less work for you as an administrator, but it also means less security since random users' data is actually stored on the disks of the computers in the user pool (in AFS, Vice machines are considered to be "locked in closets" to which only the administrators have physical access). It's good to remember a golden rule, "physical access to a computer always implies root access." Using a tomsrtbt disk for example, you can change the root password on just about any Linux machine with a floppy drive.
Since Vice (in the AFS scheme) computers are presumably kept behind locked doors, you avoid this type of problem. However, AFS is harder to maintain, and you probably have to pay Transarc for a commercial version.
For more info on AFS/Kerberos and NFS, I recommend surfing the ACM Digital Library, in which you can find the seminal papers on these various technologies (if you're an ACM member and have access). You may also be able to find case studies there (which I found to be surprisingly hard to find on the web).
I agree with some of the suggestions which recommend adopting a team coding standard.
However, to get started quickly I'd also recommend grabbing publicly available coding standards from successful teams who are already well-established (and modifying them as necessary for your own needs).
For example, my friends who worked on maintaining LAM (formerly the LSC at the University of Notre Dame, they are now in the CS department at Indiana University) had an excellent coding standard that included rules for commenting code ("The LSC Coding Standard"). I'm not sure if the document outlining their standard is publicly available, but you could certainly contact them (or any other successful coding teams you know of) and ask them for a copy. I haven't worked much in industry, but most of the people I know in the academic/research software development groups seem likely to be willing to share already-written documents outlining the nitty-gritties of their coding standards.
Also, for more good advice on the process of good software development, I highly recommend a book called the Pragmatic Programmer.
Slashdot Mirror
I guess this means that Apple will have to get out of the tech business and become a hedge fund.
Rather than be a code monkey for either Microsoft or Google, I would suggest taking the following steps to a highly profitable software engineering career. This is so common in Silicon Valley, particularly in the chip CAD software industry, that it's practically the local pastime.
1.) Get a Master's or (preferably) a Ph.D. in computer science and/or engineering
2.) Make a tiny start-up with a handful of people (people who you'd want to have in your lifeboat if you were a passenger on the Titanic)
3.) Design a brief business plan that centers on being bought out
4.) Develop a piece of software around some interesting idea, perhaps a slightly improved placement heuristic for example
5.) Get bought out
6.) Rinse and repeat 2-6
This may seem outlandish to those not in the know, but it's actually a very common career path for many people in Silicon Valley who make more money in two or three years than the best code monkey makes in 10 years at Microsoft or Google. Importantly, rather than being escorted out of any building by security, you will be handed a check worth a small fortune to give away your start-up's IP.
Heh heh, actually they DO! :)
Those machines have _definitely_ been brutalized on more than one occassion.
I asked jeaton about this... so I've heard of some people having problems with running OpenAFS (not sure if it's performance or correct functionality issues). The Stanford LUG and a couple of other groups have mentioned some of these problems. Do you happen to know how good OpenAFS is compared to the commercial version? It seems like many major institutions/companies running AFS (with the exception of Duke, as an example) use the commercial version. I'm curious how OpenAFS and the Transarc (I guess now IBM Pittsburgh Labs) version compare.
Good point about OpenAFS. I've heard of people having some problems on the server and client side of things with OpenAFS though. Have you heard of any comparisons (performance, usability, installation, etc.) between OpenAFS and the commercial version?
seawall brought up a good point, and I thought it might be helpful to clarify succinctly the pros (+'s) and cons (-'s) of choosing either AFS or NFS. I definitely would encourage anyone interested to add to these lists because I will probably leave some things out by mistake.
/afs/nd.edu/ to my Michigan account on /afs/engin.umich.edu/).
AFS
+ Vice (servers) accessible only by administrators.
+ Cross-cell Kerberos authentication (in theory) allows file transactions across very diverse cells (e.g. copying a file from my Notre Dame account on
+ Optimized callback routines lighten the load on the servers (Vice).
+ Disconnected operation extensions like CODA allow client machines to continue using accounts (in theory they are periodically cached from Vice to Venus) even when the central servers go down.
+ AFS stubs and related structures (fids, volume mappings, etc.) are optimally tuned to allow account access from client machines quickly while being somewhat fault-tolerant.
- AFS server software costs money (from Transarc), though you can get linux client software for free.
- Difficult to maintain without full-time administrators.
- Difficult to install and set up (or so I've heard).
NFS
+ Easy to install, set up, and maintain.
+ FREE.
+ Can probably find more documentation related to use/experience with NFS since more people use it (it's free after all).
+ Can also set up NFS servers that are "locked away" from the general user pool (like Vice in AFS).
- Not as fault-tolerant when you have centralized servers (NFS was originally designed to be decentralized after all).
- Not very optimized in terms of network bandwidth usage and especially server load (compared to AFS).
- May lack technical support (though I'm not sure off hand how good Transarc's support is for AFS).
- May be more difficult to set up NFS/Kerberos than AFS/Kerberos (for large-scale security).
You're absolutely right. In fact, DCO (the IT administrators for the EECS department at U. of Michigan) do exactly this. As you hinted at though, this isn't as good as using the CODA extensions to AFS, which allows disconnected operations. A few weeks back, the locked up NFS server on which my account resided on here at Michigan went down for over a week, leaving me totally unable to access my files. AFS/CODA would provide disconnected operation and is perhaps more scalable in terms of distributing physical volumes over more than one server.
The University of Notre Dame and University of Michigan both use an AFS/Kerberos set-up for large volumes of accounts.
Notre Dame offers accounts on their Solaris/SPARC machines to every student at the university. Michigan's CAEN is also an AFS/Kerberos system for the whole College of Engineering.
MIT's Athena project is pretty interesting (and also partially uses an AFS/Kerberos scheme), but it probably won't help you set up a quick public network of Linux machines since it focuses more on the research side of things (not to mention the fact that it's been actively worked on since 1983!).
In general, you will probably want to decide between an AFS/Kerberos set-up or an NFS set-up.
With AFS/Kerberos, you as the administrator would directly control a pool of servers ("Vice") which physically contain the data in every user's account. The client machines ("Venus") would get temporary "tickets" from the central Kerberos server (which you also control) to access their accounts which are stored on Vice.
In the NFS scenario, the physical location of accounts is totally decentralized and distributed across all the machines that users actually work on. This means less work for you as an administrator, but it also means less security since random users' data is actually stored on the disks of the computers in the user pool (in AFS, Vice machines are considered to be "locked in closets" to which only the administrators have physical access). It's good to remember a golden rule, "physical access to a computer always implies root access." Using a tomsrtbt disk for example, you can change the root password on just about any Linux machine with a floppy drive.
Since Vice (in the AFS scheme) computers are presumably kept behind locked doors, you avoid this type of problem. However, AFS is harder to maintain, and you probably have to pay Transarc for a commercial version.
For more info on AFS/Kerberos and NFS, I recommend surfing the ACM Digital Library, in which you can find the seminal papers on these various technologies (if you're an ACM member and have access). You may also be able to find case studies there (which I found to be surprisingly hard to find on the web).
I agree with some of the suggestions which recommend adopting a team coding standard. However, to get started quickly I'd also recommend grabbing publicly available coding standards from successful teams who are already well-established (and modifying them as necessary for your own needs). For example, my friends who worked on maintaining LAM (formerly the LSC at the University of Notre Dame, they are now in the CS department at Indiana University) had an excellent coding standard that included rules for commenting code ("The LSC Coding Standard"). I'm not sure if the document outlining their standard is publicly available, but you could certainly contact them (or any other successful coding teams you know of) and ask them for a copy. I haven't worked much in industry, but most of the people I know in the academic/research software development groups seem likely to be willing to share already-written documents outlining the nitty-gritties of their coding standards. Also, for more good advice on the process of good software development, I highly recommend a book called the Pragmatic Programmer.