ser0
In researching for this reply I see that it's joining a somewhat crowded field https://en.wikipedia.org/wiki/Comparison_of_document_markup_...
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.
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.
Within my network though, I would say that the rank-and-file usually stay fairly far away from LinkedIn posts whilst self proclaimed "thought leaders", "influencers", and "makers", devote time and attention to the dog and pony show that LinkedIn has become; or perhaps was always intended to be.
Classifying myself and rank-and-file, I only maintain a LinkedIn profile as an online resume. I do not post, do not read posts, and do not engage in their click-bait emails notifying me about how I'm missing N updates from people in my network.
In my opinion, LinkedIn is to the social network what the corporate retreat is to professional life. A highly manicured, to the point of artificial, version of our day-to-day existence.
As corporate drones attempt to portray themselves as the ideal Stepford Wife of the workplace, I hope that posts like the parent continues to be written to point out the bizzaro world that exists on LinkedIn so more of us are reminded to not take it seriously and perhaps checkout altogether.
A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of microservices. The team buys into the pitch and looks forwards to a happily-ever-after ending.
The reality though is that the team now has multiple problems, which include:
- Addressing conceptual debt that hasn't gone away. - Discovering and migrating what the legacy system got right, which is often not documented and not obvious. - Dealing with the overheads of microservices that were not advertised and not prominent at a proof-of-concept scale. - Ensuring business continuity while this piece of work goes on.
I would propose alternative is to fix your monolith first. If the team can't rewrite their ball of mud as a new monolith, then what are the chances of successfully rewriting and changing architecture?
Once there is a good, well functioning monolith, shift a subset of responsibility that can be delegated to a dedicated team - the key point is to respect Conway's law - and either create a microservice from it or build a new independent monolith service, which aligns more to service oriented architecture than microservices.
I believe a contributor to why choosing boring is hard is that often the problem we encounter in software is not new or unique, but may still the be first time a team/company is attempting it. Therefore, unless you know your company has the patience for unforeseen technical difficulties, and that your team has the skillset to overcome any fundamental challenges posed by the technology chosen, even if the technology is a better fit for a problem, it may not be a good match for the organisation.
Regardless of intent there are commercial realities that exist within the context of a company that may never be present in a non-work relationship. This has varying degrees of impact on the nature of the relationship itself and may not present itself until you are at your most vulnerable.
I find that a collegial environment with shared goals and responsibilities can be equally rewarding as non-work relationships even if we all have some level of underlying self-interest at heart. Our day-to-day interactions can also be made more pleasant if we are not constantly reminded of the at times competitive, zero-sum, structure of professional engagements.
At a team level your colleagues may be your friends but one shouldn't conflate professional relationships with personal ones.
I do agree with the general sentiment of the parent post though. Having managed IT (operations not development) when good work is done, often the intention is that no one notices. Therefore the broader organisation may not have sufficient awareness that anything of value has been achieved.
In such circumstances I believe it is up to the manager to both manage up in terms of making the team's achievement known and recognised, as well as represent the organisation and acknowledge the team's work.
A few of the posts above are essentially prescribing using STAR to offer feedback, which I think is more thoughtful than just generic words of affirmation. This can be made even more authentic if you take the time to talk to affected stakeholders and gather real testimonials to pass back to the team.
As a few of the comments on the article already notes, the article is more of an off-the-cuff opinion piece and not really a deep discussion on what is philosophy and why stoicism doesn't qualify.
One could say "Stoicism Is Not a Philosophy" is not a post on whether stoicism is a philosophy.