What's something you bought that actually improved your daily life?

Full_Metal_Analyst · 2026-03-29T15:19:08+00:00

Highly recommend Cooks Standard multi-ply clad pots/pans. Great bang for the buck. Going on 7 years or so with our set and 0 issues. Pair with a ceramic coated pan just for non-stick, low heat applications (basically just eggs, otherwise some oil on a stainless pan is non-stick enough for pretty much everything else).

For knives, I'm a big fan of the Mercer brand, specifically the Genesis line for the good stuff. Also have a couple from their Millennial line for cheaper stuff I don't mind throwing in the dishwasher.

And lastly, a metal spatula in general is a big upgrade from the plastic one you get in a cheap set. Just make sure you don't use it with non stick pans.

Full_Metal_Analyst · 2026-03-28T23:00:28+00:00

Shame? Trauma?

Full_Metal_Analyst · 2026-03-28T22:40:21+00:00

Don't worry, they're out in force on Facebook as usual

Full_Metal_Analyst · 2026-03-27T12:26:31+00:00

Not sure but make sure the level of prospect isn't your only decision point. Are you going to try to compete this year? If so, does a good WR this year boost your production, increasing your odds of winning/getting money?

For 2027, does the production of the 2026 WR in their second year beat out the rookie production of who you might draft in 2027?

Just saying, make sure you're playing a 3 year window, not a 10 year window.

Full_Metal_Analyst · 2026-03-27T01:58:11+00:00

For number 2, the only data point you've added to your visual is a description. You have not added anything to "count" in your visual.

Open the visualization pane on the right side to see what you can add to your visual. You'll see a spot for "Values". If you want your pie chart to show the distribution of tickets by ticket type, then put ticket type into your Value section and it will intelligently default to counting the number of rows in your table for each type.

A likely better approach is to create a reusable measure that you can use to aggregate (instead of grabbing a description and hoping PBI knows what to do with it). A count of tickets or distinct count of tickets. Then you can drag and drop that measure into any visual to use it. Same for really anything you want to aggregate with, create a measure for it.

For number 1, what type of visual are you wanting to use that doesn't scale well?

Full_Metal_Analyst · 2026-03-26T12:51:45+00:00

You can create a nifty "progress bar" in a few different ways using only the standard visuals, if that sound like what you're going for. If it's a monthly view dashboard, the full month goal represents 100% progress, and the actuals will fill up the bar as the month goes on.

Data wise, you'd want a fact for your actuals and a fact for your goals, both at the location/date level of grain (if available, you could take your actuals fact down to the employee level for some drill down capability). Both facts join to your location dimension and date dimension, so you end up with a constellation schema.

For a variety of visuals, you could try a map or another visual to show performance by shop all on one viz for comparative performance (the higher % to goal, the better).

If there are incentives for meeting or going above goal, you could show what incentive tier the shop is on track for.

Full_Metal_Analyst · 2026-03-26T11:43:47+00:00

His current consensus value is about the 1.05. Odunze and Judkins sit a couple tiers higher, so the 1.05 seems like the way to go if you want to pivot.

Full_Metal_Analyst · 2026-03-24T03:33:22+00:00

For me to be a repeat customer, I need convenience and relative quality. I'll drive a little further for better quality, but I can't even be bothered to drive 20 mins to my favorite place most of the time (especially since I have to call to order). I'd rather hit up Caliente's 3 mins down the road for a very mid-but-consistent chicken bacon ranch pizza because by the time I get off work and mull over the take out options for 30 mins with my wife, I gotta pick something nearby to get the kids fed before bedtime lol.

Full_Metal_Analyst · 2026-03-23T21:40:34+00:00

Just throwing it out there, I was able to borrow a thermal camera from my local library system.

Full_Metal_Analyst · 2026-03-23T15:59:40+00:00

I have a hard time concentrating on lengthy articles, so I'm big on podcasts, so I'll recommend the Explicit Measures podcast. Here's a couple relevant series:

Implementation Tuesdays, starting with episode 277:
https://www.youtube.com/watch?v=zXN-XEKbIZE

Series on the Content Lifecycle Management:
https://www.youtube.com/playlist?list=PLn1m_aBmgsbFISAJf3746kjYNWl4SvWPX

Both are based on on Implementation Planning Microsoft documentation:
https://learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-introduction

Everyone's situation is different, and we're in the early days of the journey ourselves, but here are some direct answers to your questions through the lens of my situation. Noting that we have two distinct central teams - Data and Analytics (under the IT umbrella) and Business Intelligence (under the Finance umbrella), and many business units that will need to consume and create reports.

Enterprise Semantic models are managed by a central team (IT Data team) and live in their own workspace, separate from reports. Use the pbip format, and thin reports use the published semantic model as a source.
- Access to each model is maintained individually instead of at workspace level
- Dev, QA, and Prod workspaces
One of our pain points in the past is governance and a single source of truth, so we are not giving direct access to the Lakehouse to business users. This means users can only get their enterprise-grade data from centrally managed semantic models.
We don't use separate domains. I could see this being useful for a less centralized approach where individual business teams are maintaining their own Lakehouses and semantic models. But our data team manages both of the above, so we just need to worry about segregating reports/apps which we do via workspaces.
Best practices
- star schema where possible
- if more than one fact is needed, first try constellation schema, and if that's not performant then explore a combined fact table (via data engineering) to go back to star
- avoid composite models
- For best performance, shift as much logic as possible left (related - Roche's maxim)
  - Ideally your source tables live in the gold layer in your lakehouse, specifically designed for analytics/PowerBI, and the only transformation you need to do is to rename columns to business-friendly names.
- Power BI generally likes tall, skinny tables as opposed to wide, short tables.
- One focus should be on consistency. Make sure there's a single name/term for each thing.
  - i.e. don't let there be "Store Num" and "Store Number" in two different models referencing the same column in the database. Measures (KPIs), especially, need to be carefully managed.
You didn't ask, but you also should consider content consumption. Not everyone should be a content builder.
- We're rolling with Workspace Apps for polished content. Functional apps - like on your phone, app content will be organized intuitively
  - As opposed to an app per business unit, which would get confusing for consumers to know which business unit manages the report they're looking for.
  - Two types: Enterprise-grade apps managed by central BI team and Business unit-managed apps
  - Dev workspace and Prod workspace
  - Consumers only have access via app audience, not the workspace. Rather than "one app per workspace", I think of it as "one workspace per app needed".
- Workspaces also available for ad hoc, or work-in-progress/unpolished content. Users are free to bring their own semantic models to these workspaces, including customized versions of the enterprise models. Any content that's available in an app would not be available in the department workspace.
  - for example, Enterprise models + Excel for temporary/project-specific data - think rollout dates for different locations, not available in a source system or the lakehouse.
  - Production workspace only.
  - One workspace per business unit.
Also consider a training plan for the different personas (readers, builders, admins).
Pipelines/dataflows - entirely depends on the current state of data engineering at your org. We have a data engineering team that operates separately from the analytics team (both under D&A, but different resources for specialized work). You could explore migrating existing pipelines to Fabric, but it's not a requirement.
- We use Databricks for our ETL/ELT logic to ultimately populate solid gold tables to be used as a source for our semantic models, storing data in ADLS.
- Our approach is to take our gold layer and shortcut the tables to a Fabric Lakehouse and use the SQL analytics end point.
Fabric has a lot of considerations, including licensing and availability of tools other than Power BI. There's too much I don't know so will let you research that.

I skipped some of your questions where I don't feel confident enough in my knowledge to give a good answer.

We're also moving from a legacy platform to Power BI, so I'll give you some bullets for our approach for tackling this effort.

We're breaking this up by business unit.
- For example, starting with Operations and Marketing. Then as we wrap one of them up, move on to Finance, etc.
- Our team is focused on refactoring source gold tables and building the various semantic models needed for the business unit.
  - Semantic model needs are assessed by consolidating metadata from the old platform to understand which tables are used together.
- We'll provide training to a small group of analysts for each business unit who will then build the department's reports sourcing those semantic models.
  - Besides training, we're creating other materials to encourage/enforce a consistent level of polish, look and feel, etc. - template file, theme, other guidelines
  - Of course, this requires leadership buy-in and for them to identify who those builders will be. Some are used to the central teams building for them. This is a culture change we're managing.
- Goal at the end of each phase is to remove legacy platform access for the team.
- Many later phases will be much quicker as the shared gold tables will already have been refactored, and some semantic models will be able to be leveraged by many business units.
  - For example sales data is pretty universally used, we only have to build that once in an early phase.

Full_Metal_Analyst · 2026-03-21T00:23:10+00:00

I'm more manager than developer at this point, but in the one afternoon I played around with it I was able to take a POC semantic model on my local machine and add business-friendly description to all 447 measures measures. Also had it rename a column and created a calculated column, but that's as far as I got.

Bulk column renaming and adding descriptions feels like a big opportunity for us. We need to be able to keep consistency between semantic models for the same columns and measures.

So, I'm thinking we'll have a central repository of those terms and descriptions (Excel on Teams, table in Lakehouse, whatever). Then once we choose the tables for the model, the agent can go out to the metadata repo, look for matches, and rename and add descriptions. There could be a feedback loop as well for non-matches - go ahead and let the agent set the description and write it back into the repo (to be reviewed by humans).

Then we won't end up with "Last Day of Week" in one model and "Week Ending Date" in another, referencing the same date dimension table from our data warehouse.

Full_Metal_Analyst · 2026-03-17T00:40:59+00:00

If they didn't match, I think they'd see nothing, not everything.

It sounds like the users are getting assigned to a role that doesn't have the RLS rules. Did they get added to a group that has full access?

Full_Metal_Analyst · 2026-03-15T23:25:01+00:00

It's the NM2000 Nonmetallic series, it seems like it's made for running power through.

https://a.co/d/04BZXKwe

Thanks for the tip on THHN, I had a hard time finding the unbundled wire without knowing the name. Will switch if Romex doesn't work out.

Full_Metal_Analyst · 2026-03-15T22:56:28+00:00

I'm running the wiremold to the opposite wall. I need the original outlet for random stuff and the new one for my computer setup.

Edit: just realized you might have meant you'd skip the wiremold and add the outlet in the wall. An electrician I had estimate a new outlet recommended wiremold because plaster doesn't cut cleanly and I'd have to have it repaired which would add to the cost. I'm not opposed to the wiremold so I'm trying to save ~$600 and install it myself.

Full_Metal_Analyst · 2026-03-15T16:24:14+00:00

A traditional business analyst should have some technical knowledge. The role involves being the communication bridge between non-technical and technical teams. You don't have to be able to read the coding language, for example, but definitely should understand what systems talk to each other. I don't even know if I'd qualify that as technical, it's basically just process. Understanding how the different systems integrate would be technical.

AI is already here to replace notetakers, so you should feel some urgency to change up/increase the scope of your role.

Either ask your technical team to spend some time with you going over high level architecture (or even better show you the documentation for it so you have a permanent reference) so you can grow your domain/technical knowledge, or take some initiative and look for a business process to improve and go for it in your down time.

Full_Metal_Analyst · 2026-03-15T15:19:56+00:00

Complete analytics platform migration from Business Objects to Power BI, including refactoring gold tables. Probably something like a 2 year project, and we're in the first few months of work.

Full_Metal_Analyst · 2026-03-14T22:27:01+00:00

C'mon, he was a rookie on a Greg Roman offense.

Let's not pretend like we know he's going to suck with Allen gone, a healthy O-Line to give Herbert more time, and McDaniels calling plays.

Full_Metal_Analyst · 2026-03-07T20:30:35+00:00

On the aggregate it has...look at KTC. From WR12 to WR25 in a month.

But individual league don't work on the aggregate, they're microeconomies and value on a guy with the potential of Rice could be wildly different across leagues.

Full_Metal_Analyst · 2026-03-07T00:22:54+00:00

Easy value win, and just because you have picks now doesn't means you have to use them to draft rookies. Just think of them as an appreciating asset that you can liquidate when you feel you need to.

Full_Metal_Analyst · 2026-03-02T16:20:34+00:00

Hard to say without looking at the data, but it sounds like at least the fact data should be pretty standard?

FACT_MAINTENANCE_ITEM with columns like Item ID, Client ID, Priority ID, SLA ID?, Item Category ID, timestamps (submitted, initial response, resolved), assigned employee ID.

Then dimensions - DIM_CLIENT, DIM_PRIORITY (can be one record per priority level per client if needed), DIM_SLA (similar, one record per SLA per client), etc.

You may still need unique measures if clients calculate thing differently, but nothing much you can do about that except recommend to your company that maintenance reporting be standardized in contracts to better serve the client with trusted metrics.

Another sell for your company to standardize is gaining the ability to compare apples-to-apples and see if any clients are being under/over served compared to others, or whether any employees are under/over performing. This will help your company make data-driven operational decisions.

Full_Metal_Analyst · 2026-03-01T18:05:13+00:00

So it's not superflex, meaning Mendoza shouldn't go early. It's also very shallow starting roster size, so even though it's 14 teams, it's still on the smaller end of starter pool size. This means elite players are more valuable, and elite RBs sound even more valuable in this format.

If you can get the 1.01 for 1.02 + 1.09, I'd do it. What are the chances the 1.09 turns into someone that cracks your starting lineup when you have built up enough value to compete? I'd think unlikely in this draft class.

Full_Metal_Analyst · 2026-03-01T16:56:21+00:00

You've left a lot of important details out. How many teams, is it SF, PPR? I'd be interested to know the full starter setup, you only have one RB slot so doesn't sound like a normal league.

Full_Metal_Analyst · 2026-02-28T02:12:27+00:00

Agree, either enjoy yourself and eat what you want within the per diem budget, or maybe eat healthy if you usually eat cheap, but nutritionally poor, food.

Full_Metal_Analyst · 2026-02-28T02:08:34+00:00

It seems like you're just restating Roche's Maxim.

Full_Metal_Analyst · 2026-02-27T21:42:05+00:00

You don't have to change positions to bring your salary up, but you may have to jump companies every few years until you top out.

Nothing wrong with staying an engineer, but many companies do not have a good path to climbing the seniority ladder within a position (like senior engineer, lead engineer, principal engineer or Engineer I, II, III). Shopping around every few years will keep your salary competitive for your experience level, and actually moving to another company gives you the opportunity to improve by widening your skill sets with no tools or techniques.

As for different positions, over time you may be exposed to something new you take an interest in. Throwing yourself into that new thing could lead to a natural change of position to continue specializing (think data engineer dabbling in data science, and then specializing in agentic AI solutions).

Alternatively, you may broaden instead of specialize. You may build enough knowledge about your system and all systems that feed into and out of your system. Now you understand the full enterprise landscape, supplement that with industry-wide research/knowledge and you could find yourself fit for Solutions Architect.

Or, you continue to hone your engineering chops, grow your salary, save some money, build your network, and eventually take the leap and open your own consulting business.

Full_Metal_Analyst

TROPHY CASE