Rust rules among programming languages used for WebAssembly projects, but Blazor (C#) is coming on strong.

Most humans need to think both abstractly and concretely; we often switch without realizing it. As a result, when we start to think freely about what’s happening at our jobs, even when we think we’re contemplating abstract obstacles (“it takes too long to gather feedback about pull requests”), we often think about the specific people who “cause us problems”. This is an aspect of switching from abstract to concrete thinking. Sadly, this intensifies personal blame, which both strains our relationships and leads us towards learned helplessness: “people don’t change, so there’s nothing we can do until they’re gone”.

Mapping the value stream of your work system helps shift focus away from the people towards the activities themselves. When I do this with clients, I encourage them to imagine the work system from the point of view of the pieces of work traveling through it, which orients their thinking towards activities, rather than individuals. This not only reduces the likelihood of blaming people for obstacles, but it also subtly transforms thoughts of “me against them” into thoughts of “us against the system”. It rallies people around common obstacles and encourages working together to “defeat” the system. This makes mapping the value stream more than merely a specific way of modeling bottlenecks in a work system.

Win-win.

Cynefin has entered the chat

At the same time, some folks worry that by mapping the value stream, we’re applying Complicated thinking to a Complex domain, which ignores key confounding factors that we truly need to consider. I understand their concern and even share it; however, I note two things:

Most work systems are organized such that even a Complicated approximation, such as a linear value stream map, is enough to suggest significantly-helpful improvements. Applying Complex thinking is often an optimization that almost always helps but might trigger resistance, because it’s generally harder to do well. (Sometimes, Complex thinking leads us to feeling paralyzed by choice. There’s always a more-important feedback loop.) If you want a more-powerful tool, perhaps Eli Goldratt’s concept of Inherent Simplicity would fit even better, but most people need an easier place to start making progress. Most people find it easier to start by learning to map a value stream, then using the resulting increase in slack to facilitate bigger-picture thinking.

Most groups find themselves in a situation where they’d benefit more from promoting collaboration more than they’d risk by approximating their work systems as Complicated instead of treating them as Complex—and by a wide margin. Cultivating an environment where collaboration happens spontaneously is generally more urgent than deciding once how to adjust the flow of work through the people involved. Increasing collaboration creates more opportunities—and more-powerful ones—to improve than merely rerouting tasks.

You can learn to map value streams by reading a few introductory articles, but if you’d rather invest in the guidance of a trusted adviser, contact me and we’ll figure out what you need.

Adam and Jerod are joined by Ken Kantzer, co-founder of PKC Security. Ken and his team performed upwards of 20 code audits on well-funded startups. Now that it’s 7 or 8 years later, he wrote up 16 surprising observations and things he learned looking back at the experience. We gotta discuss ’em all!

Discuss on Changelog News

Changelog++ members save 5 minutes on this episode because they made the ads disappear. Join today!

Sponsors

• Sentry – Working code means happy customers. That’s exactly why teams choose Sentry. From error tracking to performance monitoring, Sentry helps teams see what actually matters, resolve problems quicker, and learn continuously about their applications - from the frontend to the backend. Use the code CHANGELOG and get the team plan free for three months.
• InfluxData – The time series platform for building and operating time series applications — InfluxDB empowers developers to build IoT, analytics, and monitoring software. It’s purpose-built to handle massive volumes and countless sources of time-stamped data produced by sensors, applications, and infrastructure. Learn more at influxdata.com/changelog
• Honeycomb – Guess less, know more. When production is running slow, it’s hard to know where problems originate: is it your application code, users, or the underlying systems? With Honeycomb you get a fast, unified, and clear understanding of the one thing driving your business: production. Join the swarm and try Honeycomb free today at honeycomb.io/changelog
• Sourcegraph – Transform your code into a queryable database to create customizable visual dashboards in seconds. Sourcegraph recently launched Code Insights — now you can track what really matters to you and your team in your codebase. See how other teams are using this awesome feature at about.sourcegraph.com/code-insights

Featuring

• Ken Kantzer – Twitter, GitHub, Website
• Adam Stacoviak – Twitter, GitHub, LinkedIn, Website
• Jerod Santo – Twitter, GitHub

Notes and Links

• Learnings from 5 years of tech startup code audits
• Conway’s Law
• Meltdown

Something missing or broken? PRs welcome!

Download audio: https://cdn.changelog.com/uploads/podcast/494/the-changelog-494.mp3

As part of their onboarding, all of our employees are encouraged to fill out a “Skwill” — a small matrix that shows an overview of their strengths and interests in different fields. The matrix is “public” (i.e. visible to anyone inside the company) and makes it super easy to share your skillset with teammates or people outside of your team.

What is Skwill?

Skwill is a project that originally came out of our Innovation Incubator. The basic idea was to recreate a Skill/Will matrix in digital form as a small app and incorporate it into our everyday to create strong and diverse project teams and support the career development of each employee; while the concept of a skill/will matrix isn’t revolutionary, we wanted to explore different use cases and see how far it can go in a work environment.

Filling out my Skwill Matrix

I filled out my Skwill matrix shortly after joining the company in April 2021; given I joined as a designer, I focused on adding skills that were design-specific, but also skills that complemented my design skillset: “CSS”, “HTML”, or “Documentation”. Other skills which I felt were relevant to mention were things such as “Mentoring”, “Public Speaking” or “Writing”.

Filling out a Skill / Will matrix may seem easy but it also requires a good deal of introspection. Many of us are socialised to show our strengths and ignore or avoid mentioning our weaknesses: I can’t remember the amount of times I felt the need to “fake it till I make it” in a work setting because I was scared of asking a question or worried about how it would be perceived if I didn’t understand a concept or an acronym. So, sitting down to think about what skills I am objectively not so good at, especially when they’re expected skills in my field, took a bit of honesty.

I found that my Quadrant 2 (High Will, Low Skill) had a few skills that I felt would be important to my development as a designer — skills like “Accessibility”, “User Experience”, and even “Figma” (the design tool). And yet, it felt a bit embarrassing to put those in my “low skill” column.

Skwill: One year later

When I opened up my analog planner at the beginning of 2022 to start thinking about my goals and plan my year, I made a mental note to take a look at my Skill Will matrix and update it as needed. It took me a few weeks to get to it, but this was the updated version at the beginning of February 2022:

Not much changed, other than Figma being moved to Quadrant 1 (High Will, High Skill); it may seem like a small change, but with Figma being an extremely powerful tool and now de facto one of the main platforms used by designers across the world, it felt important to celebrate this little step in the right direction. This quick review of my Skill/Will matrix also made me realise that I had subconsciously worked on a specific skill from Quadrant 2 (Figma) because I was interested in it (High Will) and it was necessary for my work.

Fast forward a couple of months: After our Open Space event and a conversation in a session about contributing to open source software with a couple of coworkers, I added “Contributing to open source” to my Quadrant 1 (High Will, High Skill). And given my recent interest and deep dive into the topic of design systems, I promptly added that to the second quadrant (High Will, Low Skill) of my matrix. Here is an updated screenshot — from June 2022 — from my matrix that reflects those changes:

What’s next?

As a pretty introspective person, I love the idea of tracking these changes and seeing how my skill set develops over time. Over the last year, it also became evident to me how a skill that seems self-explanatory — for me that’s “Contributing to Open Source”, because I always forget that not every tech worker has the privilege and possibility to work out in the open — can be something extremely useful for people I work with to know about; sharing information about those types of “obvious” skills can spark a conversation and, at times, even move further into mentoring territory.

I also think a matrix like the Skill/Will matrix can help us pinpoint what skills we want to work on next, and be specific with our learning when we feel stuck. Even if you’re not a big planner or goal-setter, regularly looking at your matrix can be a subconscious push in the right direction when you want to get started with a new learning project — or it can make you realise when a skill you thought was important for you to learn actually isn’t.

And you?

What are some skills you’ve been developing over the course of this year? If you filled out a skill/will matrix for yourself in the past—did you ever use it for your skill or career development, and how?

Posted by Kübra Zengin, North America Regional Lead, Google Developers

A Path to Programming

“I was hooked from the start,” says Jennifer Bailey about programming. Always interested in the way systems work, Jennifer, now an educator in Colorado, found her path to programming in an unconventional way. She first earned a General Educational Development degree, otherwise known as a “GED” in the United States, from Aims Community College, when she was only 15 years old.

Ever a quick learner with the ambition to excel, she then secured an associate’s degree, bachelor’s, and master’s degree in Applied Science. With degrees in hand, she taught herself C Sharp while working at a local firm as a software developer building desktop applications.

When one of her mentors from Aims Community College was retiring, the school recognized Jennifer’s programming expertise and hired her to teach computer science in 2011. The administration then asked her to create the college’s certificate in mobile application development from scratch. To build out a curriculum for her new assignment, she needed to find some inspiration. As Jennifer sought out resources to curate the content for the college’s new program in mobile development, she found a local Google Developer Group (GDG), an organization where local developers came together to discuss cutting-edge programming topics.

Finding a Google Developer Group in Northern Colorado

She attended her first event with the group that same week. At the event, the group’s leader was teaching attendees to build Android apps, and other developers taught Jennifer how to use GitHub.

“I went to that in-person event, and it was everything I was hoping it would be,” Jennifer says. “I was just blown away that I was able to find that resource at exactly the time when I needed it for my professional development, and I was really happy because I had so much fun.”

The community of welcoming developers that Jennifer found in GDG drew her in, and for the first time at a technical networking event like this one, she felt comfortable meeting new people. “That initial event was the first time I felt like I had met actual friends, and I’ve been involved with GDG ever since,” she says.

A Life-Changing Community

As time progressed, Jennifer started attending GDG events more often, and eventually offered the meeting space at Aims Community College where the group could gather. After she made the offer, the group's organizers invited her to become a co-leader of the group. Fast-forward to the present, and her leadership role has led to numerous exciting opportunities, like attending Google I/O and meeting Google developers from all over the world.

“By participating in GDG, I ended up being able to attend Google I/O,” says Jennifer. “This community has had a massive impact in my life.”

Ongoing Education

Jennifer’s local GDG provides support for Android that helps other learners while also remaining helpful to her teaching of computer science subjects and the Android IOS mobile developer certificate.

“What keeps me engaged with Google technology, especially with Android, is all of the updates, changes, new ideas and new technology,” she says.

Jennifer notes that she appreciates the Android ecosystem’s constantly evolving technology and open source tools.

• After becoming fascinated with Android, Jennifer discovered that the more time she spent learning and delving into Android, the more she learned and gained expertise that she could apply to other platforms.
• Jennifer’s Android expertise has also led to her becoming an author for Ray Wenderlich, for whom she contributed to Saving Data on Android and Android Accessibility by Tutorials and a video course on building your first app using Android and Kotlin. “I like Jetpack Compose a lot, and I’m very interested in Android accessibility, so I can’t wait to update that book,” she says.
• She served as editor on an article about “Lazy Composables” on lists.

Positive Career Impact

In Jennifer’s view, involvement with Google Developer Groups positively impacted her career by exposing her to a local group of developers with whom she is deeply connected, providing resources and instruction on Android, and providing her with a leadership opportunity.

“I have met such a diverse sampling of people in Google Developer Groups, from all different industries, with all different levels of experience–from students, self-taught, to someone who’s been in technology longer than I have,” Jennifer says. “You never know who you will meet out there because GDG is filled with interesting people, and you never know what opportunities you will find by mixing with those people and comparing notes.”

If you’re looking to grow as a developer, find a GDG group near you. Learn more about Google Developer Groups and find a community near you!

When you join a public WiFi network, sometimes you’ll notice that you have to accept “Terms of Use” or provide a password or payment to use the network. Your browser opens or navigates to a page that shows the network’s legal terms or web log on form, you fill it out, and you’re on your way. Ideally.

How does this all work?

Wikipedia has a nice article about Captive Portals, but let’s talk about the lower-level mechanics.

Operating Systems’ Portal Detection

When a new network connection is established, Windows will send a background HTTP request to www.msftconnecttest.com/connecttest.txt. If the result is a HTTP/200 but the response body doesn’t match the string the server is known to always send in reply (“Microsoft Connect Test“), the OS will launch a web browser to the non-secure HTTP URL www.msftconnecttest.com/redirect. The expectation is that if the user is behind a Captive Portal, the WiFi router will intercept these HTTP requests and respond with a redirect to a page that will allow the user to log on to the network. After the user completes the ritual, the WiFi router stores the MAC Address of the device’s network card to avoid repeating the dance on every subsequent connection.

This probing functionality is a part of the Network Connectivity Status Indicator feature of Windows, which will also ensure that the WiFi icon in your task bar indicates if the current connection does not yet have access to the Internet at large. Beyond this active probing behavior, NCSI also has a passive polling behavior that watches the behavior of other network APIs to detect the network state.

Other Windows applications can detect the Captive Portal State using the Network List Manager API, which indicates NLM_INTERNET_CONNECTIVITY_WEBHIJACK when Windows noticed that the active probe was hijacked by the network. Enterprises can reconfigure the behavior of the NCSI feature using registry keys or Group Policy.

On MacOS computers, the OS offers a very similar active probe: a non-secure probe to http://captive.apple.com is expected to always reply with (“Success“).

Edge Portal Detection

Chromium includes its own Captive Portal detection logic whereby a probe URL is expected to return a HTTP/204 No Content response.

Edge specifies a probe url of http://edge-http.microsoft.com/captiveportal/generate_204

Chrome uses the probe URL http://www.gstatic.com/generate_204.

Avoiding HTTPS

Some Captive Portals perform their interception by returning a forged server address when the client attempts a DNS lookup. However, DNS hijacking is not possible if DNS-over-HTTPS (DoH) is in use. To mitigate this, the detector bypasses DoH when resolving the probe URL’s hostname.

Similarly, note that all of the probe URLs specify non-secure http://. If a probe URL started with https://, the WiFi router would not be able to successfully hijack it. HTTPS is explicitly designed to prevent a Monster-in-the-Middle (MiTM) like a WiFi router from changing any of the traffic, using cryptography and digital signatures to protect the traffic from modification. If a hijack tries to redirect a request to a different location, the browser will show a Certificate Error page that indicates that either the router’s certificate is not trusted, or that the certificate the router used to encrypt its response does not have a URL address that matches the expected website (e.g. edge-http.microsoft.com).

This means, among other things, that new browser features that upgrade non-secure HTTP requests to HTTPS must not attempt to upgrade the probe requests, because doing so will prevent successful hijacking. To that end, Edge’s Automatic HTTPS feature includes a set of exclusions:

kAutomaticHttpsNeverUpgradeList {
    "msftconnecttest.com, edge.microsoft.com, "
    "neverssl.com, edge-http.microsoft.com" };

Unfortunately, this exclusion list alone isn’t always enough. Consider the case where a WiFi router hijacks the request for edge-http.microsoft.com and redirects it to http://captiveportal.net/accept_terms. The browser might try to upgrade that navigation request (which targets a hostname not on the exclusion list) to HTTPS. If the portal’s server doesn’t support HTTPS, the user will either encounter a Connection Refused error or an Untrusted Certificate error.

If a user does happen to try to navigate to a HTTPS address before authenticating to the portal, and the router tries to hijack the secure request, Chromium detects this condition and replaces the normal certificate error page with a page suggesting that the user must first satisfy the demands of the Captive Portal:

For years, this friendly design had a flaw– if the actual captive portal server specified a HTTPS log on URL but that log on URL sent an invalid certificate, there was no way for the user to specify “I don’t care about the untrusted certificate, continue anyway!” I fixed that shortcoming in Chromium v101, such that the special “Connect to Wi-Fi” page is not shown if the certificate error appears on the tab shown for Captive Portal login.

-Eric