I thought it was pretty interesting to see that Linus was focusing on power + silence. Made me interested in picking up some quieter fans for my PC.
516 karma · joined December 12, 2012
It's too hard to rely on convention to communicate details across an org, especially when using 'this' is what your devs default to (perhaps a relic from their Java days in school).
[1] https://www.ctrl.blog/entry/google-podcasts-data-portability...
The Simons Center for Geometry and Physics has an art gallery and an associated lecture series, and James often shows up to participate in these events. Luckily, these events are free to enter for all graduate students. At one of these events, I'd commented that a particular piece reminded me of a crystalline structure I was interested in studying (as a li-ion cathode). James overheard me and came over to quiz me on some of my group's work. About 8 months later, I ran into him at another lecture. While he didn't remember my name, he asked how my hollandite simulations had turned out.
This anecdote doesn't really prove anything, other than that Dr Simons is a pretty cool dude.
https://en.wikipedia.org/wiki/2018_Atlanta_cyberattack https://en.wikipedia.org/wiki/2019_Baltimore_ransomware_atta...
Especially since we're still suffering from it. There are enough project & program managers who see the words "open source" on an engineering document & send us back to build or buy some alternative.
That said, other than a handful of coworkers who I'm friends with outside of work, only my manager & HR have my personal number. This adds an extra step where the coworker should determine if getting in touch with me immediately is actually worth the effort.
So far, I've received one such phone call in 3 years. It was an actual emergency, and easily resolved by me at that time because they called me. If they had waited until the next working day, the issue would have blown up and taken much more effort for me to resolve.
This might alternatively be an argument for working with people who respect your time.
And a surprising number of people who haven't had to work in open offices before think "Oh, that'll be cool: social, innovative, and collaborative!"
I'd take 60% per hour for overtime in a heartbeat as long as it was optional, since I've always ended up doing that kind of work for client/manager goodwill (or the pleasure of not being fired).
I'm now at another large university-affiliated research lab and excel is king here as well, though I can get away with using Matlab generated plots in my slides when I'm working solo. People still don't like python for some reason.
I had a similar experience with paper writing-- in academics it was conventional to do everything in LaTeX from my first lab courses in freshman year. In both workplaces, we've just been using word.
And it's not that people don't know python/latex here-- we've just apparently developed a culture of using these matlab/excel/word tools instead.
Though theory groups in general tend to use computational simulations as a tool to complete calculations, groups that develop novel computational methods and techniques tend to be headed by younger, more junior professors. These groups are typically well-funded and do very exciting (trendy? cutting edge?) work with distributed computation, machine learning, neural networks, etc, so they tend to pull quite a few students.
While these computational groups tend to bring in funding and are well-staffed by excited grad students, the junior professors leading them tend to be marginalized by the more traditional, seniority-focused establishment. Which is to say, a new PhD might have a lot of trouble landing a prestigious postdoc because a) their adviser might have been too young to have high name recognition outside their field and b) departments might place limits the amount of staff for these more junior professors/young groups doing exciting computational work. This is, of course, on top of the overall scarcity of jobs in academia.
But there's no such job scarcity in industry-- especially not for stats-smart programmers with years of experience a) wrangling data in python, b) writing fortran that runs on distributed clusters, or c) designing algorithms to solve /approximate hilariously expensive problems. Advisers know this and point some of their students who might thrive more in industry than academia towards that route.
(Anecdote: And of course, as a physicist who builds models/simulations in industry, I can speak a personally a little re: thriving. If you're someone in love with solving disparate problems, you're unlikely to find that in academia. Some of us learn in graduate school that we can't spend our whole lives-- or in my case, more than a few months-- solving one problem. Academia just... didn't seem like something that would be worth fighting for.)
I assume that this will gradually change as there's turnover within physics departments and we get more computational-first professors with seniority (or even in leadership). There are a few departments with better-known professors you can see it happening now. Universities are spinning up incubators and institutes for computational research. Physics departments are just slower to adapt to new developments, and the hierarchy of theorists can have more to do with seniority and internal politics than it does with technology.
- Compilers with even more powerful implicit behavior- forget automatically creating Get() and Set(), we'll be creating entire inheritance structures with one function definition.