Notes from 6/7-13/7

Hum Qing Ze

4 min readJul 12, 2020

Career

23 Alternative Career Paths that Software Developers Can Grow Into

Seems useful to keep around as a reminder of vertical skills

The Hundred-Page Machine Learning Book Book Review

Brilliant, I think we need to think about takeaways from our data science course

Data

Carbon Plan open source tracking

Metrics are based on information in public project proposals plus our own research. We are actively developing methods for calibration based on independent data and models.

The Self-Learning Path To Becoming A Data Scientist, AI or ML Engineer

Generally obvious advice except the last bit, get yourself a mentor. Just how important is mentorship? I hear about it everywhere

What is “Big Data” — Understanding the History

Tremendously done. Especially about the real origins of this, the internet drove people to be able to search such a massive database on commodity hardware. MapReduce and Hadoop’s birth.

Design

Websites designed like desktops

Super cool but impractical af

Product

Setting up Product Development Processes

Will be super super useful soon

It is useful to think about these processes along a number of different dimensions:

Steps / activities: what are the different activities that get done over the course of the development workflow? What are dependencies between the activities? What are normal and exceptional paths?
Roles & responsibilities: what roles are involved in the various activities, and what responsibilities are associated with them? Who is involved in which activity in what way?
Interactions / forums: What regular meetings or other check-ins occur along the process? This could include anything from daily standups over planning and retrospective meetings through to formal reviews and approvals.
Artifacts: what formal outputs (other than the finished software) do the process steps have? This can include things like briefs / one-pagers, product requirement documents (PRDs), development tickets, A/B test result reports, etc.
Tools: what tools are used to support the process? This could include things like ticketing systems, source control systems, design tools, data analytics tools, knowledge repositories, etc.

Areas in which standardization across teams makes sense are any discovery and development process steps which directly interface with other teams. Some examples of this are:

Customer outreach and research: touchpoints with customers need to be coordinated across different teams. Otherwise, it can be very confusing and a bad experience for customers if multiple teams reach out to them in different ways without knowledge of other interactions. This would reflect negatively on the company and product and therefore needs to be avoided.
Product, design, and technical review and feedback: there should be opportunities in the discovery and development process for teams to get feedback and guidance on their work in progress from both leadership and peers. These review and feedback sessions help align the product development organization in terms of what is on the product roadmap and improve the product by soliciting feedback about product, design, and technical decisions. They are also a critical opportunity for leaders to understand the work and performance of their teams and identify coaching and growth opportunities.
Ticketing / task management: this is a bit of a tricky one. In general, since managing tasks is such an essential part of organizing one’s work, it makes sense for every team to be able to use their own methods. If one team manages their work in Jira and another on sticky notes on a wall, so be it. However, allowing every team this autonomy means that as dependencies between teams occur, it becomes more and more difficult to keep up with the status of the work. If individual tasks regularly require contributions from other teams, it is therefore beneficial to have a certain degree of standardization.
Code versioning and integration: this one is pretty obvious: code that ends up in one codebase should be managed together. There might be parts of the toolchain that differ — for example, for backend and frontend code, or depending on the programming language — but it should all be part of one big, standardized workflow in order to be able to manage dependencies.
New feature launch: how new features are launched and communicated to customers (or not) should ideally be consistent across teams. Otherwise, the situation can get very confusing for users if some changes are announced, some have in-product communication, and others simply appear. This is not to say that there needs to be a cumbersome launch process — the common line might be to launch quickly without communication — but that it makes sense that all teams follow the same approach.
Documentation of research, concepts, and A/B test results: once a company starts getting out of the “five people in a room” phase, it starts having a history. This is especially the case once the first people start leaving the company — over time, not for all decisions that were taken in the past there is still someone around who can explain them. There are two big risks that follow from that. The first one is that people start doing things “the way we’ve always done them” without understanding what the reasons are, and therefore not finding ways to improve. The other risk is wasting time trying something that has failed in the past due to unawareness of past activities. To avoid these risks, there should be a common process to document key insights and decisions for future use.