The Cost of Skipping TDD and Code Reviews (2016) - <AUTHOR> https://medium.com/javascript-scene/the-outrageous-cost-of-skipping-tdd-code-reviews-57887064c412 <comment><USER3> I'm a big fan of TDD, but I quit reading this article the second my eyes came across "IBM System Sciences Institute" and the chart that accompanies it.

This is by now one of the most thoroughly debunked memes in our profession. I wrote a couple chapters about it: [http://leanpub.com/leprechauns](http://leanpub.com/leprechauns) . I wrote a handy little guide for people to know just how much BS was involved in any one citation: [https://plus.google.com/+LaurentBossavit/posts/aNKut1QV8pT](https://plus.google.com/+LaurentBossavit/posts/aNKut1QV8pT)

If that wasn't enough, there is now an actual negative research result on the so-called defect cost increase: [https://arxiv.org/pdf/1609.04886.pdf](https://arxiv.org/pdf/1609.04886.pdf)

It should be quite clear by now that this type of argument doesn't do TDD any favors, it taints it by association with intellectual dishonesty.

<comment><USER4> I hung on a bit longer, but lost any hope of seeing something relevant when he launched into an imaginary case study. Later on, we find him mentioning an actual study (of code reviews), only to dismiss its results as being implausible to him.

The author appears to have drunk so deeply of the dogma that he has no idea of how to make an objective case.

<comment><USER5> I thought it was funny he waved off the code review study as well. If the studies don't actually mean anything then why can't we similarly disregard the one that says TDD is good?

</comment></comment></comment><comment><USER6> A multiple of 100x the cost to fix a bug in production compared to development is very context dependent. These examples always assume your working on a large project with many developers and complex testing and deployment processes.

But there are many developers, like myself, that work on relatively small projects in small teams. The multiple is more like 5x or less for these scenarios. My current project is developed by two of us and deployed to just a couple of dozen users inside our company. I can walk to a users computer, be shown the bug, fix and test it on my machine and deploy it in minutes. Do I need TDD and Code Reviews? Will it pay back all the extra time? I would argue not. One size does not fit all. Sometimes it is appropriate but sometimes not. I hate this type of article, claiming their way should be adopted by everyone all the time. Context is everything!

<comment><USER7> I have found that small teams in small companies are more vulnerable to critical failures personally. That doesn't mean that the TDD mantra needs to be followed word for word but covering your core functionality with test cases allows you to manage risk and getting another set of eyes on the problem tends to pick up obvious problems you are blinkered to. It also enables large changes to take place effectively whic is a big problem when you have very few people working on a project. Without coverage you end up with something people are afraid to change which means every fix is snowballing it into a muddy mess because the shortest path is taken, not the most architecturally sound solution.

While defects happen, it's massively more expensive to handle them with the end user even if they are in the same office. You're costing their time as well as yours.

I'm middle of the road but I'd rather sleep easy knowing my ass is covered at least.

This experience comes from watching a company fail miserably due to their internal software failing. It cost a rewrite in the end which the company couldn't foot the bill for so spiralled into decline. Massive cock up and bad failure mode but a real one I'm afraid.

</comment></comment><comment><USER8> Not buying the dogma.

OK, having tests and code reviews sure, but spec-first has generally beat test-first in my experience.

Not "design the whole thing waterfall-style" specs, but actually just a wide ranging discussion on what the thing is more or less supposed to do. Why? Because it's not just you! The way it works is about your team, and the business and the context of that code. And 5 bazillion test cases aren't actually the best way to communicate this to all the stake-holders involved.

<comment><USER9> The best way to define a spec in the most unambiguous way is actually writing tests.

<comment><USER10> I disagree. Consider this counter-example, "This function takes a float64 'x' where 1.0d <= f <= 100000.0d and returns a float64 'y' which is the square root of 'x' to within 10ulp."

Tests can verify that the implementation with certain inputs is correct. If done incorrectly they can even over-specify the spec, like asserting that sqrt(16.0d) exactly equals 4.0d when it should also allow 4.000000000000001

But I don't see how they are less ambiguous or why they are better.

(As a real-world example, look to the Pentium FDIV bug.)

<comment><USER11> Tests are _formal_. Which means there's a lot less room for ambiguity, and that you can check an implementation for nearly zero-cost.

I'm sure you can guess what the following function does by only looking at the following (incomplete) test suite:

assertEquals([], f([], []));

assertEquals([1,2,3,4], f([1,2,3,4], []));

assertEquals([1,2,3,4,5,6,7,8], f([1,2,3,4], [5,6,7,8]));

assertEquals([1,2,3,4,5,6,7,8], f([1,3,5,7], [2,4,6,8]));

assertEquals([1,2,3,4,5], f([1,2,3,5], [4]));

... now, imagine the same test suite, but with the name 'f' replaced with 'mergeSortedLists'.

By the way, I don't get how your example actually proves your point: you're basically saying that tests "done incorrectly" could be harmful. So what?

<comment><USER10> It appears that your f is:

      def f(x, y):
        return sorted(x+y)

However, it could also be the more memory efficient in-place version:

      def f(x, y):
        x.extend(y)
        x.sort()
        return x

It could even be:

      def f(x, y):
        return list(set(x).union(y))

... and it turns out I was wrong. It's:

      import heapq
      def f(x, y):
        return list(heapq.merge(x, y))

I only figured that out when I read the name "mergeSortedLists". It's the text description which clued me in to what it was supposed to be, not the test cases.

I'm saying that test cases only verify specific data points. They don't define what happens across the entire range of inputs. I'm sure you _can 't_ guess what the following tests verify:

      assertEquals(f(1), 1)
      assertEquals(f(2), 2)
      assertEquals(f(3), 3)
      assertEquals(f(4), 4)
      assertEquals(f(5), 5)
      assertEquals(f(6), 6)
      assertEquals(f(7), 7)
      assertEquals(f(8), 8)
      assertEquals(f(9), 9)
      assertEquals(f(10), 10)
      assertEquals(f(11), 11)
      assertEquals(f(12), 12)
      assertEquals(f(13), 14)

Now replace this exemplar-based specification with "f(i) returns the i^th 11-smooth number: numbers whose prime divisors are all <= 11; i>= 1".

What test suite gives a better definition of what f is supposed to do than the one-line text-based specification?

(The OEIS says those tests could also be the divisors of 27720, the "Paradigm Shift Sequence for a (-4,5) production scheme with replacement", "Numbers all of whose prime factors are palindromes", or even the positive "Numbers in decimal representation, such that in German their digits are in alphabetic order", and more.)

</comment></comment></comment></comment></comment><comment><USER12> I'd like better stats on why you should write tests first. You can't test everything anyway and writing all your tests first eats up time when your architecture and code is still in a high state of flux because you have to keep refactoring your tests.

I've worked on TDD projects before that had huge numbers of tests for the smallest pieces of behaviour and refactoring them can be such a hassle you sometimes avoid it (but to be fair you knew when you broke something). The cost of writing some tests sometimes isn't worth it either when you weigh up how likely those tests are to catch a bug that wouldn't be caught by an integration test or during normal QA and the impact of that bug.

Strong typing to cut down on writing tests is also much more preferable to me when it's an option.

<comment><USER13> I've found TDD to be useful when you're implementing an interface outside your control, so the interface you test against is fixed and so are its semantics. This basically means that the only thing in flux is the internal implementation, and it's easy coming up with a fairly complete set of tests beforehand.

In other cases I pretty much write my tests more or less randomly before, at the same time, or after the implementation.

<comment><USER12> > In other cases I pretty much write my tests more or less randomly before, at > the same time, or after the implementation.

Similar most of the time. Once I know the interfaces have settled down and the problem you're solving is now well understood it feels like a better time to write tests. Once you have a feel for which parts are most error-prone as well you can concentrate on tests which have the most benefit.

</comment></comment></comment><comment><USER14> Of course catching bugs early is much, much better and well executed code reviews and TDD are the way to go.

But what do you do if your team struggles to get the basics right? When asking them to write tests results in doubling the code base with trivial module tests finding no bugs and only preventing the all too necessary refactoring? Slowing the team down so much it has to be scaled up? What if the software is not intended to live long?

What if manual tests are the fastest and most reliable way to establish feedback?

<comment><USER15> Sure if you run manual tests once they might be faster than test implementation, but having an automated test suite protects against regression. Having to do a full manual test for every change is going to consume a lot of time.

</comment></comment><comment><USER16> "According to the IBM System Sciences Institute, fixing a production bug costs 100x more than fixing a bug at design time, and over 15x more than fixing a bug at implementation time"

For most common software bugs, a design-time fix would imply a significantly heavier, verification based design and specification process. Comparing this cost to implementation/production bug fixes doesn't seem straightforward.

<comment><USER17> Unfortunately there seems to be no reference to the study and how it got to its conclusion. I know in the embedded world, that factor can be a lot higher, in the web world, it can be a lot lower.

Also this article multiplies a number of stats together, but It doesn't look to me that the stats referenced are super solid. In fact it seems the stats are all over the place trying to measure the benefit of TDD and live in the realm of "That's really interesting, further research needed"

<comment><USER16> Googling more, the same vaguely sourced "IBM System Sciences" figure seems to be passed on from one poorly researched web post to another. The trail went cold but it seems to date back to the mainframe IBM of the 1970's or 1980's. Certainly it's from a different software engineering culture than today's continuous delivery processes.

A promising looking current review of the question is here: [https://link.springer.com/article/10.1007/s10664-016-9469-x](https://link.springer.com/article/10.1007/s10664-016-9469-x) (PDF link: [https://arxiv.org/pdf/1609.04886.pdf](https://arxiv.org/pdf/1609.04886.pdf))

They conclude: "We checked for traces of this effect in 171 projects from the period 2006–2014. That data held no trace of the delayed issue effect. To the best of our knowledge, this paper is the largest study of this effect yet performed." ... "Our results beg the question: why does the delayed issue effect persist as a truism in software engineering literature? No doubt the original evidence was compelling at the time, but much has changed in the realm of software development in the subsequent 40 years."

</comment></comment></comment><comment><USER18> I've seen productivity gains from unit testing and no gains when adding TDD to a process and team already invested in unit testing. Anecdotally, in my experience TDD crystallizes sub-optimal implementations early on, especially for junior developers. Unit testing allows fearless refactoring but TDD makes developers less likely to refactor in the early stages where it's most beneficial.

Gains from code reviews are hard to quantify because people code differently when they know they are being code reviewed. Most of the gains come from simply announcing that code will be formally peer reviewed.

Critical bugs can cost 100x to fix since the out of band release costs can be so high. Non-critical bugs just get added to the next sprint and the extra cost is in the support costs, if any.

</comment><comment><USER19> Lack of understanding of the business model produce bugs that are much more costly to fix, and TDD cannot catch those.

TDD has a place, and finding bugs in production can range from annoying to flat out dangerous depending on the system, but the primary reason for failed IT projects is not bugs, but lack of soft skills, lack of proper business communication. Check [https://www.cio.com/article/3211485/project- management/why-i...](https://www.cio.com/article/3211485/project- management/why-it-projects-still-fail.html) and see the root of the problems, and notice that the proposed solution does not point to solve the root problems, instead they keep tooting dogmas

</comment><comment><USER20> I don't understand why people keep on painting it black or white, like either you use TDD or no tests at all? You can implement a feature and then write a test afterwards to test if it works as planned. It'll work just as good as TDD. IMHO the main benefit of tests is when refactoring at a later time, while during the initial prototyping and developing process they're usually just telling you the obvious (you didn't return the expected value... yeah, I know, I didn't finish the freakin' method yet, give me a break..)

<comment><USER10> Because if you are for a certain approach then it's easier to put all alternatives in the same category, then pick one as the antithesis, show that your approach is better, and conclude that everything which isn't your approach is worse.

You'll see that it's mostly TDD people who treat things as either "test first" or "test last", where "test last" occurs after _all_ development.

As another example, agile people say there's "agile" and "waterfall", even though there are many software development approaches other than those two.

<comment><USER21> Or, in other words, those people are shooting for political dominance and don't care about truth.

I am quite sure it is an inconscient bias, but it's tiring to keep listening those dishonest arguments everywhere.

</comment></comment></comment><comment><USER22> Assuming the bug is just a logical one, if the time to fix it in production is 15 hours then there is a serious problem with your team's release workflow. He estimates 1 hour to fix it while developing so that leaves 14 hours of code review, building, and deploying. If it takes you an hour to find/fix the bug then I would assume it would take 30-60 minutes for people to review and OK the fix (if it's an urgent bug then this shouldn't even take that long). Once it's merged, if it takes longer than an hour to build/deploy the code then I'm really sorry for you. Maybe I've just been lucky to have worked on teams where CI/CD was very important.

</comment><comment><USER23> Really liking and pushing for trialing of ATDD in my current role - <USER2> Test Driven Design:

[https://en.wikipedia.org/wiki/Acceptance_test%E2%80%93driven...](https://en.wikipedia.org/wiki/Acceptance_test%E2%80%93driven_development)

</comment><comment><USER24> [https://news.ycombinator.com/item?id=3033446](https://news.ycombinator.com/item?id=3033446)

</comment><comment><USER25> Untested code.. even if you're writing a kernel, you've got to find a way to mock/stub/double/fake your way into unit testing, smoke testing and integration testing. Cucumber isn't a requirement, but having appropriate layers of assuring production code is correct is fundamental to sustainable software engineering.

</comment><comment><USER26> Using something like [https://flow.org](https://flow.org) goes a long way too.</comment>


Conference Error in Your Favor Collect $225 - <AUTHOR> http://madisonruby.org/posts/2011-07-25-Conference-Error-in-Your-Favor-Collect-225

<comment><USER2> Kudos to the organizers for being selfless, but I actually think it's okay to recoup some money for the countless hours and unexpected $$ you WILL put into things at the last minute.

In other words, this might be a huge hit for everyone except the burnt out organizers. Good luck!

<comment><AUTHOR> We did do our homework and took inspiration from your blog post about putting on, either Future Ruby or Ruby Fringe, I forget which at the moment. I appreciate your concern and pointing out that conference organization is often a thankless task. We've been working on the conference for better than a year and continue to learn lessons that can only be learned in the first year.

This is not a decision we made lightly or without any contingency.

</comment></comment><comment><USER3> We are doing the same thing for ErlangCamp. We realized we could lower the price point, so we did, as well as retroactively lowered it for those who already had ordered.

</comment><comment><USER4> Don't know how widespread this sort of approach is, but I applaud it!

<comment><AUTHOR> It's just as fine of a line that you have to walk with a product. We had more we wanted to do but, do we _need_ more? At the end of the day we, as a conference, _need_ to get people together to talk and spread information.

Also, it's just the right thing to do.

<comment><USER5> I wholeheartedly applaud this. It makes the "student discount" less necessary too.

I think this will help me get a few more people to show up, too.

<comment><USER6> Student discounts are always necessary. I will definitely miss being able to ask for this, as even a small amount matters to students just starting to break into tech.

</comment></comment></comment></comment><comment><USER7> The MathsJam event in November is £165 (pounds sterling) with a 10% discount for early-bird (before August 15) and 10% discount for the unwaged. That covers lunch on Saturday and Sunday, dinner, accommodation, breakfast, tea, coffee, biscuits, squash, and all sessions.

Just thought I'd mention it in case anyone is interested. November 12 and 13. <http://www.mathsjam.com>

Numbers are limited, we have 50 rooms (of 100) already reserved, and 32 paid for already.

ADDED IN EDIT: Wow - a downvote. Do people think this is inappropriate for HN? It's in a submission about conferences, and pricing thereof, and I thought people might be interested in another data point. Not least, I thought people on HN might actually be interested in the event.

If I'm wrong I'll happily delete the comment, but I'd love to hear your reasons, rather than just getting a drive-by downvote.

<comment><USER8> I believe a link to a related event would be borderline appropriate here.

Your comment is an annoying, longfrom ad for a conference: 1) in a difference place 2) on a different topic

If you delete this spam and make a new submission on this topic, there'd be no reason for me or other HNers to object.

<comment><USER7> Your comment came too late for me to delete this, but I have now submitted a new item, along with a commentary as to why I made my comment here.

<http://news.ycombinator.com/item?id=2806370>

<comment><USER7> Bother - correction - <http://news.ycombinator.com/item?id=2806709></comment></comment></comment></comment>


"We must consider the possibility that the book may not be around much longer" - <AUTHOR> http://www.thenewatlantis.com/publications/people-of-the-screen

<comment><USER2> I like that the article uses a word I thought I coined (but probably read somewhere) - "techno-utopian."</comment>


Object-Oriented Programming – The Trillion Dollar Disaster - <AUTHOR> https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster--92a4b666c7c7 <comment><USER2> >OOP is considered by many to be the crown jewel of computer science. The ultimate solution to code organization. The end to all our problems. The only true way to write our programs. Bestowed upon us by the one true God of programming himself…

I've litteraly never met any one praising OOP like this. Even if the intent of this introduction is to overly to make a point, I find it flawed.

> OOP attempts to model everything as a hierarchy of objects I never heard of > anyone trying to use a hierarchy where it wasn't adapted

> The real world has no methods The real world needs to be modeled into > something that can be computed by our human Mathematics. That's the whole > point of modeling.

I'm waiting for the 'Functionnal Programming is wrong, let's go back to coding everyting in asm' post in 10 to 20 years

</comment><comment><USER3> "Those who do not learn history are condemned to repeat it".

I came up writing code in BAL, COBOL, PL/1 and a bunch of other non-OOP languages, and those who think procedural programming is better have probably never done it. The starting point for OOP, at least for me, was the splendid book "Reliable Software through Composite Design" by Glenford Myers, which was the first to study coupling, cohesion and other techniques that lead directly to OOP. This book still maintains a position of honor on my shelf, and I strongly recommend it for anyone doing software development. (You can get a pdf from [https://archive.org/details/reliablesoftware00myer](https://archive.org/details/reliablesoftware00myer) or buy your own hard-copy at [https://www.amazon.com/Reliable-software- through-composite-d...](https://www.amazon.com/Reliable-software-through- composite-design/dp/0884052842)).

Now, crappy programmers can write crappy code in any language, just as good programmers can write good code in any language -- the prevalance of crappy code speaks more to the numbers of crappy programmers than crappy languages. I would suggest that OOP enables crappy programmers to write code simply because without OOP crappy programmers wouldn't be able to write any code at all.

When functional programming is able to provide performance on a par with non- functional programming, we can talk about it. Until then it is a curiosity, but not ready for prime-time.

To paraphrase Winston Churchill's comments on democracy: "OOP is the worst programming paradigm ever invented -- except for all the other ones".

<comment><USER4> Doesn't functional programming already provide performance on par with non- functional programming?

</comment></comment><comment><USER5> Yes,I get the criticism against OOP. I kinda don't understand how FP solves the problem of shared mutable state... Or what alternatives there are for myraid design patterns.

I coded in Scala for <1 yr. Loved its syntax and code cleanliness. Not sure if I can do everything OOP does with pure FP, however.

<comment><AUTHOR> FP helps to avoid the mutable part of "shared mutable state" or at least reduces it to the minimum.

Another pattern is linear or affine type system like in Rust. They helps to avoid the shared part while keeping things mutable with ownership tracking.

</comment></comment><comment><USER6> OP seems to have ignored 2 issues

1\. Objective-C enabled Apple's productisation

2\. C++ programmer usually mix C code as well

</comment><comment><USER7> Paywalled.

<comment><AUTHOR> From Norway I can access this without any payments from a private tab.</comment></comment>


Rethinking Visual Programming with Go - <AUTHOR> https://divan.dev/posts/visual_programming_go/ <comment><USER2> As someone who's heavily used Blueprints, I can tell you they really work. You have no need to write a single line of code to program the behaviour of an entire game including physics.

You do need C++ though if you're going to write stuff like A* pathfinding, complex scene setup like hex based 3D platforms. Again it's all doable in Blueprint and I'd often do it first in BP and then rewrite it in C++ for perf sakes.

So visual programming isn't broken and it works, and not necessarily at DSL level. The UX of the editor has to be fantastic though, for noobs as well as experts. That means good support for quickly producing nodes, finding existing code, refactoring support and Git support. You may think it's tedious but with habits and patterns, with a few key stroke I could program an entire component's behaviour in no time.

One thing that was magical is that with a heavy code base of visual nodes, the brain can find entire sections very quickly, a bit like that cave analogy in the article. You could group nodes with coloured rectangle etc. and the way they were laid out you'd have instant recollection of its internal workings. By seeing a vague layout of nodes I knew this was about joystick controller, player controller, shader, etc. It's a massive advantage and takes less strain on the brain to "READ" again the code. It makes code re-discovery so much easier. If I had some gnarly behaviour it would instantly show in the pattern of nodes as how they were laid out.

I'm convinced that if we had "as good" editor for web technologies, we could produce microservices and front-end code in the exact same fashion without writing a single line of code. It's just such a massive investment to _do it well_ I don't see it happen any time soon.

<comment><USER3> Here is one, but usually only for customers with enterprise pockets.

[https://www.outsystems.com/developers/](https://www.outsystems.com/developers/)

<comment><USER4> The "enterprise pockets" requirement usually ends up with (practically) nobody learning it themselves, nobody knowing about it, nobody knowing how to use it and nobody considering using it.

Any programming tool your average joe programmer cannot try for themselves in their own computer might as well not exists nowadays and at this point it'd only rely on how good the marketing drones of the development company are at convincing non-programmers of other companies that they should use that tool, which in turns means that the tool doesn't really have a need for actually being good, just give that feel to whoever makes the decision to get it.

<comment><USER3> As enterprise developer, there are plenty of ways to learn such tools, and make oneself tasty to many HR departments.

Just not the way many FOSS driven devs like to work, while not paying for the tools they use.

Big boys club has a very different kind of rules, and politics for that matter.

<comment><USER4> If a developer cannot use these tools themselves they wont know them, in turn they wont promote them to others, they wont propose them to companies, the companies wont need them and they wont seek developers with knowledge of those tools and as a result knowledge of those tools wont be "tasty" to many companies.

The only way to break this dependency loop is to convince non-developers (executives, etc) to use those tools but at that point the incentive shifts from making those tools good for use by developers to making those tools good in convincing non-developers to buy them.

The only "big buys club" i see working on here is one of people who couldn't learn something else.

You should already have seen this with Turbo Pascal and Delphi and how these products moved from cheap $50-$100 products even students could afford and focused providing a simple yet comprehensive package to grossly priced overbloated, hype-driven, bullet-point executive-presentation-friendly monsters with tons of bugs and an over-reliance on bundling 3rd party components. And how this sort of move made their products instead of being widely known and loved by developers to become relics that only stay alive because their owners are preying on those who at the past chose them (because they were good at the time) and cannot move off.

<comment><USER3> True I have seen it happen with Turbo Pacal/Delphi, but the biggest issue there was Borland almost going broke and continuous change of hands, which destroyed the trust on the product.

There aren't "toy" versions of Cisco, Oracle, DB2, SQL Server OLAP, Sitecore, AEM, LifeRay, WebSphere, SAP, Hybris, PTC, Aicas, Ricoh JVM, Gemalto M2M, ....

And yet there are plenty of projects available to work on with those stacks, including green field projects in companies adopting them.

<comment><USER4> Borland was going broke because they abandoned their core target market for chasing after the enterprise - and that was during a time before open source even got its name and developers expecting tools for free was a thing.

And have you seen the reputation these systems you mention have among developers (assuming they know about them, after all my original point was that the "enterprise pockets" requirements lead to obscurity - with the obvious exception of those that have been around for a very long time) and how clunky they are? Turbo Pascal and early Delphi never had the reputation that Oracle has nowadays.

And sure, you can find works with them but these systems are a minority and when they are used they are practically never chosen by developers themselves.

<comment><USER3> The reputation among FOSS devs sure.

I have been working in enterprise world since 1999, where most folks don't even know that HN exists.

They don't even think twice about buying something like Oracle.

<comment><USER4> I'm not sure i follow, you mean that only FOSS devs dislike stuff like Oracle's?

<comment><USER3> Mostly.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> > At least I've never seen properly conducted studies involving psychologists > or neuroscientists upon introducing yet another new fancy feature into a > programming language.

I studied Mechanical Engineering, but did my Master Thesis on "Evaluation of MicroPython as Application Layer Programming Language on CubeSats"* - way out of my depth.

I tried to find some prior work on how to chose programming languages for specific domains, and how to judge if a language is the right tool for a task - and there wasn't much.

I even tried to measure how "easy" a programming language is, in a hilariously misinformed user study. There were 8 people, I was measuring the time it took them to implement small snippets in Python vs. C. I had this one dataset with weird outliers, where a person who performed really well, just took forever for some of the tasks ... later one of the participants told me he texted during the study.

And although I felt really bad about my really bad study, I also felt like the avantgarde of the field^^

Anyway, if we can find someone to fund it, I'd like to see brain activity scans of programmers using different languages. We already know smartphone usage rewires our brains. I wanna see the brain of JavaScript developer compared to a Lisper, Rustacean, ... .

* conference paper: [https://www.researchgate.net/publication/319525786_Evaluatio...](https://www.researchgate.net/publication/319525786_Evaluation_of_MicroPython_as_Application_Layer_Programming_Language_on_CubeSats)

<comment><USER6> The Qorum people have been doing psychology-informed Programming Language Design for a while now.

[https://quorumlanguage.com/evidence.html](https://quorumlanguage.com/evidence.html)

<comment><USER5> That would have been great input for my thesis!

<comment><USER6> As someone who also completed a Master's thesis, I really hope that feeling goes away at some point.

<comment><USER5> Not if liked our topic and would like to do more work like that :)

</comment></comment></comment></comment></comment><comment><USER7> I like the distinction between spatial and temporal aspects of programming languages. I'm wondering if the author knows Lisp though, which helps translating between those two views of code in important ways (like Homoiconicity).

Also, when trying to understand code, we typically run a simulation of that code in our head. Since we have limited capacity doing so, having a simple flow with simple data is helpful. If we hit the limits of our internal code processing capabilities, we are switching to a different mode: Experimentation, supported by tools.

In non-interactive languages that typically is a 'unit' test or a sample app or a debugger.

In interactive languages it is the REPL. A REPL allows you to experiment with the mental models we acquired from reading the code. Confirming hypotheses by letting the machine run experiments, validating the outcome, deepening our understanding of the code.

This is where I see visualization being most useful. Show the data before our hypothesis, show the data after we've run the experiment (i.e. v'=f(v)). Not just the type of data.

That's where I'd like to see better tools. (One example of this I'm currently using is re-frame-10x, which shows data epoch oriented and has neat diffs of what changed when an event was processed (i.e. time has moved forward).

<comment><USER8> I find it baffling that Lisp is still written in text. It's pure AST, so it's easy visualize and manipulate it as a tree. Small trees (definitions of functions and data structures) are composed into big tree that forms application. Why not do all development work (reading/writing) on this tree directly? In my view the Lisp should be first candidate for visual programming.

Agreed, re-frame and its tooling is awesome. BTW is there any way to drop into REPL from context of event handler?

<comment><USER9> I don't understand your surprise. Text has many compatibility, readability, and uniformity advantages. How are you going to diff a tree? How are you going to make the display consistent across platforms & tools? How are you going to represent the details of the program?

In the end, you're still just projecting abstract objects onto a 2d plane, and text already does that in a maximally flexible way. Anything else is less.

</comment></comment></comment><comment><USER10> The author of this post is also the author of the fantastic "Visualizing Concurrency in Go" [1] article.

[1]: [https://divan.dev/posts/go_concurrency_visualize/](https://divan.dev/posts/go_concurrency_visualize/)

<comment><USER11> Thanks for sharing this. It is pretty intuitive and quite helpful for developers that are visual thinkers to see what go is "doing"

</comment></comment><comment><USER12> To get to the next level and scale of bigger programs, you need to leverage the tons of work information visualization researchers have done.

I always point people to Prof. Tamara Munzner's work[1][2] that allows you to skip over all the dead ends that people have tried over the decades and gives you a "thinking framework" on how to design visualizations.

[1] VIZBI 2011 Keynote: Visualization Principles [https://vimeo.com/26205288](https://vimeo.com/26205288)

[2] Visualization Analysis and Design (Book) [https://www.crcpress.com/Visualization-Analysis-and- Design/M...](https://www.crcpress.com/Visualization-Analysis-and- Design/Munzner/p/book/9781466508910)

<comment><USER13> Index of Munzner's scholarly work:

[https://www.semanticscholar.org/search?q=%22Tamara%20Munzner...](https://www.semanticscholar.org/search?q=%22Tamara%20Munzner%22&sort=relevance&fos=computer- science)

</comment></comment><comment><USER14> Visual programming have been quite successful in some constrained domains. The fundamental imitations is that visuals does not represent arbitrary levels of abstractions very well. The visual way to represent abstractions is symbols (e.g symbols on a map), but when you go a level deeper to create symbols representing other symbols, then you end up with text.

<comment><USER15> Yeah, I've tried a handful of visual programming tools in the 90s before I got fluent in a normal programming language. It seemed very easy to start with the first steps and it was motivating how all the possibilities seemed to be one click away. But in reality the fun stopped really quickly and getting further would require deep understanding of the tool, i.e. reading a lot of - incomplete - documentation.

Another tool, I forgot the name but it's used in certain parts of science, in particular it at least used to be in use at the LHC. It seemed quite complete but complex things would easily be difficult to see, at least in the short time I did something with it.

IMHO Borland Delphi is the furthest visual programming went so far. I never really understood why IDE developers didn't pursue that path any further. (I know there's still a Delphi but almost nobody uses it.)

<comment><USER9> It seems you understand why perfectly well: it's a lot of work to do for little actual benefit.

>Another tool, I forgot the name

I suspect you might be referring to labVIEW?

<comment><USER15> Yeah probably. Still this is something I think of, also wondering whether eventually programming might become commoditized by new tools. So the question was already asked by other commenters, maybe there's an argument on can make why this won't work.

Yes, I do. :)

</comment></comment></comment></comment><comment><USER16> This article seems to be mostly ignoring what's going on in the sidebars of a decent IDE: file explorers, outlines, type hierarchies, and so on. These are pretty decent ways of getting an overview and navigating a codebase.

There may be a way to do better, but it seems unlikely to be a bunch of abstract nodes and straight lines between them, whether in 2D or 3D.

</comment><comment><USER17> Interesting topic. I haven't gone as deep in this rabbit hole but I've also written "similar" tool that I've used as a visual help [1] when reading programs written by other people. It's been useful in understanding bottlenecks and weird code patterns / dependencies. I've even printed the graph sometimes and written down notes on the paper, drawing circles around logical groups, etc.

I ended up going with separate color for each type / package.

[1] Screenshot of a simple piece of code: [https://imgur.com/a/Pr9dkkd](https://imgur.com/a/Pr9dkkd)

<comment><USER18> Nice. I've been doing similar drawings a lot – on whiteboard, on paper, on tablet, a few times even drawing them to use as the argument in pull-request debates, because words weren't enough to show the point.

</comment></comment><comment><USER19> > _The brain handles them very differently on the lowest level, but what's > interesting is that we can use spatial representation to represent temporal > information and vice versa, and, actually, often do precisely that._

The author of this article would probably really enjoy diving into research regarding sign languages, which are by there very nature both spatial and temporal languages - in other words: _kinematic_ languages.

</comment><comment><USER20> I notice most of the article is written in straight text, rather than visually.

<comment><USER18> I got the pun, but that's actually interesting point. Natural text also has both spatial and temporal components: when you read fiction, some paragraphs describe the scene, the character, the relationships, and others – how they evolve, change and interact.

For this reason, I sometimes enjoy watching movie before I read the book it's based on – the movie (visualization) so much better and showing how things look like, while text is still superior in following the story, living development of characters and so on.

So in this article I used graphics a lot – and even more so in the original slides. I actually had to write WebGL programs to show that visual aspect. That's one of the things that frustrates me a lot – it's so hard to just visualize what you mean, without being professional animator or programming 3D scenes. I'd love it to be as simple as writing a post on social network.

Textual literacy is still orders of magnitude more accessible, cheaper and widespread.

</comment></comment><comment><USER21> But programming already has zoom levels. It's called abstraction.

<comment><USER22> Yeah, and similarly we don't need hot sauces when we eat out at noun, because there's already something hot available: the sun.

<comment><USER23> Did you mean 'noon' or I missed the joke?

<comment><USER24> You're likely correct, though there have been restaurants named "Noun" in the world. (Mostly closed, but one still open in Cannes.)

</comment></comment></comment></comment><comment><USER25> Outstanding post. Author might find it interesting to partner up with game designers on visually representing massive amount of data for quick grok by the masses.

<comment><USER18> Thanks! Yep, you're reading my mind - I'll definitely need gamedev experienced brains to move this forward)

</comment></comment><comment><USER26> i don't think visual representation of structure is actually the hard part. Logic and computation seems to me is the only difficul part. We're still writing cooking recipes the same way , using lines of text, even if the ingredients are extremely easily represented with images or icons.

<comment><USER18> Fair point. I don't see how to outperform text in expressing logic and computation visually either.

The problem here is a scale – what works for cookie recipes, doesn't work for "recipe" on how to build a Boeing plane, for example.

<comment><USER26> absolutely. It seems that inevitably you'll have to abstract a pack of computation under a single concept representing what the computation is globally about.

hence the general focus on isolation , interface and composability.

Once you've abstracted a set of computation under a good concept , you should be able to understand it using just a name.

</comment></comment></comment><comment><USER27> I think the cave and torch metaphor is underselling me on my editor's ability to have split windows.

<comment><USER13> Split windows, plus regex pattern search of a set of files themselves selected by pattern, together well satisfy my own code abstraction needs.

Examples of the latter are Emacs' 'multi-occur', and Unix command line pipelines of the form:

      locate -0 /\*descriptive_substring\*.go |
        xargs -0 grep -E 'regex'

</comment></comment><comment><USER28> DRAKON flew and landed Buran. I wouldn't count it as failure.</comment>


How to fill holes in my knowledge? - <AUTHOR> Hi everyone. I am 27 years old, I finished my IT studies 2 years ago, since then I spent a bit time working as an Android developer, then I worked at a small startup basically as IT generalist (databases, C#, MSSQL, Oracle, etc). Then I left that and started working as a freelance Android dev.
I realized that I have big holes in my knowledge of Android programming. I worked on 2 (simpler) projects as a freelancer and projects I did work fine, but I am not satisfied with them. I am sure that you all know that the point of programming is not only to make the code that works.
I can make things work, but I feel like they are not meant to be made like that. Basically I am a Googler. Meaning that holes I have in my knowledge I manage to fill by using general programming knowledge in combination with a lot of googling.
I never had formal Android programming education. I learned JAVA at University and I have no idea how I ended up with Android, but I like it. And now I would like to fill those holes. I stared with intermediate course on Udacity (it is a bit outdated, but it's fine), I think about checking TreeHouse, Coursera doesn't have courses I am interested soon. And when I listen to Intermediate course basically I don't know one segment, then I know the next one, then I don't know the third, and so on.
So I was wondering what approach would you recommend me? How can I better myself?
Thank you. <comment><USER2> I can totally understand what you are trying to say because I am more or less in the same boat. But let me tell you that there is no one answer to this problem, you will get mixed opinions and thirdly, don't over-stress yourself because you would never be able to know everything about Android.

I taught myself Java during Uni, then learnt Android and have a CS masters with around 2-3 years of professional experience but I do feel those holes. I am not good with memory so I also keep forgetting important conceptual things specially when I am preparing for any interview. I also understand that it's difficult to revise and review 'the basics' and 'fundamentals' while you have your full-day job but somehow it's necessary. I recently worked for 6 months in a startup where we were only 2 Android devs. The other guy was very experienced with 5+ years and he helped me a lot in grasping some key concepts in Android. So, if an experienced person is reviewing your code, you will improve a lot. Then try to read a lot of other's code specially the best projects which are available open-source. When I used to explore that Android project code written by that guy, I felt like this dude is a Pro and I would never be able to use this stuff in this way because I just didn't know about it. So, you realise this missing blocks in your knowledge factory and you won't know until you experience.

Try to befriend and work with experts because best way to become smart is to work with smart people. I will also start the Android Intermediate course on Coursera so that I can improve my basics and learn things properly with depth. I follow Android news, you come to know about new libraries, famous bugs etc. which again helps you in filling those holes.

Best of luck to both of us !

<comment><AUTHOR> Thank you for your response, a bit of a problem is that I work alone. As a freelancer. I didn't have an opportunity to work with someone who knows what he/she is doing. Sometimes when I find some nice code online, I try to grasp concepts that they are using and that seem logical. I could probably find a job at a company in my country, and have an opportunity to work with someone experienced. But the difference in the money I would make it would be so big it's crazy.

</comment></comment><comment> amar-singh Hi,

I am an MBA graduate and having 2+ yrs experience in marketing. when I started my job career I had only theoritical knowledge of marketing but with more experience I got to know a lot of things about marketing.

In my point of view sometimes your experience increases your knowledge to fill holes and sometimes if you read more bookes as per your interest area then you can fill holes....Yes, if we spend our whole life then also we can't say that we have full knowledge cause learning never ends...

</comment><comment><USER3> Try to write an app that you know you will have trouble with, and make notes as you learn along the way.</comment>


Analyse Asia 34: The Rise of China Smartphone Makers with Bryan Ma - <AUTHOR> http://analyse.asia/2015/05/31/episode-34-the-rise-of-china-smartphone-makers-with-bryan-ma-idc/ <comment><AUTHOR> Synopsis: We interview Bryan Ma, Vice President for IDC's Asia Pacific client devices research group to have an insightful discussion on three interesting topics: (a) the rise of the chinese smartphone makers and where they are heading with a short discussion on why Xiaomi is adapting their strategy to overseas markets, (b) the tablets and PC market in Asia with specific mention of Microsoft making headways in capturing the tablets market with their surface pro, and (c) the wearables market in Asia for both consumers and enterprise sectors.</comment>


How U.S. Drone Regulations Stack Up Against the World - <AUTHOR> https://dronelife.com/2018/06/11/how-u-s-drone-regulations-stack-up-against-the-world/ <comment><USER2> Small drone regs should get pushed back to the states.

Away from airports

under 500 ft.

under so much weight

Everything else should be pushed back to the states</comment>


Ask HN: Why can't we talk to each other here? - <AUTHOR> Someone made a comment on one of mine quite a while ago, and I feel I have some information that could make their life easier as a result... yet I am unable to do anything to help them because of the time limit.
I know it takes time and money to develop, but I also know its not very hard, and there are plenty of fanboys who will do it for you (me). So can we have some kind of PM functionality?
There is someone out there who is not as informed as they could be imo. Let me help them please... or perhaps I am less informed and they will help me even more than I could have imagined. :)
HN is clearly a community. I'd love to see it furnished with the tools to help it maximise its potential. <comment><USER2> HN could use a lot of features that would improve its functionality.

I think one of the reasons it's not quit so actively developed is the philosophy behind the project which has a lot to do with PG. He thinks people care about content, not features.

Another reason is that it's written in arc. It's hard to find lisp hackers, let alone arc hackers: [http://arclanguage.org/forum](http://arclanguage.org/forum)

<comment><USER3> Hard to believe with the amount of emacs users on here.

<comment><USER4> If I'm any example, I think there are many many emacs users who are not very experienced in and certainly not proficient in LISP-like languages.

I know the basics of lisp syntax but have never coded anything substantial in it. A few helper functions here and there maybe. And I've used emacs for decades.

</comment></comment></comment><comment><USER5> "Someone made a comment on one of mine quite a while ago, and I feel I have some information that could make their life easier as a result... yet I am unable to do anything to help them because of the time limit."

Just do what I do: click on their name, find a recent comment of theirs, and reply with a message to contact you via your profile email (or whatever) for a solution to previous problem. It's how I got a hold of at least one person here in same circumstance. A few others are on list when I get time for their more difficult areas of expertise.

<comment><USER6> The problem with that is that unless it is a recent comment of theirs, then they probably won't see it as there is no notification system in place.

<comment><USER5> I thought the recent part would be obvious. Thanks for showing it wasn't. I've edited my comment to say "recent" to be clear it has to be a comment they're likely to be looking at periodically for replies or other activity.

<comment><USER6> Since you've made it clear it must be a recent comment, by qualifying your statement with the token "recent", I would agree that this is a worthy solution.

</comment></comment></comment></comment><comment><USER7> I think leaving contact information on profiles is enough.

<comment><USER8> IMHO if someone hasn't added his contact information in their profile it would be safe to assume that they don't want to be contacted.

</comment></comment><comment><USER9> When I worked on HN we actually talked about this and specifically decided against it.

Currently, everything on HN is public, except for password (hashes), emails, and who [voted for|flagged|vouched] what. If all HN user data leaked right now, it would be a bummer, but not very scandalous.

We didn't want to be trusted with private communication. We're not perfect, and it's easier not to leak data you don't have =P

</comment><comment><USER4> HN is not a social network. If people who post here want to be contacted out- of-band, they can put their preferences in their profile.

</comment><comment><USER10> This could do a lot more harm than good: spambots, or even worse, recruiters.

Not saying it couldn't be done right, but it might be involved and go against the HN minimalist philosphy.

<comment><USER11> A "pm" could be implemented as a comment that only the recipient could see. It wouldn't necessarily require changes to the UI, maybe just another "private" comment state alongside "public" and the various "dead" states.

Although without a notification system (which would require changes to the UI) it would also probably be useless. Even without notifications, a link similar to the current "saved" link could lead to a list of pm comments.

</comment></comment><comment><USER12> As others have mentioned, clicking through to their profile and using any contact details they've left is the best bet for this. If there's no information there, they probably don't want to be contacted. But if you're someone who does want to be contacted, there are tools you can use to make sure you don't miss anything here:

* HN Alerts will send you an email whenever someone replies to one of your comments: [http://www.hnreplies.com](http://www.hnreplies.com)

* HN Watcher, monitors HN posts for keywords, or you can follow certain users & have their comments & submissions emailed to you: [http://hnwatcher.com/](http://hnwatcher.com/)

I don't want yet another inbox I have to check (ie HN private messages!), but listing contact details in my profile & having alerts sent to my email has been really useful to me.

</comment><comment><USER13> I don't mind being contacted directly, so I put an email in my profile. On rare occasions people have emailed me. That seems to work

</comment><comment><USER14> I prefer how HN makes it so that if you really want to contact them badly enough, you can figure out how to.</comment>


Coelacanth: Lessons from Doom (2010) - <AUTHOR> http://vectorpoem.com/news/?p=74 <comment><USER2> To get an idea of this madness, it can help to look at some relevant footage.

Speedrun of Dead Simple from Doom 2: [http://www.youtube.com/watch?v=dfijpjvS9Q8&feature=player_de...](http://www.youtube.com/watch?v=dfijpjvS9Q8&feature=player_detailpage#t=326)

Quake Done Quick: [http://www.youtube.com/watch?v=VpiNDxssUL0](http://www.youtube.com/watch?v=VpiNDxssUL0)

~

That sort of manic movement is, I think, what really sets apart the elite FPS players of the Doom, Quake, and UT era (and the games in the same vein) from folks in the CoD/Halo games.

Also, the level design is pretty much strictly better, because it mattered a lot more. With regenerating health and lots of ammo/easy pickups, you no longer have to be quite so careful when putting together a level, because you know that if the give the player X seconds of time without suffering everything will be okay.

<comment><USER3> > That sort of manic movement is, I think, what really sets apart the elite > FPS players of the Doom, Quake, and UT era

In those days, my friends and I used to get into UT quite a lot. Most of the more experienced UT players I watched would use the double-tap of the left/right arrow button to trigger the short sideways leap as a means of rounding a corner (for a better chance of surprising an enemy), or to make it harder for an enemy to keep a bead on them when they were being fired on. I was always surprised at how - to me at least - this simple mechanic made such a difference to how dynamic the combat felt.

</comment></comment><comment><USER4>
      > Doom is about "maneuverability as defense"
      > ...
      > There's nothing quite like it today.

There's one game i'm aware of: [http://en.wikipedia.org/wiki/Painkiller_(video_game)](http://en.wikipedia.org/wiki/Painkiller_\(video_game\))

By default it also moves fairly slowly, but the player is strongly encouraged and almost forced to use bunny-hopping to gain extreme agility and speed. Most youtube LPs showcase this quite well. "Asylum" and "Snowy Bridge" are imo the highpoint levels to watch for this.

<comment><USER5> The Serious Sam games fit the DooM tradition, as well.

<comment><USER6> There is a critical gap between the sensibilities of Doom/Quake/Duke and Painkiller/Serious Sam: level flow. The latter camp is in varying degrees a series of rooms you get locked into as enemies spawn in waves. The former involves navigating a highly varied environment as you attract the attention of pre-existing enemies.

Sure, on the avatar scale, they play at a similar level. The environments are what really set the earlier generation apart, and in that respect very little approaches that sort of design.

<comment><USER4> Painkiller sometimes does that, but other times it gives you levels like Docks, where as much vertical traversal is expected as horizontal: [https://www.youtube.com/watch?v=5-0yJ2V41Jk](https://www.youtube.com/watch?v=5-0yJ2V41Jk)

<comment><USER6> I'll happily agree that Painkiller has some more variation then SS, but on the whole it's much more focused with wave-based arenas. This isn't a knock against Painkiller at all, it's a favorite of mine - yet it's still a bit inaccurate to regard it as classical level design.

<comment><USER4> Yeah, you're right. I went and watched the entire video and while they hide it well by having really big arenas, it's still just kill rooms.

</comment></comment></comment></comment></comment></comment><comment><USER7> Interesting article. I played with making Doom levels back in the day and it wasn't exactly easy. The tools (DEU, DETH, etc.) were generally clunky DOS apps that resembled very simplified CAD programs. Documentation was non- existent or spotty at best, so you really had to spend a lot of time figuring out how to do simple things. It would easily take you months to ramp up and start building levels that were more complex than two rooms with a door (and even that was pretty complex to figure out the right line defs, sectors, actions, etc. to just make a door work!). This was before the web took off so you couldn't just Google for a Stackoverflow answer when you got stuck!

Duke Nukem 3D and the Build engine were pretty interesting for level creation. The game engine included the editor so you could actually drop into a mode where you walk through the level and directly modify textures, floor/ceiling height, etc. Was a very cool experience at the time.

<comment><USER8> That was part of the point: back then things weren't supposed to be easy nor documented and investing months to really learn how the intricate details of a Doom map worked paid off in giving us years of fun creating our own levels and episodes.

<comment><USER9> Oh come on. I think they just weren't user friendly tools. I doubt they developed them with the intention of being obtuse.

</comment></comment></comment><comment><USER10> I just finished reading David Kushner's Masters of Doom, which tells the story of DOOM development, as well as the id software story around it. It was well- written and thoroughly researched story, should be a good read for many in here.

<comment><USER11> Fair warning though, if you don't want to see the dark side of your heroes maybe skip it. Because the book is very thourough and they did some morally questionable things. Repeatedly. I was horrified. I thought maybe some of it is not true but then no one sued for defamy.

<comment><USER12> I don't remember anything horrifying in it. It definitely shows that they are human with flaws, just like everyone else.

<comment><USER10> Well, there was a definite rocker component to their actions, something possibly not compatible with the idea of programming idol. At least the number of times breaking keyboards was mentioned was quite high ;).

<comment><USER13> > compatible with the idea of programming idol

I think I missed the meeting that established the criteria for a "programming idol" :P

The guys back in the old id were rockstars - plain and simple. They were trailblazing an entire new industry and setting a lot of firsts. Now that the gaming industry is more "mature", the major players are more relaxed, trying to show their artistic side, and no one's smashing keyboards or putting their coworker's bloody heads on sticks as easter eggs[0].

[0] - [http://doom.wikia.com/wiki/Romero's_head](http://doom.wikia.com/wiki/Romero's_head)

</comment></comment></comment></comment></comment><comment><USER14> What a great analysis. I'd like to see stuff like this on other games : what about shooters with instant-hit and slow physics where the player is still definitely NOT a tank (2-3 bullets from most guns will kill you), still capturing the same sense of gameplay-over-narrative and experience diversity -- _Counter-Strike_. In fact, I'd like to see an article like this on every archetypal shooter type. Goldeneye, Halo, System Shock, Counter-Strike... does anyone know of more game analysis like this?

</comment><comment><USER15> re: how mod-friendly Doom was, Portal 2's simplified level editor (released 2012, after this was written) was pretty well-done--only exposed a tiny fraction of the things one could do, of course, but enough to build real puzzles, and with just enough default visual interest that the product didn't necessarily look awful.

[http://theportalwiki.com/wiki/Puzzle_Creator](http://theportalwiki.com/wiki/Puzzle_Creator)

Of the user-made levels, it's surprising how many used the full level editor anyway--even though, as the post notes, building levels ain't quite as simple as it was in the Doom days. User-made level gallery:

[http://steamcommunity.com/workshop/browse?appid=620&browseso...](http://steamcommunity.com/workshop/browse?appid=620&browsesort=trend)

<comment><USER16> Not entirely surprising; there was already a gigantic Source modding community well before Portal 2.

</comment></comment><comment><USER17> Entirely off-topic, but that thread title sounds like the best metal album ever.

<comment><USER18> Not entirely off-topic; Doom had a pretty awesome, reasonably metal-ish soundtrack, by the standards of the day.

<comment><USER19> On the Smashing Pumpkins track 'where the boys fear to tread' they sampled the rocket launcher sound. I recognized it the minute I heard it first.

</comment></comment></comment><comment><USER20> Has anyone come across the Neo-Doom megawad?

There is one level with a Cathedral.... you walk in through the entrance to see a few dozen imps standing at pews, and there are a couple of Knights of Hell and a Baron on the front stage giving a sermon.

The mock up was pleasingly realistic, then I noticed that the crucifix on the front wall was inverted.

</comment><comment><USER21> Team Fortress Classic is similar. The levels were built for gameplay, not realism. A large modding community surrounded the game also.

</comment><comment><USER22> I was disappointed to learn that the article wasn't about a living fossil fish.

</comment><comment><USER23> [2010] but always nice to revisit

<comment><USER24> Not sure what you're implying.

<comment><USER25> It's helpful to have dates on things that aren't "news". If (for example) a doom-like game had become extremely popular in 2012, the [2010] tag would give readers more context so they know why it's not mentioned.</comment></comment></comment>


Try Going Facebook-Free in 2016. It's Amazing - <AUTHOR> https://medium.com/@karan/try-going-facebook-free-in-2016-it-s-amazing-103730bbb1f4 <comment><USER2> I teach high school, and in one of my classes a student ran an investigation where she asked for volunteers to abstain from using facebook for one week. It was a really interesting experience. Most of the adults I mentioned this to assumed that no high school student would even consider quitting social media.

She got about ten volunteers, and it was a positive experience for everyone involved. Not everyone quit fb altogether, but everyone became more intentional about their use and more self-aware of their use. People said things like, "I realized I was using my phone to hide from my peers in class. Now I'm talking to more people in real life, and I'm happier as well."

Every generation needs to learn how to manage its distractions. It's wonderful to see people thinking critically about their own use habits.

<comment><AUTHOR> I'm glad your students are proactive in controlling distractions. :)

</comment></comment><comment><USER3> is this what it has come to? we need 12 step programs to quick FB?</comment>


Should I Work for Free - <AUTHOR> http://www.shouldiworkforfree.com/

<comment><USER2> I half expected it to be a static site with the word NO in big, bold letters.

<comment><USER3> I really expected this as well. In my mind, there is never any justification. My time is worth the world to me, and so if you would like me to dedicate it to your task, that is going to cost you.

You never, EVER work for free. Not even for a charity. You invoice them. And you donate that invoice. And you get a receipt for your taxes. In this way, they can fully understand and appreciate the true value and real cost of the work you have provided for them. Everyone's book's are square. No one is left out in the cold.

When you work for free, you devalue the work that we all do. Many thousands of web devs still bitch about client's who won't pay or scoff at quotes, because "I've got a cousin who can do that." Then go get your fucking cousin, because my time has a tag attached.

Your time is worth something, and it shines in your quality. Believe in yourself.

<comment><USER4> If it's your mom then yes, you should do it for free.

</comment></comment></comment><comment><USER5> I did something for free for my aunt 20 years ago and the experience left us not talking since then. The answer is no.

<comment><USER6> Not prying, but maybe its time to offer an olive branch. Everybody changes, and the supply of Aunts is a diminishing graph.

</comment></comment><comment><USER7> The flow control of the chart is great and it lead me to the right point where I am now. I wish , I had this 2 years back.

</comment><comment><USER8> We're building an awesome tool for freelancers: Automated invoices for freelancers [http://www.recurvoice.com/](http://www.recurvoice.com/)

<comment><USER4> OT: Is this what HN spam looks like? Also, your jQuery is broken.

</comment></comment><comment><USER9> Here's my answer for this site:

[http://shouldireallyworkforfree.com](http://shouldireallyworkforfree.com)

enjoy ;)

</comment><comment><USER10> i'll simplify it for you. the answer is. no</comment>


Javascript community still most popular - <AUTHOR> http://geekli.st/communities

<comment><AUTHOR> I'm trying to understand why we were number 8 on the home page, Hackers absolutely were interested in the communities and news that Javascript was #1, and then we disappeared.?</comment>


60 Minutes: Bloom Box - <AUTHOR> http://mashable.com/2010/02/21/bloom-box/

<comment><AUTHOR> just for the record, i'd buy one... especially if they were only 3000 for a home.

i'd definitely buy one to power my remote house...</comment>


Ask HN: I want to learn about database, how should I start? - <AUTHOR>

I am a non-technical (sales). I'm interested in database and want to learn about it to enhance my network and system architecture knowledge.  I am looking for effective resources where I can study, website/ books/ e-books.  I appreciate any help that you can provide <comment><USER2> Mentioned above, but here are a number of places to start. Most of mine deal with statistical analysis, but the Data Science masters would be a good place to start.

[http://sqlfiddle.com/](http://sqlfiddle.com/) \- SQL Fiddle is an online SQL coding platform. Good place to play around.

[http://jhudatascience.org/](http://jhudatascience.org/) \- a ton of MOOC courses compiled in one spot.

[http://stats.stackexchange.com/](http://stats.stackexchange.com/) \- start browsing the forums and reading up on some of the database questions people have.

[http://janzilinsky.com/how-to-analyze-data/](http://janzilinsky.com/how-to- analyze-data/) \- great set of tutorials, etc.

[http://user2014.stat.ucla.edu/](http://user2014.stat.ucla.edu/) \- another place with a number of great tutorials in R.

</comment><comment><USER3> Introduction to Databases course:

[http://infolab.stanford.edu/~widom/cs145/](http://infolab.stanford.edu/~widom/cs145/) [http://www.amazon.com/dp/0321197844/?tag=stackoverfl08-20](http://www.amazon.com/dp/0321197844/?tag=stackoverfl08-20)

Install Sql Server 2008 Express for best .Net integration

[http://www.microsoft.com/en-us/server-cloud/products/sql- ser...](http://www.microsoft.com/en-us/server-cloud/products/sql-server- editions/sql-server-express.aspx)

or MySql if you're Linux-inclined

[http://www.mysql.com/](http://www.mysql.com/)

</comment><comment><USER4> Perhaps, this one will be useful [https://class.stanford.edu/courses/Engineering/db/2014_1/abo...](https://class.stanford.edu/courses/Engineering/db/2014_1/about)

</comment><comment><USER5> Install a database (or two or three) on your home computer. You can get free "Express" editions of Oracle and SQL Server, and of course MySQL and Postgres. Work your way through exercises in a book or two.

</comment><comment><AUTHOR> Thank you everyone!I guess I will start with DB @Standford and explore more when I secure my basic knowledge. fun stuff :)

</comment><comment><USER6> [https://www.coursera.org/course/db](https://www.coursera.org/course/db)

</comment><comment><USER7> [http://sql.learncodethehardway.org/](http://sql.learncodethehardway.org/)</comment>


Supply Chain Maps for Pandemic-Fighting Products - <AUTHOR> https://www.adb.org/multimedia/scf/#/ <comment><USER2> I'm checking out the list for final products in Spain, particularly for ventilators, and while Hersill is in the list Temel is not. Both of them have agreements with other local companies like Escribano and Power Electronics respectively to ramp up production, but there are many companies in that list that I have no clue what they do. And AFAIK those are the only two local companies that design and manufacture ventilators.</comment>


NC Startups Against Amendment 1 - <AUTHOR> http://www.startupsagainst1.com/

<comment><USER2> Our entry hasn't been added to the site yet, but here is the Fogbeam Labs position:

 _Fogbeam Labs believes that it is inappropriate for the State of North Carolina to institutionalize discrimination and bigotry against citizens of North Carolina, on grounds of sexual orientation. We also believe that it is not an appropriate role for the State to sanction, restrict, endorse, or otherwise regulate marriage, which is a private, personal commitment made between consenting adults. For these reasons, Fogbeam Labs opposes Amendment One and encourages all citizens of NC to vote "NO" on the Amendment._

<comment><AUTHOR> fogbeam is up there now :)

<comment><USER2> Mondo rad!

</comment></comment></comment><comment><USER3> I am a big supporter of more freedom, and am always in favor of laws which expand the freedoms of individuals, especially those who have historically been persecuted. This campaign does feel a bit contrived though, as a libertarian type who loves guns, hunting and many other things that shock the conscience of many in Silicon Valley this type of self selection out of a group happens everywhere.

I just wish those who support these types of campaigns could also see how they push away just as many people themselves in areas like Silicon Valley through their group think ideas of what's civilized and acceptable.</comment>


Career progress in big companies - <AUTHOR>

7 years in big software company in seattle, last promo 3.5 years ago, still not even senior. 99% friends I joined with are already senior. this feels like no career progress. earning 128k. am I being screwed or paid good money? should I stay or should I go? <comment><USER2> > Am I being screwed or paid good money?

To the Average Joe, your getting great money. The U.S. median household income is $51,939... [http://www.nytimes.com/2014/09/17/upshot/you-cant-feed-a- fam...](http://www.nytimes.com/2014/09/17/upshot/you-cant-feed-a-family-with- gdp.html?_r=0&abt=0002&abg=1)

> Should I stay or should I go?

Salary and title can be hollow benchmarks. Ultimately, you drive your career growth. It might be helpful to know where you want go. Are you looking for director level with larger management responsibilities? Or do you prefer to manage important projects as an individual contributor? Suggest developing a personal scorecard that indicates professional growth. Use that as a career road map.

</comment><comment><USER3> Career advancements in large companies can be rather arbitrary. Some of the worst programmers I've ever worked with were "Senior" or "Staff" level. From my experiences, people get promoted in large companies for a few reasons:

1 - Politics. This is the most obvious one. People in power share power with people they like because it helps them maintain control.

2 - Tenure. Some companies just auto-promote people after a certain period of time. These periods of times can be very long if the company has an older "business" view of tenure and promotions. This doesn't seem to be the case at your company though, given your friends.

3 - Business knowledge over programming skills. I've seen quite a few terrible programmers get elevated to higher positions simply because they had good knowledge of the project. Any time they were in their text editor they were probably doing a disservice to the code, but the companies really valued their domain expertise.

</comment><comment><USER4> money wise you are in pretty good position. 128k in Seattle is almost 140k in NYC and probably 150k in SF due to the tax difference. Career wise, it might be a good idea to pursue a conversation with your manager on how you can grow. What is it that you are not doing or you need to do that will make sure that you get a promotion in the next cycle.

</comment><comment><USER5> 128k a year... living in the US... and yet complaining...

I only wish I had my grass that green.

I think you are doing fine sir, just stop comparing yourself to others. If you are unhappy -- change jobs. But don't be a slave to other people opinions about how much money you should be making or your job. You'll always be unhappy that way.

</comment><comment><USER6> One of the big banks has instituted this policy recently of firing a certain percentage of the seniors-and-above every year till they get become small enough. Now, do you want to be senior in this firm? :-)

There is a way to ensure career progress even when you are denied career progress : keep doing stuff and talk about it. For example, write a paper. Or write blog posts of this level of quality : [http://aphyr.com/posts/294-call- me-maybe-cassandra/](http://aphyr.com/posts/294-call-me-maybe-cassandra/). Be good and be available. Then politics and denial of career progress at your current firm will become their problem, not yours.

</comment><comment><USER7> Have you tried asking your manager for a promotion? Be sure to state your case (don't say my friends are already senior). If not start looking internally for a higher position or apply to another company. Many large corporations are no longer loyal to their employees, so why should you?

</comment><comment><USER8> Well, either you are good and unrecognized, then you may indeed go and find (or make yourself) a better place, or it is that you are incompetent, but badly enough for the big company to bother firing you, and then your best interest is to stay.

<comment><USER9> Getting promos in large companies seems to include some amount of politics. I think I'm pretty competent at tech but not at politics. Not sure what OP (or myself) can do in these situations. My suspicion is that the politically astute do well everywhere - small and large companies.</comment></comment>


Ask HN: What's a good site to hire designers/artists? - <AUTHOR>

<comment><USER2> Depends what you want. [http://99designs.com](http://99designs.com) is good if you need a logo.</comment>


Machines Taught by Photos Learn a Sexist View of Women - <AUTHOR> https://www.wired.com/story/machines-taught-by-photos-learn-a-sexist-view-of-women <comment><USER2> ML, even when perfect, learns the world as it is, not as people want it to be. There's nothing inherently sexist about a machine noticing that the background of an image can be used to identify a class label, e.g. noticing that a mug is more likely to contain coffee than tea in a coffee shop, but given how shitty we have been to each other, some correlations are considered taboo. The only way for machines to learn our taboos is to explicitly teach them.

<comment><USER3> Have you read the article?

The problem is not that ML reproduces the bias that is present in the training set, it is that it amplifies it (a lot).

<comment><USER2> The article is garbage, but anyway.

If you see that an algorithm has issues with imbalanced classes, you could try to address that, or you could frame your problem as sexism, write a paper with _that_ in the headline and then call Wired.

And in any case, if you read the paper, they examine a single algorithm (Conditional Random Fields) on two datasets (which Wired extrapolates to the entire field), and their own solution is to add constraints saying that it should preserve the ratio of woman:man cooking as in the original dataset. And while there is no loss of accuracy, it also has no improvement, so it's just shifting the errors around. And it has absolutely no analysis of why a CRF would exhibit these properties anyway.

But this is kind of my point, even after you solve these issues that arise from class imbalance (which ML practitioners & researchers are highly motivated to solve these already because they lead to better average performance), you are still left with a bias that is taboo that society will say must be fixed, which cannot be fixed by simply more accurate ML or more accurate data.

</comment></comment></comment><comment><USER4> This is something I know very little about, but will machine learning evolve over time?

I mean imagine if this technology was being created before the civil war and it was fed images of slavery the assumptions it would make!

Our world and what is normalized changes over time, will machine learning reflect that?

The world I've experienced is different than the world a generation below me has experienced but if it's my generation feeding the machine the images what happens?

Images from my parents' generation would have shown women who didn't go to college unless it was for an MRS., nursing, or teaching. My Mom's only sport option was cheer leading. This is drastically different from my sister's life experience.

</comment><comment><USER5> There are really a few problems here that I think the article is getting a little mixed together, and I wanted to lay them out.

First, that the image corpuses used for machine learning have a strong gender bias, perhaps more than exists in the "real world." More images of men than women, more images of men working on computers, more images of women in kitchens, etc.

These images are sourced from [http://imsitu.org/](http://imsitu.org/) which is sourced from [http://image-net.org/](http://image-net.org/), which (after some digging) looks like it gets most of its images from Flickr, stock photography sites, and random corporate sites. Are these representations of the "real world"? I would argue not. Professional photography, stock photography, and photos taken for the purpose of being used in an unknown future context, and/or to appeal to the most people, tends to err on the side of being "universally applicable" and emphasizing the "common idea of a thing" rather than how the thing actually is, with all its variations. An image of a man in a kitchen be perceived as more controversial and may be less universally usable than an image of a woman in a kitchen. So if you want to take a photo with as many possible uses as possible, you'd tend to fall back on established social norms MORE often than they might actually occur.

Second, machine learning tends to emphasize small differences when it has nothing else to go on, or is improperly trained. If you have a dataset featuring people in kitchens where 75% of the time the person in a photo is a woman, you could get an algorithm that is 75% accurate simply by saying "the person in the photo is a woman" every single time. While the dataset reflects 75% women, the algorithm reflects 100% women. It emphasizes small differences in order to gain accuracy.

This isn't just hypothetical. Many times, I've worked on a categorization/labeling dataset that turns out to have no _actual_ underlying pattern, but I wind up, after many hours, getting a best fit algorithm that, say, predicts the dataset correctly 85.166667% of the time... only to realize that my dataset is spectacularly unbalanced and exactly (EXACTLY) 85.166667% of the dataset is in a single category. It's amazing how it just sort of snaps to that when you start layering the machine learning algorithms and you realize that the real problem is that there's no real pattern in the data (something data scientists don't often like to admit).

Third, sometimes the algorithms just get it wrong in ways that seem minor and rare from a data science perspective, but have large social consequences. Like improperly labeling a black couple as gorillas. It might actually be the case that the algorithm was improperly trained because it lacked photos of black people and photos of gorillas and didn't have much to go on (an example of the first issue) but I don't know enough about the situation to say for sure.

And fourth, of course, is that these patterns DO exist to some degree in the "real world," and this is a point that's been hammered on over and over again on Hacker News. The problem is that machine learning is a sort of big leveler that finds these patterns wherever it can and applies them universally (and often while emphasizing the differences for the reasons stated above). I mean, that's the point of it, after all! But knowing this fact, I think it makes sense to be careful where and how it's used.</comment>


InternMatch Raises $400K To Help Students Find The Perfect Internship - <AUTHOR> http://techcrunch.com/2011/02/02/internmatch-raises-400k-to-help-students-find-the-perfect-internship/

<comment><USER2> My school, Penn State, has something called the Washington Program. You apply to the program, then the program coordinator makes calls on your behalf to his personal network of Penn State alumni and other internship sponsors from the DC area. The quality of these internships was incredible: students worked on Capitol Hill, for big name media outlets, and for public affairs firms.

The program works so well because each year it can deliver students who have the "Penn State Washington Program seal of approval", so to speak. To an internship sponsor, the value proposition is simple: "Liked last year's intern? Well here's another."

It's definitely good that a site like InternMatch exists, but I think the best way for students to land a competitive internship is through some sort of social validation. The Penn State Washington Program provided this validation to students who otherwise might not have any connections in D.C.

Perhaps there is some business opportunity here: provide social validation for potential interns just like the Washington Program, but at scale (think Monster.com vs. TheLadders). Or maybe this is something best left to universities and their alumni associations.

<comment><AUTHOR> I think this is a really good point. Interns are usually unproven so any way to help bridge the trust gap with employers can make a big difference. With the "Penn State Washington Program," the student is essentially co-opting the program's brand to go from an unproven commodity, to someone who can hit the ground running.

There are a lot of tools we can provide to create this same effect for our interns: from coaching them on the importance of getting a TA referral, to making it easy for them to include a Github profile if they are a tech student. We have talked to a number of startups who say they read every application from interns who attach a Github profile because this shows a deeper level of interest in the field than the average student.

I like your point and we will keep innovating around this idea.

There are a number of other ways we can and will go to make sure we can help both sides determine high value matches, and feel confident with their choices in interns.

<comment><USER2> To some extent, isn't InternMatch structurally incapable of providing the same amount of validation as a college program?

A college program has few qualms rejecting someone. After conducting an interview, and reviewing writing samples and a resume, a college program will form a subjective opinion of the applicant. If the applicant garners a negative opinion s/he will be rejected, and the college program has no problem doing this.

On the other hand, InternMatch could have real trouble telling someone, "no we won't vouch for you"--it would be like telling a customer to leave the store.

Also, don't get me wrong, I'm not trying to attack you or your biz model at all--just offering my POV. Best of luck and congrats on the funding.

</comment></comment></comment><comment><USER3> I selected "any field" in both London and NYC and it had nothing for either. Not very useful without any listings.

<comment><USER4> Sorry for the confusion. We currently only have listings active on the west coast in California, Oregon, and Washington. We should definitely make that more obvious, especially when someone searches outside of our current territory. I'll add that tonight.

<comment><USER5> Actually, suppose we have internships to offer in your nonactive territories (say, the washington DC area), should we wait to post them? Also, would REU (research experience for undergraduates) be suitable to post on your site (we tend to pay about $4K for the summer for undergrads and offer free housing...).

<comment><AUTHOR> Yes please wait to post if you are in DC (but feel free to use any of the employer resources). We are growing regionally so that we can develop a traction at universities and guarentee a match. We can't do that yet in Washington DC.

The position you are describing sounds great -- its paid, offers professional experience for someone interested in the field of research, the only question I would ask is if there is much interaction with you and other employees. If you added to the program a once a week coffee, where you or other experts in the office talked to the candidate for 30 minutes and offered context on how their work fit into a broader policy and research framework it would take the position to the next level and help you get superior candidates.

<comment><USER5> There are weekly seminars from researchers and daily interaction with supervisors. Projects have include math, physics, chemistry, biology, cs, and engineering...If you think you'll become operational in our area, I'll have one of our outreach people contact you.

</comment></comment></comment></comment></comment><comment><USER6> This is awesome. When I was in college (1986-1990) internships were a pretty new concept. Then when in MBA (1997-1998) it obviously became a bigger deal. But now, the practice is very much becoming the norm. But, the tools for students and companies to find one another are still archaic (school recruiting systems... and afterthoughts on Monster, etc).

Plus, it's just as important for companies to provide killer internships (to get the best students, year after year) as it is for students to perform.

It's an ideal way to recruit, and find great companies, and a space ripe for innovation and investment.

Very excited to see what the team comes up with (and yes, I'm a fan and advisor -- my enthusiasm runs deep, and is very genuine)

</comment><comment><USER7> Internships are changing the landscape of labor where unemployment is still high. In today's economy, an internship is one of the most direct ways to gain access to ANY MARKET YOU WANT TO LEARN ABOUT. More and more undergrads are realizing this (and it's not just for those who are beefing up their resume). More grad students and mid-career folks are also realizing this. Employers are getting it.

Yes, perhaps YOU didn't get that job. But YOU can probably get that internship. Which LEADS to that job.

Sites such as InternMatch get that idea. They make this process easier for those of us who are searching. They seem to care about the search process and they keep it simple and personalized.

Keep up the good work InternMatch!

<comment><USER8> People complain about working for free all the time. I think they are pretty foolish. After all, historically people always paid for apprenticeships.

<comment><USER4> One thing to consider about unpaid internships is that they can limit the potential candidate pool. Not everyone can afford to work without being paid.

</comment></comment></comment><comment><USER9> This is great! It's a great company that really delivers on their promises on both sides. For interns - an easy way to get an internship that's actually inline with their interests and skill development. For employers - a quality intern that can deliver quality work. As someone that's experienced both sides of the internship issue through InternMatch, this is well deserved. Congrats!

</comment><comment><USER10> Same here. Internmatch really is a dream come true for college students hunting for opportunities like myself. I must say the user interface just blows away all the other competition I've seen out there and I've certainly checked just about all the competing sites!

excellent job on the site and best of luck, continue the great work!

</comment><comment><USER11> This is a great company; they're simplifying the internship search for students and employers, alike, and fulfilling a huge need in the marketplace. Keep up the good work!

</comment><comment><USER12> Way to go guys! It's awesome to see the company grow constantly. Keep up the good work : )

</comment><comment><USER13> Congrats! The InternMatch guys are awesome and are building an amazing product.</comment>