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.