You might still be getting products from the same inventory pool in an Amazon warehouse when ordering directly if the company uses Amazon's Multi-Channel Fulfillment offering. They sell on their site, tell Amazon about the sale, then Amazon ships it to the customer. They even offer the option to ship it in unbranded boxes so that customers don't know the order is being fulfilled by Amazon.
Ew, gross. I’m pretty sure the couple companies I order from regularly that also have an Amazon presence don’t do that, since they have direct-order products not listed on Amazon and often include little touches like a bonus sample or handwritten note that you don’t get if you order their stuff on Amazon, but good to know to watch out for that.
If you create a financial incentive for a behavior, you're telling your employees you want to see that behavior. If it was a problem and KPIs work, they should have changed them to make them align more with the business needs.
> If you create a financial incentive for a behavior, you're telling your employees you want to see that behavior.
And it's not just individual people modifying their behavior to game things, but more of an evolutionary process that the people who tend towards gaming things will get better bonuses, better reviews, better CVs, hence better next jobs, in perpetuity.
"Don't game it" can't be a simple solution. If there are people who game things, and they accumulate rewards for it, you will just see them out compete the nongamers. You are basically telling people to sacrifice their and their family's financial position for the sake of the corporation.
Everything can and will be gamed. But at the same time if many game it, managers will really want to see evidence of nongaming, so employees are also incentivized to signal their honesty, but this must be given some kind of channel too. If managers myopically focus on gameable metrics, then their loss. You must alwas leave a door open for receiving honesty signals through some kinds of side channels. These must always be somewhat amorphous because the moment you define them, they become gameable.
In other words, no recipe, stay alert, try to cooperate but don't be a pushover, etc.
>If you create a financial incentive for a behavior, you're telling your employees you want to see that behavior.
What a cop-out. Everyone should want the company to succeed. So why not say "Hey, boss, this KPI won't work, here's what might happen..." instead of literally working less than needed to prove some point? It's dishonest.
The company has no interest in my success, why should I care if the company succeeds? It has no effect on me if it does.
"That's my only real motivation is not to be hassled, that and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired"
Keep in mind, the context of this discussion is that someone who works really hard and completes 90% of their KPIs ahead of schedule will now be financially penalized by the CEO for reporting any additional progress.
If you want employees to prioritize the companies success over a metric, you should make yours and their interests align. Employees may fear pushing back against bad metrics because it might make them look bad saying they can't meet them or that they think they know better than their boss.
You could turn this around and ask why iterations after iterations the company didn't understand that the KPIs were not ideal and employees not happy with it ?
Put yourself in the same boat: if you had a team to manage, with the freedom to give them incentives, and they didn't have the effect you expected, you should be able to notice it and try something else.
That's great if the team is helpful and tells you exactly what's wrong, but you should also be able to evaluate how it's going and react accordingly, otherwise you're just asleep at the wheel.
I feel like that's where most people probably start, and then get some response like "we can't change the KPI's because blah blah" or get the runaround. Once you have established that you have no agency to change the system is when you are sort of incentivized to let it fail in hopes that a better system replaces it one day. You also don't wanna piss too many people off that may be invested in the current system because you want those references for your next job.
When corporations have a duty to their employees and not to the shareholders, then that is when the employees will start to care about the company. As it is, you are asking for a one-way-street. Companies will hire and lay people off as economic tides turn, but then you say that the workers owe loyalty? I don't think so.
I didn't get diagnosed with sensory processing disorder, but I did get diagnosed with Autism at a young age and have sensory issues. For example, I was a very picky eater, didn't like wearing socks or shoes, clothes with tags or graphics on them were very irritating for me to feel. My parents didn't really limit my screen time. They had given up on trying to make me eat different foods. I mostly just ate chicken nuggets and frozen pizzas. I didn't go to any sort of special school, I just went through an average public school. I can give some advice from that perspective.
I didn't really start expanding my diet until my 20s. It's hard to describe the sensory issues to others but how I would describe it is that even though I know something is food, my brain has trouble processing it and I'll end up having a gag reflex to trying many foods. What I'd suggest and what I ended up doing to expand my diet is finding safe foods, and then trying to find ways to add new foods to it, slowly expanding what is considered a safe food. For example, I ate pepperoni pizza and to help myself expand, I started adding different toppings to parts of the pizza, that way I could try something new but still have plenty of a safe food to eat if I end up being unable to get it down with the new food.
Small incremental exposure to the things that trigger negative reactions can help reduce those reactions and get them more use to it. I did the same for social situations, pushing myself to do things I'm uncomfortable with, like taking a speech class in community college, trying out to be in a play, and joining school clubs about topics I'm interested in.
In addition to this, don't be too hard on yourself about the situation. There is only so much you can do and a lot of it is out of your control. Even though my parents weren't too involved, I was lucky and turned out alright. All that extra screen time lead to me going into software engineering. I've been able to work my way up to being an engineering manager.
When not in deploy, you'd be stuck with a non distributed SQLite database for each instance your application is hosted on. There currently isn't a way to swap the backend for the deno kv API, so you would still need to update your code to use the new kv store that would have a different API.
If you use redis instead, you'd be able to easily be able to switch providers by changing configuration options instead of having to update your code wherever it is used.
Where is the wait only 30 minutes? Every time I've been to the emergency room the wait has been 6+ hours. I think the only way it would be that fast at the hospitals I've been to is if you'd die waiting longer, otherwise it's a long wait.
Everywhere and nowhere it can be 30 minutes. Every competent ER on the planet triages patients. Come in with crushing chest pains and it should be 30 minutes everywhere 99% of the time. Broken arm? You might wait hours if people keep coming in with crushing chest pains.
"Wait" can be defined very differently. Wait time to get triaged by a nurse? An ECG for chest pains? Initial physician assessment? Entry-to-exit? Lab results? Time to X-Ray if needed?
Lots of directives may be in place too. In an efficient system, the nurse is empowered to "order" many procedures that screen out serious things that require immediate physician intervention. Or just to save time like ordering an X-Ray first instead of waiting to see a doctor to order it and then waiting again for it to come back to review.
I've waited less than an hour in New Jersey and Connecticut.
When I still lived in NYC, I resolved that if I needed a hospital but I wasn't in extremely bad shape, I would drive an hour into an adjacent state's ER rather than wait in NYC.
Post COVID hospital in Ohio, limped in with severe ankle sprain, got doctor in less than 15 minutes and out within an hour with splint and crutches. Even got X-Ray.
What city? Most of us in this thread live in larger cities. When I lived in LA and had to go to the ER, the wait was 5 hours and they literally rolled a cart over and made me prepay my insurance deductible (several hundred dollars) before a doctor even saw me. Helped a friend get to the ER in Phoenix and it was about 3 hours.
Currently they just say they have them. A more common one is pretending to be the police. They tell the family member that they have to pay bond for their child/grandchild to be released.
My mom almost got tricked by a police scammer saying they have an arrest warrant for her due to not paying a debt and that she would be arrested if she didn't pay the money. Only reason it didn't work was because she didn't have the money and called me crying asking for help. Now she knows to never trust anyone requesting or demanding money over the phone.
In addition to this, the bundle files generated at runtime are stored in memory in a Map. If you have a server and want to have multiple processes for handling requests, each of those processes will have a copy of the build artifacts in memory. Any requests that get routed to newly started processes will have their response delayed by however long it takes to generate the bundle. So users would experience seemingly random delayed load times due to runtime bundling.
I think it would be better to do bundling in your CI/CD. esbuild supports incremental builds, so using that + code splitting would be one way of speeding up builds.
With their current bundling design, if they believe bundling is fast enough for users to not be negatively impacted, wouldn't it also be fast enough to not slow down development/deployment by having it in a build step?
Fresh is using esbuild to build the bundles at runtime instead of pre-deployment. So it rebuilds the bundles everytime a new process starts up and keeps copies of those files in memory for each process.
They are not using their own bundler. They are using esbuild at runtime to generate bundles for individual islands when the process starts up. Then they store those files in memory in a Map. When the bundle files are requested, it just pulls the copy that was generated at runtime.
Here is a link to the source where esbuild is used.
I personally think it would be better to bundle at deployment time so that the bundles don't need to be regenerated each time a new process starts up or on demand when a request comes in for one of the bundle files.
It's like you combined the warmup phase of the JVM with the compilation phase, except you still have to wait for the JIT, too. I better not hear anyone complain about JVM warmup times again. :p
Man the things that pass for innovation in the node-adjacent space continues to blow my mind. It feels like hte horrors of /r/programmerhumor meets generic internet hype-beast cycles.
Conceptually, I don't see how this is much different from JIT compilers in the JVM, CLR, and similar runtimes. You don't hear so much from Java devs about how they can't* see the machine code their customers are running. They talk about cold-start performance, but accept that the first few requests will be slower in exchange for the productivity and eventually-high-performance.
Now that I think about it, this is how V8 works too, for JS code itself!
JITs exist because 1. certain compilation can't be done at compile time, because the code is dynamically synthesized at runtime from data only available at runtime; and 2. knowing how the code is already being used at runtime through an interpreter, can help optimize the compiled code ("profile-guided JIT.")
Bundling on first request has neither of these advantages: everything that is getting compiled at runtime could have been compiled at compile-time; and no information is yet available on how the code will be used.
The difference is that the JIT doesn't "fail". Builds and bundling can fail, and I wouldn't want to trust that all the machinery the builder/bundler depends on (especially if it needs to fetch things over the internet) are available and working properly.
Put another way, as long as the `java` command is present and working on the production machine, I can be pretty sure my service is going to run and work (aside from any bugs in my code, of course). With Deno, more moving parts on the production machine need to be working properly in order to ensure things work properly.
JIT compilers at least do the work incrementally, profile the code to provide the best (or several) versions of native code, etc. That is, they adapt to the particular invocation, doing stuff an AOT compiler cannot do (especially for dynamic languages like JS).
I wonder if running the bundler on startup, and throwing away the (identical) result of a previous invocation of the bundler, makes much sense. It at least could persist it optionally, like Python does with .pyc files.
What kind of innovation would you prefer?
(removed snark)
Web code is made of duct-tape, nothing new.
Deno is a pretty big departure from Node in some respects as far as I can see.
I admit I haven't used it, but if it keeps only half of its promises to simplify frontend bundling and compilation/transpilation, I think it's innovative.
Because a good craftsman picked his tools and knows it’s his fault if they’re garbage.
This pattern of “thinking” pisses me right off. It’s an axiom about quality and avoiding deflection and it’s always used in a low-quality reply as a form of deflection.
I can’t recall the last time I heard someone use that phrase the way it’s meant to be used.
Builders and bundlers fail sometimes. I don't want to introduce an extra point of failure in my production services.
Maybe this is nice for local development. But really it just feels like the tooling version of a "code smell". If people think bundling/building is too slow, then people should work on making that faster. Maybe that means people need to stop writing JS builders/bundlers in JS, and use a language like Rust that has better performance characteristics. I wouldn't consider that a failure; it's just an admission that we should use the right tool for each job.
Speaking of Rust, the Rust compiler is fairly slow, but my proposed solution wouldn't be "get rid of it and have it dynamically compile at runtime", it's "profile it and make it faster" (which people are doing!).
Eh... I don't really think this is a killer feature.
If you don't want to maintain a build step, use a framework that's configured it for you and avoid customizing it.
Lots of frameworks already do that, this is just Deno's implementation of the same thing.
There's STILL a build step, they're running esbuild in the background for you. You've just lost visibility and control, exactly the same as if you picked a framework that gives you a default webpack config.
If anything, I see esbuild as the real "killer feature" here, since it's just really fast. Fast enough to bundle at request time.
Alternately, you can just stick close to standards and not really worry about it.
I write plain CSS.
I use Web Components as my unit of isolation, generally sticking with the light dom.
I have a small state utility [1] that I wrote years ago and works great.
I do have a build step before deployment, but I use vite during development so I have zero "make a change, wait, test, rinse, repeat" downtime. When it's time to deploy, vite build does the trick nicely.
I don't use frameworks. I don't use JSX. I don't use typescript, for types I use jsdoc in vscode which gives me 90% of the benefits of TS without the downsides.
My pages are light, fast and easy to maintain. I don't have to deal with painful build steps, or framework churn.
Debugging is simple. No multiple layers of transforms and sourcemaps, WYSIWYG.
I'm pretty passionate about the "keep it simple" philosophy.
I chose to innovate in the problem domain, not the technical one.
Anecdotally, I had a new developer join my team and he was initially very confused. He said "it's just so strange using this tech stack. You make a change, and you see it..."
My comment was more about the saying of the parents comment then specific to deno.
What I mean is that a good craftsmen doesn't complain about bad tool because they choose to use good tools (or more precise appropriate tools for the job) not because they ad-hoc easily negate any drawbacks of bad tools(1). And if they use bad tools anyway they do so intentionally or because there is not other choice and in turn don't complain because it's pointless to do so.
So the saying in the op comment is IMHO misleading at best deceptive at worst. Furthermore it doesn't advance any discussion, only side track it.
I'm sure the deno specific workflow from the article is a grate tool for a lot of use-case. I'm also sure there are use cases where it will fall apart.
(1): Depending on what you do creating a decent result without good tools might literally be impossible no matter how good your skill is. Or it might not make too much of a difference and can be compensated by skill, it's all context dependent, like most things in live.
