About bessiechu

www.bessiechu.com

Apr-June 2018 Learning

Books Read (related to work/professional development/betterment):

Articles:

Giving meaning to 100 billion analytics events a day

  1. Tracking events were sent by browser over HTTP to a dedicated component and enqueues them in a Kafka topic. You can build a Kafka equivalent in BigQuery to use as Data Warehouse system
  2. ‘When dealing with tracking events, the first problem you face is the fact that you have to process them unordered, with unknown delays.
    1. The difference between the time the event actually occurred (event time) and the time the event is observed by the system (processing time) ranges from the millisecond up to several hours.’
  3. The key for them was finding ideal batch duration

What is a Predicate Pushdown?

  1. Basic idea is certain parts of SQL queries (the predicates) can be “pushed” to where the data lives and reduces query/processing time by filtering out data earlier rather than later. This allows you to optimize your query by doing things like filtering data before it is transferred over a network, loading into memory, skipping reading entire files or chunks of files.
  2. ‘A “predicate” (in mathematics and functional programming) is a function that returns a boolean (true or false). In SQL queries predicates are usually encountered in the WHEREclause and are used to filter data.’
  3. Predicate pushdowns filters differently in various query environments, eg Hive, Parquet/ORC files, Spark, Redshift Spectrum, etc.

I hate MVPs. So do your customers. Make it SLC instead.

  1. Customers hate MVPS, too M and almost never V – simple, complete, and lovable is the way to go
  2. The success loop of a product “is a function of love, not features”
  3. “An MVP that never gets additional investment is just a bad product. An SLC that never gets additional investment is a good, if modest product.”

Documenting for Success

  1. Keeping User Stories Lean and Precise with:
    1. User Story Objectives
    2. Use Case Description
    3. User Interaction and Wireframing
    4. Validations
    5. Communication Scenarios
    6. Analytics
  2. Challenges
    1. Lack of participation
    2. Documentation can go sour
  3. Solutions
    1. Culture – tradition of open feedback
    2. Stay in Touch with teams for updates
    3. Documentation review and feedback prior to sprint starts
    4. Track your documents

WTF is Strategy

  1. Strategic teaming is what sets apart seniors from juniors
  2. Strategy needs
    1. Mission: Problem you’re trying to solve and who for
    2. Vision: Idealized solution
    3. Strategy: principles and decisions informed by reality and caveated with assumptions that you commit to ahead of dev to ensure likelihood of success in achieving your vision
    4. Roadmap: Concreate steps
    5. Execution: Day-today activities
  3. “Strategy represents the set of guiding principles for your roadmapping and execution tasks to ensure they align with your mission and vision.”

Corporate Culture in Internet Time

  1. “”The dirty little secret of the Internet boom,” says Christopher Meyer, who is the author of “Relentless Growth,” the 1997 management-based-on-Silicon-Valley-principles book, “is that neither startup wizards nor the venture capitalists who fund them know very much about managing in the trenches.”
  2. “ The most critical factor in building a culture is the behavior of corporate leaders, who set examples for everyone else (by what they do, not what they say). From this perspective, the core problem faced by most e-commerce companies is not a lack of culture; it’s too much culture. They already have two significant cultures at play – one of hype and one of craft.”
  3. Leaders need to understand both craft and hype cultures since they have to rely on teams that come from both to deliver. They need to set-up team cultures and infrastructure that supports inter-team learning.

Do You Want to Be Known For Your Writing, or For Your Swift Email Responses? Or How the Patriarchy has fucked up your priorities

  1. Women are conditioned to keep proving themselves – our value is contingent on ability to meet expectation of others or we will be discredited. This is often true, but do you want to a reliable source of work or answering e-mails?
  2. Stop trying to get an A+ in everything, it’s a handicap in making good work. “Again, this speaks most specifically to women, POC, queers, and other “marginalized” folks. I am going to repeat myself, but this shit bears repeating. Patriarchy (and institutional bigotry) conditions us to operate as if we are constantly working at a deficit. In some ways, this is true. You have to work twice as hard to get half the credit. I have spent most of my life trying to be perfect. The best student. The best dishwasher. The best waitress. The best babysitter. The best dominatrix. The best heroin addict. The best professor. I wanted to be good, as if by being good I might prove that I deserved more than the ephemeral esteem of sexist asshats.”

Listen to me: Being good is a terrible handicap to making good work. Stop it right now. Just pick a few secondary categories, like good friend, or good at karaoke. Be careful, however of categories that take into account the wants and needs of other humans. I find opportunities to prove myself alluring. I spent a long time trying to maintain relationships with people who wanted more than I was capable of giving

  1. Stop thinking no as just no but saying yes to doing your best work

Dear Product Roadmap, I’m Breaking Up with You

  1. A major challenge is setting up roadmap priorities without real market feedback, especially in enterprise software
  2. Roadmaps should be planned with assets in place tied closely to business strategy
    1. A clearly defined problem and solution
    2. Understanding of your users’ needs
    3. User Journeys for the current experience
    4. Vision -> Business Goals -> User Goals -> Product Goals -> Prioritize -> Roadmap
  3. Prioritization should be done through the following lens: feasibility, desirability, and viability

The 7 Steps of Machine Learning Google Video

  • Models are created via training
  • Training helps create accurate models that answers questions correctly most of the time
  • This require data to train on
    • Defined features for telling apart beer and wine could be color and alcohol percentage
  • Gathering data, quality and quantity determine how good model can be
  • Put data together and randomize so order doesn’t affect how that determines what is a drink for example
  • Visualize and analyze during data prep if there’s a imbalance in data in the model
  • Data needs to be split, most for (70-80%) and some left for evaluation to test accuracy (20-30%)
  • A big choice is choosing a model – eg some are better for images versus numerical -> in the beer or wine example is only two features to weigh
  • Weights matrix (m for linear)
  • Biases metric (b for linear)
  • Start with random values to test – creates iterations and cycles of training steps and line moves to split wine v beer where you can evaluate the data
  • Parameter tuning: How many times we through the set -> does that lead to more accuracies, eg learning rate how far we are able to shift each line in each step – hyperparameters are experimental process bit more art than science
  • 7 Steps: Gathering Data -> Preparing Data -> Choosing a Model -> Training -> Evaluation -> Hyperparameter Tuning -> Prediction

Qwik Start Baseline Infra Quest: 

  • Cloud Storage Google Consolae
  • Cloud IAM
  • Kubernetes Engine

Treehouse Learning:  

Javascript OPP

  • In JavaScript, state are represented by objects properties and behaviors are represented by object methods.
    • Radio that has properties like station and volume and methods like turning off or changing a station
  • An object’s states are represented by “property” and its behaviors are presented by “method.”
  • Putting properties and methods into a package and attaching it to a variable is called encapsulation.

Intro SQL Window Functions

  • Function available in some variations of SQL that lets you analyze a row in context of entire result set – compare one row to other rows in a query, eg percent of total or moving average

Common Table Expressions using WITH

  • CTE – a SQL query that you name and reuse within a longer query, a temporary result set
  • You place a CTE at the beginning of a complete query using a simple context
--- create CTES using the WITH statement
WTH cte_name AS (
  --- select query goes here
)

--- use CTEs like a table
SELECT * FROM cte_name
  • CTE name is like an alias for the results returned by the query, you can then use the name just like a table name in the queries that follow the CTE
WITH product_details AS (
  SELECT ProductName, CategoryName, UnitPrice, UnitsInStock
  FROM Products
  JOIN Categories ON PRODUCTS.CategoryID = Categories.ID
  WHERE Products.Discontinued = 0
)

SELECT * FROM product_details
ORDER BY CategoryName, ProductName
SELECT CategoryName, COUNT(*) AS unique_product_count, 
SUM(UnitsInStock) AS stock_count
FROM product_details
GROUP BY CategoryName
ORDER BY unique_product_count
  • CTE makes code more readable, organizes queries into reusable modules, you can combine multiple CTEs into a single query, it can better match of how we think of results set in the real world
    • all orders in past month-> all active customers -> all products and categories
    • Each would be a CTE
  • Subqueries create result sets that look just like a table that can be joined to another tables
WITH all_orders AS (
  SELECT EmployeeID, Count(*) AS order_count
  FROM Orders
  GROUP BY EmployeeID
),
late_orders AS (
    SELECT EmployeeID, COUNT(*) AS order_count
    FROM Orders
    WHERE RequiredDate <= ShippedDate
    GROUP BY EmployeeID
)
SELECT Employees.ID, LastName,
all_orders.order_count AS total_order_count,
late_orders.order_count AS late_order_count
FROM Employees
JOIN all_orders ON Employees.ID = all_orders.EmployeeID
JOIN late_orders ON Employees.ID = late_orders.EmployeeID
  • Remember one useful feature of CTES is you can reference them later in other CTEs, eg. revenue_by_employee below pulling from all_sales
  • You can only reference a CTE created earlier in the query, eg first CTE can’t reference the third
WITH
all_sales AS (
  SELECT Orders.Id AS OrderId, Orders.EmployeeId,
  SUM(OrderDetails.UnitPrice * OrderDetails.Quantity) AS invoice_total
  FROM Orders
  JOIN OrderDetails ON Orders.id = OrderDetails.OrderId
  GROUP BY Orders.Id
),
revenue_by_employee AS (
  SELECT EmployeeId, SUM(invoice_total) AS total_revenue
  FROM all_sales
  GROUP BY EmployeeID
),
sales_by_employee AS (
  SELECT EmployeeID, COUNT(*) AS sales_count
  FROM all_sales
  GROUP BY EmployeeID
)
SELECT revenue_by_employee.EmployeeId,
Employees.LastName,
revenue_by_employee.total_revenue,
sales_by_employee.sales_count,
revenue_by_employee.total_revenue/sales_by_employee.sales_count AS avg_revenue_per_sale
FROM revenue_by_employee
JOIN sales_by_employee ON revenue_by_employee.EmployeeID = sales_by_employee.EmployeeID
JOIN Employees ON revenue_by_employee.EmployeeID = Employees.Id
ORDER BY total_revenue DESC
Advertisements

March 2018 Learning

Less than normal last month due to business travel

Books Read (related to work/professional development/betterment):

Articles:

Agile Died While You Were Doing Your Standup

  1. Agile has been implemented poorly to enterprise wholesale by consultancies that mechanizes and dehumanizes teams and doesn’t respect the craft – causing them to deliver outputs instead of outcomes that drive values for customers
  2. The problem Product management, UX, engineer, dev-ops, and other core competencies need to be one team under one leader and give it autonomy and accountability to connect solving problems. If implemented correctly – it empowers teams to work toward shared outcomes with both velocity and accuracy.
  3. Embrace discovery – discovery data matched along shipped experiences creates real customer value and trust that teams can work autnomously with accountability and shipping something that meets both company and user objectives.

 

Avoiding the Unintended Consequences of Casual Feedback

  • Your seniority casts a shadow or the org, your casual feedback may be interpreted as a mandate – make sure it’s clear whether its opinion, strong suggestion, or mandate
    1. Opinion: “one person’s opinion” your title and authority should to enter into the equation
    2. Strong suggestion: falls short of telling team what to do – senior executive draws on experience but provides team to feel empowered to take risks. This is the difficult balance to strike and requires taming of egos to do what’s best – you also have to trust the people you’ve empowered to have the final say.
    3. Mandate: issue to avoid prohibitively costly mistakes – but too often without right justification signals a demotivating lack of trust

 

Ask Women in Product: What are the Top 3 things you look for when hiring a PM?

  1. Influence without authority – figuring out what makes you tick, your team, your customers. Read in between lines. How did you deal with past conflicts
  2. Intellectual curiosity- how did you deal with ambiguous problem or were intimidated
  3. Product sense – name compelling product experience you built
  4. Empathy – unmet needs and pain points – how would you design an alarm clock for the blind
  5. Product intuition – access product, feature, or user flow
  6. Listening and communication skills – read rooms for implicit and explicit

 

Why Isn’t Agile Working?

  1. Waiting time isn’t addressed properly
  2. Doesn’t account well for unplanned work, multitasking, and impacts from shared services
  3. Even though dev goes faster in agile, it has no bearing on making the right product decisions and working to realize benefits. Agile is useful when it services as a catalyst for continuous improvement and the rest of the org structure is in line – eg. DevOps, right management culture, incremental funding v project-based funding, doing less and doing work that matters, looking at shared services, mapping value streams, etc.

 

Treehouse Learning:  

Changing object literal in dice rolling application into constructor function that takes in the number of sites as an argument. Each instance created calls the method for running the base.

function Dice(sides) {

            this.sides = sides;
            this.roll = function() {

                        var randomNumber = Math.floor(Math.random() * this.sides) +1;
                        return randomNumber;

            }

}

var dice= new Dice(6) // new instance of 8 sided die

 

Watch out for applications running code again and again unnecessarily, like in code above. The JavasScript property prototype is like an object literal that can be added to roll property, when we assign a function to it, it becomes a method and is no longer needed in the constructor function. Prototypes can be used as templates for objects, meaning values and behavior can be shared between instances of objects.

Dice.prototype.roll = function diceRoll() {

            var randomNumber = Math.floor(Math.random() * this.sides) +1;
            return randomNumber;

} // shared between all instances in template/prototype


function Dice(sides) {

            this.sides = sides;

}

 

 

 

Feb 2018 Learning

Books Read (related to work/professional development/betterment):

Creativity, Inc.

The Mythical Man Month

Articles:

pm@olin 10 Most Likely to Succeed and pm@olin 11 Capstone

  1. “ A lot of being a PM is rolling with what doesn’t cost very much, and helps make the team happy. You don’t always get the most done by optimizing.”
  2. “For a PM, It’s figuring out how to find a little extra time for the easter egg. It’s doing the extra work to get a cool side project into the product. It’s helping someone else learn a new skill. It’s the thank you cards or the day off after shipping.”
  3. Sometimes something as simple as colored markets to annotate pros and cons helps whiteboarding

Manager Energy Drain

  1. You can color-code your calendar based on what mental energy you will need (eg. 1-on-1 brain, teaching brain, planning brain) to manage that piece and defrag accordingly
  2. The best give you can give direct reports is a messy unscoped project with a bit of safety net to teach them -> give them guidance
  3. Say no to focus energy – don’t be afraid to go back and say no

The MVP is dead. Long live the RAT.

  1. RAT = Risk Assumption Test – after MVP is not a product, but a way of testing whether you’ve found a problem worth solving. RAT emphasizes on building on what’s required to rest beyond your largest unknown
  2. All about rapid testing rather than creeping into perfect code, design, and danger of becoming a product
  3. It’s about maximizing discovery and removing temptations of putting resources on creating a more polished product

Scaling Agile At Spotify: An Interview with Henrik Kniberg

  1. “Autonomy is one of our guiding principles. We aim for independent squads that can each build and release products on their own without having to be tightly coordinated in a big agile framework. We try to avoid big projects altogether (when we can), and thereby minimize the need to coordinate work across many squads.”
  2. “By avoiding big projects, we also minimize the need to standardize our choice of tools.”
  3. The technical architecture is hugely important for the way we are organized. The organizational structure must play in harmony with the technical architecture. Many companies can’t use our way of working because their architecture won’t allow it.
    • We have invested a lot into getting an architecture that supports how we want to work (not the other way around); this has resulted in a tight ecosystem of components and apps, each running and evolving independently. The overall evolution of the ecosystem is guided by a powerful architectural vision.
    • We keep the product design cohesive by having senior product managers work tightly with squads, product owners, and designers. This coordination is tricky sometimes, and is one of our key challenges. Designers work directly with squads, but also spend at least 20% of their time working together with other designers to keep the overall product design consistent.”

Product Management Is Not Project Management

  1. Product management is not about making sure products ship on time – it’s about knowing the customer needs and defining the right product and evangelizing that internally
  2. Too often, Product Managers spend time writing specs, Gantt charts, and workflows instead of on customer problems, customer data, and articulating that to the company.
  3. Measuring Religiously means both analytics + talking to customers

When should you hire a Product Manager?

  1. Toxic things to a Product Management team: when it is too large and has overlaps in responsibility, it results in politics, land grabs for credit, and no clear owner on how t to make decisions
  2. Don’t hire until there’s a pain point – eg can’t prioritize backlog, slow shipping bc of mismatched priorities and poor communication between teams, people don’t know why they’re building what they’re building
  3. “My least favorite way to slice a Product team is “I’ll do the high level strategy and they’ll do details” — it makes it hard for the detail-level person to make good calls. It also makes it harder for the high level person to connect with the rest of the team.”

Continuous Improvement + Quality Assurance

  1. Minimum viable feature set: releasing a feature is decoupled from deploying code. Large features deployed piecemeal over time.
  2. Debugging is twice as hard as writing code in the first place. Focus less on the mitigation of large, catastrophic failures – optimize for recovery rather than failure prevention. Failure is inevitable.
  3. Exploratory testing requires an understanding of the whole system and how it serves a community of users. Customer Experience is as much about technology as it is about product requirements

Building Your Personal Brand Where You Work

  1. Make your boss aware of what you’re doing – women often doers who don’t make it a point to highlight their accomplishments or how busy they are at work. Great tool is informal email reports. Template can be: weekly wins, areas of improvement for my team, what was coming next week, what you need from boss.
  2. Build brand equity with coworkers, because you will need people to defend you. Being liked matters more sometimes. You want an ally at every level, your boss should respect you but it’s also important entry level employees respect you too.
  3. Keep track of your success, remember you wins. Eg. tracking weekly, monthly, bi-annual, annual wins

Product Manger versus Product Owner

  1. “Product Owner is a role you play on a Scrum team. Product Manager is the job”
  2. Product Owner should spend half the time talking to customers and half working with the team is an ideal but should vary. External v internal work will shift depending on maturity and success of product
  3. Product Managers in senior roles should concentrate on defining vision and strategy for teams based on market resarhc, company goals, and current state of products. The ones without Scrum teams or smaller teams can help validate or contribute to strategy fo future products.

How to Run an Effective Meeting

  1. Set the agenda so there is a compass for conversation. Start on time and tend on time.
  2. End with an action plan that has next steps.
  3. Be clear, light bulb or gun – you have an idea or you want people to do it. “Your job as a leader is to be right at the ending of the meeting, not the beginning of the meeting.” Let people speak so you’ve heard all facts and opinions.

Managing Software Engineers *This is totally an article clearly from 2002 and all problematic attitudes therein about not considering people might have things like families

  1. Create work environment where best programmers will be satisfied enough to stay and where average programmers become good
  2. “One of the paradoxes of software engineering is that people with bad ideas and low productivity often think of themselves as supremely capable. They are the last people whom one can expect to fall in line with a good strategy developed by someone else. As for the good programmers who are in fact supremely capable, there is no reason to expect consensus to form among them.”
  3. Ideals to steal
    1. people don’t do what they are told
    2. all performers get the right consequences every day
    3. small, immediate, certain consequences are better than large future uncertain ones
    4. positive reinforcement is more effective than negative reinforcement
    5. ownership leads to high productivity

The What, Why, and How of Master Data Management

  1. Five kinds of data in corporations:
    1. “Unstructured—This is data found in e-mail, white papers like this, magazine articles, corporate intranet portals, product specifications, marketing collateral, and PDF files.
    2. Transactional—This is data related to sales, deliveries, invoices, trouble tickets, claims, and other monetary and non-monetary interactions.
    3. Metadata—This is data about other data and may reside in a formal repository or in various other forms such as XML documents, report definitions, column descriptions in a database, log files, connections, and configuration files.
    4. Hierarchical—Hierarchical data stores the relationships between other data. It may be stored as part of an accounting system or separately as descriptions of real-world relationships, such as company organizational structures or product lines. Hierarchical data is sometimes considered a super MDM domain, because it is critical to understanding and sometimes discovering the relationships between master data.
    5. Master—Master data are the critical nouns of a business and fall generally into four groupings: people, things, places, and concepts. Further categorizations within those groupings are called subject areas, domain areas, or entity types. For example, within people, there are customer, employee, and salesperson. Within things, there are product, part, store, and asset. Within concepts, there are things like contract, warrantee, and licenses. Finally, within places, there are office locations and geographic divisions. Some of these domain areas may be further divided. Customer may be further segmented, based on incentives and history. A company may have normal customers, as well as premiere and executive customers. Product may be further segmented by sector and industry. The requirements, life cycle, and CRUD cycle for a product in the Consumer Packaged Goods (CPG) sector is likely very different from those of the clothing industry. The granularity of domains is essentially determined by the magnitude of differences between the attributes of the entities within them.”
  2. Deciding what to manage it and how it should be managed depends on some of the following criteria: behavior (how it interacts with other data, eg customers buy product- which may be a part of multiple hierarchies describing how they’re sold), life cycle (created, read, updated, deleted, searched – a CRUD cycle), cardinality, lifetime, complexity, value, or volatility, reuse
  3. Master Data Management is the tech, tools, and processes required to create and maintain consistent and accurate lists of master data, including identifying sources of master data, analyzing metadata, appointing data stewards, data-governance program, developing master data model, toolset, infrastructure, generating and testing master data, modify producing and consuming systems, implementing maintenance processes, and creating Master List similar to ETL below:
    1. Normalize data formats
    2. Replace Missing values
    3. Stnadardize Values
    4. Map Attributes
    5. Needs versioning and auditing

Treehouse Learning:  

Object-Oriented-Javascript

  • An object is a container for values in the form of properties and functionality in the form of methods
    • Methods on values can return objects, but they don’t have to return anything at all
  • Accessing or assigning properties is known as getting and setting
  • Native Objects: no matter where your JavaScript programs are run, it will have these objects eg. number, string, object, boolean
  • Host Objects: provided by the host environment, eg. the browser, such as document, console, or element
  • Own Objects: created in own programming eg. characters in a game
  • Objects hide complexity and organize code – known as encapsulation
  • An object literal holds information about a particular thing at a given time – it stores the state of a thing.

Eg.

var person = {
            name: “Lauren”,
            treehouseStudent: true,
            “full name”: “Lauren Smith”
}

Access using dot notation or square brackets

person.name;
person.treehouseStudent;
person[“name”]
person[“treehouseStudent”]
person[“full name”]
  • Each key is actually a string, but Javascript interpreter interprets them as a string
  • Encapsulating code into a single block allows us to keep state and behaviors for a particular thing in one place and code becomes more maintainable

Adding method to an object

var contact = {
  fullName: function printFullName() {
  var firstName = "Andrew";
  var lastName = "Chalkley";
  console.log(firstName + " " + lastName);
  }
}

Anonymous Function

var contact = {
  fullName: function() {
    var firstName = "Andrew";
    var lastName = "Chalkley";
    console.log(firstName + " " + lastName);
  }
}

We don’t know the name of variable to access its properties. Depending on where and how a function is called, this can be different things. Think of this as owner of function, eg. the object of method that is called.

Eg.

var dice = {
            sides: 6,
            roll: function() {
                var randomNumber = Math.floor(Math.random() * this.sides) + 1; // this means object literal of dice in this case
                console.log(randomNumber);
            }
}

var dice10 = {
            sides: 10,
            roll: function() {
                 var randomNumber = Math.floor(Math.random() * this.sides) + 1; // refers to dice10 variable
                 console.log(randomNumber);

            }

}

Object  literals are great for one off objects, if you want to make multiple objects of one type you need constructor functions:

  • Constructor functions describe how an object should be created
  • Create similar objects
  • Each object created is known as an instance of that object type

Constructor function example and new contact instances (an instance is the specific realization of a particular type or object)

Function Contact(name, email) {
    this.name = name;
    this.email = email;
}

var contact = new Contact(“Andrew”, “andrew@andrew.com”);
var contact2 = new Contact(“Bob”, “bb@andrew.com”);

You can create as many object of same type as you like, eg. real world example of:

Media Player

  • Playlist object (initialized by constructor function)
  • Song objects

Jan 2018 Learning

Books Read (work or professional development-related):

Articles

update: how can I be more assertive at work?

  1. “Reframe who had the power in these situations. I don’t need to network with these people, I don’t need these people to recommend me for other jobs because I do not want to work with them again. In a way, by being so upfront about their sexism they were giving me the gift of letting me know immediately not to waste my time, and the people who would be missing out on work is them, because I would never recommend them for jobs in the future and would actively discourage hiring them if I was able. Any short term jobs I miss out on now, are well worth it to form a network of people that are actually respectful that I want to keep working with.”
  2. “Give up on ever having that perfect retort that would wither them to their bones, or beautiful speech that would change their life. Instead, I wrote out some very simple, one line, adjustable scripts for every situation I’d come across.”
    1. ”You don’t need to tell me this, it’s making me uncomfortable.” + Silence. If they apologize, say you appreciate it and walk away
  3. Embrace awkward silence if you don’t want to make scene and just say your one line script. “Let me be uncomfortable without anyone ever being able to say I was being unprofessional.”

Blameless PostMortems and a Just Culture

  1. ‘Having a Just Culture means that you’re making effort to balance safety and It means that by investigating mistakes in a way that focuses on the situational aspects of a failure’s mechanism and the decision-making process of individuals proximate to the failure, an organization can come out safer than it would normally be if it had simply punished the actors involved as a remediation.’
  2. The cycle of name/blame/shame ends up with cover-your-ass engineering in which “Management becomes less aware and informed on how work is being performed day to day, and engineers become less educated on lurking or latent conditions for failure due to silence.”
  3. Understand how failures happened to that they can be learned from and to temper reactions to failure

How to Build a Successful Team

  1. “I hire the best people and get out of their way” is a nice line, but leaders need to play a hands-on role in making sure the group works well together and stays on the right priorities.
  2. Have a few simple priorities
  3. Simple shared scoreboards that affiliate all the tribes of the team so people aren’t arguing about keeping score. When you make statements in difficult conversations, “don’t make statements that include assumptions about the motivations behind someone’s behavior” and focus only on your feelings, reactions, and observations – you don’t really know what’s going on and being accusatory without evidence can derail progress.

SMART criteria Wiki

  • Specific – target an area for specific improvement. Or strategic and specific
  • Measureable – quantify or at least suggest an indicator of progress. Or motivating
  • Assignable – specify who will do it. Or achievable
  • Realistic – given available resources. Or reasonable, resourced, relevant
  • Timebound – specify when results can be achieved. Or testable, time limited, trackable

Start-up Metric for Pirates: AARRR! and Slides

  • Acquisition – users who come to site
    • Visit Site, Landing Page, Doesn’t Abandoned (stays 10+, visits 2+ pages)
    • Comes in via, SEO, SEM, PR, Blogs, etc. other marketing channels
  • Activation – users enjoy 1st visit
    • Views x pages, does z clicks, Signs up for E-mail/Acct/Widget
    • A/B tests critical here
  • Retention – users who come back
    • E-mails Opens/RSS Clickthroughs
    • Weekly e-mails, event-based e-mails, blogs
  • Referral – users who enjoy product enough to refer to others
    • Refers users who visit site, refers users who activate site
    • Campaigns, contests, e-mails
  • Revenue – users conduct some monetization behavior
    • Users generate minimum revenue
    • Users generate break-even revenue
  • Subs, Lead Gen, etc.

Measuring What Matters: How to Pick a Good Metric

  1. Good metrics are comparative, understandable, a ratio or a rate, and changes the way you actually behave
  2. To start something, you need qualitative input from talking to people because quantitative data can be misinterpreted
  3. Look beyond Reporting Metrics and find Exploratory metrics. Look beyond lagging metrics (that have happened in the past) and look for Leading metrics that might have insight into the future – eg. rising complaints

Continuous Integration

  1. Continuous integration is software dev process where work is integrated frequently, multiple times a day, and automated builds detect integration errors as soon as possible and allows software to be developed quickly and cohesively with reduced risk
  2. Requires a maintain a single source repo with a decent source code management system
  3. Everything should be included in automated builds and have multiple environments to run tests

A day in the Life of Joe Leech, Product Consultant

  1. There’s not a single solution or framework that’s a magic bullet to solve clients’ problems. Product management should be relationship people first and build glue across organizations to do so
  2. “Startups are good at speed, big companies are good at making good decisions,” and startups and enterprise have a lot to learn from each other, he believes. Startups are lean and for them fast actions are crucial, but their people often lack the knowledge or skill to make the right decisions, he believes. “Startup founders are especially hard to work with because the company is their baby. They hate formal processes because it gets on the way of getting going.”
  3. Prioritization as PIE (potential, importance, ease)

pm@olin: Presentations (Class 9)

  1. Tell them what you’re going to say, tell, them, and tell them what you said
  2. PRES framework: Present, Reaching Out, Expressive, and Self Knowing
  3. Relatable, to audience good content, humor, and leave audience wondering for more

How to Hire the Right Person

  1. Take them on a tour and see how they respect and if they treat everyone they meet with respect. Same with taking people out for a meal
  2. Ask unusual questions so you reveal more about a person -> not brain teasers. Find natural strengths
  3. Get them to ask questions and see if they’ve done their research, care about goals and culture

The Secret to Becoming a Better Data Visualization Practitioner

  1. Be able to express all intentions behind design decisions, including citing best practices or evidence from research to show you are using logic over feelings
  2. Document unconscious choices – write down all the micro-decisions that lead you to your current state
  3. Visualize differences in decisions, be ready and practiced in whiteboarding before and after decisions

Treehouse Learning

AJAX Basics Treehouse

  • AJAX form request example and responding to a submit event
    • Select form
    • Add JQuery submit method
    • Stop form from submitting
    • Retrieve value user inputted with JQuery’s val method

$(document).ready(function() {

$(‘form’).submit(function (event) {

event.preventDefault(); // stops browsers normal reaction to event, eg prevent from leaving page in this case

var $searchField = $(‘#search’);

var $submitButton = $(‘#submit’);

$searchField.prop(“disabled”, true); // disable search field so you can’t type new text

$submitButton.attr(“disabled”, true).val(“searching…”); // as request is happenign, user gets message search is underway

// the AJAX part

var flickerAPI = “http://api.flickr.com/services/feeds/photos_public.gne?jsoncallback=?&#8221;;

var animal = $searchField.val(); // capturing text user types in the field

var flickrOptions = {

tags: animal,

format: “json”

};

function displayPhotos(data) {

var photoHTML = ‘<ul>’;

$.each(data.items,function(i,photo) {

photoHTML += ‘<li class=”grid-25 tablet-grid-50″>’;

photoHTML += ‘<a href=”‘ + photo.link + ‘” class=”image”>’;

photoHTML += ‘<img src=”‘ + photo.media.m + ‘”></a></li>’;

}); // end each

photoHTML += ‘</ul>’;

$(‘#photos’).html(photoHTML);

$searchField.prop(“disabled”, false); // renable search field

$submitButton.attr(“disabled”, false).val(“Search”); // renable submit button and put value back

}

$.getJSON(flickerAPI, flickrOptions, displayPhotos);

}); // end click

}); // end ready

Understanding “this” in JavaScript

  • this is a special keyword to give access to a specific context – access values, methods, and other objects on a context basis
  • JavaScript interpreter assigns a value to this based on where it appears
    • In normal function calls
    • Within methods on object
      • This, when it’s being called by a method on an object, will always reference object itself and this.anyKey will look up any value that exists

var Portland = {

bridges: 12,

airport: 1,

soccerTeams: 1,

logNumberofBridges: function() {

console.log(“There are “ + this.bridges + “ bridges in Portland!”)

}

}

Would print There are 12 bridges in Portland!

  • Within an object that has been constructed
  • Invoked with .call. apply or bind
  • When we use a constructor function to create a new object, this will actually refer to the object that is created, nto the constructor function.
  • here’s a basic constructor function

var City = function(name, state) {

this,name = name || ‘Portland’;

this.state = state || ‘Oregon’;

};

portland = new City();  // new instance of constructor function

seattle = new City(‘Seattle’, ‘Washington’);

 

results in -> console.log(portland); console.log(seattle);

 

{ name: ‘Portland’, state: ‘Oregon’}

{ name: ‘Seattle’, state: ‘Washington’}

  • The first object is the one created without any parameters, so it defaults to Portland and Oregon.
  • The second one uses Seattle and Washington
  • They keyword does not correspond to the constructor function (city) but corresponds to the instance object itself. This basically allows you to create applications with highly replicable code

Dec 2017 Learning

Less reading and off-time Treehouse learning this month. Want to timebox at least 10-15 minutes a day for these.

Treehouse AJAX Basics:

  • Make sure classes correspond with html
  • Use removeClass() say after something, like a button, is selected so not all the buttons are selected for example
  • Passing data to set-up API example:
$(document).ready(function(){

  $('button').click(function () {

    $("button").removeClass("selected");

    $(this).addClass("selected");

    var flickerAPI = "http://api.flickr.com/services/feeds/photos_public.gne?jsoncallback=?"; // adding JSON callback to query string

    var animal = $(this).text(); // this refers to button and text() gets text from html element

    var flickrOptions = {

      tags: animal,

      format: "json"

    };

    function displayPhotos(data) {

      var photoHTML = '<ul>';

      $.each(data.items, function(i, photo) {

          photoHTML += '<li class="grid-25 tablet-grid-50">';

          photoHTML += '<a href="' + photo.link + '" class="image">';

          photoHTML += '<img src="' + photo.media.m + '"></a></li>';

      });// loop through the array applying the callbackfunction

      photoHTML += '</ul>';

      $('#photos').html(photoHTML);

    }

    $.getJSON(flickerAPI, flickrOptions, displayPhotos); // three arguemnts, URL to resource, data we want to send with URL, callback function

  }); // function will run each time button is clicked

});

Treehouse UX Basics Tools UX-ers Use

  • Card Sorting: all different pieces of content on card and ask users to group the cards. Optimal Sort or Remote Search can be used to do remote.
  • Search Logs: understand what users are looking for
  • Content Inventories: Excel, etc. so there’s one way to look at all it
  • Beyond Philosophy defines UX as “an interaction between an organization and a customer as perceived through a customer’s conscious and subconscious mind. It is a blend of an organization’s rational performance, the sense stimulated, and the emotions evoked and intuitively measured against customer expectations across all moments of contact.”
  • Customer or User Journeys – Mapping out phases of customer’s journey and touchpoints. Identify opportunities, etc. through this process
  • Flow Diagrams: Steps user take
  • Wireframes: Diagrams or blueprints to show information relationships on pages and views
  • Comps: Showing details of specific moment of context. Think wireframes + aesthic
  • Prototypes: Show working relationships, aesthetic, and interactivity
  • Usability Testing
    • Moderating means there’s a facilitator asking questions and assigning questions
    • Unmoderated: puts together tasks while users go on their own

Treehouse UX Basics: Strategic UX

  • UX as a strategic initiative: see it at organizational or strategic level rather than immediate goals for users and see how important a task is to overall company, eg. how does getting auto quotes impact overall org’s bottom line?
  • UXers and non-UXers alike don’t agree on how to define UX
  • Your value is partnering with business and technology to emphasize with users and creates better experience and better user loyalty that brings more to bottom line
  • Selling UX means 1) Understanding what your business and technology partners value 2) Describe to them how UX meets those values in tailored responses to them by finding root causes, eg. what are the roots of wanting conversion rates. Don’t explain hows of UX but the Whys so you’re not an expense but a necessity

How to Build an Engineering Culture that Focuses on Impact

  1. Share with the engineers the value they’re creating, even if it’s “grungy but critical tasks” to let them know they’re being valued at the company
  2. Daniel Pink argues motivation comes from three key elements: autonomy, mastery, and purpose
  3. “Shape your culture through conversations and stories,” simply writing values doesn’t really mean anything

13 tips for product leaders on distributed teams

  1. Have an insider on your leadership team that can bridge cultural gaps and understand context of both languages and cultures and can mentor colleagues on both sides when it comes to improving communication
  2. Geographic gaps can multiply specialization gaps, eg business versus R&D that is compounded with distance and cultural differences
  3. If your engineers and business people look down on each other it’s your fault, create transparency and appreciation: “It might seem irrelevant to show your messaging and positioning documents to engineering or to show complex technology architecture to your sales people, but trust me, people learn to appreciate the challenges of the different roles when you surface the complexity. Animosity among colleagues usually stems from a general lack of understanding. Let members of each team shine and teams will show each other more support and respect.”

Three questions to ask yourself, before speaking to your users

  1. “What do you need to learn?”
    1. The big picture questions: who are customers, what’s their biggest problem, what do they want?
  2. “What do we need to learn right now to make progress?”
    1. Outcome of research that immediate action can be taken on
  3. “What’s the best way to learn?”
    1. Focus on doing minimum effort or method (interview versus user test) to learn

pm@olin Metrics (Class 8)

Continuous Improvement

  • PMs can create detailed factual timeline for post mortems – everyone should add what’s missing and note patterns as well as things done well and things that can improve on next time

2017 List of Wins + 2018 Look Ahead

I thought I was going to have a low-key NYE alone, but ended up going out. I still read this before, and thought it’d be good to put down a list of #wins and just things I’m thankful for this year and looking ahead for 2018.

Wins:

  1. New role at work and working on an interesting project with a team. Felt like my career moved ahead a lot after feeling a bit stalled.
  2. I read 45 books last year, most captured here on Goodreads 
  3. I lose 11 lbs without really grinding hard, just more positive lifestyle choices
  4. Saved nearly 25% of my income
  5. Figured out who and what to prioritize in my life

For Next Year:

  1. Improve on my process at work as well as attitude and results. At my current workplace, I think we have an opportunity to build a good culture – so I hope that’s something I can help do.
  2. Read more fiction this year and still definitely read 30 books as a goal
  3. Continue to go on this healthier lifestyle path (incorporating yoga into my weekly workout routine, and eating more vegetarian meals namely)
  4. Save 30% of income
  5. Actualize some travel and academic goals

November Learning

I’m trying to give myself at least half an hour during the workdays (or at least blocking two hours or so a week at least) to learn something new – namely taking classes on Treehouse, which I still have a membership to, reading job related articles, and reading job-related books. Tracking notables here as a self commitment and to retain in memory.

Treehouse UX Basics: Modeling, Testing, and Executing the Experience:

  • Modeling a solution -> demonstrates to users, eg. axure that is not the interface. Design for the experience
  • Test interface with people likely to use your product
  • Learn to present to clients and sell your work
  • Success in UX is keeping mindful of all other players at all times and being a translator between engineering, qa, account management, project management, etc.
  • Context is about predicting the right information at the right time for the user

 

Treehouse UX Basics: How UXer’s Think

  • Think big in order to think small – system thinking – match any small feature to larger experience. All parts and processes should be part of a congruent narrative
  • Empathy is different from user-centered design -> do you know how the user actually feels. Be the user advocate of users needs, goals, and tasks
  • Be able to think beyond the end user. Eg. business stakeholders in the org, coders, etc. They are also “users”
  • Think of content beyond traditional sense – eg everything on site
  • Understand how site users will be, content available, and context – think of problems to solve just beyond surface level like articles, etc.

 

Treehouse UX Basics: Tools

  • Understand who you’re communicating with, what needs to be shared, and the context
  • Conducting User Interviews: Google Forms, Survey Monkey, Ethnio

 

Treehouse Javascript: AJAX Basics

  • Make sure property names are set properly and insert into divs
  • The jQuery method if handling errors in an AJAX response is .fail()
  • The .fail() method does not work when using the .load() method or when making requests to another site
  • Application Programming Interfaces provide a method for accessing certain content using a server-side programming language: defines what you can get and how you can get it. Some let you just get it with AJAX without server side programming
  • API key acts sort of like a password, when you connect to a server, you have to send along your API key

 

10 Steps for a Successful Wiki

  1. Link to only external files when necessary
  2. You need a well-defined structure off the bat because users build habits quickly
  3. Use good tagging for search

 

What Are Wikis, and Why Should You Use Them?

  1. Flexible access for editing
  2. Hyperlinking is the power – adding quickly and linking
  3. Key uses are having an easily searchable knowledgebase and training

 

Best practices for staging environments from increment mag

  1. Staging’s purpose is the validate the known-unknowns of your systems, eg. the dependencies, interactions, and edge cases that are foreseeable by people in the company.
  2. Tests don’t account for all the possibilities that staging can.
  3. Staging should be constructed the same way as production, eg. same load balancers, deployment tooling, security group settings, etc.

 

pm@olin Class 6

  1. Launch stages: alpha, friends & family, beta, public soft launch, traditional launch
  2. Launch communications: Internal thank you notes to team and individuals. Internal/External: customer support, blog posts, homepage announcements. External: Product Hunt Post, Press Release/PR, Help Documentation, FAQs
  3. People tend to anchor on first things you say – it can be hard to keep things general when you want to (in her class notes but applies a lot to other things)

 

pm@olin Class 7

  1. Goes without saying, but complement/criticism/complement is not a good tactic compared to specific feedback
  2. Mental model for feedback, it’s information you or a person can use if they like
  3. Johari Windows -> something useful to understand relationship with themselves and others

 

Five Levels of Communication

  1. Ritual: most simple form of conversation: eg. quick hello
  2. Extended Ritual: day to day pleasantries that may change day to day – but it’s at a safe level of no danger of being misinterpreted but are the foundation of building trust and safety in interpersonal relationships
  3. Surface: What people are in place of work, eg. receiving information at meetings and giving. Talking about basic life conversations such as politics, hobbies, families, etc.
  4. Feelings (about self in relation to content): Just below surface and sharing of riskful real feelings.
  5. Feels (about us and our relationship): Greatest level of risk and involves giving honest feedback

Organizations that are able to have four and five communication can increase potential dramatically. Companies that are just between one and three can lack harmony and cohesion and the weakness is clear in crisis situations.

 

Shipping is a Feature: Some Guiding Principles for People That Build Things

  1. The hardest part of PMing is achieving clarity and maintaining a POV and vision for a product when literally everything conspires against this
  2. Figure out how to do compromises without muddling the product
  3. 10% better can be 100% different – incremental improvements can have huge effects

 

Why Most Product Launches Fail

  1. Companies can’t support fast growth
  2. Products get released too early and aren’t ready (Windows Vista)
  3. Product limbo and positioning a product to leverage a fad is a mistake
  4. If customers don’t get it quickly – it’s toast
  5. There’s no market for it even if product is revolutionary – should answer the question “Who will buy this and at what price?”

 

Engineering Management from Yishan Wong: Hiring is number one

  1. “The quality of coworkers is the single greatest determinant of workplace happiness, and fully engaged participation by everyone is the primary way by which everyone exercises direct power over making their job experience better.”
  2. Are you hiring the best or just hiring the best people you were able to interview?
  3. Hiring good candidates ensures you have a strong internal pipeline for promotion

 

Engineering Management from Yishan Wong: Engineering Management – Process

  1. Processes should only be implemented if they are specifically wanted and by the people directly involve in using it versus management who are only really thinking about command, control, coordinating, or communicating -> true costs cannot be seen in this fashion and benefits maybe illusionary
  2. Managers can figure out how to coordinate and communicate without necessarily implementing more engineering process (eg. endless jira loops)
  3. “Managers may need to psychologically contend with more chaos than they are comfortable with, but there is a huge difference between chaos that makes one uncomfortable and chaos that actually threatens the business. Stepping as close to the latter as possible confers one of the greatest advantages in the technology business: execution speed.

    Process typically builds up at a regular and roughly constant rate. Shaping this rate is therefore key to long-term efficiency. If your company has a certain amount of process at size X and it’s less than other companies of size X, you’re faster, and when you’re much much larger you’ll have less comparative bureaucracy, and the same multipliers will apply: doing things twice as fast now while you’re small helps you get things done in two weeks while your competitor needs four weeks, but once you’re large you’ll be able to do something in two years while your competitor takes another two to catch up. Two additional years might just mean the end of them.”

 

Engineering Management from Yishan Wong: Internal Promotion

  1. “A successful manager needs to understand core elements of the company culture and values, including what makes the startup uniquely successful and what steps it needs to take next. An impressive resume or even the memory of their performance by others who worked with them in larger companies is not a reliable indicator of their ability to do this.”
  2. “Source management candidates who are willing to join as individual contributors. While the company remains below a certain size, it’s is eminently possible for highly talented technology managers to join as individual contributors and rapidly rise into positions of leadership, and they should be encouraged to do so.”
  3. People who join companies because “they’re great” tend to have very different orientations and motivations (money, security, conservatism) versus those who shared early core values in a start-up. Tread carefully and have a pipeline

 

Engineering Management from Yishan Wong: Tools Are Top Priority

  1. Internal tools shouldn’t be regulated to the back office, but rather have talented engineers work on them because there’s a direct impact on operational efficiency
  2. “The quality of your tools and your ability to continue to evolve them will allow you to suppress the need to hire for operational roles, allowing each front-line individual to do more, which simultaneously improving overall coordination (fewer people means coordination is easier) and keeps costs down.”
  3. You need a foster a culture in the organization that values internal tools so your best engineers will be willing to work on them

 

Engineering Management from Yishan Wong: Technical Leaders

  1. “All external management hires must be able to write code and show a high level of technical proficiency, up to and including the head of the technical department. If the company is a technology company, this should also include the CEO.”
  2. “Leaders are unable to tell when the technical staff is not performing up to snuff, because they cannot reliably differentiate between excuses for poor technical performance and true obstacles that arise when contending with difficult technical challenges. Performance management then becomes impossible, leading to mediocre work and eventually, outright and repeated project failures.” – > the more you understand the rules of the game, the better you can play it
  3. “Unfortunately, a non-technical leader has no personal ability to gauge the actual risk profile of overriding technical suggestions (i.e. shrewdly exceeding old limits in certain special situations) and is then prone to eventually overriding technical advice which should not be overridden.”