explain xkcd - User contributions [en]

2728: Lane Change Highway

2023-02-19T22:52:42Z

172.69.34.112: /* Explanation */ 101 in California

{{comic
| number = 2728
| date = January 23, 2023
| title = Lane Change Highway
| image = lane_change_highway_2x.png
| imagesize = 374x530px
| noexpand = true
| titletext = I just think lane markers should follow the local magnetic declination.
}}

==Explanation==

{{w|Highway}}s are large roads designated for high-speed traffic. Like in [[253: Highway Engineer Pranks]], [[Randall]] proposes an ineffective highway design, which reportedly got him fired.

Highways normally have several, but not a fixed number of lanes; more lanes may be included on parts of the highway with higher traffic flow, and the design decision can interact with entrances and exits to the highway. One common structure is to merge a lane from the right to the left after an entrance, to remove the extra lane created by the merge of the entry ramp. Drivers are expected to merge into one of the lanes further left before the lane on the right ends.

Here, Randall has designed a highway where the lanes are not aligned to the road, thus constantly expanding to the left and requiring merges from the right. This is highly impractical, as each individual lane merge is a difficult maneuver compared to normal driving; being forced to perform these near-constantly is a large hindrance at the least and a large danger at the most.

Effectively every car would have to drive with their left turn blinker on constantly in order to drive in a regular straight line. Alternatively cars could stage their lane changes which would make them swerve gently back and forth across the road. Since everyone will choose a different strategy, the road would be chaos. People would almost never try to make a right lane change since lanes to the right end sooner.

While considerably less extreme, a section of U.S. 101 "North" (which is actually traveling west) in California is somewhat like this. The road is four lanes when crossing over I-405, with an additional lane immediately entering on the right from I-405 South, but three of these lanes become exit only lanes in the San Fernado Valley (at Haskell Avenue, Havenhurst Avenue, and Topanga Canyon Blvd) and two in Ventura County (one in Thousand Oaks and one in Ventura), so all through traffic must merge into the two lanes that enter on the left carrying traffic from I-405 North.

The title text refers to local {{w|magnetic declination}}, the angle between the magnetic north pole and the true (geographic) north pole. Magnetic declination varies over time due to polar wandering and so the lane markers on the highway would need to be regularly updated to account for this.

==Transcript==
:[In a white panel a black road starts at the bottom left and curves gently towards the right until the middle of the panel, where it begins curving slightly to the left ending in the top right corner. The road has space for four lanes divided by lane markers, but the markers does not follow the direction of the road but goes more from left to right than the road, even though they do follow the general curve of the road, but never the actual direction of the road. This results in all these lanes to end near the right edge of the road. Every time the lane gets too near the edge the lane lines stop and on the end of the lane there is a curving arrow pointing left. Below the arrows the word "Merge" is written. This happens seven times on this small patch of highway. At the bottom and top there are the lane marker lines entering and exiting, so there are always four lanes. After the three starting at the bottom, seven new ones begin, the last just below the top, where the final merge arrow also is, stopping the last of the right lines from exiting at the top.]
:Merge
:Merge
:Merge
:Merge
:Merge
:Merge
:Merge

:[Caption below the panel:]
:I got fired from my traffic engineering job for building a highway where you could only travel by lane changes.

==Trivia==
* A faint grey outline is visible under the caption, as if text was rewritten over a semitransparent layer, which was never deleted.

{{comic discussion}}
[[Category:Engineering]]

Talk:2730: Code Lifespan

2023-01-28T17:02:43Z

172.69.34.112:

I'm not sure if the thesis in this comic is accurate. But if it is, my explanation would be that a person with a more spontaneous live-in-the-moment attitude might program stuff that is more interesting, than the stuff made by the person who is (maybe neurotically) obsessed with making clean code.
<br />My own experience is that one loses the fun of programming something if the perfectionism plays to big of a role.{{unsigned ip|162.158.203.40|14:53, 27 January 2023}}‎
:The advice always given to me is "never let the perfect be the enemy of the good enough". Though I tend to bounce between being so obsessive, that I don't realise that I'm now gilding the lilly, or hastily kludging it because of the need for an immediate workaround, knowing that if it needs looking at again then I'll be doing it later anyway and that's when I'll get my gilding gear ready. (Hence why I'm 'always' being told that phrase. But I suspect that there really ''is'' no sweet spot between too little and too much, or at least no single keystroke at which I would earn universal praise for my finely balanced tenacity and moderation upon the handling of the issue. Always critics!) [[Special:Contributions/172.70.86.28|172.70.86.28]] 17:19, 27 January 2023 (UTC)
:On the contrary, there are perfectionists like myself who get a distinct satisfaction out of tweaking code to perfection, making it airtight, cover all conceivable bases. Make the code look clean, efficient, making sure it's fully commented... A lot of the joy in programming, for me, comes from this crap. :) [[User:NiceGuy1|NiceGuy1]] ([[User talk:NiceGuy1|talk]]) 05:25, 28 January 2023 (UTC)

At least at a corporate level, I suspect this phenomenon has an extremely simple explanation. When your code is high-quality, people often won't even realize they are using and interacting with it, because it just does what it's supposed to. When your code is hackish, you and your coworkers will constantly find it breaking seemingly unrelated stuff, forcing them to go back to it over and over, trying to make it work, only to discover it breaks even more things when they try to fix it.
<br />Your high-quality code is still interacting with those seemingly unrelated things, it's simply not breaking the unrelated things, so you don't notice it's interacting with the seemingly unrelated things.[[Special:Contributions/172.69.68.97|172.69.68.97]] 16:32, 27 January 2023 (UTC)

This also reminds me of [[2347: Dependency]] where a single project made in 1990 has become the backbone of so many other applications. [[Special:Contributions/172.71.151.100|172.71.151.100]] 17:47, 27 January 2023 (UTC)

I won't do the edit myself (because I'm shy), but here is how the comic rings to me (from my own current experience):
- Often in dev, there are many daily repetitive tasks that are annoying (i.e., build-test-lint-commit-push). These get automated out of spite by someone in a quick'n'dirty way, just to make life easier.
It has a limited audience (the development team), but lives on forever, since it is used daily (and therefore maintained accordingly).
- On the other hand, the stuff the team codes and sells is subject to changing requirements (cf. next release, marketing, ...). So it gets overhauled often, all the more easily because developers are not familiar with it (because they don't use it, and they worked on some other part of the project).
There is also the fact that there is no budget for making changes on the tools, as opposed to the product, so no one really has time to refactor the former - that's how it lives so long!
~~Aveheuzed~~

The never ending war between "I don't have the time to do this right", and "this is way too complex for our simple needs" is exactly where this comic lives. The reality of programming is that general solutions are great for saving time writing, but are often bloated (with unneeded options), miss edge cases, or introduce extra dependencies and slow downs. plus the whole "not invented here" thing coupled with licensing headaches means this will probably still be a thing in a hundred years. PS I think the person explaining missed the point of the order in which the title text options are presented >.> [[Special:Contributions/172.70.206.150|172.70.206.150]] 18:19, 27 January 2023 (UTC)
:I took the (un)crossed combination as implicit, myself, as I read that version, dealt with prosaically in the follow-up paragraph, but I added the contrariwise statements (and preamble) to the end to make it perhaps more obvious as to the intended humour.
:...on your earlier point, add "...I don't have time ''not'' to write it as a behemoth of a function, when I'm sure it could all boil down into a few lines that are far simple to understand and maintain". By incremental testing and putting together, you miss that you end up with something that basically has some common role such as "looks for the third non-digit character after every other colon, and returns the first full whitespace-delimitered word that follows on from that" in multiple different data-unmunging instances that all looked the right way to pick apart the necessary data at the time. With time, you can realise that this'ld go nicely into a singly-defined internal function which can be more easily commented, centrally maintained for immediate cross-code consistency, updated or even made more flexible by additional parameterisation (for when it occasionally needs to be the ''n''th non-digit character, etc) and... most importantly... give it a decent function name that does most of the work of commenting its own purpose wherever it appears. But that may takes time, and then they change the stream-format to some alternative that requires a new rewrite across the board. [[Special:Contributions/172.71.242.11|172.71.242.11]] 19:05, 27 January 2023 (UTC)
::There's definitely space between those extremes. I can't count the number of times I've taken some code and either stripped parts out that were outside my use case, built up something that was missing for the same, or sometimes both at the same time... as long as an eye is kept on internal consistency and a bit of flexibility it usually works out... usually [[Special:Contributions/172.69.34.112|172.69.34.112]] 17:02, 28 January 2023 (UTC)

I took it to mean if you say it's fine it isn't (thinking of Murphy and that
it's fine fire cartoon here) and if you worry that it isn't it will usually be. Jinx. That's the word I was looking for.18:40, 27 January 2023 (UTC)
:"Tempting fate", I'd say, in the latter case. Whatever the overcautious opposite is in the former, which I'm sure has a phrase but I can't immediately think of one so I haven't added the one I know, unpaired. I think we are all having similar thoughts about the philosophical paradoxities, however. [[Special:Contributions/172.71.242.11|172.71.242.11]] 19:05, 27 January 2023 (UTC)

Circa 1969, "Surely 16 bits will be enough for a timestamp, it won't break until the year 2000. Who knows if it will still be around by then." Circa 1998, "Surely 32 bits will be enough for a timestamp, it won't break until the year 2038. Who knows if it will still be around by then." But to be fair, while Unix has outlasted one of it's major contributors (Dennis Ritchie, RIP), it was designed with best practices to encourage reuse. [[User:Rtanenbaum|Rtanenbaum]] ([[User talk:Rtanenbaum|talk]]) 18:58, 27 January 2023 (UTC)

Should this be added to the Code Quality series? It fits the vibe and the title style too.[[User:Xurkitree10|Xurkitree10]] ([[User talk:Xurkitree10|talk]]) 16:32, 28 January 2023 (UTC)

2358: Gravitational Wave Pulsars

2020-09-11T20:19:57Z

172.69.34.112: more astronomy?

{{comic
| number = 2358
| date = September 11, 2020
| title = Gravitational Wave Pulsars
| image = gravitational_wave_pulsars.png
| titletext = The most important attributes of a vector in 3-space are {Location, Location, Location}
}}

==Explanation==
{{incomplete|Created WITH EXQUISITE TIMING. Please mention here why this explanation isn't complete. Do NOT delete this tag too soon.}}
The title text references a well known real estate saying that the three most important parts are "location, location, location." In 3d space the three coordinates all refer to locations along one axis

==Transcript==
{{incomplete transcript|Do NOT delete this tag too soon.}}

Ponytail: Ask me what the secret to detecting gravitational waves using pulsars is.

Cueball: What's the secret to detecting grav--

Ponytail: '''''Timing!'''''

{{comic discussion}}
[[Category: Comics featuring Ponytail]]
[[Category: Comics featuring Cueball]]
[[Category: Astronomy]]

2358: Gravitational Wave Pulsars

2020-09-11T20:18:29Z

172.69.34.112: /* Transcript */