Hacker News Reader

Comment by belkarx | Hacker News Reader

... https://gist.github.com/belkarx/299b6d83a85beee2c2559c1b42f9...

I will admit that I'm using almost exclusively external tools and had I wrangled the X library myself, this would have taken longer. And while it's technically a working product, it's not exactly polished. But it proves my point. Not a difficult project

View on HN

Great, I bet you hacked that script in 5 minutes or less, which I don't dispute.

However, you cannot claim that you learned bash scripting within those 5 minutes. Or that you knew in seconds that these were the libraries to use for that little but valuable script.

All costs considered, time to learn what to do is included. So, it was far more than 5 minutes, though your execution was less than that.

This topic is part of: https://en.wikipedia.org/wiki/Systems_development_life_cycle.

Next time anyone asks me for a time estimate on building something, I'm going to hit them with "well its been about 15 years since I started tinkering, so let's start there"

I bill my customers based on value delivered, not on my time exposed to a topic[0].

It could happen that my 15-year tinkering effects in great value delivered.

My point is that time devoted to learning something is not free; you must consider it a business cost.

Regardless of time exposed to the topic at hand, not necessarily a lot of time invested* into something results in a great deal of value to be delivered. You could optimize that time with ultra-learning techniques[1].

The correlation of time exposed to a topic doesn't result in the causation of how much should I charge a customer.

[0]: https://www.ivanmontilla.com/blog/does-professional-experien...

[1]: https://www.scotthyoung.com/blog/ultralearning/

EDIT: * Improved clarity by adding a word.

I don't think time to learn bash or programming intuition can reasonably be included in the timeframe to build a product. It's assumed that time starts after you come up with the idea to do something, and retroactively saying "this project took me a year" for something you created in a few hours is ... odd.

I agree that the time spent to find the libraries and their documentation should be factored in, so I'd like to note that that part of the process took ... 3 ddg searches (so +a few mins).

?where does parcellite store clipboard data -> https://www.mankier.com/1/parcellite -> `clipboard -c`

?regex for url -> https://gist.github.com/securibee/f15f8c7aaa0593cc32fc30f585...

?get notified when something has been copied to clipboard linux -> https://askubuntu.com/questions/1167026/detect-clipboard-cop... -> https://github.com/cdown/clipnotify -> `while clipnotify;do`

I think we are caught in semantics for this discussion because you are talking about "direct costs" (X causes Y), but I'm defending the idea of "indirect costs" (X doesn't cause Y, but you had it lying around, so you used it).

Using your previous knowledge inventory is not a direct cost of resource usage, but you'd not have been able to craft that script if you had not known about the tools.

The way I understood [1] is that even a trivial app (such as a clipboard URL logger) will take longer than 2 hours once you start adding the polish. I don't think that can be refuted by writing a 5-minute non-polished version of the app.

[1] https://austinhenley.com/blog/thisprojectwillonlytake.html

Reply on news.ycombinator.com