I've said this myself as Java's reification of mid 90s OO and poor interop via JNI are not to my taste. But I've spent 25yrs in banking with JPMC, BoA, Barclays et al. Done lots of interop with Cobol on S/390, AS/400 and VME. Never heard of any of those systems being rewritten in Java. Have encountered key mainframe prod systems for which source is lost.
I know of one investment bank (a former employer) that rewrote its mainframe-based settlement system in Java (on Linux). Front office systems were often Java (replacing Obj-C in some cases).
That was two decades ago – almost a generation! Interesting to think that some of those systems would now be considered “legacy”.
So my imperfect understanding is they formalised Escher's shading tricks. And so systematised making the impossible look possible. Which is what magicians do by gaming our perceptual firmware. Which is the reverse of what we do when debugging a nasty corner case. The observed behaviours seem impossible, until our perception of possible causes realigns.
Are they tricks, or are they topological, non-Euclidean integrations? My guess is as the occipital is not 3-D, but dual input 2-D that splinters into thousands of topological units, that our 2.5-D (it's not 3-D in the slightest) vision slammed together on the primate face for parallax response times is uniquely suited for plastic revolutions in dimensions beyond 2-D, not just 3-D.
Most job descriptions contain some version of "other duties as assigned", IMO with good reason.
No job description can realistically capture every responsibility; this language helps prevent bad-faith disputes when new tasks or responsibilities arise that aren’t explicitly mentioned but are 5 millimeters away from those mentioned and entirely reasonable to be considered as in-scope for an existing employee.
I think also it's the reality in most engineering roles that you will often have to pivot to new technologies, help out on unfamiliar projects using different technologies (e.g., work on the front-end for a bit when you're a backend engineer), etc. Some engineers aren't comfortable with this and it shows. This is how I understood the original comment, anyway.
Anecdotally: People who aren't flexible about their job description are some of the worst people to work with. They always leave the tough unforeseen challenges to their colleagues to handle. Kinda the definition of "not a team player".
As an engineer, I had a job at a small company where I sat by the office phone, answered it sometimes, and had to get the door for deliveries. Not in my job description, but it needed to be done.
UK too, and concerned. I agree that amendment 1 and 2 provisions effectively underpin individual freedom in the US due to founder perspicacity. My fear re US constitutional provision is on separation of powers, and transfer of power. Fortunately Pence held to the constitution. Nobody ever willingly takes their hands of the levers of power!
Written code is an auditable entity in regulated businesses, like banks. Fowler suggests we get more comfortable with uncertainty because other eng domains have developed good risk mgmt. Cart before horse. Other engineering domains strive to mitigate the irreducible uncertainty of the physical world. AI adds uncertainty to any system. And there are many applications where increased uncertainty will lead to an increase in human suffering.
reply