Month: February 2019

Lessons From re:Work

Recently I discovered re:Work, a website where Google shares its knowledge about human resources and management. In this post I highlight a few of the articles that I found inspiring.

A thought provoking article “Changing the Change Rules at Google” covers a new approach to reorgs. As a large, fast moving company, Google goes through frequent reorgs that are not always handled well. In some instances, Google found that half the people do not understand the reorg. The new ChangeRules approach is driven by four key broad questions: Why? What? Who? How? The reason behind these questions is to find out what is the goal of this change and how to best implement it. It may actually turn out that the reorg is not needed. One of the aspects that I found surprising is to get stakeholders’ input early, including input from employees affected by the reorg.

The project I am working on at work is a large undertaking that requires a major shift in the way teams are working. People need to nurture their innovation abilities, atrophied by many years working on legacy projects. These legacy projects needed to be maintained, without making any significant changes. An article “Hacking Your Innovation Mindset” provides tips from an eponymous Stanford d.school class to achieve improvement in innovation. Three main abilities are promoted during the class:

  • Learn to navigate ambiguity. I love this quote: “It is not only about problem solving, it is about problem finding”.
  • Practice mindful observation.
  • Experiment with your ideas.

After completing the Stanford class, the students were significantly more confident in showing their work to others, before it was finished to their satisfaction. Showing unfinished work to provide feedback is one of the major signs of innovative work.

For people wanting to learn more about this fascinating subject, read “Entrepreneur Behaviors, Opportunity Recognition, and the Origins of Innovative Ventures”. This study is based on interviews with dozens of innovative entrepreneurs and hundreds of executives and it posits that innovation differs from management in the patterns by which information is acquired. To my surprise, it is not personal traits, including risk taking, that explain the difference between being innovative and non-innovative.

Project Chameleon is a project in one of the divisions at Google to provide an internal marketplace where employees are matched to projects and managers, based on their skills and preferences. The project has been running for 2 years and 80% people who participate in it are satisfied, with 90% employees and managers getting one of their top three choices. This project has potential to provide benefit at other larger companies as well.

WebAssembly

Until recently, JavaScript was the only language supported by all web browsers. But it was difficult to compile it efficiently and the JavaScript applications typically run much slower than native applications.

Then, programmers from the four main browser vendors designed a new language, sort of a machine code for the web, and called it WebAssembly. The new language was first announced in the “Bringing the Web up to Speed with WebAssembly” paper in 2017, a specification published together by Google, Microsoft, Mozilla, and Apple. The specification lists in detail the formal syntax and explains design choices made. A major design goal of WebAssembly has been high performance without sacrificing safety or portability. To provide security, each WebAssembly module is designed to have a single block of memory (array of bytes), disjoint from code space and other internal memory spaces. It is not possible for compiled programs to corrupt their execution environment.

This week, the “Analyzing the Performance of WebAssembly vs. Native Code” study was published, which appeared to throw cold water on claims that WebAssembly is only about 10% slower than native code. The study shows numbers that are closer to 50-90% slower. However, in order to run large suite of performance tests SPEC CPU, the authors significantly modified how WebAssembly is run in the Unix environment by adding support for a file system and I/O. It is not clear if their implementation is sound.

While discussing WebAssembly, you might be wondering about what is the level of WebAssembly support across web browsers. For this purpose, head over to CanIUse.com, a web site that details web technology support on a per-browser basis. When searching for “WebAssembly”, you get the following picture, indicating that all major browsers do support WebAssembly.

Screenshot from CanIUse.com searching for WebAssembly support. All major browsers support it, with the exception of an outdated Internet Explorer. Box sizes are relative to browser popularity. Numbers in boxes indicate browsers’ versions.

I work in CAD software development, so I read with great interest about Autodesk’s recently completed rewrite of its behemoth AutoCAD software to support web browsers by using the LLVM framework with Emscripten on the back-end to produce WebAssembly. Considering millions lines of code comprise AutoCAD, it was no small feat.

Autodesk’s AutoCAD Web browser based user interface.

I suspect that I will come back to this topic in a future blog post here at CodingRestart. Until then, happy coding!