hey kids remember the 80s?

Two interesting articles (especially as I use this period of particularly bleak jobhunting to think about where I've been):

"The looming demise of the 10x developer"  what really hit home for me was not the subject of the tile but the recognition of the distinctiveness and luck of a certain generation of coder. Luckily I tend to run as a youthful version of whatever age I happen to be, because I grew up with those 80s computers - horribly slow (especially given we all ran interpreted BASIC on 'em) but the way you had full power over the machine was intoxicating - or you could even write a game in the ballpark of the store bought ones. As the world moved on to Win 3.1 and Mac-ish WIMP UI, things were more egalitarian but the  power of coding for fun was less obvious. (In this era I turned to Visual Basic - even designed and taught a class in it for my fellow undergrads - and then later added Java-based Processing into the mix.)

Then the WWW and first dot com boom happened, and the DIY web was hella fun. Even Geocities pages could be an exercise in coding, and the "Blogosphere" was way more open than Web 2.0. Again a turn with things becoming more egalitarian, but less open. (And I'm bummed how even in the last 10-15 years, the chasm in tools and technique between coding for fun and coding for work has continued to grow - lots of added complexity, not as much added stability as one might have hoped...)

And with the dawn of widely available LLM / ChatGPT stuff - anyone who types for a living has to rethink how they do what they do. 

Anyway, related to the first article's emphasis on young geeks growing up - "an Ode to Grids" -  - some truly fun animations in that one. I remember geeking out with graph paper as a high schooler and then even when I got a nice graph paper notebook - playing with 2D and isometric 3D fonts and shapes is tons of fun.

high tech the emporer has no clothes vs FOMO

Github blog on keeping up with big shifts in tech. Two of the big takeaways from the participant's history for me were:

1. Object Oriented Program regret

2. But later, regret on not jumping on React sooner. 

The anti-OOP feeling reminds me of the classic Object Oriented Programming Oversold! geocities page. In a way that dead page inspires me when I feel like a curmudgeon shaking my fist against a landscape with way too much flavor of the month.

I also feel like a little bit of a hypocrite, I have great stories about my personal projects (especially my porchfest websites) - performant, long-lasting, lots of UX challenges met - but the code base is laughably out of step with what I do for work (and always tempts me to fire up "Taking PHP Seriously" and its descendent posts) - but then I see something like Javascript Gom Jabbar (named after a point scifi torture device) that is a deep dive into the myriad painpoints of a modern JS project's "package.json" and I don't know if I should be grateful that I avoid those pitfalls in most of my projects, or sad that I'm weak and flabby for not having more practice with them outside of a work context.

But the way how two of the respondents regretted avoid React in its early incarnation... interesting. Like, React smelled so much better than Angular, and the idea of declarative programming has such a beauty to it, that I was able to embrace it with few of my normal reservations. (That said, I still prefer to turn to declerative programming in Vanilla JS when I have that kind of problem for side projects, but still...)

first round interview advice

Some good advice on first round interview prep and the like. There's a fair amount of legwork you should be considering!

(Also random specific nugget I heard from another successful job seeker - for your LinkedIn headline, play the keyword game. Don't spam it, of course, but put in relevant technologies and skills recruiters will be looking for instead of high level aspirational summaries.)

a note on blogging platforms

Also, not unrelated: I've been doing this blogspot based devblog for 12 years - like just over half as long as I've been doing my own blog kirk.is (with its custom homebrew CMS). But Kudos to blogger and blogspot (both of which got start in 1999) on their longevity, even if it all got bought by Google. They've been low key kicking around powering the indie web for almost a quarter of a century!  Famously long lived institution Harvard's effort is petering out this summer after only 20 years.

svg for you and me

Making the rounds, a really nice deep dive into SVG. It reminds me of the old Logo programming language, where a little turtle (generally virtual but they also had small robots you could buy) would scoot around.

I think SVG expertise is a really interesting boundary of design and dev. A designer might generate an SVG with little idea of how much like a little computer program it is (heh - an svg file is like a computer program as source, a png or jpeg is more like computer program as a binary file.) But a dev often won't have a feel for how that program relates to the curves and lines that went into making it.

(On a more pragmatic note, this article argues for SVG icon sprite sheets as being the best blend of performance and flexibility in React)

honking namespaces

A job interview I'm on might touch on Python. I asked ChatGPT to bring me up to speed a bit, knowing that I have good knowledge Javascript and a small pile of other exposures of varying ages and intensity (Java, PHP, Perl, etc)

It mentioned the "Zen of Python" you get when you type `import this` into the Python interpreter:

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

I like it a lot, and find it amenable to my views and practice. The main thing I might not get is the last one (well maybe it's the second to last one - there's rumors of an unprinted 20th one which might be a kind of metajoke about not saying too much) - Python has scoping (as does everyone) so it's not clear if it's a call for more explicit namespacing or what.

what? HTML? from a SERVER? In THIS economy?

Interesting hearing about "server side languages for the front end" - especially in proximity of all the hubbub about Server Side Rendering in React and other javascript based languages. (And also how much vitriol javascript inspires in so many full stack folk)

SSR in React feels like teaching the new dog old tricks. And overall the trend to do more server side and ship the HTML over the wire... heh. I remember this one time I stumbled on some little used JQuery syntax that was geared at smoothing replacing part of page content with the HTML from a server query:

$('#someElement').load('url_to_your_server_page');

(Interestingly, GPT 4 knew that command I half-remembered, while GPT 3.5 used more typical ajax commands)

So, like, there's nothing new under the sun! (but there sometimes seems to be a weird acceptance of increasing complexity and size of the cross section of what folks need to know to do their job properly.)

 

back to BASICs

I have a technical interview Monday. 

These are so often intimidating, either because they may throw in obscure-ish "gotchas", or just the general issue that 90%+ of, say, React work is done in a context where the basics are setup, and every new component for feature is the appropriate variation of something that already exists. But most tests are throwing you up against something new and closer to greenfield (even they are asking you to "find the mistakes in this code")

Anyway. Sometimes in these cases I like going back to basics, like going through tutorials and hands on stuff so I regain fluency in low level stuff.

The React site has a Tic Tac Toe tutorial. You are given the option of editing it in codesandbox, or from there you can hit "export to zip" and run it locally, which seemed like the richer option to me. But if you do so you are likely to see this error:

./src/App.js Line 2: 'React' must be in scope when using JSX react/react-in-jsx-scope

The solution is to explicitly import React at the top:

import React from 'react';

Not  sure why the demo there doesn't have/need that. 

Also doing a simple "2 player only Tic Tac Toe" game (i.e. no AI to play against) was one of the first programs I remember writing in BASIC on Atari 8bit computers (the 800XL). What's funny is I used the same basic algorithm for detecting if the game was over that the React demo uses (just seeing if any of the square sets representing the 8 possible ways of "winning" the game were filled with the same player's marks.) I remember as precocious...4th grader? 5th grader? explaining that technique to my Aunt, and her saying it was the kind of thing she didn't think that she could come up with. No wonder I was so full of myself as a kid. (Sure, only as a kid)

cards

I play in several activist street bands - BABAM's supply of business cards was running low. The old front design was pretty good, but I revamped the back:

 

Here's what the back used to be:

While this was more of a "UX" than a "UI" exercise, I think the new back does a better job of explaining what the band is, and serving what I've seen about the card's two main rolls: encouraging musicains to join in, and making ourselves known to activists who might find us useful

Not quite as cool as my personal cards, with artwork by James Harvey: