strife25

I think context matters a LOT here. Knowing when to be pragmatic and quick vs thorough is the mark of an experienced engineer. The trick is knowing HOW to pick the right approach.

A key point is understanding the business (or personal) goal of the system.

Is this a mission-critical system that is core to how the company makes money? Then make sure its robust.

Are you a startup figuring out product-market fit? Then thorough and robust systems matter less. The goal is figuring out how to get users and customers, not stabilize.

I actually wrote more about this a while back: https://www.buildthestage.com/when-should-you-over-engineer-...

Generally agree with this approach. We need to make sure that friction exists in our kids' lives.

I have a toddler, and screen time is something that is on top of my mind, Balancing the trade-offs of when to use it while also minimizing it as much as possible.

Something that made me really sick to the stomach was learning how Cocomelon was doing AB testing to make sure that children don't look away from the show[1]. In response to that, I default to showing my kids shows from the 90s that didn't use cuts, aggressive cuts, to keep attention going. Things like Sesame Street, Mr. Rogers Neighborhood, etc.

Heck, I remember trying out one Disney show focused on Minnie Mouse and barely allowed the show to run for three minutes after I realized that there were multiple cuts happening every three seconds.

[1] https://www.nytimes.com/2022/05/05/arts/television/cocomelon...

Marginal costs matter in this world.

I like this angle. I didn't read much of the article, but I do think this is a topic that people should consider, at least when it comes to estimating software projects. I don't think we really think enough about the monetary costs of our projects. When I raise the topic in my discussions, it really changes and focuses people, particularly when folks are advocating for tech debt projects that don't really have a return because they're not a focus for the company at this time. When we say that it's going to be a $60,000 project, it quickly becomes deprioritized in the conversation.

Does anyone know of good building science websites? I'd love to better understand best practices.

The only one I've found is https://inspectapedia.com

There's great stuff on YouTube too (e.g. Matt Risinger's channel), but soooo much conflicting information.

> Sometimes making the cinematics wasn't a core competence of the studio working on the game, so VFX or animation studios would be contracted to do this.

That explains why FFX's cinematics had different character models compared to in-game designs.

What I've been annoyed with for years: Drying Racks.

What do people do instead of using these? I'm guess just hand drying them. I do have a lot of air-tight container lids that are super annoying to hand dry.

I like the convenience of the drying rack, but hate the countertop clutter and space it takes.

Labor wasn't the issue, it was UX.

Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc.

Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an issue anymore. Rendering a bunch of HTML is as quick as rendering JSON.

As a vet of the IE7 days, I love this trend. Leveraging the best of server compute and browsers is going to simplify web app development a LOT.

_hums the rhythm of wisdom_

+1

SPAs were a workaround to slow CPU servers serving millions of requests in the mind-2000s. Client computers were faster, so it made sense to push UX logic there.

We've flipped things around. Servers are fast as hell for rendering HTMl. We can leverage that and re-focus the client on UI code that only it can do.

I switched from Paprika to Plan to Eat this year and love it.

Https://plantoeat.com

It has the same features as Paprika but Generates a shopping list from your meal plan. Saves a ton of time when shopping.

The one thing I don’t like about PtE is you can’t mark off ingredients as you prep them. Paprika has this and I miss it.

Exactly! It’s a crazy diverse user base too.

The needs of designers creating a marketing site and engineers working on a real web app are different, but they all work with web tech.

The bar to writing javascript is so much lower compared to other languages. All you need is a browser and learn how to open its devtools. Beyond that, you need a text editor, learn basic HTML and JS, and open a file in your browser.

Compare that to other languages, where you need to open a terminal or install special software, figure out how to write commands, install these things called packages, get esoteric errors, etc.

That amount of work to write JS vs other languages is drastically different for new coders.

With this lower bar comes a larger user base. A larger user base leads to more innovation – for better or worse.

It's inevitable to see people reinventing the wheel as they learn, simplified tools targeted at niche users, different needs (high-scale engineers vs designers), etc.

I know engineering communities get exhausted by the library churn of the JS community, but I think it's a symptom of real success. A user base this large is going to create noise, but also produce real gems from time to time.

------

I write about engineering management at [Build the Stage](https://www.buildthestage.com).

The book is completely fine and worth the read! Just know that it's a book to explain the career path of an Engineering Manager in the tech industry.

My criticism is around how often the book is recommended. Many people want to learn HOW to become a manager. Manager's Path doesn't provide that.

Conversely, a lot of people recommend An Elegant Puzzle. Great book, but I would not recommend it to first time managers – it's too advanced.

Elegant Puzzle is for experienced managers, specifically people that are managing Managers. Check it out if you're 2+ years into their management career.

Everyone recommends The Manager's Path, but I don't think it's a good book to explain HOW to become a manager. The book's goal is to explain the career path of a manager from tech lead to CTO.

My #1 recommendation these days is "Become an Effective Software Engineering Manager" by Jamies Stanier. This book explains how to approach the work a manager is involved in and what you can expect from the day to day. Planning, hard conversations, performance reviews etc.

Also, look for general management books. Leadership is something all humans do – software management is about managing creative people. Some other books I recommend are:

• Creativity, Inc by Ed Matmull • Crucial Conversation • Team of Teams

For email newsletters, I recommend Software Lead Weekly (https://softwareleadweekly.com/) and Better Allies (https://betterallies.com/more-content/).

Lastly, I also write a blog called Build the Stage (https://www.buildthestage.com) about managing SWEs. I've got posts about performance reviews, team meetings, how to give feedback, etc. It'll help you out.

When it comes to how much testing should be done, I think it's contextual on the project.

I expand on this specific point in a blog post: https://www.buildthestage.com/just-enough-automated-tests/

I've had the most luck w/ TDD for designing APIs.

When I write the tests first, it gives me a feel for how consumers of the API will use it. It's a great method to understand the UX of the re-usable code.

Shameless plug for my blog: https://www.buildthestage.com

I write about technical leadership and engineering management. The target audience are technical leads, managers, and people who wish to become leaders one day.

Reminds me of a recent email I got from a CTO community commenting on the "crazy salary inflation" that's occurring in the tech industry.

I used this method for a while on one of my teams. It was useful and helped provide more accurate estimates.

Some tips I have for people interested:

* Get about two months of velocity data in place first. * Run the simulation on a regular basis. Update your estimates every week/sprint. * It helps to have individual work units be "sized" as consistent as you can. (E.g. each ticket is 2-3 days, a consistent pointing system, etc.) It's ok if anomalies happen from time to time. * Dates will get more accurate the further you get into a project.

Some things I've learned from doing this exercise:

* When work units are sized to be 2-3 days of effort, engineers complete about 4 units/wk on average. * Don't shoot for the perfect estimate at the start of a project. Plan as much scope as you know and enough to get started. * As new scope is found, update your project plan and estimates.

When new scope is found, you update the plan of the project and provide new estimates.

I don't expect my team to know everything about a project on day 1. I just want them to know enough to start and provide a "good enough" estimate.

I do expect my team's estimate to get more accurate the further they get into a project.

Why is Jira a deal breaker for you?

IC = Individual Contributor

PIP = Performance Improvement Plan

hak5!!!

Such a classic tech podcast. So cool to see them still around.

_sigh_

Not a fan of the tone and judgement in this article.

It's great that your team doesn't require getting on a call or meeting in person to coordinate their work. That's not true for every other team that exists though.

There is no single process that works for everyone. Great teams take pieces of different processes and find what works for them. If Daily Stand-ups don't work, that's cool. If they do, that's cool too.

My team still does daily stand-ups. We stay focused and it's nice to see everyone. Other teams don't and produce just as much.

Anyways, if anyone is interested in learning how to make their daily stand-ups better, I wrote this article:

https://www.buildthestage.com/the-daily-standup-is-a-waste-o...

This Stratechery article from 2018 nailed it for me: https://stratechery.com/2018/ibms-old-playbook/

Home Improvement YouTube is amazing.

There's a reason we don't see modern Bob Vila-personalities on TV as much these days.

"Are Right, A Lot"

Does this value annoy anyone else? It screams to me that the only people whose opinions are respected are the ones in leadership positions.

meh, it's about balance and knowing what communication medium to use for a specific topic.

great teams don't just use one communication method, they adapt to the situation and people.

For deeply technical topics where there are a ton of specific details, yes - use writing.

For more free form topics - one on ones, retros, brainstorming, high level planning, calls or video chat may work better. It depends on what the people involved want.

No communication tool is perfect, use the ones that are right for the topic at hand.

Ask them what the top 3 problems they are spending time on. That will uncover areas for you to invest in understanding to uncover solutions.

People at this level are looking for help from people that are doing the real work in the organization who have a better understanding of the details. Conversely, this level has a wider view of problems that have high impact across the organization. Seek to uncover those problems and find solutions.