site banner

Friday Fun Thread for January 24, 2025

Be advised: this thread is not for serious in-depth discussion of weighty topics (we have a link for that), this thread is not for anything Culture War related. This thread is for Fun. You got jokes? Share 'em. You got silly questions? Ask 'em.

2
Jump in the discussion.

No email address required.

Another year, another karma farm<ins>post about civil engineering</ins>.


The fifty-mile-long pavement-preservation project described in my previous post has been sent out for initial review. The one drafter in our office drew from as-builts and from satellite photographs the pieces of roadway that were not available in electronic format. Then the design (as far as pavement preservation even needs any "design") was split up between the five engineers in our office, yielding a workload of around ten miles per person. The end product was two hundred and fifty 24″×36″ sheets for fifty miles of roadway. (Again, this is just a brain-dead pavement-preservation project. Resurfacing projects have been known to exceed one thousand sheets for ten miles of roadway.) A good use of taxpayer dollars? I guess so.


Bureaucratic rigmarole:

  • I mentioned in my first post that, whenever the elevation of a roadway is increased by at least half an inch: The project must be reviewed by the Environmental people for flooding problems, and any location that would cause a flooding problem must be milled down before the new pavement-preservation treatment is applied, so that the overall increase in elevation is reduced to zero. Locations underneath overhead structures (whether bridges or signs) must also be milled down in this fashion.

  • I also mentioned that, if old electronic stuff like weigh-in-motion stations is present in the road, the electronics people may request that the electronic stuff be replaced as part of a pavement-preservation project.

  • New environmental rule: Any amount of elevation increase in or near a floodway (definition; red-and-blue striped areas on this page's maps) is forbidden. The half-inch exemption is not applicable in and near floodways.

  • New rule from FHWA (Federal Highway Administration): Any amount of milling in a project now triggers the requirements to construct new ADA-compliant curb ramps at intersections throughout the project. Previously, pavement-preservation projects were exempt from this requirement if the milling was limited. (I think the limit was something like ten percent of the project's total area, but no pavement-preservation project ever got anywhere near it.) That exemption has been eliminated. Also, weigh-in-motion stations can't be replaced in pavement-preservation projects under whatever exemption they previously were operating under.

  • The construction of new ADA-compliant curb ramps is out of scope for pavement-preservation projects.

  • Result: Goodbye, a quarter-mile-long piece of this pavement-preservation project that runs over a dam, plus a few other random spots adjacent to bridges! Goodbye, two random spots underneath overhead sign structures! Goodbye, three weigh-in-motion stations that the electronics people wanted to replace!


Bureaucratic failure:

  • In the first half of 2024, my office originally was supposed to be working on a project to replace an old traffic circle with a standard intersection. (The traffic engineers recommended a modern roundabout*, but the municipal government rejected that option.)

  • Whoops! The traffic-circle project was immediately adjacent to a bridge-replacement project. There was a minor conflict between the two proposed roadway edges, and a major conflict between two proposed drainage basins. (These conflicts weren't noticed previously because: the bridge spans a river between counties A and B, and the associated project was assigned to county A in the project-management system; the traffic circle is in county B, so the associated project was assigned to county B in the project-management system; and counties A and B are in two different project-management regions.)

  • The conceptual designer for the traffic-circle project and the final designer for the bridge project suggested adjusting the drainage basins and coordinating the roadway edges to eliminate the conflicts. But the Environmental people complained that doing a drainage (or hydrological or hydraulic—whatever) assessment of the same location twice would be a waste of their extremely limited resources. Since the bridge-replacement project was much further along in the design process, the traffic-circle project was merged into it, leaving my office to sit idle with no project assigned (other than the aforementioned fifty-mile pavement-preservation project, plus whatever random maintenance work orders came along) for six months.

What a wonderful use of taxpayer dollars!

*Reminder: A roundabout is a circular intersection with no traffic control except a yield sign at every entrance. Anything else is just a sparkling traffic circle**.

**Imagine being at intersections / so fat you look and see food


Reiteration:

More people need to make lengthy posts about their cool jobs in the vein of my previous post<ins>s</ins>! I've been waiting with bated breath for the past <ins>two </ins>year<ins>s</ins> to hear about the dreaded "scrum master", "daily stand-up", and "Git merge conflict" from some of the 10× programmers that supposedly frequent this website. Maybe we even have an architect who can complain about his clients' wishy-washiness and scoff at all the pathetic free (libre) attempts to compete with Chief Architect, or a paving contractor who can express his hatred of his local transportation authority's resident engineers and in-house designers in the strongest of terms.

God, what great writing

I used to write diatribes when I worked @ General Nutrition Centers

I work retail still so my passion for everything has waned

Best I can do is complain about how wonky the budget is for a somewhat important piece of shipping software. You'd think we could get $ENTERPRISE licenses squared away easily, we're not some fly-by-night shop. Because we don't have $ENTERPRISE licenses we apparently aren't allowed to install $TOOLS I need to unify our Unix and MS build processes, and we can't just stand up a build server running, say, $DROP_IN_ENTERPRISE_ALTERNATIVE or something on it because policy. Devsecops is goofy.

Also, as a sidebar - apparently barely anybody has put in the effort to try to build $WELL_KNOWN_INFRA_TOOL for Windows on Unix in the last decade and a half, and somewhere down the stack it just completely blows up because of preprocessor hell in a cross-build environment. My favorite thing in the world is when a header is included with nice and neat capitalization that doesn't match the actual file's (entirely lowercase) capitalization, so it builds just fine on MS because MS filesystems aren't case-sensitive and dies on Unix because someone wanted their includes to look pretty. I have done black magic to this dependency tree to get it close to building and then it still dies because of platform-specific linker options that are getting improperly set in a CMakeList. There's reasons why we're building this from source instead of using a package for it, but it's a huge morass of fiddly that I'm allowed to keep bashing my head on because if we get this to work, the payoff for our whole CI environment is huge. Somehow I've only had two drinks in the last six months.

(Apologies if you find the formatting obnoxious but I'm trying to keep a minimal degree of opsec.)

MinGW and MSVC capitalize their header names differently, so it's possible they were correct for the person who wrote them.

My civil-engineering organization only recently upgraded from a version of CAD software that was literally twenty years old—not for budgetary reasons, but because the old codger in charge of the CAD unit saw no need to upgrade, and dug in his heels to resist upgrading until just a few years before he retired. There were regular problems with renewing the license for it.

Ooooof, that sounds rough. At least my shop is aware of the licensing problem - part of our major infra push is an effort to fix it, but we're still kinda kneecapped by policy at the end of the day.

I switched from doing Java Spring Boot microservice development at one company to doing the exact same thing at another company.

Well, not the exact same thing.

Old Job:

  • Provided a somewhat innovative software product/platform/service that helped private companies get a good deal on transport logistics.
  • Was an organizational mess that never got its goals straight.
  • Was a somewhat international affair with English as the lingua franca.
  • Did run-of-the-mill agile software development, and had fairly mature and functional processes.
  • I started out in a local team, but transitioned to an international one.
  • I did it all Working From Home, poorly.
  • Paid decently.

New job:

  • Provides an extremely specific financial product/in-house software platform/service that helps private individuals maximize their gains from government subsidies.
  • Is fairly well-organized overall, but is very set in its ways and responds glacially to any problems.
  • Is an extremely localized company, almost provincial in terms of who works here. Obviously German is the only language in use here. Even our code is in German!
  • Does "agile" software development, which should make any software dev laugh out loud but all the people here except me never worked anywhere else and don't know just how ludicrously not agile their practices are. It makes sense, of course - the company isn't in the business of going fast and breaking things; it needs to observe a million regulations and sell financial products that last a lifetime. Fun activities here include doing tons of manual testing, having reviews every step of the way, several layers of quality control and redundancy on everything, and needing manual authorization by this authority or that for things that devs would be expected to handle on their own anywhere else. I keep needing to explain why I want to even write unit tests, and I need to admit that given the slow pace of development and the very thorough manual testing they are not quite as essential here as I thought them elsewhere.
  • I work with a local team, and it's great because I actually get to know the people and we speak in dialect. Absolutely excellent.
  • I work in the office, which is also great because I actually get things done. At least as long as I keep my phone switched off so I can't receive messages from home.
  • I get paid somewhat generously. I also suspect that my experience and abilities were grossly overestimated in the hiring process (I deny responsibility here; I'm very certain I did not oversell myself), but it seems both sides are willing to make it work anyways.

Overall I'm happy with the change. I still ask myself sometimes whether I should've maybe taken a more technologically interesting job, but eh, everything else about it is pretty decent.

> Even our code is in German!

> Java Spring Boot

Must lead to some long class names...

Ex: AbstractAutomatischeKonfigurationsStrategieProxyFactoryBeanImplementierungDelegate

Hah! Yes it does, except for names that need to match those of our COBOL systems, which have something like a 32 character limit.

So we end up with names like AAutoKonfigStratPFacBImplDel.

Uncle Bob wouldn't survive a day here.

More people need to make lengthy posts about their cool jobs in the vein of my previous post

My current job is fake and lame, but maybe I'll manage to get off my ass at some point and write a few words on the day in the life of a System Design Agent. Or, before that, a Technical Writer allowed to do exactly zero writing/editing.