HN user
How does this compare to RST, which also claims to solve specific MD inconveniences?
In researching for this reply I see that it's joining a somewhat crowded field https://en.wikipedia.org/wiki/Comparison_of_document_markup_...
I made https://poemd.dev/ as an online markdown scratchpad that supports GitHub Flavoured Markdown and stores all data in the URL. This means there are no accounts to work with and everything is basically stored in bookmarks if you choose to.
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.
Having worked in ecommerce on both merchant and SaaS side I can explain why they may have and as a customer you will basically never see it applied.
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.
Pop is a very similar product.
Part of the problem is discoverability. As the library gets larger, without adequate time invested into docs or standardised naming to enable faster code-based search, people can end up writing their own functions when one already exist. Often these are not discovered unless PRs are reviewed by someone that either wrote or has experience with a reusable function.
I think the topic of having/not-having children should be treated like politics and religion in polite conversation, to be avoided.
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'm glad it's posted and thanks for being quite generous with the sample content of downloads and links that did not require an email to access.
I have bought a copy.
Since the description is pretty light. It seems Canon Rumors is a site dedicated to Canon related news in the same vein as MacRumors.
I think the idea is that it makes for more compliant, or less empowered, workers that will put up with more abuse.
I have similarly varied background and I have not had candidate employers put it through that lens.
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 have found Vimac [1] to be an okay alternative to mouse keys. Unfortunately I find that it's still slower than just grabbing the mouse. Performance can also vary depending on the number of clickable elements on the screen.
I kind of just rely on Vimium and Vim mode in editors/IDEs now.
Agreed. A company that would enable a work environment that fosters a mass exodus would be unlikely to feel accountable to any remaining employees.
Effectively, yes, this.
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.
For me The Silver Searcher (Ag) has replaced trying to memorise various grep flags. Its defaults produce largely what I'm looking for without needing any flags.
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.
I have to disagree with this.
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.
If you want a simple library that doesn't use vdom, have a look at RE:DOM https://redom.js.org/#introduction
The article covers the basics. Once you are ready to go beyond that, I would recommend exploring customisations, which are well covered by Awesome Tmux: https://github.com/rothgar/awesome-tmux
The other beginner tip I would give that's not in the original article is the command:
set mouse
Having been on the other side of this I do have a viewpoint to present you.
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.
The rule of thumb that I was taught for software delivery is to double it for every layer of management you have to deal with.
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.
Dare I say that given the choice of stretching the truth or admitting failure, startups will always choose stretching the truth. Often the truth is just seen as yet-to-be-realised potential. This is the nature of startups, which have limited runway and thus have to make the most out of their opportunities.
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.
Agreed. A new language will not solve garbage in, garbage out problems. A lot of times even when a BA tries to untangle the mess of business practices by carefully documenting it and proving that a better way exists, some stakeholders can still find it challenging adapting to a well intended change.
As far as satire goes, this is not very biting. Nevertheless, the point is appreciated as LinkedIn becomes a professional self-promotion channel for certain types of people to project their take on successful career milestones.
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.
This is why definition of done is quite important, to get everyone one the same page about what it means to complete a task.
A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team.
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.
Along the lines of an ADR, another useful document to have is Decisions and Opinions. Often choices are subjective, highlighting these will let contributors know about your preferences for the project. Often these relate more to linting styles, choice of libraries, etc.
I think that "boring" is being used here as shorthand for well known and predictable, which are attributes that I would rate highly when developing a platform or trying to work on a novel problem.
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.
HR is not your friend and your company is not your family.
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.
A few companies I have been in have recognised this PR mistake and have renamed themselves "People and Culture". However, do not be fooled, the purpose remains ensuring the organisation has the right type of people and a culture that aligns with the objectives of the company.
I think this is the main issue with generic "you guys are [something] it!" type of praise. There are no details at all, so it seems fake and superficial.
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.
I think that just because a philosophy is misused, or used as an excuse for anti-social behaviour, doesn't make it less of a philosophy.
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.