I used to joke with colleagues of mine at a former employer, saying "it's not a job, it's a lifestyle." I was on-call all the time. Really. The only time I wasn't on-call was during my honeymoon and we had made special arrangements to have coverage. I'd work from home more evenings than not. I'd answer email at 6am and 11pm (without a blackberry!). On the flip side, I'd also take a two hour class in the middle of the day with my boss's permission. I'd occasionally teach an undergrad CS course.
Things weren't always this way. Early in my career, as a SunOS Unix & IP/Ethernet network admin, my day started when I arrived at work at 7am and ended when I left at 3:30p. There were very clear lines of when I was and wasn't working. One day per month, I would work a 7 hour shift on a Saturday during which time I'd do patches and "invasive" upgrades. I would get a "comp day" for that day. I purposely avoided having a home computer (I was a Unix snob and having to work with a DOS-based PC over a 24000 bps modem seemed unimaginable to me).
The new lifestyle actually fit me okay. And, surprisingly, I didn't resent it. I felt useful, reasonably compensated and clever. Since I was working at a hospital, I rationalized that if the doctors weren't too good to be on-call than neither was I. Managing your own time in an environment where the lines between work and non-work time are all but erased is one thing -- managing the time of others is much more difficult.
There are many kinds of employees with varying work ethics. Over the last 16 years, I've seen all kinds of people.
- There are balanced, salaried (exempt) people. They'll get the job done intelligently, work whenever is necessary to get the job done, occasionally take off during the day to run an errand and always be ready to handle and emergency.
- There are the work-beaten people. I've supervised at least two *very* intelligent hard-working people who would probably worked themselves to death if someone didn't stop them. One of them, discharged himself from a surgical procedure early so that he could be available for a planned change. These folks are heroic but need balanced supervision or they'll burn themsevles out.
- I worked with a couple of people that were *very* hard working but didn't have the technical skill of their peers. I have mixed feelings about how to handle those employees -- people that are trying very hard but not as productive as others.
- There are the salaried "I work 40 hours per week" group. They're willing to put extra hours in but are constantly keeping a tally in their heads of how much time is owed to them.
- For hourly employees, the management of this "lifestyle" is very difficult. They are compensated based on the time they put in. You can't legally have them adopt interlaced model. But we have employees and employers who *want* to do that. I'm currently working with my HR on finding ways to do so (perhaps it just involves a lot of clocking-in/clocking-out).
The reality is that our work and non-work lives are becoming integrated. We check work email from home and we go on Amazon from work. Some employers have tried to discourage this. For "thinking" jobs, I think is a good thing. Supervisors need to be sure that they're getting out of their employees what is reasonable while not burning them out; employees need to be careful as well; they need be sure that they don't either burn themselves out or cheat the employer out of work owed.
New assays such as so-called "next generation sequencing" technologies will increase the storage requirements of some biomedical researchers but orders of magnitude. This exponential growth of storage requirements is likely to out-pace the downward price-performance curve of storage. We must consider new models for the long-term storage of huge research data sets.
There has been a great deal of hype surrounding "utility computing" (also known as "Cloud Computing") recently. The basic premise of cloud computing is that a consumer of services purchases their services (computational cycles, space on hard drives, etc.) from a utility-like service provider in much the same way that one might purchase electricity or water. There are many issues that we must address to consider if this new technology makes sense for Penn State investigators, specifically:
1. Security: can we put data "into the cloud" and be confident that it remains under our control?
2. Reliability: how reliable is our access to data in the cloud?
3. Who: who would we purchase services from? Is Penn State big enough to be a cost-effective cloud provider on its own?
4. Ownership: Who owns the data once it's in the cloud? Are we willing to receive advertisements that are created as a result of scanning our data?
5. Performance: Is our network infrastructure (particularly to the Internet or the cloud computer provider) sufficiently robust such that we don't suffer undo performance hardships?
I'm happy to say that the Cancer Institute building is now open. There haven't been any significant technical problems. The bits are flowing on the network, the VoIP phones are working and the applications appear to correctly functioning. In two weeks, clinical operations move into the new building and in four weeks, 95% of the move activities will have concluded. It's probably too early for back-patting but I've been incredibly impressed with my IT colleagues during this effort. They should be pround of what they've accomplished.
So now my thoughts turn to the big research grant efforts in front of us. The CTSA and CCSG applications are being written simultaneously and I've got a significant role in both. Since this is public forum, I won't divulge much here but these grant applications are likely to take up most of my time this summer. As the core director fo the bioinformatics core, I've begun work on the core's narrative for the CCSG application.
I also continue to think about how we can inject more strategy into what we do. There are certain institutional barriers that push us into operational rather than strategic thinking. I plan to highlight these on my next Research Computing strategic plan (which I plan to complete by the end of the summer).
So now my thoughts turn to the big research grant efforts in front of us. The CTSA and CCSG applications are being written simultaneously and I've got a significant role in both. Since this is public forum, I won't divulge much here but these grant applications are likely to take up most of my time this summer. As the core director fo the bioinformatics core, I've begun work on the core's narrative for the CCSG application.
I also continue to think about how we can inject more strategy into what we do. There are certain institutional barriers that push us into operational rather than strategic thinking. I plan to highlight these on my next Research Computing strategic plan (which I plan to complete by the end of the summer).
One of the biggest challenges that we face at Penn State is the geographic diversity of our biomedical research faculty. The PSU-Hershey campus not only consists of a large hospital but also most of the clinical, clinical research and man of the basic biomedical research faculty. We at Penn State go out of our way to bridge the 100 mile gap between University Park and Hershey by having twice-daily shuttle service and a lot of video conferencing. However, the video conferencing is usually (still) based on H.323/H.320 and is usually not quite NTSC quality. This is frustrating for the person who is the only person not in the room (I speak from experience). High-definition video conferencing is slowly making it's way into PSU but it'll be years before enough equipment gets replaced so that it's common place.
An alternative that's been investigated by ITS and others is Cisco telepresence. It's very cool but still very pricee. It requires that a room be devoted to the predetermined furniture which limits its flexibility. It also requires that the other end have the same set up. This is probably not going to work in the short-term.
Another option is the AccessGrid. AccessGrid is very cool but it's got some of the same problems as Cisco's telepresence. It also requires IP multicasting to be enabled which is difficult in our heavily firewalled/proxied Hershey campus.
Breeze/Adobe Connect is good but only if everyone participating is sitting at their desk. If one end is 10 people in conference room and the other end is one person, Breeze just isn't a good experience for the singleton person.
My group has been looking at Skype. A few months ago, Skype introduced high definition video to their free P2P communications application (not fair to call it *just* VoIP). If you have the right camera and processors on both ends, the video is extremely impressive. I've been using a Logitech Pro 9000 with dual-core 2.333 Ghz machine and the video is very impressive. I had an idea that for meetings where there's a "lone man out" -- which is a significant percentage of our televideo conferences -- we could use Skype with a laptop and place that person at the table. This would require little if any set up, no room specialization, etc. Skype is also extensible so the remote person could (if we or someone else developed it) pan their camera towards the speaker (you could also see if following voice volumes, etc). I think this would really approximate "teleprescence" with the added flexibility.
The next step (which I don't think anyone has yet) is to have a solid virtual window. We've discussed having this with two labs -- one here, one at University Park -- where people interact everyday. The window would always be on and looking into the "window" you'd see th e other lab and they'd see you. One of the challenges with this is that cameras are often offset from where the picture is being viewed. So even though I'm looking you in the eyes you may see the top of my head. What we need is a monitor with not only emitting pixels but receiving pixels. After doing a little bit of research, we found that Apple has a patent on such an idea -- not sure if they're going to bring it to market or not. This seems like a logical next step though.
An alternative that's been investigated by ITS and others is Cisco telepresence. It's very cool but still very pricee. It requires that a room be devoted to the predetermined furniture which limits its flexibility. It also requires that the other end have the same set up. This is probably not going to work in the short-term.
Another option is the AccessGrid. AccessGrid is very cool but it's got some of the same problems as Cisco's telepresence. It also requires IP multicasting to be enabled which is difficult in our heavily firewalled/proxied Hershey campus.
Breeze/Adobe Connect is good but only if everyone participating is sitting at their desk. If one end is 10 people in conference room and the other end is one person, Breeze just isn't a good experience for the singleton person.
My group has been looking at Skype. A few months ago, Skype introduced high definition video to their free P2P communications application (not fair to call it *just* VoIP). If you have the right camera and processors on both ends, the video is extremely impressive. I've been using a Logitech Pro 9000 with dual-core 2.333 Ghz machine and the video is very impressive. I had an idea that for meetings where there's a "lone man out" -- which is a significant percentage of our televideo conferences -- we could use Skype with a laptop and place that person at the table. This would require little if any set up, no room specialization, etc. Skype is also extensible so the remote person could (if we or someone else developed it) pan their camera towards the speaker (you could also see if following voice volumes, etc). I think this would really approximate "teleprescence" with the added flexibility.
The next step (which I don't think anyone has yet) is to have a solid virtual window. We've discussed having this with two labs -- one here, one at University Park -- where people interact everyday. The window would always be on and looking into the "window" you'd see th e other lab and they'd see you. One of the challenges with this is that cameras are often offset from where the picture is being viewed. So even though I'm looking you in the eyes you may see the top of my head. What we need is a monitor with not only emitting pixels but receiving pixels. After doing a little bit of research, we found that Apple has a patent on such an idea -- not sure if they're going to bring it to market or not. This seems like a logical next step though.
So, it's been about a year now that I've been coaching/leading a technology club for the 2nd-4th grade set at my kids' school.
Here's what I've learned:
1- boys like making bloody video games; it seems that any video game that we develop will ultimately include blood even if it's completely unrelated to the subject matter (e.g. Pong); the girls in the group are more likely to make "cute" video games.
2- don't expect kids to program in a language that requires a lot of typing. yes, I realize that for most people, this is probably a no-brainer. But not for me!!! having them program in C didn't work out well for a number of reasons. The work took too long (particularly the typing), the results weren't flashy enough (printf'ing "hello world" is just not satisfying for these kids).
3- interestingly, some of the kids that work remarkably well individually don't work well when they're all in a group (and vice-versa).
4- Scratch (scratch.mit.edu) is absolutely a great tool for beginning programmers. It's free, it's fairly easy to use and learn and requires almost no typing.
5- Lego robots are fun but the work/reward cycle may be too long for this age group. I think if I do this again, I'm going to have some pre-built robots and then they can just do the programming.
Here's what I've learned:
1- boys like making bloody video games; it seems that any video game that we develop will ultimately include blood even if it's completely unrelated to the subject matter (e.g. Pong); the girls in the group are more likely to make "cute" video games.
2- don't expect kids to program in a language that requires a lot of typing. yes, I realize that for most people, this is probably a no-brainer. But not for me!!! having them program in C didn't work out well for a number of reasons. The work took too long (particularly the typing), the results weren't flashy enough (printf'ing "hello world" is just not satisfying for these kids).
3- interestingly, some of the kids that work remarkably well individually don't work well when they're all in a group (and vice-versa).
4- Scratch (scratch.mit.edu) is absolutely a great tool for beginning programmers. It's free, it's fairly easy to use and learn and requires almost no typing.
5- Lego robots are fun but the work/reward cycle may be too long for this age group. I think if I do this again, I'm going to have some pre-built robots and then they can just do the programming.
At the Hershey campus, we've been engaging in a project (is it organized enough to call it a project?) to more formally codify our IT architecture. By architecture, we mean standards. We're doing this because -
a) this is an increasingly complicated ship to steer
b) we would like to minimize our technology footprint so that we can keep the skillsets required to steer the ship minimized
c) we'd like to be clear with vendors and developers about the best or most preferred method of accomplishing a task
This is a complex task. It's not clear how much detail we need to record or how parental we should be. Some things are intuitively obvious (at least in my opinion), e.g.
1- we should standardize on one software development platform
2- we should standardize on one layer three network protocol
but even these, relatively simple things are fraught with questions..
For the "software development" platform -- how often do we consider changing it? do we have more than one? what constitutes software development to start with? here's a real-world example. Several of my staff are Java developers and we're about to develop a new application. My developer says "i could develop it in Java but I could do it in PHP with a Cake framework in 1/5 the time." It's difficult (possibly ridiculous) for me to say no to the PHP route.
So, how do you build a process that is both flexible but seeks to minimize the variety of technical solutions? How do you minimize costs both from a development perspective and a staff breadth perspective?
a) this is an increasingly complicated ship to steer
b) we would like to minimize our technology footprint so that we can keep the skillsets required to steer the ship minimized
c) we'd like to be clear with vendors and developers about the best or most preferred method of accomplishing a task
This is a complex task. It's not clear how much detail we need to record or how parental we should be. Some things are intuitively obvious (at least in my opinion), e.g.
1- we should standardize on one software development platform
2- we should standardize on one layer three network protocol
but even these, relatively simple things are fraught with questions..
For the "software development" platform -- how often do we consider changing it? do we have more than one? what constitutes software development to start with? here's a real-world example. Several of my staff are Java developers and we're about to develop a new application. My developer says "i could develop it in Java but I could do it in PHP with a Cake framework in 1/5 the time." It's difficult (possibly ridiculous) for me to say no to the PHP route.
So, how do you build a process that is both flexible but seeks to minimize the variety of technical solutions? How do you minimize costs both from a development perspective and a staff breadth perspective?
I had a friend visit a few months ago from California. She and I were both sys/net admins at another university what seems like a lifetime ago. She told me that she's getting out of IT because it's "not fun anymore." It's been a while since I've done day-to-day technical engineering. But I think I understand her point.
Then: Reboot the system whenever you need to so long as you give the users a few minutes to save their work.
Now: Subject reboot scheduled several weeks in advance to change control committee. Notify users about potential 30 second outage. Negotiate time for outage.
Commentary: We've probably gone in the right direction with this one. Before being a sys admin, I *was* a user and used to dread it when they'd reboot things while I was in the middle of something...particularly if the system didn't come right back.
Then: System is slow. Run 'ps auxww' to see if there's anything obviously running amuck. Look at vmstat, iostat, netstat, etc. Use 'ofiles' (now lsof) to determine open TCP ports. Strace certain executables and find where unnecessary 'malloc's are occuring and re-write program to fix leakage.
Now: System is slow. Buy another system. Schedule replacement through change control.
Commentary: okay, i'm not being completely fair here. Smart sys admins still do some analysis to see what's running. But few actually modify the software that's running on the system. And vendors are very quick to recommend upgrading the CPU, memory, etc. without doing any analysis what-soever to determine the actual bottleneck. That really bugs me.
Then: User ran out of quota space and complains. You either gave the user more space or told them to prune their giant mbox.
Now: User is potentially going to be named in a lawsuit. Preserve their email until lawsuit is complete or no longer probable.
Commentary: See below.
Then: User is downloading eight simultaneous streams of porn from Finland. Email user telling him (most likely a "him") not to hog resources. Refer him to the nice(1) man page.
Now: User is downloading movies and you are notified by MPAA. Notify security, HR, user's supervisor, etc. User is escorted out promptly. Put him on academic suspension.
Commentary: (for this and the above one) Sys admins have becoming increasingly like police and lawyers. You need to understand how long to hold onto logs, what are the "rules" of usage and what are the HR rules.
My point in saying all this and to expand on my friend's sentiment is that system/network admins used to be an 80% technical and 20% administrative job. The ratio has changed significantly towards the administrative side. Sys admins have become more and more like accountants (having to no rules and regs) and less like engineers (having to understand the underlying technology).
Then: Reboot the system whenever you need to so long as you give the users a few minutes to save their work.
Now: Subject reboot scheduled several weeks in advance to change control committee. Notify users about potential 30 second outage. Negotiate time for outage.
Commentary: We've probably gone in the right direction with this one. Before being a sys admin, I *was* a user and used to dread it when they'd reboot things while I was in the middle of something...particularly if the system didn't come right back.
Then: System is slow. Run 'ps auxww' to see if there's anything obviously running amuck. Look at vmstat, iostat, netstat, etc. Use 'ofiles' (now lsof) to determine open TCP ports. Strace certain executables and find where unnecessary 'malloc's are occuring and re-write program to fix leakage.
Now: System is slow. Buy another system. Schedule replacement through change control.
Commentary: okay, i'm not being completely fair here. Smart sys admins still do some analysis to see what's running. But few actually modify the software that's running on the system. And vendors are very quick to recommend upgrading the CPU, memory, etc. without doing any analysis what-soever to determine the actual bottleneck. That really bugs me.
Then: User ran out of quota space and complains. You either gave the user more space or told them to prune their giant mbox.
Now: User is potentially going to be named in a lawsuit. Preserve their email until lawsuit is complete or no longer probable.
Commentary: See below.
Then: User is downloading eight simultaneous streams of porn from Finland. Email user telling him (most likely a "him") not to hog resources. Refer him to the nice(1) man page.
Now: User is downloading movies and you are notified by MPAA. Notify security, HR, user's supervisor, etc. User is escorted out promptly. Put him on academic suspension.
Commentary: (for this and the above one) Sys admins have becoming increasingly like police and lawyers. You need to understand how long to hold onto logs, what are the "rules" of usage and what are the HR rules.
My point in saying all this and to expand on my friend's sentiment is that system/network admins used to be an 80% technical and 20% administrative job. The ratio has changed significantly towards the administrative side. Sys admins have become more and more like accountants (having to no rules and regs) and less like engineers (having to understand the underlying technology).
As you've probably read recently, the new administration will shortly be asking congress to pass another stimulus bill. I say another -- the TARP bill is probably better described as a "banking stabilization bill" for it really didn't introduce new money into the economy. But I digress (for those econ people out there -- do they publish the levels of M1 & M2?)
Part of the new stimulus proposal (and this was included in the president's inaugural speech) calls for a significant (~$20B) to be spent on health information technology. The recurring idea here is that by employing electronic health methods we'll be able to gain significant savings in workflow (and potentially in the analytics that we could then use after we have all of the data). There are examples of purely electronic records already that have had their share of benefits (Vista (not to be confused with Windows Vista) at the VA for example).
Penn State is well positioned to take a leadership role in HIT. Why do I say this:
- we have a famously well-implemented in-patient electronic medical record that has demonstrated real return on investment as well as benefit for our patients (based on most measures, our electronic medical record implementation is in the top 5% of the country)
- we have a data mining team that is able to ask questions of our clinical data warehouse
- we are recording basic research data that will position us to see not just patterns in care but also things like genome wide associations (we potentially have data about genes and phenotypes)
- we have forged a strongly alliance with one of the most prolific EMR vendors in the world
- we have strong academic programs in applied health informatics (e.g. IST); we will be graduating the students that will be in more demand in this field.
I'm excited about the opportunities ahead of us and how we will contribute to the future economic efficiencies in the US.
Part of the new stimulus proposal (and this was included in the president's inaugural speech) calls for a significant (~$20B) to be spent on health information technology. The recurring idea here is that by employing electronic health methods we'll be able to gain significant savings in workflow (and potentially in the analytics that we could then use after we have all of the data). There are examples of purely electronic records already that have had their share of benefits (Vista (not to be confused with Windows Vista) at the VA for example).
Penn State is well positioned to take a leadership role in HIT. Why do I say this:
- we have a famously well-implemented in-patient electronic medical record that has demonstrated real return on investment as well as benefit for our patients (based on most measures, our electronic medical record implementation is in the top 5% of the country)
- we have a data mining team that is able to ask questions of our clinical data warehouse
- we are recording basic research data that will position us to see not just patterns in care but also things like genome wide associations (we potentially have data about genes and phenotypes)
- we have forged a strongly alliance with one of the most prolific EMR vendors in the world
- we have strong academic programs in applied health informatics (e.g. IST); we will be graduating the students that will be in more demand in this field.
I'm excited about the opportunities ahead of us and how we will contribute to the future economic efficiencies in the US.
We are five months away from the opening of the Penn State Hershey Cancer Institute. This is a wonderful building that will combine much of our cancer research and clinical care under one roof. Everyday when researchers come to work, they'll pass patients as they walk in. As an employee this is very powerful -- the constant reminder of why you come to work everyday. Even though, as a non-direct patient care giver, most patients are anonymous to me -- I often easily visualize them as being my wife, my kids or myself.
I've been working in cancer for a long time now. I took a brief leave in 1999 when I opted for more money and less stress. I found the new job to lack personal fulfillment. I found myself thinking "if I had $X that they're spending on this silly project -- imagine all the good I could do with that back at my cancer institute." This all sounds corny but it's true -- I ultimately (and quite voluntarily) left the "new" job and returned to my cancer center job for a 30% salary decrease. So -- for those of you looking for careers -- make sure that you evaluate more than just the salary.
I've been working in cancer for a long time now. I took a brief leave in 1999 when I opted for more money and less stress. I found the new job to lack personal fulfillment. I found myself thinking "if I had $X that they're spending on this silly project -- imagine all the good I could do with that back at my cancer institute." This all sounds corny but it's true -- I ultimately (and quite voluntarily) left the "new" job and returned to my cancer center job for a 30% salary decrease. So -- for those of you looking for careers -- make sure that you evaluate more than just the salary.
Not wishing to start a flame war of any kind, I have to ask -- why do people still use LaTeX? I've noticed that many people still use LaTeX. I used to use LaTeX and I still edit code in emacs but I usually use OpenOffice or MS Word for word processing. They both have reasonable equation editors.
Is there some advantage to LaTeX?
Is there some advantage to LaTeX?
