cheeseface

Every country should have legislation in place that allows this.

It depends. If you were hell-bent on selling snake oil for your own profit and then suddenly make a U-turn, you should definitely be called out.

Optimal slicing is indeed a hard problem, since what is ”optimal” also depends on what you’re optimizing for. Bigger slices more easily lead to higher short-term throughput and more developer flow time, but less collaboration, knowledge-sharing, and predictability.

You meantioned ”sprints” so sounds like you’re working with something Scrumlike? I worked in Scrum teams for ~5 years and have now worked with Kanban for the past 2.

For me, Kanban has really solved much of the ”puzzle everything together at the end.” Instead of sprints we structure our around stories (goal of the original scope is ~2 weeks). Before we start, we slice the work inside the story into less than 1 day tasks (or as small as feasible). This allows us to have a high-level plan on the APIs, migrations, frontend, and backend work. Each story can then have 2-4 people working on them (depending on the level of ”natural concurrency” the tasks offer).

This is true, but when it comes to software projects, I don't think you can ever commit to a "hard deadline for a big project" unless the scope (or the cost of the project) is not set in stone.

I think those big companies are poor examples, as big companies have always more problems with aligning people around customer needs/business priorities. There's a lot more of corporate politics that takes time and a lot more money to waste (when the core business itself is highly profitable). If you look at the smaller companies (e.g. Linear.app) it is immensely hard to argument that they would not be building "useful software."

In our case, we stay close to the customer. Some ways we achieve this:

- We have a shared Slack channels with at least 20 customers. All engineers are on these channels and see the communications that is going on.

- All engineers work with customer support 1 week every X weeks. All engineers are on the support channel too and see the topics of the tickets / customer requests. - We gather customer feedback for feature requests and all new features are based on business priorities informed by this feedback.

- PMs and Designers regularly talk with customers when doing product research. When we have an idea of what we might want to build, 1-2 engineers join them in shaping an Epic (size: 1-2 months) or a Story (size: ~2 weeks). One of these engineers will lead the Epic/Story, which means that they amass a lot of context of the both problems of the customers and the technical details of the solution. Usually they are able to do much of the scoping/product decisions quite quickly after the Epic/Story has started.

- Engineers watch a sales / customer success call every two weeks and then join to discuss the contents of the call together.

This works well, if the size of the stories is small enough.

When trying to get ”consistency” rather than trying to estimate better, you should aim for a smaller ”batch size” since it results in less variability.

This type of cargo culting for sure exists, but I haven’t encountered this behavior in my career. Even all the ”agile” people I know are focused on delivering value to the end customer and the business. Meaning, they’re really interested in building software and features that people actually use.

Agreed. Seems to me that the whole thing is about getting good growth numbers on paper before the IPO.

He’s not interested in the long term success of the platform, but trying to get a successful exit.

I definitely want to hand over all of my medical records to a convicted criminal who has made his career in running ponzi schemes and abusing people with rare medical conditions.

We have a similar setup with TS/Node.js app and it is very easy to work with.

The article very well matches my experiences working with marketing in an early-stage startup for 1,5 years.

Slonik comes pretty close https://github.com/gajus/slonik. It does not inspect your DB schema, but has worked very well in our SQL-heavy architecture.

There are so many uses cases for this, even with the current quality. Many game developers dream of having something like this.

My favorite one is these jamming slippers tha come in many colors: https://drive.google.com/drive/folders/1XRtLQynqiYRVE54-MUYa...

I have the opposite experience. I've tried Illustrator and some Corel products, but Inkscape has been the most easy-to-approach tool for me.

Oddly satisfying.

The promise of a stablecoin, in this case Tether, is that you can always change 1 USDT into $1. When people buy Tether, they pay then $1 and believe the promise that they will get $1 when they want to.

This is not surprising. The WordPress scene is super confusing right now. I spent almost 5 years building WordPress websites professionally and stopped a few years go. If I would need to build a WordPress site today, I would not know if I should start. Even the themes at WordPress.com (the hosted "user-friendly" version) have wildly different editing experiences.

In the end, culture and values change surprisingly slowly.

They have had the same accounting firm for the past 5 reports, not alternating. " MHA Cayman" is just the new name for "Moore Cayman".

https://www.coindesk.com/markets/2022/01/26/tethers-new-acco...

Tether (USDT) is the largest "stablecoin" and the most interesting one here. Tether (USDT) and USD Coin (USDC) have a combined market cap of ~120. The total "stablecoin" market cap is ~170B. UST was at ~18B before the collapse, so it does account around 10% of the market. Significant, but not the most important player.

The biggest Stablecoin, Tether, is also struggling (https://coinmarketcap.com/currencies/tether/). Their 3 month trend is clearly downwards.