I'd not been on one of these before and felt privileged to join Patrick in a night of hounding around inside some of the less open bastions (lots of security) in Portland's downtown: Puppet, Aruba Networks, Mirador, Cloud Compass, iovation, New Relic. These were the ones we got to, plus many more were participating.
We also dropped in on The Tech Academy, given we've both served as Python mentors for the O'Reilly School of Technology. OST has closed. I kept some of its DNA in a test tube (not literally) in the form of OCT / RU, a Flickr album of little diagrams and such, along with souvenir business cards. None of our proprietary software leaked out. That would all need rewriting, and would reflect lessons learned, no need for carbon copies anyway.
However, I digress. What I was seeing were prototypical work spaces offering the kinds of roles those who study computer science and engineering hope to get for themselves. Ample kitchens, friendly people, handsome facilities, right downtown.
What more could one hope for? We don't have Cubby Camps yet, with people doing more async out in nature. The corporate cube farm has evolved considerably, but still loves a good 30th floor view, more of the mountains than from the mountains.
In taking pictures of the Puppet library (on display in the foyer), I didn't come across many Python titles. Ruby looks to be making more inroads there. Tech Academy did have a Python course. Mirador is more a Java shop.
We see different levels in people's willingness to be polyglot. I'll venture into Clojure, which I admire, while coding something I've coded before in other languages, such as Quadrays, a system of 4-tuple vectors mapping the same space as XYZ but with four positive rays to the corners of a tetrahedron, old hat to my long time readers, check Wikipedia.
Why would anyone use that? In philosophy class maybe, to introduce "language games" in mathematics, but where else? Do any architects learn about A, B, T, E, S modules these days? How about art school students?
These are not core questions pondered within the business sector downtown I don't think (not "CBD questions" -- except maybe at PSU, or University of Portland, in some study carrel somewhere, where following Wittgenstein links makes more sense). I've taught the basics of "Martian Math" on both campuses, at one time or another, as well as at Reed and OGI, using Python mostly. CBD = Central Business District; OGI = Oregon Graduate Institute.
In other words (back to "polyglot"), suggesting people "language hop" as if that were some trivial jump, is often unrealistic, any more than an English speaker might simply "hop" to Japanese or vice versa.
There's not much truth in the slogan "learn one computer language, and you've learned them all". Not really. They come in families, like musical instruments do. Learning Python does not make you a great J programmer (APL family), though I've found them to make a great combo. Both feature a strong REPL (a rich interactive mode or "shell").
Geeks in this day and age will tend to identify as Front End or Back End as to their stronger skill set and area of most expertise. If you study Twitter awhile, you can pick up more buzz words, like Data Scientist and Machine Learning (additional skill sets, mostly back end, except the front end is about visualization and so is data science also).
Front End means HTML / CSS and Javascript.
Back End means what happens to those HTTP / HTTPS requests once received. Is the front end a smartphone app? Java, Ruby, PHP... Python. Many more languages play in this space, or define the frameworks that provide yet more layers of shared person-hours. Why reinvent every wheel? Speaking of which, I met an old colleague from Plone days (still a popular Python CMS), still with CD Baby.
Patrick and I went by bus (4 going, 14 returning) and wound up at Hophouse with our visiting friend Mike, in his later fifties like Patrick and I. We've already enjoyed technology careers, against the backdrop of the PC to Open Source to smartphone revolutions. I've spent a lot of time in cube farms, often in hospitals, or other client offices, staring at screens. I'm still into staring at screens.
Those initial waves of technology were sufficient to change the guts of Portland's economy in some ways, while in other ways much stays the same. I'm not the expert, but I've seen quite a bit of water under the bridge, had a front row seat on some of the action.
Some of my journal entries from years gone by somewhat bemoan the loss of CubeSpace, a US Bank building facility on the east side (not the USB Tower) that helped with cross-pollination, important when wanting to help geeks not fall into over-isolating silos. Reinventing the same wheels over and over costs everybody.
However the code schools, especially the ones hosting regular meetups, have helped provide synergy, in tandem with the user groups layer. The Meetup culture has taken hold. People from different walks of life discuss their projects and share skills.
Without a "public square" mentality, specialized knowledge becomes over-specialized to the point of semi-paralysis.
A Renaissance fizzles into yet another Dark Age (YADA) when the kind of liberal sharing encouraged by academia (traditionally) goes away. The Free and Open Source movement was a direct extension of that tradition, per Richard Stallman at MIT, and the birth of GNU.
On a final note, I'd just been reading Quincy Larson's impassioned plea for "more async" i.e. less interrupt-driven open office plan setups. He's talking about what we call Personal Workspaces (PWSs) in the GST namespace. Study carrels. Cubes. Sometimes it's just office culture though, that needs to be addressed, if the floor plan is already fixed.
OST was all about async and PWSs. Mentors gave focused attention to student programs, but not in real time while looking over their shoulders. Diagnosing program bugs on the fly is not typically how it's done. We'd encourage unit tests, and lots of them. I continue to work that in.
"Too much task switching results in lost productivity" -- that sounds easy enough a proposition for the workflow architects to get. Human beings are not ARM chips; they have their own specs.
Tech work sometimes means getting into a flow, almost a trance, like a novelist does. I good novelist is a first reader to get the story, concentration is required. Many novelists move to a beach cabin or some such, to get more work done.
"We need our software to work for us, not make us slaves to our machines" -- another good one.
I met up with PDX Code Guilders in one of the towers. I'm expecting to cross paths again at the upcoming Maker Fair.
We also dropped in on The Tech Academy, given we've both served as Python mentors for the O'Reilly School of Technology. OST has closed. I kept some of its DNA in a test tube (not literally) in the form of OCT / RU, a Flickr album of little diagrams and such, along with souvenir business cards. None of our proprietary software leaked out. That would all need rewriting, and would reflect lessons learned, no need for carbon copies anyway.
However, I digress. What I was seeing were prototypical work spaces offering the kinds of roles those who study computer science and engineering hope to get for themselves. Ample kitchens, friendly people, handsome facilities, right downtown.
What more could one hope for? We don't have Cubby Camps yet, with people doing more async out in nature. The corporate cube farm has evolved considerably, but still loves a good 30th floor view, more of the mountains than from the mountains.
In taking pictures of the Puppet library (on display in the foyer), I didn't come across many Python titles. Ruby looks to be making more inroads there. Tech Academy did have a Python course. Mirador is more a Java shop.
We see different levels in people's willingness to be polyglot. I'll venture into Clojure, which I admire, while coding something I've coded before in other languages, such as Quadrays, a system of 4-tuple vectors mapping the same space as XYZ but with four positive rays to the corners of a tetrahedron, old hat to my long time readers, check Wikipedia.
Why would anyone use that? In philosophy class maybe, to introduce "language games" in mathematics, but where else? Do any architects learn about A, B, T, E, S modules these days? How about art school students?
These are not core questions pondered within the business sector downtown I don't think (not "CBD questions" -- except maybe at PSU, or University of Portland, in some study carrel somewhere, where following Wittgenstein links makes more sense). I've taught the basics of "Martian Math" on both campuses, at one time or another, as well as at Reed and OGI, using Python mostly. CBD = Central Business District; OGI = Oregon Graduate Institute.
In other words (back to "polyglot"), suggesting people "language hop" as if that were some trivial jump, is often unrealistic, any more than an English speaker might simply "hop" to Japanese or vice versa.
There's not much truth in the slogan "learn one computer language, and you've learned them all". Not really. They come in families, like musical instruments do. Learning Python does not make you a great J programmer (APL family), though I've found them to make a great combo. Both feature a strong REPL (a rich interactive mode or "shell").
Geeks in this day and age will tend to identify as Front End or Back End as to their stronger skill set and area of most expertise. If you study Twitter awhile, you can pick up more buzz words, like Data Scientist and Machine Learning (additional skill sets, mostly back end, except the front end is about visualization and so is data science also).
Front End means HTML / CSS and Javascript.
Back End means what happens to those HTTP / HTTPS requests once received. Is the front end a smartphone app? Java, Ruby, PHP... Python. Many more languages play in this space, or define the frameworks that provide yet more layers of shared person-hours. Why reinvent every wheel? Speaking of which, I met an old colleague from Plone days (still a popular Python CMS), still with CD Baby.
Patrick and I went by bus (4 going, 14 returning) and wound up at Hophouse with our visiting friend Mike, in his later fifties like Patrick and I. We've already enjoyed technology careers, against the backdrop of the PC to Open Source to smartphone revolutions. I've spent a lot of time in cube farms, often in hospitals, or other client offices, staring at screens. I'm still into staring at screens.
Those initial waves of technology were sufficient to change the guts of Portland's economy in some ways, while in other ways much stays the same. I'm not the expert, but I've seen quite a bit of water under the bridge, had a front row seat on some of the action.
Some of my journal entries from years gone by somewhat bemoan the loss of CubeSpace, a US Bank building facility on the east side (not the USB Tower) that helped with cross-pollination, important when wanting to help geeks not fall into over-isolating silos. Reinventing the same wheels over and over costs everybody.
However the code schools, especially the ones hosting regular meetups, have helped provide synergy, in tandem with the user groups layer. The Meetup culture has taken hold. People from different walks of life discuss their projects and share skills.
Without a "public square" mentality, specialized knowledge becomes over-specialized to the point of semi-paralysis.
A Renaissance fizzles into yet another Dark Age (YADA) when the kind of liberal sharing encouraged by academia (traditionally) goes away. The Free and Open Source movement was a direct extension of that tradition, per Richard Stallman at MIT, and the birth of GNU.
On a final note, I'd just been reading Quincy Larson's impassioned plea for "more async" i.e. less interrupt-driven open office plan setups. He's talking about what we call Personal Workspaces (PWSs) in the GST namespace. Study carrels. Cubes. Sometimes it's just office culture though, that needs to be addressed, if the floor plan is already fixed.
OST was all about async and PWSs. Mentors gave focused attention to student programs, but not in real time while looking over their shoulders. Diagnosing program bugs on the fly is not typically how it's done. We'd encourage unit tests, and lots of them. I continue to work that in.
"Too much task switching results in lost productivity" -- that sounds easy enough a proposition for the workflow architects to get. Human beings are not ARM chips; they have their own specs.
Tech work sometimes means getting into a flow, almost a trance, like a novelist does. I good novelist is a first reader to get the story, concentration is required. Many novelists move to a beach cabin or some such, to get more work done.
"We need our software to work for us, not make us slaves to our machines" -- another good one.
I met up with PDX Code Guilders in one of the towers. I'm expecting to cross paths again at the upcoming Maker Fair.
Here's me after the Pi talk last night, modeling with said museum piece mascot: https://t.co/xC2MNabLvX Pauling House on Hawthorne, PDX OR.— Kirby Urner (@4DsolutionsPDX) September 7, 2016
