Hacker Newsnew | past | comments | ask | show | jobs | submit | devilshaircut's commentslogin

It should be obvious but, limitations, whether they be related to time, budget, or other resources, make stock assets desirable.

For instance, commissioning a custom icon set rather than picking one off-the-shelf is a luxury only some projects will have access to.

Additionally, oftentimes stock assets function as good placeholders until a larger budget comes into play. Suppose you are working on a video game and waiting for environmental assets to be complete; in the meantime, a sample texture may do.

In a perfect world, perhaps every font, icon, illustration, photo, or texture would be bespoke to its exact application. In the mean time, we have stock assets.


If "hyper-rational atheism" were the "Times New Roman of metaphysics", you'd think it would be far more common than it actually is.

Going with your n=1 "I meet people like this all the time." theme, I know far more people of various religious flavors than I do atheists of any kind, "hyper-rational" or not.


I definitely agree that there is a perfect world where designs are fully researched with a battery of user tests and for large companies like Facebook, Atlassian, and Lyft this is critical to their success. Every design decision, large and small, matters when you have an audience of billions of people. Furthermore, there is no excuse not to conduct research when you have the resources to dedicate to doing design right.

That said, if you are a scrappy startup (or in the case of an article, a single founder who may not even be a designer to begin with), it is often necessary to simply do whatever it takes to deliver a product. Money, time, experience, infrastructure, personnel, etc., are all limiting factors.

If I were consulting on a project for a Fortune 500 I would tell them to leverage their resources to maximize their change of success. If I were consulting on a project for a small business or startup I would tell them to be smart and triage key pieces that represent their "special sauce" above features that feel more like known territory.


This is (partially) why the major platforms have published their design decisions, and why we have open source libraries to leverage.

I agree generally, scrappy businesses should prioritize shipping (and validation, market fit, etc.) above almost all else at the start. But even if you're leveraging existing patterns and design elements, there's really no reason /not/ to spend a fraction of a fraction of your time to understand the differences between a checkbox and a radio button; especially when such fundamentals are already laid out for you online and your team can easily leverage them both in design comps and code.

Quality design doesn't require infinite budgets or unlimited time for research. A little effort to understand the work goes a long way!

It's the same thing with programming: copy+pasting something from SO might get you 75+% of the way to success, but relying solely on that approach without understanding the code also means you'll inevitably run into issues with things like memory management, technical debt by locking into approaches, etc. in your product sooner than later.

(fwiw I've also started several businesses myself, created my own products independently, and consulted with many startups; I haven't solely functioned in the deep pockets of silicon valley, if that's what my original comment came across as.)


> In October, The Information reported that Bird was spending $551 per scooter with a goal of reducing that cost to $360.

The full article is gated, but I'd be interested to know where that figure came from. It is possible for a private individual to buy the same scooter tax and import duty free for the lower of those two prices. I would hope that multimillion dollar companies like Lime and Bird would be able to secure better pricing than that.


Agree. Maybe it is more helpful to think of numbers as adjectives than nouns. Oneness plus twoness equals threeness. The part of speech is sort of irrelevant but it obviates a debate over whether or not instantiation of the unattached idea of a number is important, while still allowing math to occur.


This also surprises me. If for no other reason than I would imagine that authors who are not guilty of plagiarism are interested to some degree in verifying that their original works do not contain anything that could look like plagiarism.


The "How Knowledge Work Happens" graphic is really what resonates with me. I run a dev shop and I hate time tracking for the complexity implied in this image. Questions come to mind.

What counts for time tracking and what doesn't? If I spend an hour emailing back and forth with a stakeholder, none of this is reflected in my GitHub activity. So there is a delta between what is billable time and the actual deliverable.

What if I spend an hour researching a solution for a feature? Or debugging my environment? Again, that implies delta between billable time and the deliverable.

What about my level of expertise? I might be a junior or senior level developer; I might have certain specialized knowledge in an area of programming (or lack it). Again, more delta that tracks closely to the specific logistics of a small feature and less with overall "time".

Suppose I had a machine that strictly tracked the amount of time I spent "doing something project-related" (whatever the specific rubric). At the end of the day, I now have a number. What does this number actually tell me? I am not sure it is that useful and it definitely depends on however the rubric was defined (which would be inherently arbitrary anyway).

To me, it makes sense to just allot hours to devs and trust that they are doing their jobs. When people stop doing their job, peers notice anyway, hour tracking or not.


I don't entirely understand why some people find CSS so difficult to work with. I agree that it has its own challenges, but solutions generally aren't very complex. Global selectors ("variables") collisions? Use namespacing. Specificity is convoluted? Simplify by using only non-nested classes.

Does the annoyance primarily center around the fact that styles cascade to child elements? Hard to tell from the article.


Good software is reusable. I can import functions from 1,000,000 different npm modules all into my project and they don't fuck with each other, right?

Let's say you wanted to pull in a button from Bootstrap for one part of your page, a button from Material UI elsewhere, a button from Semantic UI elsewhere, etc.

These things are made to be reusable right?

What are the chances you can do that without issues? Do you think any of their style rules/selectors would clobber each other? What about the base/assumed CSS that they all most likely require? What about components more complicated than a button? Without actually trying it, how much confidence do you have in your guess, vs. your assumptions about importing other things (like functions from npm modules)?

Good software is reusable without worry.


> Good software is reusable. I can import functions from 1,000,000 different npm modules all into my project and they don't fuck with each other, right?

I just spent the whole day trying to fix compatibility issues between different versions of npm libraries transitively imported in a project. Reusability in JS is a joke.


Agree.

As a primarily JS/React developer, I think there is irony if JS is held as a good design pattern in comparison to CSS with respect to reusability. Inasmuch as what are being called CSS "workarounds" are in fact workarounds, so too has been the case with JavaScript itself. I am old enough to remember jQuery and Prototype colliding over the dollarsign namespace.

Don't get me wrong. I am not a JS (or CSS) hater. I think these "workarounds" are more than adequate in making these technologies easy to work with. Which I suppose is sort of my point. I see a lot of overengineered codebases with Byzantine solutions to relatively simple problems.

Also, to parent poster:

> Let's say you wanted to pull in a button from Bootstrap for one part of your page, a button from Material UI elsewhere, a button from Semantic UI elsewhere, etc.

1) First of all, don't do this. Perhaps you were just saying this to make a point, but obviously don't include 3 monolothic libs with overlapping functionality in order to implement 3 things with the same functionality.

2) It sounds like your problem with this is more with the libraries themselves. When I write a component, I always namespace it myself. Obviously, if libraries are properly namespaced, then you could easily include buttons from three separate button libraries.


What dependency system anywhere on earth is free of the problem of "two things require different versions of the same library"? I don't see the relation to JS at all.

I've had this problem with JavaScript-before-npm-existed, Python, apt, Homebrew, Portage...


stack for haskell

nix package manager


Note that npm also supports having multiple versions of the same package installed just fine.

The problem:

I use X to create an object with library A v1.0.

I use Y to create an object with library A v2.0.

These objects are not necessarily compatible, so X and Y have problems communicating.

I would be very surprised if you told me nix or stack inherently make objects from multiple versions of the same library magically compatible with each other.

Feel free to close issues like this one if I'm wrong: https://github.com/NixOS/nixpkgs/issues/30551


Hmm I think this should go something like this:

How would objects created from X and Y can reach each other and communicate when X is not dependent from Y or otherwise? You need global mutable state or your own code witch depends from both X and Y is somehow connecting them.

So one top thing FP movement argues against is global mutable state so of course you don't have that ...Unless you are wrapping some non-FP thing like QT...

And if it's your own code it shouldn't be different that Y creates B:s instead of A v2 since your code is aware from two different versions anyway.

Do you see any weak points?


In your own citation:

"Rewards kill creativity. Some twenty studies have shown that people do inferior work when they are expecting to get a reward for doing it, as compared with people doing the same task without any expectation of a reward. That effect is most pronounced when creativity is involved in the task."

Would this not suggest that people do their best work when they aren't doing it for the paycheck? In other words, given UBI, anything an individual may do would be his or her own prerogative and therefore represent higher quality output.


Artists represent 1.4% of the workforce in America. Lots of people (the ones who need support) don't do jobs requiring creativity.


>given UBI, anything an individual may do would be his or her own prerogative and therefore represent higher quality output.

But having fun making art means little to an economy.

Having less fun designing a robot to pick potatoes will transform an economy.

Creativity is nice, but it doesn't directly correlate with additional value.


I guess I'm kind of confused- additional value to what exactly? The GDP in America is massive but I don't know what are the returns of a growing GDP to my experience as a human, to my family, to my friends, to my quality of life. Will I pass by less homeless people on the way to work if I work harder? Will there be less hungry children in my schools if I make the economy grow, and by how much? What "additional value" is actually occuring?

(EDIT: This is a genuine question; I'm not highly educated on economics and I'd like to know the approximate models that currently exist on how much growing the economy helps numbers like homeless population, healthcare coverage, lifespan, birth survival, food security...)


I wasn't really referring to economic value, nor was the quote or the cited article itself.

The proposition was that people will do the least work for the most reward where possible.

The cited article suggested that rewards result in poor quality work.


I am in my mid thirties and would say I definitely do not think I am as sharp now as I was as a teenager.

That said, I am overall much happier now.

For me, mental agility has proven less important to me than a number of things. Example: I have been hit by motorists a few times (I am a cyclist.) and my left knee has really taken a beating as a result. Keeping it in good shape so that I can continue to run and bike is much more important to me than, for example, being able to quickly memorize or learn something. As I see it, mere speed at assimilating information is a luxury whereas physical mobility is a necessity for having a life worth living.

Conversely, certain things have gotten better with age: my financial wellbeing and emotional maturity both come to mind.

Although I try not to worry about the inevitable and live in the now, I am personally more concerned about the point in my life where my body will entirely preclude certain activities.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: