How to care about technology watch in a healthy way? 📱🧘🏼

Part 3 out of 4

This is the third post in a series of four articles
about how I came to appreciate software technology watch
as part of a tailored-made self-education process,
deemed bearable with regard to mental health preservation
in the context of my line of work since 2009.

The first article and the second one are also available nearby.
By subscribing to Sioukam’s Letter,
the next articles will be delivered to your mailbox.

---

Approximate reading time : 6 min

Readers I had in mind when drafting:

• craft·wo·men longing for life - work balance ⚖

Overall progress in this series: 3 / 4
🟩🟩🟩⬜

Tags: #MentalHealth #Toolbox

---

...So You Think Your Job is Monotonous! - https://w.wiki/5dtg

Are tedium and fatigue
two faces of the same coin? 🎭🪙

Who has ever heard of "JavaScript Fatigue" over those last years?

In [web] development, we often hear of software composability,
or modularity as holy grails and yet, most of what the market always wants,
is very much attached to this strangely shaped feature requirement
nobody has ever heard of,
nor ever seen before bringing implacable success
with its discovery (or so we’re told by modern myths and legends).

Have your ever felt like you only have this cube-shaped artifact
or that other circle-shaped piece fitting absolutely nowhere else
even though both turn out to be quite elegant at times?

Fortunately, long-lived communities appear to also thrive
with some of their efforts focused on

• bringing more

  • openness,

  • diversity with proactive inclusion,

  • humane thoughtfulness and

  • decency coming in so many colors, shapes and cardinalities
    (I don’t have hard numbers or statistics,
    only hopeful thoughts and beliefs -
    and I’ll surely be able to fix all reported mistakes 🤞🏼)

• organizing efficient standardization committees and task forces 
  (like IETF meetings or councils taking place around the world like NRO's)
  - to be honest, I don't know much about those only that they exist
  and apparently they are regularly prepared asynchronously and remotely 🪄

• publishing code of conducts while making a point in enforcing them
  as faithfully as possible although navigating intersectionalities
  doesn’t get any easier,

• demonstrating living documentation or specifications,
  revealing how shortening (or lenghtening) feedback loops
  may not equate to additional pieces of software shipped to production
  but less or better yet, by figuring how to make
  some programming team happier💃🏼
  by a raw count of total unused ¹ lines of code removed from version control,
  to be celebrated by all those who feel like it among team members,

• revealing achievements and milestones 🧭
  to all participants of

  • product discovery sessions,

  • product refinement or

  • bare meeting about what needs to be done,
    as soon as a domain’s corner has been deemed sufficiently covered
    so that we could identify confidently aforementioned milestones or
    that no more effort is to be safely provided
    until another breathable room is made available again 🥱

• animating collaboratively aforementioned
  discovery workshops in exploratory, and funny ways.
  I’ve had occasions for playing with actual lego bricks™ and,
  board games with former colleagues to develop a more natural sense towards in-situ and less-wrong decision-making processes,

• allowing one to move from "old" ways of doing things to
  "newest" ways of doing things
  without necessarily wreaking havoc
  among both her peers and datacenters 🌪
  even though new and old are essentially
  a matter of zooming in or out
  a fixed period of time,
  which is definitely not that long for software development
  (considering roughly the 500 000 years of homo sapiens lineage)
  and all computers glitches in history

However technology buses (or silver bullet trains if I may 🚆)
don’t get any less difficult to catch,
and while the landscape for hiring software developers appears to be rather tense
(in comparison with other fields of professional activity in a larger picture maybe?), implementing robust solutions could only look even fancier
when pinning so many constraints on one’s toolbox :

• collaboration in designing solutions and,

• implementation while

also remaining within reasonable i.e. affordable time / space / price territory, infrastructure cost.

At the end of the day, aren’t we all fashion victims,
all dressed up in shiny clothes made-up of brand-new tech constructs
in meta-realities of jobs serving segmented industries on steroids
(or pumping energy from electric batteries ²)?

Does one have to necessarily be picked as a
«web-rounded full-stack T-shaped cloud-native
solution designer slash developer
playing well with others and compilers» and
when delivery times come,
to be able to fallback to artifact verification mode?
(by manually typing and clicking all around,
which of course is a requirement in our field most of the time)
- or are such constraints only featured
as gatekeeping buzzwords in online job boards?

Who could have manufactured better ways
to partition (recruitment) campaigns
so that they look as complicated to precisely map,
without saying much to both insiders and outsiders alike
about a product to be built or a team to be part of
(with exceptions to be emphasized when
we can meet with future fellow team members)?

I'd venture to say that not so many people
might need real convincing when debating
the generalization of this JavaScript Fatigue
concept to a much broader Tech Fatigue.

Today, I'd like to share with full acknowledgement that
I've lured myself for good and for long until it was nearly too late,
into thinking that trying to stick with
cleanly defined technical trends in professional environments,
a.k.a. programming paradigms would be something to wish for,
whereas all along opposite scenes were unravelling before my sore eyes
(blue lights eventually got me those light-filtering lenses 👓).

Teams seem to have anisotropic features
(i.e. they don’t have the same properties
depending on wherever direction one may look at it from)
much alike an observable universe model
(only much smaller, and warmer 😌)
and there often seem to be an adherence
between problem spaces regions and teams members.

Their familiarity with multiple product features and
the roughest edges shaping history goes well beyond
the choice of programming styles
and also seem to have compounding effects
with both intensively influencing factors
(tech leads and product managers decisions
may have dramatic impacts on teams effectiveness)
and extensively influencing factors
(the raw number of team members available for instance).

All that being said, I can surely also nervously smile
about this uncomfortable posture
with regard to trying to stick as much as possible
to a specific programming aspirations while we’re at it 😓😅😬.

See the following expressions ending with programming
but not exclusively (sorted by ascending personal preference
and also accessorily approximate times of personal encounter) like

• imperative _,

• declarative _,

• event-driven _,

• object-oriented _,

• agile _,

• test-driven _

• behavior-driven _,

• aspect-oriented _,

• data-driven _,

• functional _,

• concurrent _ and so on, etc.

Try to picture “silly me“ believing these topics
might somehow push us (as in former product teams) forward
in the direction of more fulfilling tech careers
when a even cruder parallel reality might have been about
being irrevocably pulled in whatever most-suited direction
this industry of world-eating, climate-warming software production
as a whole would rather led us to think of,
as the golden standard of a very short period of time,
into which we should throw ourselves wholefully towards
to basically bring food on a table in the end
by forcing flattened rocks into computing things, anyway.

That’s all, folks 👋🏼 Congratulations for staying with me!

We’ve wandered off a little on this one.
However, we’ll return to more on-topic subjects
in the last article of this series. I can promise you that.

---

This was the third post in a series of four articles telling a story
about how I came to appreciate software technology watch
as part of a tailored-made self-education process,
deemed bearable with regard to mental health
in the context of my line of work since 2009.

1. unused: this single word alone might rise some strong level of controversy
and fiercely defended opinions though.

2. To reuse a metaphor from Cloudmoney, authored by Brett Scott
BigTech and BigFinance could be seen as being reunited
under an umbrella materializing as the giant network, that Internet is.
Submarine cables are only part of a larger nervous system,
where datacenters would be similar to neurons computing outputs
from states and power sources.