“I never expand” - printf, Starcraft pro-player

Constraints lead to innovation. Without constrains, the road is paved and the best you can do is optimize and innovate on top of existing paradigms. That’s how, without having the option to implement a proper server-side service component, I was forced to design a way to implement partial rollout on the client side.

I teamed up with one of my colleagues and laid out the specs we wanted for our partial rollout feature: as a delivery squad, we wanted to give early access to a feature to a group of a limited amount of customers, so that we can monitor incidents while we increase the amount of customer that have access, or roll back the feature completely, in case of an unforeseen major failure:

• allocate a configurable percentage of total traffic that would experience the new feature - a percentage that we can change between 0 to 100, without redeploying the application

• don’t shuffle the users between the groups on a given configuration. Allocation should be sticky, so that users don’t see different features every time they log in

• because of organizational constraints, we couldn’t build any backend service components. We had to figure out a quick, good-enough solution, in the client side code.

We were lucky enough to find some piece of customer data that’s monotonic: unique and increasing - uniformly distributed. Once we had that, we were able to use it to distribute the individual users in a fixed amount of buckets (sharding), i.e. by modulo-operation. Imagine you have 200.000 users, which are allocated 200000 unique ID-s, integers, in consecutive sequence. You can choose to allocate them to 100 buckets, by computing their Modulo 100:

We then found a problem with this design - for every new feature we wanted to partially roll out, it was always the same users that got to be targeted:

If your user identifiers are not countable and uniformly distributed, then you will need to come up with an additional stateless transformation that would directly convert the identifiers to a monotonic sequence. If the hash function does not distribute the users evenly into the buckets, you’d risk having significantly more traffic in one or more of the buckets, and thus, the percentage you configure can be a bad underestimation or overestimation.

The crux of this design is that it only works if the traffic is evenly distributed in the buckets, and you are comfortable having the frontend decide the configuration of your features or version of the features of your app.

For more advanced designs, you’d want to include this in your load balancer and handle the allocation logic there. Then, the frontend app can request the feature configuration, which may change based on how the user session is assigned to the control groups of your new features. This approach is not only more powerful but also more secure, as you can verify the feature configuration on the server, preventing malicious users from manually accessing a feature.

Creativity isn't always about revolutionary solutions. In this case, it was about a simple, easy-to-implement change in the frontend that helped us roll out gradually without much development effort.

Once you're satisfied with a new process or ceremony that' you got it working well for your team, consider how much it depends on your involvement.

Your target is to lower that involvement to zero.

In a previous article, I shared how I created a ceremony for all Frontend chapter members to openly discuss and improve their frontend expertise and craftsmanship during a weekly "Frontend Open Office Hours". It was all hunky-dory until I realised how much the get-together relied on me to moderate, prepare the agenda, and conduct live presentations. This had to change - the frontends needed to self-organise so that I could step back from managing frontends exclusively and better mind my own development.

Reflecting back to the learnings in group-coaching sessions, I realised I needed to design a role. I called this new role the Frontend Open Office Host. This role would be designed to include all the tasks I was doing:

1. Gather agenda just before the meeting
   If the host is unable to make a non-empty list of topics, the meeting is skipped until the next week. Cycle repeats.

2. Launch and Moderate the meeting

3. Pick the next host!
   This is the part that keeps the ball rolling. Make sure the hosts does this at the 55-minute mark, as some discussion tend to bleed over the time limit. Which is fine, we want people to engage - but we also want all people present when we randomly choose the next host.
   I particularly wanted to make this part fun - we ended up using a randomiser built by one of our frontends, as a frontend challenge - go check it here.

4. Record the topics & references in our "Frontend Open Office Hours" one-pager.
   Always keep a public track of whom presented what. This helps us to jump back to the past presenters and topics, every time we need to remember something that was presented. It's also useful during mid-year or end-of-year review discussions to recognize those who have made significant contributions. Meeting logs don't lie!

You know what happened? Suddenly, more and more diverse voices began to take the mic. Although the host's role was primarily organizational, to keep administrative responsibilities to one person, almost every time, the host also introduced a topic for discussion. It is true sometimes the meeting got delayed several weeks in a row - don't be shy and throw yourself some log to the fire to keep it running.

This is just an example on how to move the needle towards self-organization - and it won't happen overnight, but the benefits are clear: a more engaged team, a culture of shared responsibility, and the freedom for leaders to explore new horizons. As I reflect on changes like these, I am reminded that the essence of leadership lies in empowering others to grow and lead. True leadership is about the power of letting go, trusting your team, and the incredible outcomes of collective growth.

Instant Push Notifications are a powerful tool. If you don't already do this, you can start by creating a "Work Focus mode" on your phone. Don't let random apps disturb you. If you're waiting for deliveries to your door, you can add delivery apps on your exception list, and enable receiving calls. Or simply put the phone in full-DND and only check on it during breaks. I'd argue the "Inbox Zero" habit should now be replaced by "Zero irrelevant push notifications"-mantra.

However, blocking or delaying colleagues that are trying to reach you is not a part of the solution, it just postpones the problems and clusters the interruptions on your own terms. I'm not saying it's a bad approach, but you still want to lead the persons that are trying to reach you, and in a timely manner. Sometimes answering a team member or reading a comment just in time may save yourself a lot of trouble in the future. What you need is a systematic, leadership-oriented approach by which you elevate the quality and reduce the quantity of your incoming interruptions. So whenever somebody buzzes you, you know it's worth switching context.

In 2021, as a Chapter Lead of 14 chapter members spread in 10 delivery squads in a large organization at full speed at leveraging Microsoft Teams, I had to find a way to cope with interruptions. It's true that leadership roles are mostly about communication, but structure is always preferred. The following method is what I personally developed and at least one peer successfully used it; so if you too are struggling with being interrupted at work by instant messages or impromptu calls, this is something for you to try.

The LOG Method

L-O-G: Log, Organise, Get :chocolate-soft-serve-swirl-emoji: done

Keep an instant messaging log, by writing down every time somebody starts up a convo or a call with you. You want to write who messaged you and why. I also label them "self-initiated" if I was the one to start the conversation.

Step 1: Log

Make the habit of logging every conversation topic for 1-3 weeks. It helps keeping this file on your desktop, or open at all times. Although I'm a big fan of jotting down in markdown or in a structured data format (yml, json), I gave in and used a spreadsheet 'cause I always wanted to Excel at work 🥁.

I group interruptions by day, and always include who interrupted and the reason why.
Here's an example from mine, based on real data; persons and some details are made up.

Step 2: Organise

Once you have enough data, start labeling logged interruptions. The category labels will come to you :) don't worry for that. You'll see how the interruptions cluster around topics.

Or don't label. Simply read them, one after another. Patterns will start talking to you.

I'd ask you to extract the categories in a separate list, and sort them descending, by how much they generate noise in your Messaging app. But that's not the case for me. I simply could pin-point 2-3 big issues that were generating noise, straight away.

For instance, if we had documented our browser support list and shared that with QA chapter, my 31st of January would have had 2 less interruptions. Not to mention 30th of January was a wreck simply because somebody in my team had misinfo on the change management process.

Step 3: Get it done - the action items

For each category, it's you, the tech leader, that needs to come up with a plan to make your colleagues more autonomous and require your assistance less frequently. For me, that meant walking all of my chapter through change management process in all its intricacies, so at least they're aware of its steps and reasoning behind it. And made sure we have clear, up to date docs on the org wiki on what devices and browsers we support. At least these two shouldn't generate noise anymore in my Teams app.

In closing, there's no silver bullet for managing interruptions - it depends on the culture of the team, on the nature of your team's priorities and how good you can cope with context switch. When reaching for my Teams window, I prioritise my same reporting line peers (my first team), my direct reports and my manager. They should always hear back from me, almost immediately.

In large organisations, information overload is practically unavoidable: you have to turn off some channels to cope with it. If the info were important, it would eventually swing back to you. But as a leader, you are responsible for how you handle instant messaging and ad-hoc call interactions.

However, what I want to focus on is the process of code review in its entirety that takes part in one or more teams - typically split into the following parts: the creation of the CR request, the actual act of giving feedback by one or more reviewers, the subsequent amendments as a result of applying the feedback and asking for a subsequent review and finally, closing the Code Review either through merging the changes into the target branch or abandoning the changes.

Trouble is, once you have some sort of Code Review process guidelines in place, how do you get large teams to learn from these guidelines and change their behaviour during the Code review process accordingly? Yes, I know, I just stated pretty much the whole mission of technical leadership. Creating comprehensive guidelines on all of the steps of the code review process, for both actors - code author and reviewer - is a good start, but definitely not enough in order to yield results.

• Only a few will read the guidelines

• The ones who do, will forget most of the details, without actively practicing. A few things will stick, depending on what each individual is prone to remember, and it can work as a "go-to" place for beginners. Still, as time passes, folks will forget they exist.

• you can link them in the Code Review template; yet again, do not expect too many people to click and skim through them. Clicking and opening a new page from a CR is an effort most won't take.

A Code Review template has better odds to yield results, if well tailored!

There's a good read on templates here, mentioning one example here and another here. I won't share with you yet another template, but I'd like to walk you through the most important bits when designing it for your team. The purpose of the template is three-folded:

• 👍 to inflict the good habits you listed down in the detailed guidelines that no-one reads

• ✌️ to as many people as possible

• 👌 on the long term

The CR template is the default free-text body of the Code Review. Therefore, it is probably the most precious and "expensive" advertising place amongst engineers in your org, so choose your words wisely, and don't overdo it. Keep it short and efficient. Give the authors the choice not to fill-in the template, instead erase it and do their own thing in the free-text area. I chose to mention that upfront, in the template.

Author should be reminded about creating the best possible experience for the reviewer

The body should include any non-obvious reason what the code change is about, how it tries to achieve that and why. If the change is one commit with a good enough commit message, then fine, just point to it. I've heard engineers say "but I am already required to link a workitem on my backlog". I don't believe that's enough: we all know the User Story is not about the "codez" so much as the acceptance criteria and the business request; e.g. it won't mention the reason why the code author moved one class from one package to another. That's for the author to explain in the CR. And few reviewers will actually open and read the workitem to gain context (kudos to you if you do!).

The Code Change should be as final as possible. Don't submit code for review that's not production-ready - unless you're asking for a quick feedback, which is totally fine, but a different process. To check upon this, in my team's template we're asking the author to write exactly how the change was tested. Manually, with fabricated inputs? Unit-tested? End to end? On a feature-testing build? Which one?

Reviewer should be reminded what's important to touch upon

And of course, to be kind 😊. Although I haven't seen this anywhere else, we chose to include a short checklist for the reviewer, as a read-only section in the template. The checklist will vary heavily on the nature of the project, so each technical lead or manager of a delivery team should have a strong say on what should be included here.

Make it fun

Or create some different intrinsic drive for both the author and the reviewer to put in the effort - don't make it sound like another chore. Ask for some creative input. Ask how they felt coding that. Occasionally publicly praise great Code Reviews, pointing to what made it stand out. Don't force it, pick genuinely good code review requests, or code reviews. I've seen people include before&after screenshots, performance metrics, or JavaScript bundle sizes comparisons.

Success indicator?

When we started this out with multiple teams in my org, I received an interesting question: How would we tell the template was successful? What would this metric be?
I would like to address this question in a separate follow-up post. Reviewing is not quantifiable. It's all up to professional judgement. What we would need to do is sample Code Reviews before and after using the template, and subjectively judge how much it made a difference.

The Talks

Let's jump right in, one by one. Note - my notes are written based on my memory of the presentation. Later I saw they were published on YouTube. Expect discrepencies.

Tug of War – Pushing and Pulling In JavaScript by Ben Lesh

Ben is best known for his involvement in writing RxJS, but also a dad of three, living in Texas. He touched upon the topic of Signals with a creative approach, the one of data pull and pushing: "Each line of code either pulls or pushes". He surprised us by creating a set of logical operations which represented syntactical transformations of Promises and Observables by the "pull or push"-pattern, which he then applied to model Signals after the same pattern - proving Signals are not, in essence, much more different than Observables.

There Is No Such Thing as a 'Generic' by Matt Pocock

Matt is best known for his Typescript course called Total Typescript. "Generic is overloaded": There is no such thing as a Generic (noun) because generic is an adjective, and it is used in constructs such as "generic functions" or "generic types". While the generic types have at least one parameter (type parameter), generic functions don't require type arguments, because they infer (resolve) the type.

Type-Safe Style Systems: The Future of CSS by Josh Goldberg, selected from ✍️ CFP

CART: Convenient. Assistable. Refactorable. Themeable. (Performant).
We were presented with possible futures of CSS - circling around CSS modularizations, "themeable-ities" and developer experience while writing and organizing styles. I see I jotted down "@vanilla-extract/" and chackra-ui. Oh, and "squiglies".
Josh couldn't find his favourite button-down shirt because his luggage chose a different flight. Luckily he got that back for the next day, and he was the one to volunteer (I presume) for a second talk standing in for a speaker that couldn't make it to the conference anymore.

New CSS Features You Can Use Today by Rachel Andrew

Rachel is Content Lead for Chrome DevRel at Google, and yeah, you could tell she's a professional tech writer; I'm just reading on her website that she has authored or co-authored more than 20 books! I love how articulate she is, providing all the right info for the right purpose on her website.
But now back to her presentation. We got a primer on CSS latest standards adopted or soon to be adopted by browsers: sizing units based on viewport sizes (svw/svh, lvw/lvh, dvw/dvh), :focus-visible ("browser: 'is focus ring required?'"), Cascade Layers, @layer framework, layout, utilities, container queries, range operator for media queries, "High Definition CSS Color Guide", color-mix, gradient.style, :not(:has(img)), @property (type, initial - fallback), Web Platform Baseline.
Never have I thought I'd write down so many notes on a CSS presentation.

Understanding Rendering Patterns by Atila Fassina, selected from ✍️ CFP

Atila learns Rust, was born in Brazil and lives in Berlin. This talk was a walkthrough on rendering patterns - including a live demo sampling a performance optimization in reactivity based on signals (hope I don't mix up). My doodles:
Abstract the DOM -> batch changes -> Reconcile
prop drilling
"tide" vs "wave" - the tide raises everyone, as opposed to the wave that only raises a subset

Demystifying Web Performance Tooling by Anna Migas

When you think you saw and read everything you could on web performance, then there's this presentation that can very well serve as a performance audit starting point. My doodles:

1. Load web performance

2. Runtime web performance - jank, code splitting, animation optimization

3. Perceived web performance - Laboratory Data versus Field Data

PageSpeed Insights, Webpack, Web Vitals extension, devTools: Network, Performance, Lighthouse.
Lighthouse: paint flashes, Layout Borders, Rendering tab -> use a different Chrome Profile
Network tab: Priority column
Time to first byte (waiting for the server to respond). SpeedCurve, Calibre

No-BS SEO for web developers by Martin Splitt

Martin put on a show. He made up (I think?) a website trying to sell toasters, in two flavours: the no-go one, and the SEO optimized. We had a good laugh since the joke was the brutal truth for many online businesses.
I appreciate how Martin creates his GIF-s out of his personal video content - and avoids any comments on licensing - I do the same Martin, with my image content. My doodles:
content, strategy, technology
"protoduction", "build an aeroplane while in flight"
a fly on the wall of a company
efficient & no sense of humour (loved this joke - how many Germans do you need to change a💡? One. Because..)
evergreen, GoogleBot, crawl budget

Security by(e) Design? by Benedek Gagyi, selected from ✍️ CFP

This talk draws attention to balancing web security and UX decisions. My doodles:
tea brewing, gongfu
Devs <-> UX <-> Security
Credentials API, Web OTP API, WebAuthn -> Passkeys

You Could Lint More by Josh Goldberg

Josh, previously selected through CFP, stepped in to hold this second talk as a replacement for a speaker on the agenda who couldn't make it to Timisoara because of personal reasons. The title is spot-on: indeed, es-lint is a gold mine for teams. My doodles:
--max-warnings - create a gate of a maximum number of warnings allowed in the CI pipeline. eslint-plugin-deprecated, eslint-comments, eslint-plugin-jsdoc, eslint-plugin-markdown, eslint-plugin-perfectionist, eslint-plugin-regexp regexp create-typescript-app, warp - terminal, vitest, pnpm

The Ethical Choice by Alex Moldovan, selected from ✍️ CFP

This goes beyond accessibility or UX: what choice does it feel to be good or bad for the interest of the user when designing web experiences? We all know the annoying tiny "unsubscribe" links lacking contrast. Or the "opt-in" default selection. Yeap, those. I'm happy somebody framed this topic in a talk.

Have You Heard the Joke About Async Debugging? I Promise It Is Good. by Jay Phelps

Async issues are the worst! Not to brag, but I spotted the one in the talk on time. Jay was top of the game on teaching - he led you in solving the mysterious bug by yourself. I can't wait to show this talk to my team. My doodles:
"input" event - including Paste
request coming back out of order
typescript-eslint/return-await: "error"

Breaking Down JavaScript Complexities With Generative Art by Ritvi Mishra, selected from ✍️ CFP

How many of you are visual learners? Ritvi showed us how one can learn Javascript as their first programming language by coding visualisations: such as visually describing the steps in repetitive structures or the call stack.

Node.js in 2023 – What’s New in the Node.js Native Test Runner by Erick Wendel, selected from ✍️ CFP

I have to admit that this talk stretched my Javascript knowledge and attention. Erick is a high performing professional, contributing to nodejs's native test runner. Kudos for an enjoyable in-depth walk-through of such a difficult topic. My doodles:
v-test
TAP - protocol
dot; spec; junit; lcov
test sharding & concurrency
why-is-node-running

Testing Your Testing Strategy by Trent Willis

I empathised a lot with this topic: what types of testing and how much testing do you need? How do you know "you're good" or "yikes, too many tests to maintain, are they really paying off.."? My doodles:
The value of testing is in quality, not in quantity
Optimize invested time versus confidence. The trouble is - confidence can't be quantified noti.st/trentmwillis

Requiem for APIs – The Evolution of Web Development by Ciprian Caba

Ciprian created a sort of "time-lapse" for web development, showing us how the data rendering into the presentation layer has circled back from server to client to server, and pointing out API-s can get obsolete, once we use the full abilities of the new frameworks that can simply access the data model directly, on the server side.

Beyond the Web of Today by Kenneth Rohde Christiansen

I had no idea about all the work involved to better support high-level API-s from the producers of hardware processing units. We're talking hardware that can speed up software related to (but not limited to) computer vision: blurring background, virtual background, eye-following, real-time visual filters, as well as anything that involves tensor calculus & whatnot. A hard subject. My dribbles:
Project Fugu
Web Codecs
WebGPU, NPU / TPU, Web Neural Network API (Web NN)
ONNXM, MediaPipe, OpenCV.js

The Vibes

I can't thank the community of professionals in Timisoara enough for making revojs happen. I know it isn't easy. It takes time, energy, commitment, lots of helping hands, and sponsors (and trust me they do need a lot of sponsorships for such a scale of an event). The thing is - their commitment and their helping hands are something money can't buy for a conference to take place - and that's what makes revojs so special.

Most of the participants are part of the local community. Both of the times I travelled by myself to the conference and made friends on the spot. This time, however, I couldn't see anyone familiar at the after-beer outdoorsy party, and I was fortunate enough to bump into Jay while ordering drinks and, long story short, I ended up having a great time drinking and chatting with all the speakers at the party, for hours. I even realised I had been walking very close to Matt's home address in Oxford when attending RenderConf 2016. Such a small world, isn't it?

Who would have imagined I would one day have a drink with Matt and talk about that conference in his hometown? Can't wait to see what the next revojs has in store.

The law says that:

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody

One colleague (desperately) needed to access a couple of properties of a web component that was developed and maintained by a different team, but consumed in his own micro frontend. For the simplicity of the example, let's consider the default web component generated by OpenWC's npm generator:

class AppMain extends LitElement {
  static properties = {
    header: { type: String },
  }
...
   render() {
    return html`
      <main>
        <h1>${this.header}</h1>
       ....
     `;
    }
}

Consider you'd be consuming this component in your template

<app-main></app-main>

And you, as a consumer, imagine yourself not knowing the implementation of the component, but needing to access the data rendered through the means of the header property. You'd probably select the element in DevTools, then jump to Console, type $0. and see what properties pop up. That's the exact process one colleague followed and ended up using the hidden dunder property (double underscore property) - the equivalent $0.__header in our example.

Lit's quirks

So what's up with lit shadowing any .property in a .__property? Why is there a property called __header with, surprisingly-not-so-surprisingly, the same value as header property? Well, we've run into an implementation detail that at no point was intended to be used by component consumers, or any developer building web components on top of lit. But since I can't leave you wondering, lit's actual component properties are setters and getters, whilst the true value is stored in this hidden dunder property. By the use of this wrapping, at any point, lit can detect when the setter is writing something different than what it's already stored so that the rendering cycle, as well as update hooks are triggered only then. Simple and effective!

Fun, hackish experiment: If you do set a value for __header, it won't trigger the render process, since you're bypassing lit's setter, so the template will not update. If you then do set the exact same value through the header property, again the render cycle will be skipped, because it would be compared against the value in __header.

Advanced Deep Dive

If you reaaaally want to see the bottom of what I just explained, then head to lit-element's source code. What we call properties, are actually called accessors or descriptors in lit, and one can implement and configure a custom accessor, should someone need a different one, for a given property, on a given component class. As far as I can see, the property itself, created on the prototype, is an accessor, while the assigned value is called a property descriptor.

  static createProperty(
      name: PropertyKey,
      options: PropertyDeclaration = defaultPropertyDeclaration) {
    // Note, since this can be called by the `@property` decorator which
    // is called before `finalize`, we ensure storage exists for property
    // metadata.
    this._ensureClassProperties();
    this._classProperties!.set(name, options);
    // Do not generate an accessor if the prototype already has one, since
    // it would be lost otherwise and that would never be the user's intention;
    // Instead, we expect users to call `requestUpdate` themselves from
    // user-defined accessors. Note that if the super has an accessor we will
    // still overwrite it
    if (options.noAccessor || this.prototype.hasOwnProperty(name)) {
      return;
    }
    const key = typeof name === 'symbol' ? Symbol() : `__${name}`;
    const descriptor = this.getPropertyDescriptor(name, key, options);
    if (descriptor !== undefined) {
      Object.defineProperty(this.prototype, name, descriptor);
    }
  }

But what about Hyrum's law?

Lit dunder properties were never meant to be used. However, since they're observable, and usable, voilà.

Strongly typed, mature, compiled, object oriented programming languages like C++ or Java employ the use of Access Modifiers, offering developers the possibility to precisely define which members of a class can be used (depending on its type, you can read it, set it, execute it etc.). All you need is the following cheatsheet:

Typescript uses access modifiers as presented before, but the concept is called Member Visibility, and the list is shorter, only three - private, protected, public - where public is the default and no sane person specifies it explicitly in code. There's no need for "default", as Typescript does not have such a strong notion as packages in C#/Java. Moreover, as stated in their docs,

Like other aspects of TypeScript’s type system, private and protected are only enforced during type checking.

Javascript itself didn't have any encapsulation, until recently. It's called Private class fields and .. you guessed it, it allows you to explicitly prevent your consumers from directly accessing specified members of your class.

Class fields are public by default, but private class members can be created by using a hash # prefix. The privacy encapsulation of these class features is enforced by JavaScript itself.

class ClassWithPrivate {
  #privateField;
  #privateFieldWithInitializer = 42;

  #privateMethod() {
    // …
  }

  static #privateStaticField;
  static #privateStaticFieldWithInitializer = 42;

  static #privateStaticMethod() {
    // …
  }
}

The browser support is good, but not fabulous. The syntax is understood by Chrome >= 74 (April 2019), Safari >= 14.1 (April 2021), so if you want to go lower with supported clients, consider transpiling your production code using babel >= 7.14 which enables the required plugins by default, or include them yourself in the transpiling configuration.

I've seen great enthusiasm throughout my team for adopting this level of encapsulation, despite adding one more concern (class member access) to the JavaScript developer; a developer previously spoiled with simplicity, but simplicity that may backfire on long-lived software. As they say in Google, "Software engineering is programming integrated over time".

At my first (actual) job, I used Zope2, a Python framework that, for that version, was able to hold code and templates in its database. The database was not relational, but instead, a tree-like structure of objects, called ZODB - zope object database. I see both projects are actively maintained.

In a big tech I had to migrate some API clients that were written in Perl, while some template rendering was done in Mason. What stuck with me, was that Mason scripts had some kind of delimitation of execution context; they had some kind of header that was being executed in a faster manner than the rest of the script. Can't remember much.

In spring 2022, I went through Primeagen's Solidity class on frontendmasters when I was doing "my research" on non-fungible tokens and blockchain tech. I don't see myself coming back to that language, but it did showcase a framework in which operations matter in terms of cost. Directly. In 2022 I also watched Richard Feldman's class on Rust - the way you could "cast" the life span (lifetime) of the allocated memory for a variable to an annotation ('a) - that, that stuck with me. Probably, on this list, Rust has the highest potential to find its way into my keystrokes again.

Reminding myself of computational cost and memory brings me back memories of all the obscure development environments I went through in my 4-year Computer Science Bsc - Assembly (mnemonic processor instructions), Matlab (actually Octave, useful for running numerical algorithms that approximate or sample continuous signals), Verilog (simulating simple logical circuits or more advanced electronics, using static gates as well as clock based circuits). Then we have the other programming paradigms that we experimented in, as students: Prolog (solving the Wolf, Sheep And Cabbage Game), Clips and Haskell (functional programming).

Can you top it? :) What's your less-popular development experience?

As I was saying, this is a framework for brainstorming initial ideas. Don't rush me into theory on Product design. It's up to you to iterate on the ideas you will produce, by using Design Thinking and other techniques as such. You're free to start writing your business canvas.

But before experimenting and pivoting on a solution, you first need to find the problem to address. And that's why "thinking of an idea of an app that does something" just so you can practice or learn a new technology is so difficult: because rarely do we search for a market of customers, just because we have a certain technology at hand. It's like buying a fancy hammer, before knowing whether you'd have any bolts to hammer in.

Offers vs Ameliorates

It comes down to understanding what the technology offers and what problems it ameliorates. It's a subtle difference, and it's easier to explain by using an example. If we look at Dall-E, it offers a way to generate images based on a natural language definition. But it can ameliorate a lot of needs, such as obtaining images based on a brief description, ready to be used, without the hassle of contracting and/or paying for a license. Maybe you're a magazine editor or a publisher looking for your next cool book cover. The cover of this article was generated by Dall-E using the prompt "a lightbulb surfing a wave".

Once we figured that out, we move on to synergies: yes, you guessed it, combining the technology advantage with your added value, if they're a good mix!

Your Added Value

A good example of added value here is unique data. Something no other possesses. Do you have an encyclopedia you built on all possible water sprinklers ever produced? Do you have unique cooking recipes from your ancestors? Extensive documents of architecture in your organisation? All of these may be the subject of your next unique idea. It doesn't even need to be structured data, because that's something OpenAI can do for you. Just try to match your data with the technology offerings in order to list new problems your potential solution ameliorates.

Water with a drop of dish soap

When practising the steaming of the milk for latte art, using an espresso, a fairly good replacement for actual milk is water plus a drop of dish soap. Works like a charm fairly similar to milk.

You can do the same by looking for synthetic data or producing it yourself. And you can do that with GPT itself ;) I found this data set on data.world (under BY-NC-SA license by Datafiniti). It contains a bunch of customer reviews of their purchases - mainly Amazon hardware products, such as Kindle. I created a prompt where I asked for the topic to be changed to something that I needed the reviews to be about.

I.e., if we consider this real review of Kindle Paperwhite:

Great for those that just want an e-reader I am enjoying it so far. Great for reading. Had the original Fire since 2012. The Fire used to make my eyes hurt if I read too long. Haven't experienced that with the Paperwhite yet.

..when asked to change the topic to a restaurant, "text-davinci-003" model will return:

Great for those that just want a meal I am enjoying it so far. Great for dining. Had the original restaurant since 2012. The restaurant used to make my stomach hurt if I ate too much. Haven't experienced that with this restaurant yet.

The repo is on my Github; please pardon my clumsiness in Python and pandas - it's been a while (about 8 years since I last wrote some py; but not much has changed I see).

Iterate

This. This is the part where you dive into Design thinking methodology; of course, if you want to go out there and build a service for actual users.
Otherwise, if you just want to try out your technology of choice, simply start prototyping your fresh idea.

How did you find your latest idea?

Will is CEO of codesmith.io, a top-ranked coding school, online and in NYC. That's the bit I didn't know about when I came up with the idea of documenting his class.

How I stumbled upon JavaScript: The Hard Parts v2 class

In my organisation, we dedicate about 1 day out of 10 sprint days for self-development; yes, that's during office hours, I'm not talking about moonlight coding - or at least that's the deal on paper. You probably heard of something similar taking place at Google, on Fridays - that's how Gmail was born. But here, we choose to invest it in the development of our craftsmanship. We're taking this study time in an organised fashion, in alignment with one's development plan. Otherwise, it would just sound like a day off to read online content.

As a Chapter Lead, I struggled to make my chapter take this seriously. Engineers have a greater incentive to perform to the goals of the tribe, so they often commit to the delivery for the entire sprint-time, rather than saving some for their own learning and development. Of course, it is a trap; in the long run, we're rotting as engineers, becoming blind to innovation opportunities and growth. Becoming better professionals would benefit the organisation, the projects, and the effectiveness of the delivery, as a whole.

To move the needle, I become more aggressive in decisions: I asked a colleague to pick a class on Frontend Masters (really, any class), by 5 pm the same day, or else I would make this choice for him. So I chose JavaScript: The Hard Parts, v2. Since we're working a lot with web components, and we're converting business logic from AngularJs to Vanilla Js classes, it looked like we need strong JavaScript-skilled engineers with proper ownership of the fundamentals of the language. Not just frameworks.

And so, a couple of weeks later, my colleague returned to provide his thoughts. Bracing myself for harsh feedback on my choice of topic, I got particularly enthusiastic to hear that he considered the class amazing. "We all use and think we know those things, but it helps to understand their underlying reasoning once again".

Just after Christmas of '22, I had some spare time and gave it a shot. I went through the class myself. The content - indeed, fundamentals of Js. But I was immensely impressed by the manner the class was built and delivered.

I studied Will, I decomposed his style, his setup, and his props, and I reverse-engineered his recipe to three key advantages:

1. Distraction-free teaching "props"

2. Live audience - In-person participants

3. Smart use of creativity

Distraction-free teaching props

Will is using a blackboard and white or colourful markers. He's not employing any digital means. He's not typing code, he's writing it, by hand. The representations limit themselves to basics: global scope, local scope, and execution stack. When needed, a slide with code pops up.

Live audience - In-person participants

Will is not recording himself teaching the class to a camera, or to a virtual participant. He has actual participants sitting and learning physically in the same room. They don't appear in the footage, maybe just rarely when one is "called to the blackboard". You get to be an actual spectator to the learning activities taking part between Will and his trainees. I've seen this before and it's highly beneficial:

• you get a sense of what is expected to understand or to have trouble with, in each moment, because the real people in the class will articulate that. You will feel what they feel. You will share their silence when some concept needs time to sink in.

• it's auto-paced by the audience. The trainer will adjust speed and level according to a tight, real-time feedback loop with the audience. Will stops after every milestone, to ask how much they understand:

  • thumb up = I got it, move on

  • thumb down = I don't get it

  • horizontal thumb = I need to ask a question

I said I saw this before - ages ago when I started learning German, I ran into the so-called Michel Thomas Method which, besides many other techniques specific to foreign language learning, also leverages the power of having actual people participate in the act of teaching together with the trainer, while the class is being recorded for a much larger, remote, audience.

Smart use of creativity

Many engineers display passion, but it takes skill and creativity to convey it in a catchy manner, in a phrasing that sticks. It takes some degree of creativity and lateral thinking to portray a JavaScript closure as a backpack that gets carried by a function that's returned as a value.

Teaching styles are different,

But some stand out. And by no accident, with solid experience in his backpack, Will Sentance is a model for the teacher in me. I wouldn't rush out the door, into buying and installing a blackboard. It's not about techniques one can copy. It's about having the act of teaching in the centre, with a spotlight on the main actor - the trainee, not the trainer. Whenever you're building a new product, all decisions revolve around the potential customer. If you look at teaching as a product, then yes, you have to put the participants first, preferably in person, in the same room with you.

Let's see how each type of team has the privilege of a collaboration scene:

If we take a two-week sprint, the squad has a net advantage on time spent together: 1-hour planning + 2h grooming(s) + 1h retrospective we get 4h, not to mention the daily stand-ups, 10 x 10mins equaling almost another 1 hour and a half.

The chapter has its chapter meeting which can be weekly or once per sprint .. and, that's it. I needed to address two issues the chapter faced in the tribal model, that few talk about:

1. The chapter is disadvantaged on time spent together. It can never compare to the time spent in the squad. The squad takes first place in the hearts of the people. It's hard to compete with people striving together in the same sprints, the same backlog, and that get to hear one another every. single. day.

2. When domains of ownership fall short in between squads, the Chapter (Lead) is the one all people reach for. I've seen it too many times - the Chapter Lead becomes a proxy for any chapter inquiries from other areas.

I felt there was room for something that can address both, so I created a public, free-to-attend, 2-hour weekly meeting with all frontends, having them work in one big room, which I called Frontend Open Office Hours. When we transitioned to hybrid work (read "remote work"), we switched to an online Teams get-together meeting which proved to be well-suited for code sharing and live peer programming with an audience.

As I much later read about it, in "An Elegant Puzzle" by Will Larson, one of the time thieves, interruptions, can be fought with

"A strategy here is to funnel interruptions into an increasingly small area, and then automate that area as much as possible."

Yes, he was referring to cookbooks, opening request tickets and such, but this weekly meeting was my way of funnelling questions.
To make it successful, you need to tick the following boxes:

• make it accessible to anyone in your organisation. I organised the meeting under a public Teams channel, and the chat is also visible to anyone.

• invite other people to join, but don't push the meeting into their calendars. Simply advertise it every time they have a question - "Why don't you come by during our Open Office Hours? And ask us there, I bet my colleagues can help you even better". Make it grow organically. People will talk about your Open Office hours!

• invite your chapter to bring up questions or impediments in their work. Create the necessary psychological safety to ask any questions.

This is the exact wording of our Open Office Hours, which runs weekly, on Wednesdays, from 3 to 5 pm.

Weekly, during this interval, the Frontend One chapter is available to all colleagues, in this Teams call, to answer any frontend-related questions. Best to send us your questions beforehand, but we also welcome spontaneous walk-ins. If there are no questions from guests, we'll just mind our own business and share our project-related issues during the call. You are nevertheless welcome to attend, Thank you, Mihnea

Things I observed after running it for so long:

• don't expect too many visitors. People will get very excited that they too can join this get-together of developers, and that they can ask any questions - but they won't :) We're all so very busy with our work; at least there's no slack for that in my org.

• some open-hours will be crazy short. It's not a problem, some weeks are dull, and others are more eventful

• other times people will take the opportunity to chit-chat. Let them be; people need rapport, especially when working with remote teams.

• take the opportunity to spice up the series with interesting talks and showcases. Show them interesting cutscenes of online classes, or short conference talks on youtube. Show them the Wat talk. Have fun as a team!

• everyone in the organization will talk positively about the transparency and collaboration of your chapter. Great teams are teams that make room to help others.

If you lead a chapter, let me know how else you encourage efficient collaboration and transparency. If you're not doing it already, would you dare create a recurrent call for Open Office Hours and advertise it to the other chapters?

I'm writing this so you don't have to spend the same amount of time on the course; although if you care about the Web and its fundamental principles, I strongly encourage you to do so. It's free and it's enlightening.

My prior knowledge of Accessibility, before attending this course:

• there are contrast thresholds readable text should meet

• use descriptive alt attribute for images

• use appropriate css units for sizing font (em)

• one should be able to browse a website or use a web app without a pointing device (keyboard only)

• something with aria

• some online evaluation tools can score the accessibility of your website

• a11y is the numeronym for accessibility

And that was it.

What I was looking for:

1. Theory, but in a practical approach. The school was cool, but we need real-life usable stuff shipped

2. Structure

3. Fundamentals on which to build upon - not just tips and tricks

Theory

All great stories start with a history lesson, and accessibility makes no exception.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect said Tim Berners-Lee, W3C Director and inventor of the World Wide Web.

And because we're greedy and hungry for the greatest, the fastest, the bestest ways to grow a business, policies and laws were required to come in place and protect people. People are imperfect - we don't see, hear, move, or infer with the same acuity, and most often than not, not because of their own fault; not that it would matter. People are people, and in the society we want to live in, we ought to use technology in the interest of all human beings. Not just the young, the sharp, the healthy, the genetically lucky ones, the ones privileged in society. Let's remove the word privileged as much as we can.

The course is not intentionally sentimental, but it does showcase people with all sorts of disabilities. You will step into the shoes of disadvantaged people. You will become emotional, realising how lucky you most probably are. Statistically, there's an 85% chance you have all your senses and your motor function in good shape to browse and to read and understand the content on, say, this Hashnode blog. Some people would have to use a keyboard with the aid of a stick in their mouth to get here.

WCAG - Web Content Accessibility Guidelines version 2.1 is what you're aiming to adhere to when offering your services on the web. I like how the course is spot on from the start: Don't jump to the standard. Half of it explains how the other half should be read. It's a show-stopper. Instead, the course introduces a less scary approach. And provides structure.

Structure

There are two types of approaches people use to improve the way they interact with technology:

1. Through the means of assistive technologies, meaning software or hardware that helps people more easily operate. I.e. a screen reader, a switch control, or even ordinary glasses!

2. By employing adaptive strategies such as enlarging font size, changing contrast or resizing a window. Some people need to enlarge the font and window width, others, surprisingly, read better when the text is smaller and the line length is much shorter.

The second module of the course focuses on these two, grouped by the types of disabilities: physical and visual, hearing and speech, cognition and learning.

The third module is all about business cases and benefits; probably the dullest, at least for me. Accessibility needs no business case, but in case you need some, they can be easily found.

The fourth module is the real deal, diving into WCAG 2.1 fundamentals.

And the fifth is just as dull as the third. It's how to lure the important stakeholders in the organisation into accessibility. How to get started. I'm not sure one can make a real-life working guide on that, but I should however appreciate the Shift-left recommendation. I'm seriously starting to laugh every time I hear shift-left. So much shifting that one starts to wonder what's left on the right-side of the delivery, but that's for another story.

The key takeaway on the shifting is probably that particularly the persons involved at the start of the product design process (product designers, UX architects, project managers) need to have a working literacy on Accessibility, so issues are addressed earlier in the process. Don't leave Accessibility for the last week before the first MVP go-live.

Fundamentals

W3C WAI contributes with not one, but three guidelines:

1. WCAG - Web Content Accessibility Guidelines; the most popular ones, regarding Web Content.

2. ATAG - Authoring Tool Accessibility Guidelines; guidance in building accessible software used by content creators. Imagine the admin panel of a blogging platform. Or the "Create a Post" page of a social network.

3. UAAG - User Agent Accessibility Guidelines - for browsers, media players and other user agents.

WCAG defines four principles:

1. Perceivable - techniques for making information available in different ways.

2. Operable - In addition to perceiving info, users should be able to operate, navigate, fill in and submit forms, and have some sort of interactivity with the application; to do so, they might employ a mouse, or no mouse at all and stick to keyboard only, sip and puff, speech input; yes, some people are limited to simple switches because of their lack of mobility and their difficulty in speaking.

3. Understandable - both information and functionality; use simple vocabulary, make intentions clear, and be explicit on what is required and in which form. Don't make the user think or guess what is expected on his/her side.

4. Robust - Reliability when rendering the content or running the application on a variety of platforms. If it's web content or an app, it should run without issues in any present or future version of a major browser. If it's multimedia content, we should expect to behave the same on multiple players.

Technical dive-in

On a scale of 1 to 5 on technical expertise, you need a 2, but it's not a hard requirement to follow through. The course only scratches the surface, for both web content and mobile apps - iOS and Android.

You will need some tiny knowledge of HTML and to be able to grasp basic native UI elements, like backward and forward navigation, gestures and haptic. That's it. The material is not designed for engineers. It's universal.

Key takeaways

Accessibility is important for anyone who cares about people, before any policy or checkbox that we need to tick off, in our large business or for our small project. Following accessibility guidelines never stops, it's not a one-time process. It needs to be embedded in the design and delivery process. The sooner, the better, the cheaper. Just like you strive to do with your other non-functional requirements.

You only truly know your accessibility makes a difference when testing with real people. Evaluation tools can mislead. Ask for feedback from people having trouble using technology, older people, your grandparents; reach out to organisations for people with disabilities. I bet they can't wait to help with feedback.

Thank you for reading, and keep caring!

In my country, the exam has two parts: a "road" test on the sea and a written examination, a lot like the one for the driving licence - it's composed out of 26 multiple-choice questions. For each question, there are three answer choices, one and only one is correct. The authorities were kind enough to offer for free download a large batch of sample questions. However, all the data is presented in a big big table spread in a multi-page PDF file. Which looks like this, and goes on for 20-30 pages:

Each line in the table represents a question. Then, each column represents an answer choice, each choice followed by another column - with values 0 or 1, whether the choice is correct or not. Luckily, I managed to take all that data by using the Preview app in MacOS - I simply Selected All -> Copy -> Paste (in vim or any other text editor), and I was able to make some sense of the data.

I did so by writing a nodejs script that would create an Array of meaningful objects. Typescript types are simple enough to use them in order to demonstrate my modelling:

type Answer = {
    text: string,
    correct: boolean
}
type Choices = [Answer, Answer, Answer]

type Question = {
    text: string,
    answers: Choices
}

// some sample data
// only for the sake of the example
const answers : Choices = [
  {text: 'fine', correct: false},
  {text: 'awesome', correct: true},
  {text: 'great', correct: false}
];

const question : Question = {text: 'how are you', answers}

It looks fancy in Typescript, but honestly, I simply wrote a node script to dump it all in a big JSON file and get the job done. I believe proper domain modelling is key to a successful system - whatever engineering you'd be doing.

Nice. We have data with meaning. Now let's create the presentation layer (aka the UI!) and then let's add interactivity to the UI, so we can have feedback when actually simulating an exam (aka the Frontend!). Since in ING we are advocates of Web Components, I always wanted to give this stack a try for side projects. I jumped right into open-wc.org and used the npm generator. Everything worked precisely as expected. It was a breeze since my Chapter is using lit every. single. day. So I could finally get some mileage myself, in writing lit. At work, as a Chapter Lead, I prefer to spend my time more effectively for the team, rather than coding new features by myself; my chapter does it better anyway (#proud).

You can take a look at the simulator here. There are also quick deployments for each topic - seamanship, navigation, maneuver, COLREG, RND - fresh water regulations. Caution: all texts are in Romanian since the data source is in Romanian anyway. But you get the gist.

What I saved for later (read: never)

Things I skipped on purpose, because #shipping:

• unit testing

• styling

• creating a proper API, rather than big bulky json-s sent to the client

It's funny cause when I put a screenshot in here, my design looks like a big billboard ad 🤭

No compromise on

Things I did not want to skip, no-matter-what:

• create a minimum viable product, have it attain its purpose: helping people learn for the test (d'oh!)

• deploy it on a webserver and share it with my awesome sailing class colleagues

• make it Open Source on github. However, you have to download the full PDFs and run the data conversion yourself. I did not want to include that in the project for a couple of reasons:

  1. it's not my data, I do not have a license to distribute it. Best I could do is package it differently and use it as a support for a free, non-commercial web-app.

  2. hey, data may change anyway

• sharing this diary page with you 🤗. I didn't want to skip that.

When did your engineering skills help you get through with something totally unrelated?