Daily calendar
- divide the workday into 2-hour chunks. Fill your calendar the preceeding week into those chunks to avoid context switching. (context switching is forcing your brain to remember the state of a previous task or go through the act of switching platforms / activities)
- By Setting your calendar early, you avoid burnout (the work will never be over but at least you have a schedule) and improve accountability for your time.
- You can improve your bill rate because you bill in consistent 2-hour chunks!
When designing dashboards:
- If you don't have a wireframe, use a text card to describe the story or narrative of each card and or how to use the page. What should users walk away with? What question does the User have coming into the conversation?
- Unless the client explicitly wireframes the cards they want, deliver fewer cards (let's say 5).
- Always start with a good title
- Have a narrative in mind. What is the hypothesis that you're setting out to prove? Does the data back up your Hypothesis? Or do you accept the Alternative? (ex. "Gurtinder believes that precipitation impacts avg. daily revenue) Know how you're going to prove this BEFORE you build the card.
- "So what?" --Always question if what you are presenting has real value (i.e. "what are you trying to tell me. Is it valuable. Is it common sense?)
- Relate cards back to the core business case or the examples they give (ex. "I want to minimize the number of croissants thrown away at the end of day)
- Use the "sniff test" (does the result make common sense?) And always understand the granularity of the underlying dataset before you build a card (remember the Average Daily Sales with Pret. We saw 3.44 with AVG and 7044 when we used a beast mode)
Is it good /robust analysis?
- Are we doing an apples-to-apples comparison? Is it fair / reasonable to compare the two things? Did we already know that? Or are you providing new insight?
- Get comfortable with googling the analysis you're trying to do. If you're working on a forecast problem, spend the weekend reading about forecasting.
Practice Presenting ONCE A WEEK
- use Zoom (or any screen recording tool) and record yourself presenting a topic. Listen to the recording. Are you reading slides or teaching?
Create Documentation on all your ETL as you move along (Do this. TCs)
Ideally dataset and dataflow names should be self documenting, but for more complex implementations, you'll need to show your work.
- business description of the input and output datasets
- business description of the design pattern implemented
- URLs for any dataset
- assumed granularity or CHANGES in granularity
- key filter columns
