Hackers on happiness & tiny houses, plus The Story of Stuff - <AUTHOR> http://faircompanies.com/blogs/view/hackers-on-happiness-tiny-houses-plus-story-stuff/ <comment><USER2> The problem with tiny houses would seem to be resale value. I personally don't want a large house necessarily, but I want a really nice one. I want top of the line counters, ceramic floors, top-notch appliances, etc. It's not so much that I want more stuff, in fact I probably want less. It's more than I want nicer stuff. I think that's not uncommon. (It's also why if I had an infinite bankroll, my next startup would make a luxury version of the Corolla, but I digress.)

The problem is that if I put all that stuff into some tiny house, I'm stuck with it pretty much forever. Nobody else who can afford that stuff wants a 65 square ft house, or at least so few that I have no hope of getting a fair market value. It seems unlikely that will change, especially since by the time you can sanely afford these things you're probably near having a family.

One extremely way in which people value homes is $/sq.ft. Compare a 65 sq ft home to a 4,000 sq ft one, both with top of the line everything, and you're probably left with a market value about equal to what your dishwasher cost.

If I buy a 4,000 sq ft home and load it up I'll be able to sell it 10 years from now. Barring the very rare bubble bursting (like we're experiencing now) I'll probably be able to sell it for more than I paid for it. If I buy a 65 sq ft home and load it up, I'll be out a bundle.

So if money is not a constraint and you just want a smaller home, I think you have to find the happy median. Get a fully loaded 1,500 sq ft house and hell, just leave half of the rooms empty. There's certainly some size below which you're hemorrhaging money on the deal, and I imagine it's at least 1,500 sq ft here in Middle America.

If you have so much money that you don't care about resale value and you do care quite a bit about the environment this is probably fine. If you want laminate counters, vinyl floors, and cheap appliances, this solution might also be fine too. But for a large segment of the market this is unfortunately financially untenable, no matter how appealing.

<comment><USER3> Exactly.

I'm the "programmer in Michigan" (actually Minnesota) she mentioned in the article. I live in a 3,000+ sq ft house. We moved from an 1,800 sq ft house that we only used half of, so we obviously didn't need all that space. So why is my house so frickin' large? We needed at least 10 acres of land with less than a 50-minute commute to work and wasn't 100 years old (Minnesota's climate is very harsh on houses). _Every_ place on the market that met the basic requirements we set was close to, or more than 3,000 sq. ft. Many were much larger. Around here builders simply don't build small houses on large lots and I suspect they won't anywhere else in the US for much the same reasons you give.

Personally if I could sell my house tomorrow and buy a 1,200 sq. ft. home on 20-30 acres I'd be thrilled to death.

<comment><USER4> I too had to buy a comparatively giant house to get a parcel of land the size I was looking for within sane commuting-time of my job. We were living in a house almost half the size, but have figured out ways to take advantage of the extra space, but clearly could live without it.

I think a big driver of this phenomenon is <http://en.wikipedia.org/wiki/Highest_and_best_use>

</comment></comment></comment><comment><USER5> It's highly recommended that we all watch every single documentry by Adam Curtis, including "The Centuary of Self". His stuff is gold IMO, opinionated, but gold.

If you want a taster check out the latest series running on his blog about the history of Afghanistan:

[http://www.bbc.co.uk/blogs/adamcurtis/2009/09/kabul_city_num...](http://www.bbc.co.uk/blogs/adamcurtis/2009/09/kabul_city_number_one.html)

<comment><USER6> "The Century of the Self" in 4 parts.

<http://www.archive.org/details/AdaCurtisCenturyoftheSelf_0>

[http://www.archive.org/details/AdamCurtisCenturyoftheSelfPar...](http://www.archive.org/details/AdamCurtisCenturyoftheSelfPart2of4)

[http://www.archive.org/details/AdamCurtisCenturyoftheSelfPar...](http://www.archive.org/details/AdamCurtisCenturyoftheSelfPart3of4)

[http://www.archive.org/details/AdamCurtisCenturyoftheSelfPar...](http://www.archive.org/details/AdamCurtisCenturyoftheSelfPart4of4_0)

<comment><USER7> Also, you can find the same documents on Google Video. I share the search "google video the century on the self" on Google. <http://tinyurl.com/yb7kluz>

The Google Video link: <http://tinyurl.com/yd5ptt6>

<comment><USER8> down modded for the short urls. Please use the full urls here. HN shortens them automatically.

<comment><USER7> Sorry about that. Links (search and google video) were, as anyone knows, long.

</comment></comment></comment></comment></comment><comment><USER9> I started reading the PDF, and I found several errors on just the first couple of pages. I also found information that was sourced to warresisters.org, greenpeace, commenweal.org, etc.

I'm not trying to be harsh -- I'm sure the video is of high quality -- but when you say things like "In 2003, humanity's Footprint exceeded the Earth's biological capacity by over 25 percent" or "In the past three decades, one- third of the planet's resources, its 'natural wealth,' has been consumed" there is certainly room for debate about these things.

Debate which probably doesn't belong here.

Flagged.

<comment><USER10> Which PDF?

The URL I followed brought me to a interesting blog post with good but speculative discussion about the perspective of 'hackers' vs 'greenies' on mass consumption.

Did you really flag this link because somewhere within it there is a link to a PDF that includes unreliable sources? That's a pretty tough standard! :)

<comment><USER7> Reading all the comments, I came to the conclusion he probably refers to this coment: <http://news.ycombinator.com/item?id=940369>

It would be great if he can confirm so.

<comment><USER9> Yes.

I didn't have bandwidth for the video, so downloaded the PDF and scanned it as I had time.

If I missed the point of the article, doh! I was relying on the other comment.

<comment><USER10> The PDF is a transcript of a video that is linked from 15th paragraph of the article, but is just one of many linked videos. The actual article is a response from the author (approximately) of the recent HN post about the 100 square foot house.

The article itself is good, and you might enjoy it. I skipped the video, which is probably flawed in the ways you suggest. But maybe you could unflag the interesting link to the response in the meantime? :)

<comment><USER9> done

</comment></comment></comment></comment></comment></comment><comment><USER11> I highly recommend that you watch the film mentioned: "The Story of Stuff".

It is a very detailed look at how companies drive consumerism to keep the economy going at the expense of third world countries.

<comment><USER12> I started watching it, but then stopped when she started going through the "corporations are evil" bit.

She deliberately chose to paint government as good and corporations as bad even though they are both only composed of people, who are just looking out for their self-interest, trying to get money from other people, who are also just looking out for their self interest.

It's a intellectual shortcut to paint corporations OR government as evil, and not accurate or meaningful at all.

<comment><USER11> Actually in my experience she painted government as evil as well. She clearly points out how governments give corporations the power to do what they do.

In addition, I see no reason why painting government or corporations as evil is a bad thing because when it comes down to it, what they are doing to third world countries is evil.

We execute murderers for killing people. Yet corporations are killing people overseas by poisoning and maiming them in dangerous factories.

I see no reason why calling a corporation evil is not accurate or not meaningful.

<comment><USER13> I think the point the OP was making was that both corporations and governments are made up of people. I agree with this; a corporation and a government is not a physical entity, and can therefore not be evil. However, people can act evil in the name of that entity. Personally, I think that as soon as we try to brand a group of people, we lose the argument.

<comment><USER11> I personally think more as Steinbeck in "The Grapes of Wrath". The people in the organization are not evil, it is the organization itself which forces them to play certain roles to serve the group and the machine they have built.

Steinbeck portrayed the bank as a great machine in which each person working for it played a small role that they didn't necessarily like to play. Agents were forced to evict people from their land because they were not able to pay their mortgage, yet that was not something that they really wanted to do. It was something they had to do because of the corporation they were a part of.

No individual person in the corporation is evil (generally). However the corporation is bigger than each individual member.

So calling a corporation evil does not mean branding each individual person. Rather it means that you recognize that the corporation as a greater force causes evil things.

In that respect I don't see it as unrealistic to say then that the corporation can be evil.

</comment></comment></comment></comment></comment><comment><USER14> 1\. Sigmund Freud lectured in the US in 1909, when Bernays was a teenager.

2\. Planned obsolence: I see 40-year old cars and pickup trucks here and there. On the one hand, a lot of cars could be run longer before replacement. On the other hand, an older car is vastly less safe, without airbags or crumple zones, and the older car (ignoring manufacturing costs) pollutes more. And how many on HN work on old computers? America was settled during a period when technology rapidly advanced and obsolescence did not have to be planned.

<comment><USER15> I drive a 26 year old car and my home computer is a six year old Macintosh.

</comment></comment><comment><USER16> I intend to build my own.

<http://www.shelter-kit.com/kits.php?kit=barnhouse>

</comment><comment><USER17> I highly recommend everyone watch Penn and Teller's "Bullshit" series.</comment>


China aims for its own Silicon Valley - <AUTHOR> http://features.csmonitor.com/economyrebuild/2009/02/09/china-aims-for-its-own-silicon-valley/

<comment><USER2> China has already had its own Silicon Valley for many years in Beijing called Zhong Guan Cun (中关村) : <http://en.wikipedia.org/wiki/Zhongguancun> .

</comment><comment><USER2> btw, I am in Guangdong currently, I'm pretty sure it is nothing like Silicon Valley. There are lots of computer component factories here, but not really any web companies.</comment>


Things I've learned in 20 years of programming - <AUTHOR> https://daedtech.com/5-things-ive-learned-in-20-years-of-programming/ <comment><USER2> Some things I've learned after 35 years;

      1. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I would recommend formal training and practice.
      2. question all assumptions.
      3. there is no silver bullet (read mythical man month).
      4. fight complexity and over-engineering : get to your next MVP release.
      5. always have a releasable build (stop talking and start coding).
      6. code has little value in of itself; only rarely is a block of code reusable in other contexts.
      7. requirements are a type of code, they should be written very precicely.
      8. estimation is extrapolation (fortune telling) with unknown variables of an unknown function.
      9. release as frequently as possible, to actual users, so you can discover the actual requirements.
      10. coding is not a social activity.

<comment><USER3> This is unreadable on mobile.

<comment><USER4> I'm also having a hard time swiping the text. So ahead of the poster:

1\. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I would recommend formal training and practice.

2\. question all assumptions.

3\. there is no silver bullet (read mythical man month).

4\. fight complexity and over-engineering : get to your next MVP release.

5\. always have a releasable build (stop talking and start coding).

6\. code has little value in of itself; only rarely is a block of code reusable in other contexts.

7\. requirements are a type of code, they should be written very precicely.

8\. estimation is extrapolation (fortune telling) with unknown variables of an unknown function.

9\. release as frequently as possible, to actual users, so you can discover the actual requirements.

10\. coding is not a social activity.

</comment></comment></comment><comment><USER5> I've been programming professionally for 20 years too.. What I've learned is there's no end to the "architects", "mentors", "coaches", "team leaders" and "know it alls" who want to condescend and tell me how to do my job.

20 years of programming has taught me to avoid working with people who take themselves so seriously and think they've figured it all out. 20 years has taught me the importance of compromise, give-and-take, and following as much as leading. It's also taught me that there are people who've only been doing this for half as long that are 10 times better.

<comment><USER6> Don't forget the self-described "thought-leaders".

Oh you've been ~programming for ~3 years and you're now a thought leader - fantastic delusion.

</comment></comment><comment><USER2> This is not the best advice I've ever read, some of it smacks of "silver bullet" thinking. For example, it's sometimes better to duplicate than couple. Within the same component sure don't copy pasta. Also I think TDD is frankly ridiculous; I've seen many teams spending more money on gold-plating test lines of code than actual code. I've seen other, better teams spend all their efforts on full integration testing only. There are no golden rules, it's just hard work.

<comment><USER7> You're in good company with Jonathan Blow and, it appears, John Carmack. Teams pushing TDD might be a good smell test for whether they know how to efficiently code.

<comment><USER8> Until you mentioned him I had never heard of this Jonathan Blow character. The thing is both of these people seem to do game development. If you write code that is close to the hardware and needs every ounce of performance there might be a point to this. It would make applying TDD both harder to pull off and less beneficial.

When one is writing complex logic that is supposed to receive both frequent new features and keep working correctly there is nothing that beats TDD.

Let me attempt to compare this to bowling even though I know nothing about bowling. If you just occasionally like to go out bowling you can use whatever technique you like and you will get better if you just bowl a bit more often. If you want to play bowling on the national level you may at some point have to drop the technique that you made up yourself when you started out. You need to go through the uncomfortable stage of learning a new an better technique and temporarily be worse at it. I think the people not doing TDD are just refusing to go through this because there is not much of an objective standard of quality for developers. We are in a field where code that lacks any sort of quality is standard and where breaking features three times a week is standard. TDD will fix these things.

<comment><USER9> TDD works great when the requirements are known and there's little mystery. Waterfall methods oddly enough lends themselves well for TDD, which is kind of associated with hip styles like agile.

The reality is most projects start as exploration. What you're thinking might not even be possible. Can you even approximate the classes you'll need yet? For these scenarios TDD fits in awkwardly.

I prefer to do a little back and forth. A little dev. When things are looking stable, a little resting. Towards the end a lot of testing.

<comment><USER10> I've found the opposite. When I start to write a test, I often realize I don't know exactly what I need to do because the requirements are unclear or somehow conflict with some other assumption of the system. That realization prompts me to go talk to my product owner, which forces them to clarify their requirements and target a more coherent idea of what the system should be.

</comment></comment></comment></comment></comment><comment><USER11> I like TDD but it should be adapted to the project. For some projects, I only do integration tests, for others, I only write the unit tests for one or a few of the more complex modules and test the whole system manually then if needed I will add more tests later after the project code has settled.

It depends on a lot of things; such as what kind of complexity the project's modules are prone to (algorithmic complexity or integration complexity), team size, security requirements and reliability requirements.

It's very important to keep the testing as minimal as possible at the beginning. Sometimes minimal means a lot, but you need to be able to justify it because tests (especially unit tests) lock down interfaces and functionality and this can go against agile principles. If your project is innovative and requires that agility.

After 15 years experience coding on many different projects and companies, what I learned is that blanket statements are often unhelpful. You need to critically evaluate every case as unique and make arguments about why and how your case differs from the norm (and it usually does).

<comment><USER12> Agreed, I don't write a lot of tests until happy with the design. When that solidifies it's time to get cracking on the unit tests.

<comment><USER13> I have a variant on this. I start with a bullet-list of functionality I think I'll need. Then I write one test each for items that could impact my architectural choices. Once I finish that first pass I go back and flesh out each item with multiple tests as necessary.

Flushing out the architecture early is the trickiest part for me. Occasionally I miss a seemingly-simple feature that ends up requiring an architecture change. If this happens late in the process, I may pay for the oversight with hours of refactoring.

</comment></comment></comment><comment><USER14> From my ~15 years of experience, if there is just _one_ advice I could give to someone starting their career as a software developer: irrespective of whether your work is exciting or not as much, it is a joy in itself to keep working on improving your craft, which is writing software systems. Excellence is always a moving target, but if you stop working on your craft, the joy you will experience as you become senior and older, will keep decreasing.

<comment><USER15> This is my experience as well. At this point in my career, craft and quality is about the only thing that keeps me from ejecting.

</comment></comment><comment><USER16> One more advice for young programmers is - make the effort and learn the domain you are programming in. If you are writing finance software - use the opportunity and learn finance/accounting. If you writing retail software, learn about retail. If doing some network automation - learn about networking. I neglected this early on and picked up only enough needed to complete my programming tasks. Now regret this as could have ended up with more options across industries I worked in. Even maybe start your own business if you become expert in some domain.

</comment><comment><USER17> Started coding in 1987. Have no idea what I'm doing. Regularly panic about how little I must know. Can't figure out if people giving advice and writing books are genuinely a lot better than me, or just more confident.

<comment><USER18> Haha, same here (but I started -81-82). Love programming but get my kicks out of running code in production, not written code in a repo, so I'm always in a hurry to ship and usually don't have time to learn the new, shiny tech and practises. Which makes me feel out of date, ignorant, impostor:ish. But then I realise (or tell myself?) that I'm shipping working functionality way faster than most, and that I can't be so bad. I think.

</comment></comment><comment><USER19> The one point in this article that I will challenge relates to duplication of logic. The moment you've come across two similar scenarios that on the surface may benefit by a refactor and consolidation of logic, don't just instinctively jump to it. Refactoring to a universal model can take a great deal of time and effort. Days, if not weeks, may pass before your universal design is ready. Consider the cost of time and effort. Others are waiting for this work to be finished. Time is not on your side. Make sure you have a damn good business justification for consolidating designs and fight your biases.

I am advocating for knowing the costs and benefits of your refactoring decisions. If you can't predict what the costs are, take that as an indicator that maybe you should avoid refactoring, just yet. Consider as a litmus test discussing costs and benefits with people whom it will affect and try to reach an agreement. If you dread the thought of having that discussion, you probably ought to avoid refactoring. If you can't argue in favor of your refactoring idea, it's not worth the effort.

Also, consider that just because you can re-use flexible designs doesn't mean you will. You may not be the best person to consider the probability of re- use. Assume that it's unlikely: YAGNI (you ain't gonna need it).

</comment><comment><USER20> Started coding in 1988. What I've learned, it seems, that there are many styles. That they are worth learning. They are part of the art we practice. There are rules that these styles bring. And compromises.

Zen of Python. The exceptional beauty of John Carmack. Rebases of Google Style. Dive into a Linux Kernel. Very Objective Apple Style. Infinite pains of TensorFlow. Simple magic of SQL. Clarity of PyTorch. Unique ways of Prolog. Formality of Antlr. Frictionless Microsoft Style. Completeness of Theano. Abstract Syntax Notation One. Eldritch style of Michael Abrash.

<comment><USER21> Ditto methodologies.

Maybe analogous to mixed strategy equilibria from game theory.

</comment></comment><comment><USER22> Regarding avoiding copy-paste; I'm a JavaScript developer, and from time to time, I run `npx jsinspect src` in the root of my projects to detect copy- paste. The results are always interesting.

<comment><USER23> cool, if this is reliable enough to be part of CI process it will be super useful

<comment><USER22> Never ran into a problem with it myself but ¯\\_(ツ)_/¯

</comment></comment></comment><comment><USER24> I'm at a point where I think that "(2) Code is a liability" is a fundamental revelation that separates developers. It acts as a proxy for so many things, including some from this post:

\- Code duplication should be avoided, but not if the alternative is complicated or highly-coupled code. Duplicated code is increased liability, and complicated code is increased liability. Sometimes two similar but separate functions is just easier to read, use, test, and maintain; assessing the "liability" helps you make the best decision.

\- Tests are good because they decrease liability of other code, but they are themselves are a liability, so you can go too far (as many other commenters note about TDD).

And "Code is a liability" is not a silver-bullet. It isn't specific or prescriptive enough, and that's a good thing. It requires experience and effort to understand what that means and to make use of it on a case by case basis. But I think it does point you in the right direction by posing the right questions and focusing on the important trade-offs.

<comment> house9-2 > Code duplication should be avoided, but not if the alternative is > complicated or highly-coupled code.

100% agree.

Along these lines, avoid applying DRY principles to "incidental duplication"; You can end up coupling completely unrelated code if you are blinded by removing all duplication.

<comment><USER25> This is so important! You must have separate functions, even if they contain the exact same code, if they are semantically different.

</comment></comment></comment><comment><USER26> The stack is to deep. Nothing is easy anymore. The technology count is staggering. I'm close to retirement. I'm looking forward to pursuing my personal programming interests while I work some mundane, no responsibility, minimum wage job.

Programming is a ridiculous career path.

<comment><USER27> It is indeed ridiculous.

I am in my early 30s and I am aggressively saving as much as I can while living very frugally, to hopefully retire multi-millionaire abroad or get a lower paid job that won't stress the life out of me before I turn 40. Hopefully I won't become unemployed before hitting my target, or die of a stress-related heart attack.

I am not completely disappointed about my career choice because it allowed me to save a lot of money (see note), but boy, it is an insanely ridiculous career. Very frequently I wish I pursued something else, there is just way too much and fresh new crap keeps coming, every week. Can you believe 4 years ago almost nobody was talking about containers/Kubernetes? Just to name a random niche. Can you imagine what will happen in a couple years? They say "it's all the same, it's a cycle, you already learned it": that might be true if you are a manager or a PM and you just need a very superficial overview of the ecosystem, but if you are a senior engineer you need to master your craft, so even if a technology has been reinvented you need to spend hundreds of hours learning the details of this new incarnation, that's literally what your employer expects. Ask an engineer if being proficient with VMWare is enough to get up to speed with Kubernetes just because one is the sequel in the virtualization scene... exactly.

Also add the effect of globalization: my company hires talent from Eastern Europe (not consultants, entire teams with local management, product, ...) who produce insanely high quality software products at a ridiculous pace, exquisitely documented. Those people are wicked smart and on top of that work 20 hours a day. I am surprised software engineers are still hired in the US, where working 10 hours a day is already considered unhealthy. I feel the same way as a brick and mortar store that's going to get pushed out of business because of the more efficient and cheaper Amazon.

Note: It also helps that I choose to live in the super expensive Bay Area while not wanting kids, so I don't have the same spending requirements of people with kids and can bank the spread that most people would have to spend on schooling, nannies, good housing, ... I rent a studio for $2k in a ghetto- ish area, and that's 70% of my expenses. If I had a couple kids for whom I needed to provide good housing, nannies and private schools, I would be spending all I earn and there wouldn't even be an end in sight to this madness.

<comment><USER28> I hope you can make it work. I am nowhere near the path to saving enough to retire soon. Although I'm still holding onto the hope that I could build my own path start enjoying programming again with the BS and pointless stress removed.

To make that work though, I'm done with the interview circus. It's been such a distraction over the past 3-4 years, that if I wasn't prepping for interviews or staying up to date with the waste of knowledge that they test for in tech interviews, I could've built a successful business already. Now I'm choosing to focus my time there.

<comment><USER29> These days the effort required to get a well-paying programming job is more or less equivalent to the effort required to start your own business. If you can start a business. It's worth a shot. Worst-case scenario, the business fails and you are back on the job market but you can use your startup as a demonstration of your capability to deliver on projects that require time and dedication. You will also grow and learn a lot and be in a much better position than your competition.

</comment></comment></comment></comment><comment><USER30> When people say TDD does that imply writing unit tests before writing code?

Or do they just mean doing unit tests as you code?

I'm never sure when I hear this term because the benefits described (thing's just working first try) seem to apply no matter what order do it in.

<comment><USER31> Pure TDD is, as the others have said, to write the tests first. If you aren't writing code to fix a broken test you are doing it wrong.

TDD, though, is really a learning system. The main point is writing the code with testability in mind. You can write them together and get the same results as long as you do that. It keeps the code loosely coupled and the APIs clean.

So, IMO, you can still call it TDD as long as you are writing the code and tests together and are writing the code with the tests in mind. You can do that with the pure TDD or with some variant as long as the result is the same. I guess it depends whether you are referring to the general style or the specific learning methodology.

<comment><USER32> Unless you're writing super functional stuff, I don't understand how you could reasonably apply TDD when developing user interfaces: I target web, but the same could hold for mobile and other devices.

Because, what exactly is the contract? Do I essentially write integration tests to the effect of "If I click input element with css class .username, type 'x', and then click input element with class .password, then type 'y', then click the button with class .login, the page URL has changed from <mysite.com>/login to <mysite.com>/profile?"

There are no clear API interfaces for UIs. A user wouldn't really care that the button had class .username on it, for example -- that just gives us some way to identify the correct DOM element to perform the e2e test against. And some day, a developer could rename that class name, and it'd break the e2e test.

In other words, I can't assumption what TDD looks like for user interfaces, without the whole testing process seeming extremely brittle. Contrast this with, if I call some REST API, I expect this response body. It's quite concrete.

<comment><USER31> I don't think it is that much different, just maybe in proportions. In pretty much every application I write there 2 types of code. There is the guts or business logic that is written in the style of a library making it very testable. The other is the top level code, the 'main loop'. This is just there to hook together the library code in as short a way as possible. I think UI code differs in that it tends to have quite a bit more of this top level code that is basically un-testable except for very high level integration/scripted tests and QA testing. But UI code still has some amount of the library/logic code that can be written with testing in mine. I think this speaks to the myth that 100% test coverage is desirable and good. It is not.

</comment></comment></comment></comment><comment><USER33> Some of the things "I've learned in 25 years":

After arguing with a friend who claimed to have discovered a bug in `malloc` because his program crashed (that was a long time ago), I figured that there's a hierarchy of probable causes of bugs, from most probable:

1\. The code I wrote [you must understand only your code]

2\. A 3rd-party library/dependency [you must understand your dependencies]

4\. The compiler [you must understand the compiler-generated code]

5\. The OS, or OS-provided library [You must be intimately familiar with OS internals]

6\. CPU, or other hardware-related [You must be intimately familiar with how the CPU or other HW works]

It's basically arranged according to how many _other_ programs are using the given facilities. Returning to the "buggy malloc", I did not dismiss his theory outright just pointed out that if malloc _were_ bugged in such an elementary fashion, that no _other_ programs could work, hence there was overwhelming probability of _his_ code being bugged, not malloc.

\---

Just like security features, error-handling cannot be bolted on afterwards. Robust programs begin with defining error-handling strategies and expected outcomes in case of errors and building the rest on top.

\---

I could probably go on, but... meh.

<comment> GuB-42 The bug in malloc() is an old classic.

From my experience (about 20 years):

1- Obviously...

2- Some libraries are more reliable than others.

3- Missing, are you working for Valve?

4- I sometimes encountered compiler bugs, but it was things like compile-time crashes, never bugs in the generated code.

5- Never happened to me. Or at least no bugs that weren't documented (there is a BUGS section in manpages, read it).

6- Actually more common than the previous two. In fact extremely common in the embedded software business. But even with PCs, bad RAM sticks and things like that happen.

</comment></comment><comment><USER34> Does anybody have some words of wisdom / articles / tutorials / books on TDD for your typical web applications?

I am asking because for me, writing tests before the code is a natural choice for pure functions where I can easily map inputs to outputs. I cannot imagine writing that kind of code without tests.

But the usual task is gluing together tons of components and 3rd party calls (e.g. starting from an HTTP request, doing some transformations, calling some APIs maybe, persisting stuff in the database).

All of this depends on tons of side effects and hard to mock components. The only test I can write there easily is a full contract that mapping the HTTP request to HTTP response.

This doesn't help me with developing the internals (definitely not TDD), it only verifies the end result.

Even worse if there is no clear response but the result is piped into some queue over the network or something similar.

I am either completely incompetent or I develop applications that are tons of hard to test stuff (especially with simple unit tests) with only tiny core of functionality that seems easy to test.

<comment><USER35> Here's a few ideas on testing web apps:

1\. The internal pure data representation. If you're using some state management like redux or xstate then you can just cache the state on changes and run tests as-is (e.g. running the tests would be sending events and then checking that the state is what you expect it to be).

2\. The page itself. Tools like Selenium and Cypress will allow you to easily inspect and run tests against the DOM state (e.g. running the tests would be emulating interactions with the page and checking that the properties of elements are what you expect them to be)

3\. Checking the virtual dom (or other middleware). For example, with React, you can "get at" its internal data (at least the level you need) via a testing framework like Enzyme.

4\. If your app uses webgl context or is simply too hard to test on any of the above "pure data" levels, you need some sort of image recognition to compare pixels. I doubt this is going to be _perfectly_ testable but you can try your hand at Sikuli or roll your own with OpenCV

</comment></comment><comment><USER36> Do you / commenters here really "enjoy" programming as a career as much as when they first had enough skill and enthusiasm to build things?

I think this is a big misconception among devs with less than five years of exp.

<comment><USER37> I started programming when I was 11. Taught myself C++ from that age. Solved tons of tough problems in personal and school projects before going into industry at age 22.

Now at 35, I definitely think it's time to move on. I won't lie about my lack of interest in the field. The problems are less difficult to solve, but also much more frustrating. A lot more black boxes that you can't reverse engineer when you get stuck. Working with other people in a big company means things move far slower than my ability to get things done.

Plus the proliferation of different tech stacks means that despite the big job market, most of the new jobs require specific knowledge that I don't have, and my existing experience with low level coding and problem solving don't carry much weight.

<comment><USER38> > Plus the proliferation of different tech stacks means that despite the big > job market, most of the new jobs require specific knowledge that I don't > have, and my existing experience with low level coding and problem solving > don't carry much weight.

None of those jobs _require_ specific knowledge upfront. The problem is clueless fuckwits in HR filtering out CVs based on keywords. General problem solving ability and knowledge of fundamentals means you can actually learn any of the latest shitty frameworks in a few hours on the job.

</comment></comment></comment><comment><USER39> I just wish I knew as much now as I thought I did 35 years ago.

</comment><comment><USER40> I was very lucky that my first job out of school was at a Perl shop with older, senior engineers. It felt like I hit the jackpot in mentorship. I learned more with my two years with them than the next 5 where I cycled through all the trendy frameworks and devops tools. I'm hoping to find another small, experienced shop like that and where I can give my next 10 years; willing to relocate and take a pay cut.

<comment><USER41> How do you find those though?

<comment><USER40> As a new developer, I'd frequent a lot of meetups to build my network. I always made a point to talk the oldest guys in the room as the conversation was always the most interesting. I happen to be a sucker for dot-com bubble war stories.

</comment></comment></comment><comment><USER42> From the creator of TDD on why TDD doesn't work in many highly innovative environments [https://softwareengineeringdaily.com/2019/08/28/facebook- eng...](https://softwareengineeringdaily.com/2019/08/28/facebook-engineering- process-with-kent-beck/)

</comment><comment><USER43> Point 2. "Code is a Liability" ends with the sentence: "Always strive to do everything using as little code as humanly possible."

On its own I consider this bad advice.

I would change it to 'Always strive to make your code as easy to understand as possible, while less lines of code and complexity is preferred'

</comment><comment><USER44> "From around the age of six, I had the habit of sketching from life. I became an artist, and from fifty on began producing works that won some reputation, but nothing I did before the age of seventy was worthy of attention. At seventy-three, I began to grasp the structures of birds and beasts, insects and fish, and of the way plants grow. If I go on trying, I will surely understand them still better by the time I am eighty-six, so that by ninety I will have penetrated to their essential nature. At one hundred, I may well have a positively divine understanding of them, while at one hundred and thirty, forty, or more I will have reached the stage where every dot and every stroke I paint will be alive. May Heaven, that grants long life, give me the chance to prove that this is no lie."

— Hokusai

</comment><comment><USER45> The "no copy pasta" requirement leads to left-pad incidents.

</comment><comment><USER46> I've worked in multiple systems where we've needed country-specific DoX() and you always end up completely separating them. You start trying to fit one core logic for all countries but it always gets reduced into nothing and you wish you had just copypasted the first country logic to the next to begin with.

Once everything is separated you feel much more comfortable introducing that specific Mexico change without messing around with the core logic. Of course things that are truly agnostic shouldn't be duplicated but that tends to be extremely narrow in the end and you never know what it is before you have a lot of countries. It quickly becomes a maintenance nightmare trying to fit broad logic to impossible flexibility.

</comment><comment><USER47> Things i've learned after 20 years :

\- understand and care about context. Understand the input and output of what you're developing. Why people need it to function a certain way. And how people are actually going to use it.

\- business trumps tech (most of the time). Not just in matter of how well a company will perform financially, but also in everyday developer life. For example : a different business model may imply a different tech stack choice (and that's just one example). Understand and care about the business side of the place you're working in. It'll also helps you greatly communicating with your managers.

</comment><comment><USER48> What relates to me is when he was gonna write how awful TDD is, then he actually tried it - and liked it! There are so many things we think are utterly stupid, but have never even tried.

</comment><comment><USER49> Is there a single example of a notable great programmer who uses TDD?

<comment><USER50> Martin Fowler is an example.

<comment><USER49> What makes you think so? Have you seen any great code he has produced or are you aware of him having implemented something decidedly non-trivial? I might be wrong, but my impression is that he's someone who spends almost all his time telling people how to write software, not writing it.

</comment></comment></comment><comment><USER51> First one was an immediate turn-off. Duplicating code once is fine. With the given example, there's no need to start building an abstract billing method and a data structure to encapsulate the differences in billing between different countries, because there are only two countries and one is new. Wait for a pattern to emerge before refactoring, especially when such refactoring will make the code more complex and harder to reason about.

</comment><comment><USER52> "Do you know what correlates more than anything else with undesirable codebase properties? The size of the codebase."

Well yeah, more code means more bad code. I'm interested to know whether more code means _proportionally more_ bad code. If not, his statement doesn't mean much.

</comment><comment><USER53> What about copy/pasting interfaces between packages to avoid cross package dependencies

</comment><comment><USER54> [https://twitter.com/dougarcuri/status/1198217546362753025](https://twitter.com/dougarcuri/status/1198217546362753025)

</comment><comment><USER55> 1\. Interview skills >>>>>> Job skills, productivity, and ability to get work done.

2\. Learn office politics and learn to do it well.

3\. Everything else is irrelevant.

</comment><comment><USER56> 10 years of coding in trade for 10 years of middle management... why would I follow your coding advice? A serious question.

</comment><comment><USER57> There's some silly Moore's law variant buried here: The programmer demand will double every couple of years.

</comment><comment><USER58> > Learn yourself some TDD. You won't regret it.

How?

<comment><USER8> Read the book. Worked for me.

<comment><USER8> And after you read the book do a simple toy project to try it out.

</comment></comment></comment><comment><USER59> Going on about 17 years here.

It's not looking great for the future in terms of staying a developer. It's getting harder to find reasonable jobs anymore. My current one and the last one are/were disappointments.

I think the best words of advice are: Devise a career backup plan. I don't currently have one even though I have exerted effort in that direction. Probably end up a stocker at Home Depot or something. Hope not.

At some point, knowing another language or framework may be interesting to you, but it is pretty much immaterial unless you are going to use it on that job. For instance, I love Kotlin, but there's no Kotlin developer roles in my market hardly. Waste of time. Same thing happened with Clojure. I never learn.

You will be too expensive: I recently went after a Kafka Architect role which I should have been a slam dunk for but when it got to price the other side suddenly got all wobbly, excuses appeared, and poof, it disappeared.

Companies want cheap, throw away talent. I will say it again: Companies want cheap, throw away talent.

<comment><USER60> Would you comment on what made your current and last jobs disappointments?

I don't even know what the baseline is for satisfying programming jobs. All my jobs have been similar in terms of points of frustration.[0] I've just kind of accepted it as normal.

[0] I would elaborate but don't have time right now. At work.

<comment><USER61> > I don't even know what the baseline is for satisfying programming jobs.

For myself, it's always been about the team I was a part of. When you are part of a team that takes pride in their work, and they perform well together, supporting each other, learning from each other, etc - no "prima donnas", and they all have fun doing it - it leads to a good day of work.

I'm lucky in that for most places I have worked - from the first shop that took me in, to my current employer - this has been the case. I can only think of a couple of places I worked where that wasn't entirely the case; both came with excess politics, and other stress that I just didn't (and still don't) understand. I stuck out with it at both, but I'm glad I'm no longer a part of either.

One thing I do know and understand - this comes from someone who started their software engineering career when they were 18 years old, and now I'm pushing 50 - every place I have worked that I have had this "good team quality" has been a small employer, usually with fewer than 50 employees. My current position, there are fewer than 20 employees.

No - I don't make, have never made, and likely never will make "FAANG" money - but I'm not stressed either, and I make enough to keep a roof over my family's head, the lights on, and food in the pantry. I'm content, and if an opportunity comes up for a FAANG-money type position - I will have to look long and hard at it, before making that leap - because I feel that it might come with costs that just don't make sense to me any longer. I'd rather have a more "basic" salary and little stress, than a lot of money but stress out the door due to a myriad of reasons in such a workplace. That isn't to say that's inevitable, but I've just found that as the employers I've worked for were larger, the less my satisfaction with going in and the job overall.

<comment><USER62> I'm just entering the field (19-yo), and I don't have an particular experience in the field yet. From people I've talked to, jobs that you describe are the best options. I'm particularly interested in government jobs for these reasons.

<comment><USER63> At 19 work everywhere. Startups can offer so much value at your stage with freedom if you choose right.</comment></comment></comment></comment></comment>


Rise of the Mathematicians - <AUTHOR> https://antonhowes.substack.com/p/age-of-invention-rise-of-the-mathematicians <comment><USER2> I guessed that this would be an article about how mathematicians are starting to become newly important today, with the rise of ML. Most use of mathematics we rely on, up to the present, is performed by non-mathematicians.

Off by only five centuries...

<comment><USER3> Mathematics is used in statistics, physics, biology, finance, engineering, medicine, social science and more. Even in the 15th century, most mathematics was done by non-mathematicans, it's not a new thing.

<comment><USER4> To a physicist like me, the assumption that mathematicians are the source of mathematical revelations is the same as assuming that the best novels are produced by people who studied english.

<comment><USER5> That is by no means an apt metaphor. Mathematicians are in the business of creating new mathematics, not in studying the "language" in which mathematics happens to be written. Of course the history of mathematics is replete with contributions from physicists and others, particularly during the period when the educated could turn their hand to nearly any such discipline and find a problem on which progress could be made.

<comment><USER6> Yes. In fact it has often been noted by physicists that when they make a new discovery they sometimes find that mathematicians have been there before them. Like Einstein and non-euclidean geometry etc.

<comment><USER2> It more often goes the other way, and more profoundly.

Group theory.

Laplace transforms were considered an irrelevant curiosity until somebody figured out they were isomorphic to the wildly effective Heaviside D operator. Then everyone did their best to bury Heaviside's demonstrations of their utility, and pretend that Laplace had done all the heavy lifting.

<comment><USER6> Group theory was invented by physicists?

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Here's your answer to the question.

[https://en.m.wikipedia.org/wiki/History_of_coffee#England](https://en.m.wikipedia.org/wiki/History_of_coffee#England)

</comment><comment><USER8> Somewhere is another HN article about all the navigation schools that sprung up during the time this article discusses, how eventually everything req you to build technical skills even a contract sailor hundreds of years ago.

<comment><AUTHOR> was it this one? [https://aeon.co/essays/how-european-sailors-learned- celestia...](https://aeon.co/essays/how-european-sailors-learned-celestial- navigation)

</comment></comment><comment><USER9> Mathematics is the source of Western civilization. Modern science and technology is descended from philosophy and theology, which started with the mathematical presocratics and Plato's use of math to argue for unchanging forms, justifying the pursuit of philosophy in itself.

</comment><comment><USER10> How important were math books in English really? English mathematicians were reading and writing latin at the time. And would have had access to Euclid well before that book was written.

</comment><comment><USER11> I kind of like thinkibg of mathematics and language as technology for the mind - in the sense that both enable you to think thoughts that you otherwise may not have been able to think .. and to teach others how to do it, thereby transferring the technology.</comment>


Nasa's secret art studio: how to make rocket science beautiful - <AUTHOR> https://www.theguardian.com/science/2016/aug/07/nasa-secret-art-studio-rocket-science-jet-propulsion-laboratory <comment><USER2> There's a page linked from there where they have a set of poster designs you can freely download and print, promotional posters for solar system travel. [http://www.jpl.nasa.gov/visions-of-the- future/](http://www.jpl.nasa.gov/visions-of-the-future/)</comment>


Your Kickstarter idea on sale in China before you've finished funding it (2016) - <AUTHOR> https://qz.com/771727/chinas-factories-in-shenzhen-can-copy-products-at-breakneck-speed-and-its-time-for-the-rest-of-the-world-to-get-over-it/ <comment><USER2> _Yet Sherman estimates that he has lost "hundreds of thousands" of dollars in potential revenue due to copycats._

Just like piracy, it doesn't work that way. Far more people are willing to pay $10 for a selfie-stick phone case than $50.

Alternatively, I've also seen a lot of Kickstarters which were simply "marketing" for an existing yet not-so-well-known product available from Alibaba, with a substantial markup added. This means there is already significant "innovation" happening in China, contrary to what a lot of people think --- they just haven't seen the true scale of what manufacturing in China looks like.

<comment><USER3> Yes, there are more people willing to pay $10 than people willing to pay $50. But, how many people willing to pay $50 would prefer to pay $10 and will switch once the option arises?

<comment><USER4> Doesn't matter. The economy should ultimately favor the buyer, not the seller.

<comment><USER5> I disagree. The whole point of IP laws is that they provide a monetary incentive to innovate.

If someone decides to take some time off to invent a new device and incur a financial risk to bring it to market, they should have the opportunity to profit from it. If new inventions are cloned within weeks in Asia and undercut the original inventor, where's the incentive to take risks on novel inventions?

If the invention was trivial, why didn't the Chinese manufacturers come up with it in the first place?

<comment><USER6> Why are you assuming that kickstarter projects would have any IP? It seems that a very low percentage of kickstarter projects would own IP on their devices considering the amount of time and cost involved in just applying for a patent.

If no one owns a patent that covers the design then manufacturing a bunch of "copies" for a much lower price isn't illegal. It makes sense that kickstarter would be targeted as a source of not patented ideas to use.

</comment></comment></comment></comment></comment><comment><USER7> Is it just me, or is this article incredibly biased?

here's a thought.. if you dont want your stuff counterfited, dont outsource it to china. The companies loved the idea of "cheap labour" and also want the underpaid employees to be honest and loyal to them?

The "high price of low cost" at play here..

In this selfiestick, china is bad here.. but for a lot of the counterfits.. you sent china the moulds, templates, specs.. hmmm...

Jack Ma is correct, a lot of the counterfits come from the same factory someone outsourced to.. so what is the difference between a "counterfit" and "genuine" article other then price?

<comment><USER5> > so what is the difference between a "counterfit" and "genuine" article other > then price?

The counterfeit product has no incentive to ensure their product is of high quality, as long as it passes a cursory inspection before/after being bought. If you buy a brand X product and it fails after six months, you can complain to the company about it, you can post on social media to make it known that brand X doesn't last long, and so on. Brand X has an incentive to make sure their products last as long as customers expect them to, that they're safe, etc. as to not tarnish their brand image.

If you get a FakeX branded product, who do you complain to when it breaks six months later? The AliExpress seller is long gone, the FakeX brand is replaced by FakeX+1 brand, and you're pretty much SOL.

If the product has a major defect or safety issue, there are no recalls for FakeX branded products. How many hoverboards were recalled for being fire hazards?

<comment><USER8> This applies as much to genuine products as it does to counterfeit ones. If the company behind the genuine product wanted to ensure high quality, they wouldn't outsource manufacturing to China, to the cheapest plant available.

Chinese plants generally give you what you pay them for. See how much crap you can buy in western shops, made by western brands, but "in China". It's not the "in China" part that's responsible for it, it's the pittance the western brand is willing to pay for manufacturing and controls.

</comment></comment></comment><comment><USER9> Wow, it's like an AI that makes your product for you! Put up a project on Kickstarter and if it gets funded just buy the product from China and send it to your backers.

<comment><USER10> Right, except the AI is just really "cost-effective" labor and manufacturing, with some corners cut on small items like ethics, human rights, and materials.

<comment><USER11> Sounds like most dystopian AI to me.

</comment></comment></comment><comment><USER12> This is very easily preventable if Amazon easily allowed the listing to be flagged for IP violation. Such multiple violations should cause supplier to be banned. It is quite surprising that foreign supplier just can dump whatever they want without any regards to IP in US markets via Amazon.

<comment><USER13> Amazon just doesn't care. They let hundreds of suppliers sign up with the same bank account details.

</comment></comment><comment><USER14> Comment thread from 2016: [https://news.ycombinator.com/item?id=12724096](https://news.ycombinator.com/item?id=12724096)

</comment><comment><USER15> This is terrible if you're trying to make money from your product, but it's great if you just want to make something that you can't find in the market. Although it would be nice to not have spent the time and money on prototypes and getting ready for a Kickstarter.

</comment><comment><USER16> Here's a nice documentary about foreigners moving their startup to Shenzen, where they can have same-day prototypes built and go into production immediately: [https://youtu.be/SGJ5cZnoodY](https://youtu.be/SGJ5cZnoodY)

</comment><comment><USER17> I wouldn't might sending the Chinese companies some ideas to implement but I guess what they was is validated ideas to reduce the risks.

</comment><comment><USER18> Hence the proliferation of "X as a service".

</comment><comment><USER19> The real problem is: why can they produce it 5 times cheaper? that's the real question you should ask yourself.

The cost of production is much lower there because living costs are lower. The lower we can get our living costs here in the US, the more wealthier and productive and more competitive we'll be. instead of focusing on relentless gdp growth, we should instead focus on what we can do to reduce costs everywhere here at home, that will make us more competitive.

<comment><USER20> Have to be careful with this line of thought. Are costs high because workers are paid too much, or because margins are too high on necessities that workers need?

</comment></comment><comment><USER21> This is why it's worthwhile filing a provisional patent application ($70).

When your product takes off, you have a potential recourse if you're ripped off.

<comment><USER18> This guy's sliding selfie stick probably isn't patentable. Telescoping selfie sticks are known. Parallel sliding telescoping devices are known; ladders are made that way. So it's an obvious combination of prior art.

<comment><USER22> But "handheld/miniaturised ladders" are not a thing, so even if the mechanism is the same, the application is different and that's probably enough for a patent.

<comment><USER23> > _But "handheld/miniaturised ladders" are not a thing_

No, but there are tons of handled/miniaturised telescopic devices. Antennas in portable walkie talkies and radios are an obvious example, there are umbrellas like that, and tons of other things...

<comment><USER24> You can own a patent for telescoping ladders and still have to pay royalties to the owners of the telescoping mechanism patent. And if anyone else makes a telescoping ladder with a beverage holder, they can patent that but you can go after them because your patent is more generic. More generic patents take more effort to get but are much more valuable because of this.

</comment></comment></comment></comment></comment><comment><USER25> Very boardly speaking, if something can be easily copied, it means the value- adding part is not comimg up with the idea, but the execution of it.

<comment><USER26> I would think the opposite. If something is easily copied, it means the execution is simple. The value adding part is coming up with the idea that people want.

</comment></comment><comment><USER27> Far more frequently, I see Facebook ads for rebranded and heavily marked up Chinese products.

In a way, the Western resellers are providing a service with their ad spending, in that I sometimes see products I like, trace them back to the original manufacturer, and buy them there.

</comment><comment><USER28> As somebody who toys with the idea that we'd ultimately be better off with minimal (or even no) IP protection in law this is a fascinating case study.

Let's assume this situation remains in place for a long period and knowledge of it spreads widely. There'd be no more kickstarters like the one in the article.

How does this play out in the long term? What kind of world are we left with?

<comment><USER12> Assume that there was no IP laws and everybody is freely allowed copy software/ideas/content as they see fit. Now developing a significant size software takes human hours. There is a fixed cost associated per human hour. Now let's say your cost was $1M and it's useful to 1M people. As there are no laws to protect IP, I can't divide my cost to potential users and sell my software at $1 a pop. If I do that then I can't recoup my cost. This means I must sell my software at $1M to richest possible single buyer. Or create a buyer group much like vacation condo model. In either case, no IP translates to scenario where only upper class of society can benefit by advancement in innovations.

This is a massive philosophical "bug" in free software movement. It's one of the goal to make software more accessible to everyone but under the reality of economics it does exactly the opposite. Once free software arrives on market, cheaper but slightly superior commercial versions will die out and only expensive superior versions will live benefiting more affluent class/organizations.

The hybrid models where you provide enterprise support for money while keep things free is interesting but I am still not sure that it can be as powerful when you can use full power of economy to drive resource scaling at fullest extent. Most companies which use this model run extremely frugal and usually can't afford large scale research and development activities.

The things that has been described in article has already caused significant damages. There have been Chinese companies who received designs from innovators and started creating white label products. They didn't had to worry about capital cost of arriving at that design or reliability to protect the brand reputation. They also didn't care about doing R&D investments to evolve the product further. The focus was strictly on generating cheap knockoffs that produces short term profits and then move in to next victim. So in essence, your model of IP extinguished innovation, it's evolutio and promoted cheap short lived knockoffs.

<comment><USER28> I do understand the fundementals of this topic. I've grown up with the assumption that everything you state is right and proper. I'm also aware that IP laws have a significant downside as they require fairly elaborate and repressive measures to maintain and they come with many indirect costs.

(On a side note as I don't want to derail the central point we're discussing:

> but under the reality of economics it does exactly the opposite.

Considering most computing devices on the planet are running an open source OS then this is surely open to debate)

<comment><USER12> One would argue that Linux has stalled OS evolution. It's free so there is no incentive for other innovators to come forward and invest massive resources and capital. The OS investment at all major companies had been drying up. Think about it, this is now almost 50 year old OS. There have been virtually not much of research, advancement or evolution even when *inux has several opportunities to rethink design and architecture in so many areas. To a common user, it's even hard to use, manage and understand but we are still stuck with it. We carry almost half a century worth of historical baggage with us every day with no end in sight. Here's interesting reading: [http://doc.cat-v.org/bell_labs/utah2000/utah2000.html](http://doc.cat-v.org/bell_labs/utah2000/utah2000.html)

You will see this pattern virtually everywhere when free software has become standard and it brings to halt research and development in that area that may require large scale capital.

</comment></comment></comment></comment><comment><USER29> China has enabled trading to be easier. I have a device, PlusX 5501, just patented across US and some African countries. Officially not launched. Chinese companies have over $800000 in sales for nearly the same device some with innovations not on the original device. As I work on the software front, my bet is that I will make my innovation on the software, potential name brand markup as well as support.

<comment><USER30> I tried googling plusx 5501 and didn't find anything relevant.

I'm genuinely curious about what device you're talking about.

Would you mind sharing?

<comment><USER31> Funnily enough, these two comments are now the top 2 Google results for "plusx 5501".

<comment><USER32> XKCD 369 [0] strikes again :)!

[0] [https://xkcd.com/369/](https://xkcd.com/369/)</comment></comment></comment></comment>


Should parents ever worry about minecraft? - <AUTHOR> http://www.bbc.co.uk/news/magazine-32051153

<comment><USER2> No

<comment><USER3> Excellent application of Betteridge's Law.</comment></comment>


Canadian cellphone market poised for shakeup as spectrum auction ends - <AUTHOR> http://www.cbc.ca/technology/story/2008/07/21/tech-spectrum.html?ref=rss <comment><USER3> On a related note, it seems Canadians are indeed far behind when it comes to celluar phones compared to the rest of the world: only 69% of adults have a cell phone! [http://www.reportonbusiness.com/servlet/story/RTGAM.20080721...](http://www.reportonbusiness.com/servlet/story/RTGAM.20080721.wrcellphones21/BNStory/Business/home)

Of course, anyone who knows anything about the Canadian wireless industry - <USER2> nasty oligopoly with unheard-of contract lengths and extremely high prices will not be the least bit surprised by this statistic.

</comment><comment><USER4> Thank God. Now if only the CRTC would drop those stupid foreign ownership rules we might actually get service that is reasonable.</comment>


Merge request checklist (2017) - <AUTHOR> https://smalldata.tech/blog/2017/10/06/the-merge-request-checklist <comment><USER2> That's a nice summary of some good techniques. I'll send this around in my team to improve our MRs.

The link to the submission here should be different though I think. It should be

[https://news.ycombinator.com/item?id=16562100](https://news.ycombinator.com/item?id=16562100)

instead of

[https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fsmal...](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fsmalldata.tech%2Fblog%2F2017%2F10%2F06%2Fthe- merge-request-checklist&t=The%20merge%20request%20checklist)

</comment><comment><USER3> For a volunteer driven open-source project I work on, we just use the [wip] nomenclature in the titles so that progress can be shared on a PR without every thing being tidy. But these guidelines seem reasonable and useful.

<comment><AUTHOR> Yeah, gitlab actually provides a really nifty feature where if you mark the MR as WIP:, it won't let you merge it!</comment></comment>


Obamacare upheld 6-3 by Supreme Court - <AUTHOR> http://www.nytimes.com/2015/06/26/us/supreme-court-affordable-care-act-health-subsidies.html

<comment><USER2> This ruling is actually very good for individual freedom. I'm happy to see that the supreme court made an intelligent ruling. I'm 54 and semi-retired. I have pre-existing conditions and if we went back to the way things used to work, I'd have to become employed full time again.

I hate everything American employment stands for. Age discrimination, employment-at-will, invention agreements, covenants not to compete, and binding arbitration to name a few.

At least now, I can continue to live off my investments and rental income, and contribute to the open source community in the areas of hardware and software design.

The taste of freedom is exhilarating!!

<comment><USER3> Are you getting subsidies from the government while living in a state that didn't set up an exchange? If not, this ruling has no effect on you.

<comment><USER2> I'm in California. A state with its own exchange.

If this ruling had gone the other way, it would have affected me eventually. I would not expect Congress to do anything, and the state of California may not have been able to react quick enough with state legislation to stabilize things.

There would have been a domino effect as more people in red states cancelled their insurance and left only the very sick with insurance. The effect would have reached the states with their own exchanges. The whole thing would have likely collapsed.

<comment><USER3> I don't get why it would affect other states. The only people cancelling would be people who couldn't afford without the subsidies. Are you saying the whole system only works because of the subsidies? But it wasn't _that_ much worse before, and all the other provisions would have remained.

<comment><USER2> Yes, it would be unworkable without the subsidies.

There are 34 states using the Federal exchange. Most of these states are in the south and midwest. The income per capita in these states is much lower than the states with their own exchanges. It is estimated that 70% of those covered would cancel their insurance in these states if the subsidies were eliminated. The remaining 30% would try to hang on as they probably really need the insurance due to pre-existing conditions. Insurance companies would not be able to make a profit off of the remaining 30% and they would raise unsubsidised rates to try and compensate. As they raised the rates, more people would drop out and then the insurance companies would start raising rates in the states with their own exchanges, and on employers who offer health insurance to employees to compensate. The whole thing would have come crashing down.

<comment><USER3> Why are the people getting subsidies and are poor also the ones the insurance companies are profiting most off of? If you don't assume such a correlation, then the worst that will happen is a slightly smaller economy of scale.

Am I missing something?

Also, if an insurance company is losing money in a state, stopping to service that state is strictly better for profits than continuing and raising money by raising prices elsewhere. One state shouldn't affect others like that.

</comment></comment></comment></comment></comment></comment><comment><USER4> Without obamacare i would have no coverage at all. i dont object to paying for traditional health insurance but before obamacare i could not qualify as i have too many preexisting conditions.

<comment><USER5> Just about everyone agrees with the preexisting conditions aspect of the law. The problem with the law is much bigger than that however. I'll try to break down some of the issues to clarify.

1\. The law institutionalizes a broken insurance and pharmaceuticals system that puts profits about health outcomes.

2\. Because of high deductibles, the employed poor are paying for care they cannot afford to use, in effect subsidizing the upper classes who can.

3\. Dependents become a burden to tax payers b/c they are now responsible for their health coverage. (Think unemployed granddaughter who lives with, but also helps take care of, her grandmother.)

4\. Administrative requirements are out-of control. And digital record systems are proving to be a complete disaster (thanks to lousy regulations).

5\. The system continues to perpetuate employee provided care.

6\. It unfairly burdens the young to placate the old.

I am sure others can add to this list.

<comment><USER2> Point 1 I agree on, the others not so much.

2\. Not true. The co-pays and deductibles for low income people are subsidized. Some pay as little as $5 to see the doctor or get a name brand prescription drugs.

3\. The system was designed to spread the risk. This is by design.

4\. Not really. I don't have any trouble seeing a doctor when I need one due to red tape.

5\. No. It does the opposite. It offers freedom from employment for those who work for 35 years and acquire assets to live off of.

6\. Historically, the young have always supported the old in human society since the beginning of time. There's no logical reason to change that deal.

<comment><USER5> 2\. Cost sharing only operates in a very limited window of income. One must also buy a Silver plan which costs more (offsetting some of the cost share) and these plans are highly restricted to in-network doctors and hospitals.

3\. And the effect is to destroy family bonds.

4\. It's not just about seeing a doctor, but the additional costs. Do you know the average doctor has 7 minutes per patient per visit in order to be profitable?

5\. People who work 35 years soon get Medicare. For everyone else one still has to contend with getting new coverage when one leaves their job.

6\. That makes it okay to institutionalize? You missed the word "unfairly". The ACA goes beyond what is natural. We are going to tax 18 year olds to pay for grandmom's $500,000 cancer medicine so she can live an extra 4 months?</comment></comment></comment></comment>


Support for Canadian programming conventions in the Ruby language - <AUTHOR> https://github.com/vanruby/canada

<comment><USER2> Yes, many Canadians pronounce "aboot", but you don't find the ", eh?" construction all over Canada, particularly out west.

<comment><USER3> I always considered "eh?" to be very much a central Canadian thing (just Ontario maybe?)

<comment><USER2> Having grown up in the ecosphere of Lethbridge, I never heard that construction until I came back east. (We would frequently watch "Front Page Challenge", one of the longer-running TV programs anywhere.)

</comment></comment></comment><comment><USER4> I was once married to a Canadian. She got furiously angry when I pointed out that she said "aboot".

But yes, she said "aboot".

<comment><USER3> Typically Canadian's pronounce it about as əˈbəʊt. A boot is pronounced əˈbu̟t. The sounds are distinct, but similar. I think many Americans here it as "aboot" because they're not used to the phonetic raising.

<comment><USER5> so, aprox. uh'buh oh t

<comment><USER3> Yeah, that seems like a good approximation to me.. People are probably wondering why I'm sitting here mouthing about.

This is good sound clip actually.

[https://en.wikipedia.org/wiki/File:En-us- about,_a_boot,_a_bo...](https://en.wikipedia.org/wiki/File:En-us- about,_a_boot,_a_boat.ogg)

</comment></comment></comment></comment><comment><USER6> I hope this will continue to be supported as I'll be including it in my projects going forwards.

</comment><comment> vezzy-fnord Similarly, British conventions for PHP: [https://www.addedbytes.com/blog/if- php-were-british/](https://www.addedbytes.com/blog/if-php-were-british/)</comment>


Isaac Choi, CEO from "Scammed by a Silicon Valley Startup" Pleads Guilty - <AUTHOR> https://www.bizjournals.com/sanjose/news/2018/02/06/isaac-choi-wrkriot-guilty-plea-fraud-charges.html <comment><AUTHOR> This analysis on the Fenwick website "Grand Jury Indicts Startup Founder Isaac Choi – Implications for Silicon Valley" By Casey O'Neill and Hanley Chew from June 19, 2017 [https://www.fenwick.com/publications/pages/grand-jury- indict...](https://www.fenwick.com/publications/pages/grand-jury-indicts- startup-founder-isaac-choi-implications-for-silicon-valley.aspx)

Seems to conclude that there nothing new to see here, noting in the Significance section:

The facts of Choi are not particularly complex, and are far from groundbreaking. The indictment contains a handful of wire fraud counts for conduct that, if proven, amounts to simple deception at a small Silicon Valley company. As one commentator has noted, much of the conduct is par for the course in the Valley. For employees seeking to earn their stripes and fortune at a startup, experiences similar to those at WrkRiot are practically a "rite of passage."

They don't link or footnote who the commenter is or who viewed this as a rite of passage. They conclude:

"Ultimately, the government's success if Choi is litigated, and the length of any resulting sentence, will depend in part on whether a jury and judge accept the notion that Choi's conduct amounts to something more than conventional Silicon Valley antics, that is, this was more than an unfortunate rite of passage for WrkRiot employees. Regardless of the result, the Choi indictment demonstrates that on suitable facts, DOJ will delve into the internal affairs of a startup despite only modest losses. Founders and their advisers should keep WrkRiot in mind, balancing zeal for product and capital and the need to survive with the need for both investor-facing and internal restraint."

</comment><comment><AUTHOR> Original HN discussion [https://news.ycombinator.com/item?id=12379518](https://news.ycombinator.com/item?id=12379518) opening paragraphs from San Jose Business Journal article:

"Isaac Choi, the founder of a shuttered Santa Clara startup, faces up to 20 years in prison and a potential $250,000 fine after pleading guilty to defrauding his employees.

The story of 36-year-old Choi surfaced after former employee Penny Kim wrote a Medium post titled "I Got Scammed By A Silicon Valley Startup" in August 2016.

Federal prosecutors said that Choi, who went by at least four different names, falsified his educational and professional history and personal wealth, and scammed at least a dozen employees.

His online job search company, WrkRiot, was known as 1.For.One when it was founded in 2015."</comment>


Rails Hotline (live phone help with RoR) - <AUTHOR> http://www.railshotline.com/ <comment><USER2> It does seem like this would be a lot easier if there were also chat (or even if it were chat-only). If you're talking about code, it would be really helpful to be able to paste in snippets or links to resources.

<comment><USER3> #RubyOnRails on freenode is basically this.

<comment><USER4> Give the #RubyOnRails users a way to paste a link (shorturl?) to people who come into the channel asking for premium help.

Make a game of it for the users, have a bot which reports the user stats (which users can auth via privmsg/ctcp password).

edit: a bot which reports stats on a request basis only, and privmgs all interactions with other users! no channel spam!

</comment></comment></comment><comment><USER5> Thanks for the ups guys.

As I said on the site I owe a lot of our success to the generous spirit of the open source community and wanted to give a little back.

If you're interested in volunteering to take calls: <http://www.railshotline.com/apply.html>

<comment><AUTHOR> chap, as I've mentioned before, I think this is yet another great way to contribute to open source. It's not always about writing code - projects like this are just as valuable as someone who works full time on documenting open source projects, writes code or creating user interfaces. thanks for a fresh idea!

<comment><USER6> Really great idea. Other opensource community should learn from this.

<comment><USER5> Thanks! If anybody else is interested in getting a community hotline setup, we've been working on making that really easy.

Shoot me an email: email@example.com

</comment></comment></comment></comment><comment><USER7> Reading this and pockethotline.com, and thinking about your offer to help set up other community hotlines: what about a Founders Hotline? Call to talk to a real live business founder, whether to get some advice, get a recommendation or opinion for a particular service, bounce an idea or pitch off someone for feedback, or just get a different perspective. And the "experts" would get the benefit of hearing from some interesting people doing interesting things, and having a nice conversation with a fellow founder, as well as the recognition and networking you mentioned elsewhere.

<comment><USER8> The only issue I forsee with this is that such a hotline would get spammed up with idea-mongers who refuse to share anything without signing an NDA, and who equate a TechCrunch link with a guarantee long-term success.

<comment><USER7> So say "no" and hang up. :) Easy enough to add a FAQ making expectations clear.

</comment></comment></comment><comment><USER9> So, I guess this is like going to Freenode#RubyOnRails, but for people who don't know what IRC is?

You should absolutely, totally, utterly figure out a way to charge for this service.

<comment><AUTHOR> The major distinction here is voice is much more personal and one on one than IRC. IRC can be intimidating for a novice, and let's be quite frank, many times people's IRC persona does not reflect who they are in real life. As someone who's been contributing to major networks such as EFnet for many years now - I've learned IRC can be a great tool for learning, but it can also be downright aggressive and humiliating, particularly to the majority of users who this service would be targeting.

A voice on the other hand is more personal, synchronous and on-demand. I think there's value there and that it's possible to charge for that additional value.

<comment><USER10> EFNet and Freenode are quite different, however.

</comment></comment></comment><comment><USER11> Seems like a promising idea, and I have no absolutely intention of knocking it.

But ... you have to admit that it's a wide-open target for parody: picture the earnest young Rails beginner calling (from Chennai, of course) and getting DHH. From there it slides into some kind of ChatRoulette nightmare involving DHH, _why, Zed ("fuck this shit! Just use Python"), a werewolf, ...

</comment><comment><USER12> This is a neat idea and I commend you for the effort this has taken and will continue to take. I have some questions for you about how you perceive people using the service:

How do you bridge the code-to-voice gap; that is, someone calling in with a question about coding and you have to describe something that requires a lot of code syntax. Do you pass that off to some sort of e-mail type discussion or screen-sharing process, anything like that?

This seems like it could be a great consulting-style opportunity, but also an awesome way to get new developers over the stumbling blocks they experience commonly when picking up new languages.

 _edit_ My curiosity on this stems from past experience, doing phone-based coding or tech support to family or friends - it has always been a major challenge for me to verbally describe some more complex tasks, and 9 times out of 10 I find myself saying, "you know what - I'll just swing by and show you, it'll be a lot easier and faster for the both of us". (I am not a very good auditory learner/processor - I need tactile or visual assistance, and teach others better using the same methods.)

<comment><USER5> Thanks!

Obviously, some questions you're going to need to work through the code, so we can always move the conversation to text.

So far lots of the calls have been about documentation and best practices which are pretty easy to talk through.

<comment><USER13> Agreed - maybe an Rails environment similar to <http://tryruby.org/> for Ruby IRB?

<comment><USER14> an, if only herokugarden lived on, that would be ace!

</comment></comment></comment></comment><comment><USER15> Neat idea.

What do you suggest for non-US volunteers (and callers, although I suspect that is harder to solve, at least for free)?

<comment><USER7> Seems like you have several independent problems there. First, issues of timezone, language, and similar. Second, technical issues of long-distance and connectivity. You can pretty trivially solve the second set of issues with VoIP and other means; however, that doesn't address the non-technical problem. To address that one, you might consider making it easier to connect with people in the same general locale, which would also solve the second problem.

</comment></comment><comment><USER16> Idea:Record calls and make them available to others through the website. Less repetition of questions and you will be available to have a much wider outreach.

<comment><USER17> Great idea. With some simple transcripts and text-based search, it could be a great searchable tome of information one day.

<comment><USER16> Just called in and talked to Chap. I wanted to make sure he got to see the idea and know about before it got lost. He immediately made the jump to transcripts and text-based stuff.

Chap: Recording calls with skype forum post: <http://forum.skype.com/index.php?showtopic=477581>

Good luck!

<comment><USER5> Thanks for the call!

I love the idea of sharing recorded calls to help more people.

</comment></comment></comment></comment><comment><USER18> The Rails community is serious about outreach. Good on ya!

</comment><comment><USER19> Just used the service and had a great chat with Chap, one of the founders. There's something qualitatively different when you're talking to someone using voice - it makes it easier to articulate some of the bigger questions that aren't just syntax or "help me debug this" type of questions. Anyway, I think this is a great idea, and love that these guys are making it happen. Kudos.

</comment><comment><USER3> Wow. I saw this and thought, 'genius.' What's it going to cost.. $50/ 20 minutes.. that would be more than fair for an expert.

FREE?????

<comment><USER20> It better be free so long as they're not picking up the damn phone. :)

<comment><AUTHOR> I'm assuming they're getting overwhelmed with traffic after being linked here and other high traffic properties. With only two volunteers on staff, there's only so much you can do. I am sure they are rapidly going to look into adding volunteers if the volume stays persistent (and/or hopefully grows even larger).

<comment><USER21> Perhaps raising the price would help keep demand from outstripping supply?

</comment></comment></comment></comment><comment><USER22> If you can think of a way to bring this together with railsmentors.org, ping me. I'd love to see what we could do.

</comment><comment><USER23> These guys are brave!

</comment><comment><USER24> Ok so how many prank calls have you gotten? Anyone mistakenly call thinking it was a phone sex number?? Rails does have a lot of connotations...

<comment><USER25> haha awesome.

</comment></comment><comment><USER26> I'm not sure if it was intentional or not (to grab attention) but the blue text with drop shadow on that red background hurts my eyes.

<comment><USER5> Nope, suppose to be white.

I'm guessing you're browser is automatically creating a link to that phone number and using some default stylesheet. What browser are you seeing that?

<comment><USER27> I see it as white, but the Skype plugin for Firefox changes phone numbers to highlight them.

I have it installed at home, will try it and then get back to you. Maybe some phones do that as well?.

<comment><USER27> Just tried it, it doesn't look blue, but it does look awful with the Skype plug-in.

</comment></comment></comment></comment><comment><USER28> I called, no hold time. Good stuff. Though I am an excellent holder.

</comment><comment><USER29> Called and was walked through my problem with a working solution!

</comment><comment><USER30> What is a rail shot?

</comment><comment><USER31> do they offer quiche as well?

</comment><comment><USER32> Has Rails become so complex that people need a hotline?

<comment><USER32> Seriously, downvoters, I'm curious as to what motivated this. What's the need for a hotline? If there are problems, is a hotline really the best approach, or does it suggest that there's some larger underlying issue that makes it necessary?

People used to tout Rails as being stupid easy to use. I.e. <http://www.amedias.org/img/java_vs_rails_books.jpg>

So, just how complex has Rails become? What are the difficulties people run into?

<comment><USER33> It's not about the complexity of _Rails_ , it's about helping a learner get comfortable at their own speed, outside of the usual channels of support. It's about creating something that will unexpectedly delight people. No one expects free phone-based tech support for an open-source project.

This is ridiculously awesome. I think your reply did not contribute much of use to the conversation, and I think that's why you got downvoted (wasn't me, I can't downvote).

<comment><USER32> Thanks very much for the response.

 _No one expects free phone-based tech support for an open-source project._

That's true, but there are various reasons for that, one being that it's rarely needed. Now, offering it despite any demonstrated need is an interesting experiment, but it also suggests that the typical paths for learning and support are lacking.

 _I think your reply did not contribute much of use to the conversation, and I think that's why you got downvoted_

I asked a question with an unflattering (albeit realistic) supposition.</comment></comment></comment></comment>


Scripting is Dead; Long Live Scripting - <AUTHOR> http://waffle.wootest.net/2011/05/20/scripting-is-dead-long-live-scripting/ <comment><USER2> As I've understood the term (and how I use it), a scripting language is one that doesn't require explicit compilation (as opposed to JIT compilation, for example) to be run, allowing for fast(er) code-test cycles.

You hear of shell and Python scripts, but (at least myself) _never_ of C and Java scripts.

<comment><USER3> But in fact, there are C interpreters, such as:

<http://root.cern.ch/drupal/content/cint>

and

<http://code.google.com/p/picoc/>

There are also Python compilers, such as:

<http://cython.org/></comment></comment>


Information Overload, the Early Years - <AUTHOR> http://www.boston.com/bostonglobe/ideas/articles/2010/11/28/information_overload_the_early_years/?page=full

<comment><USER2> This is a fascinating historical perspective on the problem. I think the people who complain about the internet reducing attention span and memory are missing the point. Our intelligence is not reduced, just more and more distributed outside our bodies. Me + laptop + wifi is a much more intelligent and capable creature than plain old me and that gap will only widen as we develop more tools for handling information and offloading the parts of intelligence where computers outperform human brains.</comment>


Facebook down - <AUTHOR> http://www.facebook.com/?down

<comment><USER2> Nope. It's up.

<comment><USER3> I just routinely flag submissions like this - they are of zero value and use valuable real estate, making them net negative value.

They are also genuinely inappropriate.

Flag it and move on.</comment></comment>


Ask HN: What is the distribution of startup success? - <AUTHOR>

In the Platonic world there is a distribution of the success of startups that achieve $500K (or more) of seed funding. For instance maybe 1 in a thousand achieve 100:1 returns on the seed investment in 5 - 7 years, 1 in ten goes completely to zero, and the whole range in between. It is pretty close to impossible to actually gather the information required to derive this distribution, but I think a survey of folks knowledgeable in the start-up funding area would be a decent proxy. If you think you can contribute to this survey, what is your estimate of the distribution? Let's establish the following ground rules:
1) By startup we mean largely software-driven company of interest to the HN community. It can either go on to VC financing, or not.
2) Startup achieved $500K+ seed capital on or after 1/1/2002 (we want to eliminate the dot-com bust as much as possible).
3) Within 7 years there is either an actual valuation event, or good subjective evidence to support a valuation. (This rule leaves many younger companies in a nebulous state. Use your judgement.)
4) Return is return on the seed investment.
5) Estimate for distribution points of 100:1, 50:1, 10:1, 5:1, 2:1, 1:1, 0.5:1, 0.1:1, 0:1, summing to 1.
I realize this is not a substitute for due diligence, but simply a data point similar to total stock market return. <comment><USER2> I love the idea of surveying such data and would love to see the results. But you're going to need a huge set of data because potentially interesting and non-intuitive factors will be several 'layers' deep.

The data will show a very strong relationship between the space entered by startups and funding; much of a startup's likely success - and thus VC interest - depends on macro factors (e.g. industry growth, competition). These things are known.

Perhaps to get a larger dataset than you're likely to receive here, scraping public databases might be better? Can anyone please suggest such databases (e.g. I don't know how much data you could get from Crunchbase?)?</comment>