The persistence model makes documents somewhat sharable, but I do find Open Graph previews to be mixed. In Messenger it renders the whole URL, which is quite long due to encoding, and that kills the conversation view.

From an engineering point of view, yes you can save so much packaging for the company and optimise for a delivery to be in fewer boxes, which is a fun problem to solve.

From a retail operations point of view the cost of packaging and shipping is negligible and why it’s so often discounted. The real costs though are labour.

Your pick and packing staff are basically all judged on throughput so if someone spends 5 minutes to pack an order in 1 well fitting box they will be fired if everyone else can pack 5 orders in the same 5 minutes.

Generally speaking your packer station is set up so they either have a terminal showing their packing list, a tub of goods to pack for one or more orders, and stacks of different sized boxes.

The stations usually get messy quickly with papers etc all over the place. It’s not a place for precise work and speed is valued above all. In describing the work station I didn’t even mention scanning, taping and labelling of the package that has to happen in the same space too.

Some may argue it’s possible to be both fast and precise, but I would argue it’s not sustainable over an 8 hour shift.

Finally, similar to why potato crisps/chips have so much volume is that inefficient, or spacious, packing is generally better for transport as you are less likely to have goods damage each other from being too tightly packed together.

That’s why IMO generally things are packed sub-optimally from a space use perspective but actually optimally from a convenience and speed perspective.

Unfortunately there is quite the philosophical, ideological, and even dogmatic schism between the two sides.

Like another post I read, if you do have to enter a debate about it, it's probably a more useful exercise to ask each other what it would take for their stance to change.

I have bought a copy.

If anything I find people tend to look upon varied experience as proof that you can add value on multiple fronts and across functions within the organisation, which should make you a slightly less common cog in the machine.

I kind of just rely on Vimium and Vim mode in editors/IDEs now.

[1]: https://vimacapp.com/

Just as businesses are expected to monitor and react to competitors that are after their customers. They should also have processes in place to react to competitors for their staff.

On occasions where I do need more advanced features such as excluding file patterns or directories, I find the man page to be pretty easy to understand.

Working for a flexible work arrangement employer has made me appreciate the following alternatives to what I used to consider pros of working in the office.

- Hall way chats are now Slack chats. These are more likely to be in the open and allow more participants. When gathering feedback or ideas this allows interested parties to participate asynchronously, which they may not have been able to do in person.

- Quick tap on the shoulder assistance or conversations. These were always a little disruptive. With Slack statuses and huddles, I'm finding we can have explicit do-not-disturb signals and when everyone is ready, a quick low-friction way of having a discussion.

- Group meetings. There was always a limit to the effectiveness of this depending on the make up of the group and the size of the group. Being forced online means it's even more obvious when people are not comfortable participating. The solution being more async collaborative RFC-style processes before meeting in Zoom to discuss only the points of difference.

- Recordings. Often we would need to take notes, etc. Now everything can be recorded. Minutes are still good, but no longer need to be taken all the time. If the meeting was a bust and nothing of value was gained, you don't need to type it up. If something important was discussed, you don't have to rely on memory and can transcribe off the recording.

All of the above I consider to be a benefit to both the employer and employee as it allows for greater flexibility in how and when we interact and automated digitisation means a much easier process of persisting and communicating institutional knowledge that is being created among a group.

The other beginner tip I would give that's not in the original article is the command:

    set mouse

For context I worked for an online apparel retailer that had a lot of images and the site was hosted on Shopify.

The first solution chosen by the team was imgix, which was chosen because it had a very simple API, so integration effort was minor. The internal pitch to the business was we can reduce page load time by optimising the images. It received quick approval because it's a quick win and the costs seemed okay.

As the site got larger and our bills got greater than $1,000-$2,000 someone from imgix reached out and offered to sign us up to a contract for a better rate. I don't recall actual numbers but we ended up paying approx. $2,000 a month despite our growth in usage.

At the same time, competitors would approach us mentioning cheaper fees, sometimes half. However, all pitches failed because even at 50% off, the cost to the business was so insignificant as to not warrant the dev time. In addition to that, most replacements failed to be simpler to integrate than imgix.

The team did eventually move off imgix when Shopify introduced their img_url filter that actually did less than imgix - but was free. For the team the motivation to move was reduce a dependency and completely cut ongoing costs associated with a 3rd-party service.

Coming back to your question I think there are two approaches you can take:

1. Find slow, image heavy, sites and pitch them your product. If you are first in the door you could have an advantage. When working with e-commerce most founders start from nothing and you can just search for "founder of X" and should be able to find a name on LinkedIn. The pitch here is use us = your site faster = more revenue.

2. Offer agencies really competitive affiliate kickbacks. My observation of e-commerce is that many agencies receive kickbacks for recommending tools. Shopify themselves provide an affiliate program for referrals. As long as your service is easy to use and reliable, the agency won't care too much about other factors as long as its profitable. The pitch here is use us = more profit.

3. Content market to developers by showcasing how easy it is to use your app and clearly demonstrating benefits. The goal is to catch developers that are looking for solutions and doing some kind of market analysis or prototype. The pitch here is use us = get job done fast.

So if it's just you to a customer, 1 week becomes 2.

If it's you, reporting to your manager, to a customer 1 week becomes 4.

Although I generally don't apply multipliers this liberally, I do keep in mind how many stakeholders there are that can add uncertainty and friction to a project.

By not doing everything you can to get more funds, land a client, or hire that candidate, a startup increases the probability of failure. When a startup fails it's not only the founders that are affected but the whole organisation. How can you make a questionable ethical choice that guarantees the moral outcome is people lose jobs and lives you interact with daily are negatively impacted?

The challenge here though is that the consequences of questionable choices add up. If all choices turn out to be wrong, you end up with hires question why they were hired in the first place, partners that realise they joined on a hope and a prayer, and investors that realised they backed a dud. However, if all choices turn out to be right, then you become a visionary that saved the company multiple times. Perhaps even mythologising your bluff.

Theses risks and stakes contribute to why we lionise successful startups and founders, and why key decision makers generally will take their chances; if they wanted safety they would've taken a corporate job instead of founding or joining a startup.