On Outsourcing, Delegation, Code Review + Mentoring of Juniors, and Alternative Paths Not Taken

This started as a series of response to a thread discussing Boeing's disasterous decision to outsource the coding of their firmware "to the lowest bidder", with the thread starter originally claiming that "you still have to spec and test" the outputs of those outsourced workers. In general I agree that, the senior folk who were responsible for writing the specs that the code followed (AND most likely should also be responsible for testing/verifying that the obtained results were fit for integration into the codebase)  *SHOULD* bear some responsibility for ensuring that the work done is up to required standards. However, I'd also like to point out that in many ways, this way of working is in many ways much harder for everyone involved, so the blame-torch shouldn't be aimed at these folks dropping the ball (save for complete systemic dereliction of duty). My own mini-thread of response follow (inlined together + tweaked to follow read a bit better).

2024 Recap

Happy New Year!  Time for a brief recap of 2024 I guess.

Main Highlights

* Trips to Mt Cook, Sydney, and Wellington

* First full year at work supporting the important operational system we're responsible for (and getting it stable / fixing all the major-ish quirks that popped up after it launched in late October 2023)

* Taking the plunge and getting a new camera setup (Canon R5 - Mirrorless) after years of using my trusty Canon 7D

* Capturing multiple Auroras, after years of trying unsuccessfully

* Starting a mini collection of my favourite aircraft as detailed diecast models at 1:200 scale (i.e. Emirates A380 + Cathay Pacific 747 in old "green-white-stripe" livery)

* Finally getting a heatpump for my main home-office  (hot room days be gone!)

* Hosting visitors a few days ago + reconnecting with a bunch of old friends

* Returning to actively posting longer-form posts on here (after a few years away mostly posting on Twitter) 

   * I'm still trying to figure out some plans for migrating off this platform onto a more stable / sustainable solution under my own control...

 

Firsts

* Spending time actually exploring the Mt Cook national park  

* First overseas trip post-COVID 

   * And, actually, having this happen after actually contracting COVID for the first time - probably at a local healthcare facility

* Flying in Premium Economy - especially on an A380 flying out of my home airport - that I paid for myself.

* Visiting the Blue Mountains + various other Sydney locations

* Seeing + Photographing an Aurora for myself... and from my back yard at that!  Then getting to do so again multiple times again during the year!

* Capturing a kookaburra + pelicans + "garbage bird" in Sydney

 

UI / App Toolkits + Frameworks - The "Missing Middle-Layer"

Over the past decade and a bit, on almost every project I've worked on, I've come to realise that there is often quite a massive gulf between what the Standard Library + UI Toolkits typically offer, and what it is that you really typically require when building anything of consequence for the real world. The problem is such that really, you end up needing to spend quite a bit of time re-inventing the following sub-systems for each project OR end up paying the tax of not having these for each and every feature you add (by effectively reimplementing them *per feature* instead, but without the benefits that having the standardised system brings).

While the initial seeds of what I'm about to discuss date back to around 2010, things really started to take shape around 2018/2019, when I first seriously started mooting the idea of maybe creating my own Programming Language / Environment someday (i.e. "Kea"), a batteries-included environment for doing everything "my way"...

One of the key aspects of that language would be that the following functionality / capabilities would end up being "baked" into the language as first-class citizens. Before fully embarking on that journey again, I thought it would be good to first prototype these systems in other environments where they may help advance the overall state of the software industry. Hence this blog post.

 

The Short List - Core Functionality:

* 1) Property Metadata System  (i.e. something like Blender's "RNA" system)

* 2a) Bidirectional Property Binding (Data Objects <-> UI Widgets)

* 2b) Widget / Factory that creates standard auto-bound widgets, given only the Property ID + host object reference  (i.e. something like Blender's UI widgets)

* 3) Automatic hierarchical property serialisation system  (i.e. something like Skyline-X's Preference Sets)

* 4) Version patching  (i.e. something like what is used for Blender's SDNA system)

   * Includes utilities related to version number management and/or Git branch/revision info

* 5) System for Physically-Based Unit Handling and/or Unit Conversions

 

The Short List - Extended Functionality:

* 6) Static/Dynamic Expressions / Drivers, Expression-Evaluation, and/or String Template Substitutions

* 7) A "Datablocks" System + CRUD API's for managing those

* 8) "User Preferences" system

* 9) "Operator"-like system (for standardised logging / error handling, undo/redo, and background-exec of expensive long-running-processes) - inspired by what Blender uses since 2.5

* 10) Basic Extendable Templates/Base-Implementations for Handling the Following Functionality (Optional)

   * Standard logic for New / Load Project/ Save Project stuff

   * Standard logic for handling cache files / support data files

   * Built-in screenshot per-viewport/view-angle screenshot functionality (with repeatable / savable parametric configuration)

   * Grease Pencil / Built-in Freehand Annotation Tools

   * Node-editor 

* 11) UI Toolkit Extensions + Features

   * Collapsible Panel implementation   (Note: This is surprisingly absent from most UI toolkits in practice)

   * Control-Gain Ladders / Input Convenience mechanisms

   * Popup panels templates

   * "Overlay toolbar / interactive viewport tools" system 

   * Popup info panels / extended menus for Unit Conversions + String Templating functionality

 

Silvereye Season 24 + Different Types of Silvereye Calls

Every year, November marks "Silvereye Season" - the month where the bottlebrush outside my window blooms, and the silvereyes come jauntily swooping in to feast on the nectar, pulling all manner of cute and adorable acrobatics. Sadly, this year's season has been heavily interrupted + restricted by a series of home renovations we've been doing that just happened to need to coincide with this month... *sigh*

 

As a result, this year, I've been limited to only getting a literal handful of very short shooting windows this year, and an even smaller number of OK photos, of which the ones above are probably the sum total...

(There were also a bunch of early ones where I managed to capture 2-3 staging a surprise visit just when I got home... but those aren't that great quality due to only having a short zoom + wrong camera settings on an afternoon with very average lighting, so I won't be posting those online)

You may also notice that the colours are a bit punchier than usual, as I've also been forced to trial a new photo processing pipeline (i.e. Darktable) as noted in a previous post.

[Darktable Trials] Testing out a New Photo Management / Editing Workflow - Part 1

Over this past week, I've been kicking the tyres on Darktable again -- partly to see if I can now make it work for me, but also partly out of necessity (as my usual workstation + office-space are out of commission currently, but I had a bunch of photos needing editing, and Picasa - which I've been using to date - will eventually bite the dust in a bad way as it's been long deprecated so I wanted to avoid putting it on yet another machine... plus, I kept forgetting to grab the installer from my backup drive when I plugged it in).

Maybe there's a bit of "Stockholm Syndrome" here, but early indications are that with the latest current version (4.8.1 when I went to download it recently), Darktable has resolved a whole bunch of idiosyncrasies that made it an annoying non-started previously, along with offering a bunch of new capabilities that present a good way of achieving some of the "Ultimate Photo Editing" tool points I mentioned previously.

 

Update Notes: 

* 25/11/2024 -  Original Post. May end up tacking on more details in a later revision, in which case these update notes will be updated.

Initial Thoughts on "Shortcut Editing" UI's

Is it just me, or do pretty much all the "Shortcut Editor" UI's in various apps suck?

I don't claim to have a fully fleshed out + well considered + tested alternative in this case (unlike with many of the UI problems that I've spent some time toying with), but just to throw some ideas out there to kickstart a conversation about these UI's that I think as an industry we need to have.

So, without further ado, here are a few ideas for how I'd go about making Shortcut Editor UI's better if / when I try to design one next time.

 

On intrinsic motivation when learning new skills

This morning I saw an interesting discussion where someone was asking how they should about learning to code.  This got me thinking about how I personally learned, and the transferable lessons from that process for picking up new skills / knowledge in general.

From that, I realised that I believe that intrinsic motivation - i.e. you first have to want to know for your own sake / to meet some of your own goals, rather than it being like "someone says I have to do it". I suspect this is one of the first major barriers many people face: For many people, their experience with learning in general has been through their schooling years - an fraught experience where the answer is often, "I do it because the adults made me do it" (i.e. extrinsic / non-self-motivated)

The easiest way to learn is not to go through a tutorial / course "just because", but rather, if you set yourself a goal of "I want / need to be able to make <x> happen"

From there, it really focuses your learning:
  * What do I need to know to do that?   

     There's nothing better than a real concrete need / roadblock in the here and now that you need to overcome in order to get to the next step towards your goals, focussing your attention in ways you may not have considered possible.

  * How does what I'm learning / coming across tie into what I'm doing, or how does it compare to what I've seen working on my project? (I.e. what's the point of all this)?

     For example, from experience, this was what helped me get through some of the most boring series of lectures I'd encountered at Uni, where we were going through this dry abstract set theory stuff on database operations. I found it really helped to reframe those abstract concepts back into the more concrete world of how I'd go about implementing such a thing in code using a for-loop going over such collections of objects.

  * What else could I easily do now that I didn't originally consider?  

      This is where you start engaging your creative juices, and start coming up with new idea for other enhancements or features or even completely new projects come from. Those in turn will drive a lot more experience building and hunting for new and better ways to do things, and pretty soon, we'll not be having this discussion here at all, as you're too busy trying to feed all your projects!  

     (That's why I also believe that if you manage to get your kids hooked on some pursuit where their drive for personal improvement can start taking over - i.e. for example, anything from programming, playing a musical instrument, sports, or various forms of art - they really won't have time or the inclination to bother with drugs or petty youth crime)

For an additional piece of fun reading, I came across the following article this morning about how lab rats taught to drive "rat cars" apparently looked forward to the experience, with the anticipation for that having many positive benefits (including making their tails look more like those of "friendly cats"). Interesting food for thought...

https://theconversation.com/im-a-neuroscientist-who-taught-rats-to-drive-their-joy-suggests-how-anticipating-fun-can-enrich-human-life-239029

Thoughts on Rust - 2024 Edition

Here are some of my current thoughts on Rust, as initially prompted by a thread I saw this morning asking: "What features of Rust are most appealing to you?"

My reply follows.

~~~

Originally, what drew me most to Rust I guess were (in following order)

1) Complex compiled language with momentum that was not C++ 

This was by far the biggest motivation, back when I was still mostly a C/Python dev. Having spent a few years working professionally as a C++11 software engineer now (having learned on the job, thanks to working during code reviews with a bunch of top-notch Modern C++ gurus), it now just looks like Haskell-lite for Modern C++ devs  (which enforces all the best practices we generally do, *by default*).

 

2) Claims of speed + memory safety (esp around multithread type stuff - This was a big one coming from several bad Python codebases that struggled with really bad concurrency issues (i.e. random deadlocks on machines with different processor numbers than the original dev machines used), but also because Rust first started rising in prominence as I was looking into the Depsgraph stuff (which would have really benefited from being able to evaluate multiple things in parallel, to do background recalcs + caching of your scene)

3) Didn't have "cuddled else" / "caterpillar ifs" hard coded into the syntax (*cough* Go *cough*)

To this day, it still really annoys me running across code written that way. Like, really twitchy annoyed.

It's a real pity that there are a bunch of languages that hard enshrined it in their syntax (due to design decisions), and also that increasingly many examples across other C-like languages also do it. Ugh!

Blasts from the Past - Reminders and Remnants of Different Times

Sometimes you just cannot make these things up!  Either that, or "The Algorithms" pervading our lives these days are getting much better at juxtapositioning contrasting but related things together. Anyway, I digress.  Tonight's impromptu post is inspired by the following 2 snippets that popped up across my various feeds this evening:

   1)  Local newspaper had an article saying that a *third* building at my former High School had just been deemed "quake prone" - with all three buildings having been built either shortly before my time there, or during my time there, and all having been places I'd spent a bit of time in.

   2)  An old clip of Bill Gates giving a demo of Visual Basic back in 1991

 It's funny how these things go sometimes, isn't it...

 

Principles and Frontiers for Creative Software Tools

Here's the long-promised "Manifesto + Roadmap" for the future of Creative Software Tools I'd been wanting to publish since May/June 2024, but was ultimately stalled from doing so by a bad first encounter with Covid ultimately sapping my strength to take on outside-work commitments for a few months.  

NOTE: To get this out, I may just publish it first then amend it later

 ~~~

Dabbling with designing up another DCC tool after a hiatus of a short break from that field has reminded me of a whole bunch of untapped / unsolved directions for the future of DCC tools to make them more useful to the humans who use them.

Graph Layout and Diagramming Tools Projects

Automatic Graph Layout

Every few years (i.e. roughly 4-6) I will often end up having some project that necessitates auto-generating a big graph, in which case I again waste time going through all the layout engines checking if any do what I actually want, find that none do, and then waste time trying to tweak GraphViz parameters again...

That reminds me that it is probably time to give my own graph layout engine another go. Would've been for multilayered graphs with a particular flow structure 😜

(i.e. For those who know, it's basically a layout engine for Blender's DEG graphs, as I originally envisaged them - so the idea is to recursively group/agglomerate clusters of nodes which belong to some common entity. Then at each layer, just solve the simpler problem that exists at that level within the container (i.e. only layout the nodes under said parent container). Once we have this, we can then flush the required bounds for each nested layout up the hierarchy, and so forth).

My Own Dream Diagramming Tool

Of course, in the process, I'm reminded that a bigger priority is really to build my own diagramming tool that will fully work the way I want - with all the style presets, palettes, and interaction flows I've always dreamed of.

Oh, and to have this work multiplatform somehow, so I can use it on our locked-down work machines, but also on my phone (for quick sketches / doodles).

This is much much more a priority, as I do this *all the time*, and the existing tools are annoying for various reasons.

 

Congratulations to Notepad++ for 21 Years and Counting

Saw an interesting link today to a blog post proclaiming that Notepad++ has been existence for 21 years now:

 

 

https://learnhub.top/celebrating-21-years-of-notepad-the-legendary-journey-of-our-favorite-text-editor/

Having used it as my primary text editor for nearly a decade (i.e. starting roughly sometime around 2005-ish, and no later than 2006, until roughly 2014-ish), it has certainly been an invaluable tool for me personally.

 

Among other things:

* It was the text editor I used to code most of my Blender work (notably doing the 2.5 Animato refactor, and initial implementation of Grease Pencil)

* It was also the text editor I used for all my undergrad, and a big chunk of my honours project work (with Geany on Linux doing the rest of the heavy-lifting when I was using the department Linux machines)