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

Why an exponentially increasing rate? A device like this doesn't use much storage, any logs it keeps can be rotated out after a certain duration, and the cost of storage goes down over time, not up. So storing the same amount of data 5 years from now will be less expensive, not more expensive, than today.

In addition, there are things called annuities, where the purchase price today can have enough set aside to be self-sustaining. Not saying they've done that in this case, but it's not outside the realm of possibility.


He's working on his "Switching from Caddy to nginx article" right now.


If you deliver the same value to the company in 6 hours as you do in 8, then you should get paid 100% of your salary. You (should) be paid to deliver "X" value.

Auto mechanics have this figured out -- we (developers) should be able to as well. They get paid a certain amount for a certain job (say, 3 hours for a brake job on a certain model of car). If they can do it faster/more efficiently, they still get paid the same amount even if they work fewer hours.


The problem with this idea is that programmers generally never do anything 'correctly', so if you go home early, you're leaving the job unfinished.

This is far less applicable to an auto mechanic who simply has to replace a part with another stock part and let a customer walk away with it the same day.


There is some truth in this. Programmers are generallynever finished. You can always refactor or polish it a bit or squeeze in another feature.

That said in agile you have a definition of done so at least you can agree as a team when the job is done and then it's like the car mechanic example


You probably should have spent some time fixing that hole in the firewall that let you bypass your company's download restrictions. ;-)


You would usually not try to block Tor at the network level. You would lock down your computers so employees can't make changes, and only allow them to run executables from locations which they have no write access to.


Tor can and should circumvent any firewall using obfuscation proxies that use AWS, GCS, Azure, etc. You'd need to block most of the internet to kill Tor.

And as for monitoring, I guess it might be possible, but if someone thinks to use bridge nodes that's also defeated.


Why would they charge the equivalent of transaction fees when they (Apple) pays those fees? How would they make any money if they only charged transaction fees?

I've run the numbers on products like this before. In order to absorb transaction fees, build your own product, and support it, fees need to be in the 10-15% range.

Also, note that almost no companies charge less if you pay out of app -- the company just keeps more for themselves.


> I've run the numbers on products like this before. In order to absorb transaction fees, build your own product, and support it, fees need to be in the 10-15% range.

Apple does charge 10-15% for Spotify like apps viz. apps that sell subscriptions for more than 1 year.

https://developer.apple.com/app-store/subscriptions/whats-ne...

   After a subscriber accumulates one year of paid service,    
   your revenue increases to 85% of the subscription price, 
   minus applicable taxes. All current subscriptions are 
   eligible.


That's a brand new rule, just going into effect.


So is Spotify's letter.


FYI, since 285 is a loop and 75 runs all the way through Atlanta, there are two 285/75 interchanges. While I think you're correct in your selection, here's the other one for completeness: https://www.google.com/maps/place/33°37'55.6%22N+84°24'02.8%....


This is of practical importance. There are two 285/85 interchanges as well and I broke down at one of them once, and the tow truck thought I was at the other one.


And you can tell that it's a loop because it has an even first number.

#: Main Highway ##: Main Highway [Even]##: Loop [Odd]##: Spur

One of the great things about the interstate system.


That's sort of true, but "loop" just means that both ends are at interstates. See for example I-675 south of Atlanta, which runs from I-285 to I-75 in roughly a straight line.


Two reactions to this article (and I say this as someone near 50):

1. Dan's obviously not cut out for startup life. When he meets Zack, he assumes Zack must be someone's assistant because he is young. Dan has no concept of the fact that someone might have their position because they are skilled and perform well. In his mind, the only way to have a fancy title is tenure and age.

2. Sure, the language of startups is interesting (graduation as a euphemism for quitting or getting fired), but the clear message is that this is odd, and thus, wrong. As though normal corporate America is the one true way and is just fine. Bullshit. Let's make sure to keep the workplace exactly as it's been for the last 100 years and never evolve.


But this is normal corporate America. Dan apparently isn't familiar with the history of IBM, which was so bonkers it had its own song book attempting to engineer a cult of personality around Thomas Watson.

http://arstechnica.com/business/2014/08/tripping-through-ibm...

This was back in the 1930s. Apparently not much has changed.

In the 60s and 70s the DEC people used to talk about "Mother DEC" and "Father Ken (Olsen - CEO)" - and DEC was a vastly more pleasant company to work for, if you didn't mind meetings where people shouted at each other a lot.

Elsewhere, this: https://www.youtube.com/watch?v=RINizGmhrYo

US corporate culture is insane. It has always been insane. The insanity takes different forms, and the web startup version frequently manages to be both insane and infantilising. (See also, startup names that sound like baby talk - more of a thing before DotCom 1, but there are still a few relics today.)

This is not what an adult professional culture looks like. Signifiers of playful childlike wonder and creativity shouldn't come in stick-on corporate office multipacks, especially not if they hide much uglier relationship dynamics in the office space.

It's fascinating to wonder why this has been such a strong trend in the startup space. Obviously it's more likely to appeal straight-from-college CS grads than battle-hardened senior engineers. But my guess is it's also an evolutionary adaptation to trigger paternal (less often maternal) feelings in investors and VCs, who are more likely to feel generously disposed and still part of youth culture if they sponsor a brogrammer creche, and less likely to feel threatened by kids who look nothing like direct competitors.

Social signalling in business is a very interesting thing, and maybe isn't questioned often enough.


Great point on this actually being part of corporate America. I had neglected/forgotten that point, when I'm pretty sure buzzword bingo predated the rise of startups (synergy, touch base, strategic alignment were all part of the lingo when I worked at larger companies).

I wasn't really commenting on the healthiness of the startup culture, just how out of touch and corporate Dan was (apparently so out of touch he doesn't even realize he's out of touch). But you make some really good points about this trend. I'll have to think about that some more.


On point 2:

A lot of this sounds extremely similar to corporate America. BS euphemisms, 1+1=3 (synergy, ya'll!), and a lot of hype about how you are helping the world when you are just doing a job to make money (and often employing skeezy/immoral tactics to accomplish those goals).

My take away from this article is that start-ups are not as "think different" as they like to pretend.


True, but the article implied at startups it was weird and wrong, when (as you correctly point out), it's actually part of corporate America as well. Which defeats his point that startup language is cultish and weird/wrong.


> it's actually part of corporate America as well. Which defeats his point that startup language is cultish and weird/wrong.

Those two points are not at end with each other.


HubSpot is not a startup.


That's a better reply to the OP, or perhaps directly to Dan Lyons. I didn't come up with the title of the book.


"the language of startups is interesting (graduation as a euphemism for quitting or getting fired), but the clear message is that this is odd, and thus, wrong"

What makes it 'wrong' is that 'graduation' is deceptive when employees are being fired or quitting because they hate the company.

Surely, some / many employees are leaving for positive reasons ('graduating' to something bigger / better) but if Lyons is right that that was the general term used for people who left the company, it is not only odd but Orwellian.


As others have pointed out, that's not unique to startup culture and completely demolishes Dan's point. Corporate America gave us "downsized, right sized, offboarding, redundant, outsourcing, reduction in force)". It might not be right, but it's not the fault of startups.


How is it superior? Simple.

How do I systematically make sure that I have the latest version of every stackoverflow code snippet? If it's a new post, it may not have all the edge cases fixed yet. So now I have to check back on each of the X number of snippets I've copied.

In the npm approach, I can easily tell if there's a new version. For prod, I can lock to a specific version, but in my test environment, I can use ^ to get newer versions and test those before I put them in production.

If the edge case of new version of a package breaks my code, I've learned that I'm missing a unit test. Plus, the question isn't whether this bad thing might happen on occasion, the question is whether this approach is, on balance, superior to cutting and pasting random code snippets into my code. I think the downside of the npm approach is less than the downside of the copypasting from stackoverflow approach.

And every moderately useful npm package I've looked at has very good to great documenation.


Yeah, there are a few shitty examples on npm. It's an open system and anyone can upload anything. The market speaks on how valuable those are. Cherry picking poor modules says nothing about the rest.

Plus, if you think that's too small, write your own broader module that does a bunch of stuff. If people find it valuable, they'll use it. If they find it more valuable than a bunch of smaller modules, you'll get 10,000 downloads and they'll get 10.

The module you roundly ridicule has had 86 downloads in the last month, 53 of which were today (at the time of this writing). I imagine most of those 53 were after you posted. So that's 40 downloads in a month, as compared to the express framework which has had 5,653,990 downloads in the last month.

The wailing and gnashing of teeth over this module is ridiculous.


If I engage in as much hyperbole as the author, where does "write it yourself" stop? If I'm working on a team of two, should we each write our own left-pad? How about a team of three? Four? Five? Fifty? At a certain point, it makes sense for that to be written once for the project. We spent 30 years in software engineering trying to figure out how to get code re-use, and now that's it common and widespread, we want to go back to NIH?


I think about this every time I write a UTF-8 decoder. It's a task which is simple enough that I can bang it out from scratch about as fast as I can find a library that does it, so I can't really stomach adding a full-blown dependency to deal with it - but it's also just complex enough that I have to think about it, write some tests to make sure I didn't forget something, and wonder whether this implementation is any different from the last one I wrote.


I have 'tools' repository on my local gitolite server just for that. Saved a lot of time already.


I pretty much came to the comments to post something similar. I'm sure there was a long comment thread here on HN discussing the perils of NIH this week. This seems like the end point of the alternative.


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

Search: