A New HP: HP commission a new logo - <AUTHOR> http://www.underconsideration.com/brandnew/archives/a_new_hp_so_close_yet_so_far_away.php?

<comment><USER2> People don't like Apple, Google, etc. because they have cool, meaningful logos. I don't even know if the apple has a significant meaning beyond a fruit, and if it did it wouldn't make me want Apple products more than I do now.

This reminds me of when Pepsi paid several million dollars for a new logo, and this 27 page marketing doc leaked explaining how their new logo takes into account everything from the Mona Lisa to gravitational fields:

[http://code.google.com/p/daxp/downloads/detail?name=pepsi%20...](http://code.google.com/p/daxp/downloads/detail?name=pepsi%20gravitational%20field.pdf)

I wonder if the Pepsi execs are still looking at this doc and wondering why they are second to Coke and Diet Coke?

<comment><USER3> I think companies that are falling behind seem to be grasping at the straw. Someone suggested "well we seem to be losing market share, it is probably because we have an outdated logo, let's fix that"

</comment></comment><comment><USER4> Some of the design work in the main case study [1] is fascinating and really good, but I think the new logo suggested is pretty poor.

It's a nice concept, but falls down badly on actually being readable and recognisable as a company logo, not a random modern art installation.

[1] <http://www.movingbrands.com/?category_name=hp-work>

<comment><USER5> HP is a big enough company that they will be able to take this and make it recognizable. As with any brand, it will take a lot of time, but I'm interested to see how this works for them.

It's likely the most abstract and simple logo I've seen a company of this size try using, so I admire this move on their part because it's risky and interesting. I do question the 13° thing, though. It may be crossing the line of simplicity and non-description if they intend to move on to just a forward- slash in a decade. I don't know if such a simple shape can do the job of a logo.

edit: Regardless, almost any logo can be a good logo if it's stamped on good products.

<comment><USER6> > HP is a big enough company that they will be able to take this and make it > recognizable

If they have to do it, it's already a failure. Unless you are _very_ familiar with their current logo, the odds of you guessing what the new one is are vanishingly small. They'd have to spend a ton of money to _maintain_ its recognizability.

<comment><USER5> _If they have to do it, it's already a failure._

That's not true, no logo is recognizable when it's first designed. The whole point is you build an association to your company by putting it on your products, and ads (which will probably be crucial in this transition). If you start seeing this logo and hearing the letters "HP" along with it you'll start to recognize it really quick.

 _They'd have to spend a ton of money to maintain its recognizability._

Like I said, the way you maintain a logo's recognizability is by simply using it. What I meant to say is if they use a specific design aesthetic/context, through repetition the logo will become recognizable. HP is a big company and their usage of it will be heavy enough to make that happen. It just might be more challenging since they're pushing the limits of abstraction in logo design, which is what I find interesting.

<comment><USER6> > no logo is recognizable when it's first designed

I am surrounded by logos anyone with even the most a tenuous grasp of written language would be able to interpret correctly in less than 5 seconds. IBM, Dell, Microsoft, Philips, HP (the current one), iG (the company I work for). The ones that would require more work would be the Microsoft flag, Apple's bitten apple (which is obviously an apple) and Ubuntu's circle of friends. I understand your point of continuously using the logo in order to build context, but this one is not like Cisco's bridge - it's a very generic set of four parallel lines. When someone tells you it's HP's logo, you say "ah! of course!" but, until then, people will scratch their heads for a while.

<comment><USER5> Maybe you're right, but to be fair those names you mentioned all use logotypes and this design is bordering on just a logo- it's much less of a logotype.

<comment><USER6> True. This would be HP's first pure logo. I mean, it resembles vaguely what remains from h and p when you get rid of all horizontal lines...

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> "The defining signature of the system is the 13° angle. 13° represents HP's spirit as a company, driven forward by ingenuity and optimism about the future and a belief in human progress."

This reads to a non-designer like myself as pure BS, written merely to justify the likely exhorbitant cost of their work. All that seems missing is a few "paradigms" and "outside the boxes".

Could an experienced logo designer weigh in a let us "pure techies" know if this kind of stuff passes muster with you? Does a 13* angle really convey that much more than a 14* could?

For what it's worth, the new logo looks terrible. The old one had a classic tech look like IBM's.

<comment><USER5> As a design student I can guarantee the 13° stuff is presentation BS. It's an attempt to make the HP board-members feel as if they really got their money's worth, like it's been meticulously designed and perfected to the degree.

I wish they had just referred to it as an italic, because that's what it is. But that wouldn't fly.

<comment><USER6> 13 is louder than 12, after all ;-)

</comment></comment></comment><comment><USER8> Does anybody else like the 1941 logo a lot better than the rest of these?

<comment><USER6> I like the current one better than the 1940's one, but the best one, IMHO, is the one used from the 60's to the late 90's.

</comment></comment><comment><USER9> When you _look_ at it, you see the 'h' and the 'p', but when you just glance at it, it's nothing. The effect is kinda neat, but I'm tempted to say that 'clever' is not what a logo should be (and I think clever here is being generous).

edit: at least not this kinda of clever, where the whole thing is hidden.

</comment><comment><USER10> [http://www.underconsideration.com/brandnew/archives/hp_mb_lo...](http://www.underconsideration.com/brandnew/archives/hp_mb_logo_explain_chart.jpg)

Seems to imply this is some kind of joke?

<comment><USER11> No, that's easily on the level.

</comment></comment><comment><USER12> A little bit too simple for me. I guess it supposed to look cool and sleek, but I don't know, something is odd about just 4 lines. What do you guys think?

<comment><USER13> It might be a fad in logo design: oversimplify everything into a few lines. I hope it goes away and I hope good designers don't follow it.

I would say that the Cisco (old: <http://www.it- building.ru/insertfiles/Image/cisco-270406.jpg> new: [http://www.theavco.com/sites/default/files/images/Cisco_logo...](http://www.theavco.com/sites/default/files/images/Cisco_logo.png)) and Russian Railways (<http://img254.imageshack.us/img254/1487/1111qa.jpg> old: left, new: right) are too parts of this worrying pattern.

<comment><USER14> Cisco was the first thing that came to my mind when I saw this new logo.

I also don't like this fad.

</comment></comment></comment><comment><USER15> I honestly can't tell if this is satire.

</comment><comment><USER16> So you're the new CEO at HP, and you look out across the landscape. You see many problems. Lots of things need deliberate attention with a mindful approach to creating solutions that can be put in motion today and followed through for years to come....

And you come to the conclusion that what the company really needs is a corporate identity refresh.

Je ne sais quoi - An intangible quality that makes something distinctive or attractive.

\-- <http://en.wiktionary.org/wiki/je_ne_sais_quoi>

I can say, with a high level of confidence, that the intangible quality that produces _je ne said quoi_ surrounding brands like Apple. The current HP logo is sufficiently "designy" to surpass the general public's expectations.

</comment><comment><USER17> Yeah, because what HP needs right now is a new logo...

</comment><comment><USER18> Looks like "lip" at first glance.

</comment><comment><USER19> Happy to see Meg is on top of HP's core problems. They were so 12°!

</comment><comment><USER20> It looks like they just copied the MIT Press Logo and italicized it.

<http://en.wikipedia.org/wiki/MIT_Press>

<comment><USER21> Looks like the MIT Press Logo just drank illy coffee:

<http://cyberiancafe.com/wp-content/uploads/2011/02/illy1.png>

</comment></comment><comment><USER22> Looks like a middle finger to me.

</comment><comment><USER23> I couldn't stop reading it as bp. Maybe it's a hint of another merge?

</comment><comment><USER24> Good choice! They went with a logo that is as stripped down as the company itself.

</comment><comment><USER25> Looks like a 4-state postal barcode to me.

</comment><comment><USER26> They should have just made it a pear with a bite out of it.

<comment><USER26> I like the way Californians have zero capacity for sarcasm. Source: down voted comment above.

<comment><USER21> Zis is Hacker News, we don't dududu here.</comment></comment></comment>


Life in the Algorithm - <AUTHOR> https://www.adbusters.org/magazine/117/life-algorithm.html

<comment><USER2> There is a lot to learn from technophobia, specifically for people who devoted their lives and careers to technology in one way or the other, but with its bubble-gum logic and name-checking gusto, it's almost impossible to take this article seriously.

</comment><comment><USER3> Great article on algorithms!</comment>


BadBios - <AUTHOR> https://plus.google.com/app/basic/stream/z13tzhpzvpqyuzv1n23cz52wykrrvjjce

<comment><USER2> Reading some of this guy's other posts, I'm guessing mental illness. (It's certainly a much more likely possibility than a mysterious piece of malware which somehow infects every piece of electronic hardware in his house.)

Quite sad to see, really. Hope he gets some help.

> So it turns out that annoying high frequency whine in my soundsystem isn't > crappy electrical noise that has been plaguing my wiring for years. It is > actually high frequency ultrasonic transmissions that malware has been using > to communicate to airgapped computers... one "ghost" located at least. And > now we know how the "hypervisor" functions, its probably stored in the > realtek firmware, and thats one of the ways it survives reinstalls and BIOS > reflashing. Off to find tools to dump the RealTek audio chips, and to try to > find clean firmware to compare it to. Haven't ruled out video firmware yet, > either.

[https://plus.google.com/app/basic/stream/z13itlihtui4gn2cl23...](https://plus.google.com/app/basic/stream/z13itlihtui4gn2cl23cz52wykrrvjjce)

</comment><comment><USER3> Certainly worrying but something on this scale and impacting I would of thought that more sources of this would be scropping up. But may bea early days.

Certainly the aspect of rewritting the controller code on flash drives of all available types would be a very news worthy issue in itself beyond this being used as a vector to rewrite the system BIOS. Which would be a way of doing it, given how many manufacters that have windows based BIOS update programs that have caused people fun and games in the past. This avoids the whole windows/AV and indeed any protection the system BIOS has beyond a checksum that would also appear to be easily bypassed.

Still the whole area that I wonder is when flaws in network card chipsets are found and then the potentual to rewrite the code/BIOS upon those NIC's. That would be an area which a failing CD-ROM drive would not show up.

Now waiting for somebody to invent a USB product condom, as in you plug it your unknown USB device into it and it checks that it is not going to infect your computer and puts on a green or red light accordingly showing it is safe to insert into your computer.

Hope some more details come too light, just seems too big a deal to be this low scale on the news front.</comment>


Ask HN: What server side language/framework did you choose and why? - <AUTHOR> I've had an interesting discussion in a Ruby/Rails related group.<p>Without falling into the "Rails is dead, long live XYZ", I would love to know what language/framework you chose for your startup/project/company and why... <comment><USER2> I still believe that Rails is more productive than anything Python, because of basic choices in both the design of the frameworks (I've used Django, Web2py and Flask) and the underlying language. With the same level of skills you write less code in Rails and deliver quickly also because of the predictability of where stuff is.

Phoenix can be an alternative, at least you get some advantages with parallelism. Elixir could have been designed to require less boilerplate when doing common operations like creating genservers. Basically you can copy/paste and search/replace the code around the functions that would be methods in Ruby, which is a waste of time, but the thing that every object (the genserver) has its own CPU is great.

That is what I suggest to customers that don't care about the language of new projects. If they already have invested in a language anything would do. I've seen PHP frameworks with various degrees of predictability and readability, JavaScript (always anarchically written applications), Java 8 (can't remember the framework but something modern, much improved compared to years ago, but still unproductive because of Java's verbosity). I wouldn't use any of them in my company. It would be Rails or Phoenix and a separate project for the frontend, possibly with some server rendered pages to reduce the time to see the initial content. I could consider writing Ruby and deploying to the JVM for parallelism.

I never seen or used Go or .NET. Did anybody already use the latter to deploy to Linux servers and has experience to share?

</comment><comment><USER3> First time I tried doing a web startup, we used Rails, Sinatra for testing, and no real client-side JS. Ruby provided a fairly familiar way of thinking about classes and objects, and had enough sugar and utilities and great libraries to get a project up in reasonable time.

The second web/healthtech startup I was an early engineer and engineering lead on, and we used Node and C/C++. I initially wanted to backport practices from Ruby and Rails--and did so making some view helpers and other things--but eventually I came around to really enjoying Javascript as a functional-C-with- closures-and-associative-arrays. Almost all of my subsequent hacks and prototypes were in JS, going as far as Angular until it was rolled back for simpler-to-maintain pure JS.

Nowadays I wouldn't bother doing any server-side stuff not in Erlang or Elixir, because the community is a bit mature and conservative and because the languages don't have a lot of magic and are still quite performant. My best- tested web application would probably be an Elixir message board.

<comment><AUTHOR> What lead you to "ditch" ruby the second time? (if it was your decision).

Would you choose Ruby again today starting fresh? If not, what would you choose?

<comment><USER3> The second time was a result of my inability to get the CTO to move off of an ancient version (0.10) of NodeJS--our web frontend could've been quite happy as a Rails or Sinatra app and we could've made great use of ActiveRecord for some of the early problems we tried to solve.

However, the realtime component of the system (streaming data to the browser) was implemented using websockets through Node and even if we had Rails for that we still would've kept that part in Node. I would've loved to have kept Ruby around just for scripting and munging, but since it was also a Windows shop (uggggh) I found it more expedient to just move things over to Javascript. The things that I _did_ manage to take from Rails were view helpers for things like generating links, certain types of buttons and forms, and that sort of thing. We ended up doing a lot of reporting and that ended up in boring old SQL, but that would've been the case with Rails too.

Today, I'm still a bit faster hacking in JS than I would be getting the rust off of my Ruby...so if I needed to do a spike, I'd do it in Node/Express/pg- node--again, that's just personal skill and speed, your mileage may vary. From a testability standpoint, I think the two ecosystems are about on par (finally), with a slight edge for Ruby. Either one is a fine choice, but if you don't need realtime (websockets) stuff, I think you'll probably just enjoy Ruby more. That said:

For starting a new project today, I would use Elixir. I value the already- reasonable testing story. I value the general quality of the ecosystem packages and conservatism (good taste, sorely lacking in Node). I especially value that, as a compiled language, it can catch a lot more of my stupid. I also value that it is conservatively 10x using Phoenix than Rails ( [https://github.com/mroth/phoenix-showdown](https://github.com/mroth/phoenix- showdown) ), and does so while having a much more compelling functional and reliability story than I see in Ruby without slowness-inducing metaprogramming tricks. For the prototype architecture I favor, monolith + a few microservices, that efficiency means I don't have to worry about ops stuff as much at the start.

At the end of the day, though, go to war with the framework that you are most comfortable with or the one that most clearly matches the problem space of your domain. For me, that used to be Ruby. For you or somebody else, it still might be--and that's a great thing!

</comment></comment></comment><comment><USER4> I used to use Elm + Elixir/Phoenix and am transitioning to Rust/Elm. Both for the same reason: I don't want things breaking. Elixir is pretty great for that, but odd DB connection problems every ~1.5 server-years left me with a emergency-response burden that was a little too much (across all my services).

</comment><comment><USER5> > I've had an interesting discussion in a Ruby/Rails related group.

if the discussion has a log somewhere on the web it would be interesting to provide a link.

I don't choose this or that tech for the sake of it. I choose the right tool for the job or what the client imposes. So it should mostly be about the requirements. Obviously some techs are more versatile than others.

The community is also important. Getting help from a respectful and friendly community is important. Because there are some really shitty language communities out there...

<comment><AUTHOR> The discussion does exist, although you'll need to use the "translate" options on some of the comments

[https://www.facebook.com/groups/173510639329747/permalink/14...](https://www.facebook.com/groups/173510639329747/permalink/1493584430655688/)

I agree with your comment 100% and that's what I commented in that discussion as well.

Question is, with 3 things that conceptually serve almost the same purpose, why would you choose one over the other.

For example: Rails, Django, Meteor.

</comment></comment><comment><USER6> I get to use Go at my day job and have had great success with it considering it has a great ecosystem of third-party packages. It's nice to have graceful shutdown, middleware chaining, and request contexts in tandem with easy concurrent programming.

The only troubling thing is trying to find a package manager that makes sense and so far that has been glide.

Perhaps someday I will get to use Rust paired with the new async libraries that are being worked on.

</comment><comment><USER7> Clojure, because it is Lisp, run on the JVM, node and browser.</comment>


The 16th century computer and the book that kills - <AUTHOR> http://www.marianotomatis.it/blog/index.php?post=20130322

<comment><USER2> This is a 1-dimensional cellular automaton. Apparently John Dee was fascinated by the chaotic patterns such automata are famous for. It reminds me of Stephen Wolfram's love of Rule 30.

Conway's Game of Life similarly intrigued hackers in the 20th century, but without the mystical subtext.

<comment><USER3> Oddly enough, it _does_ share the life/death subtext.

</comment></comment><comment><USER4> I can't help thinking that these books might have been keys for encrypting messages. Key-based substitution ciphers, such as the Vigenère cipher[1], were already known in the 1500s. If two people each had a copy of this book, they could send a key to each other by referring to a sequence of characters such as "the third row on page 25". The messenger who carried this message wouldn't be able to reconstruct the key without a copy of the book. If you wanted to give the code to somebody else, you wouldn't have to send them the book: just tell them the "seed" words and the algorithm for generating the pages, which could be sent separately, for security.

[1] <https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher>

<comment><USER2> Using this as a keypad (modular addition) would be much better than the Vigenère cipher, since there aren't such obvious correlations between key characters-- a good cellular automata is closer to a proper PRF.

</comment></comment><comment><AUTHOR> I haven't delved into the whole logics, but it seems from the wikipedias (<http://en.wikipedia.org/wiki/Book_of_Soyga>) that there's much more to be decoded from the tables. Given their likely magical or esoteric nature, the contents themselves of course are likely to be much less interesting to HN than their encoding... but a challenge remains.</comment>


Very Confused Judge Allows Bizarre Copyright Lawsuit to Continue - <AUTHOR> https://www.techdirt.com/articles/20190718/17562542612/very-confused-judge-allows-bizarre-copyright-lawsuit-against-cloudflare-to-continue.shtml <comment><USER2> CloudFlare runs a (free!) reverse proxy that obfuscates the identity (e.g., IP address) of servers that sometimes host copyright-infringing material.

As a copyright holder, your only choice is to request a DMCA takedown to CloudFlare. There may be no other way to identify the host than to ask CloudFlare, as they pass all traffic to the host.

CloudFlare responds that they are not the host of the material, merely a "CDN" or "reverse proxy". Perhaps they respond with the identity of the host, perhaps not.

If they do not, how are they _not_ contributing to copyright infringement? And even if they _do_ identify the source IP of the host, how does their obfuscation of the host not provide some direct (contributory) benefit to the host for distributing copyrighted content?

<comment> em-bee the point of cloudflares service is to make content faster to access by hosting it closer to you. that requires that the content is available on a different ip address. this is not obfuscation but purely a side-effect.

obfuscation would be to put the content on a different location without any other benefits. that's what the use of a vpn achieves (in the other direction). people use a vpn to obfuscate their ip address. cloudflare does not provide their service to obfuscate a hosts ip address.</comment></comment>


Domain Knowledge or a Lack Thereof - <AUTHOR> http://jacquesmattheij.com/domain-knowledge-or-a-lack-thereof <comment><USER2> Ah yes, the tragedy of studying computing to the exclusion of everything else. Graduates with computer science degrees have an in-depth understanding of... text editors. And maybe compilers, databases, and operating systems — all items of zero value until they are applied to solving some real problems in some other field. Problems which the computer science graduate knows nothing about.

Then these graduates go into the working world, and they typically can't help solve problems in economics, physics, applied mathematics, or medicine except by coding up some system to someone else's specs. The more dedicated ones make an effort to understand what they're doing. They exceedingly rare, gifted, and motivated ones might learn enough about an industry to make real contributions.

I hope that our field eventually evolves to the point that programming skill becomes an accessory. People will then learn to program just like they learn to write, and use the craft to help them solve their actual problems. The profession of programmers who only know how to program should disappear like the profession of scribes who only know how to write.

<comment><USER3> And yet another cheap stab at many people reading HN. HN is filled with negativity --if not downright hatred-- towards nerds lately.

Items of zero value? A certain sci-fi author would beg to differ with you. Even someone that would have zero knowledge of anything else but would be mastering programming is still a technopriest. Even with zero knowledge about anything else but computers one still understand more about today's world than most people out there.

I'm not advocating refusing to learn other domains (I'm the kind of person who, when writing a book, decides to learn typography and typesetting software so I can typeset the book myself) but your cheap stab at young programmers (I'm 40) is uncalled for.

The world is going to shift to even more 0's and 1's. Many things are going to disappear and be replaced by 0's and 1's.

If there's one thing common to _every single profession out there_ is that people need to read, write and communicate. And you know what? The tools allowing to read, write and communicate are written by the technopriests.

It's even more "scary" than that: the very infrastructure in place allowing people to communicate (like electricity and Internet) are, themselves, run using software. Not to mention very basic need like the entire infrastructure providing clean water to fullfill one of the most basic Maslow need.

There's no need for someone taking care of a network to understand what's inside the packets of information running through the network. All they need to know is that if there's no more Internet packets travelling worldwide, then there's no western civilization anymore.

The very foundation the entire society now relies on is software. If a worlwide EMP blast would render all computers useless tomorrow the world would probably turn to a mad max horror scenario in a few hours. No more water. No more electricity. No more food. Our logistics would be so screwed that "advanced" countries would fall into chaos. It's probable that in some places people would die after a few days because of the lack of drinkable water and it's very probable that in a few weeks many would die due to lack of food. Not to mention the nuclear facilities which would leak radioactivity left and right and break havoc.

Doctors aren't forced to understand how computers works to do their job. Most doctors are utterly clueless when it comes to technology: they're bound to live in fear of being hacked and not understanding what's going on when they connect to their online banking account and not understand why this or that mainstream article tell them to disable Java in their Mac. I've got doctor friends: they simply don't understand the world they're living in. We're _already_ in the technopriest age. And they're asking me questions, lots of them.

The most computer-wise knowledgable doctor I know was thinking that the latest state of the art way to diagnose using computers was still to use an "expert system", filled by doctors. That's not how it works. These "experts" aren't able to process the amount of information a computer can process and can't find the correlation a computer software can find. Which is why now machines are trained with gigantic amount of information and suggesting exams and deceases to look for that are way more relevant than what doctors would suggest.

I think you got it totally backwards: it's a lot of the _other_ professions that are going to disappear. Replaced by robots, machine learning algorithms, software and... The technopriests.

The ones still able to somehow understand the world they're living in and still able to _write_ the world they're living in.

P.S: regarding mainstream economics I'd like to point out that Krugman, Nobel Prize winner, recently said that it wasn't a bad idea to mint a one trillion coin to deal with the U.S. debt SNAFU. Sure. Why not mint 26 of them and be done with the U.S. public debt!? _That_ is the kind of economics most economics and most universities do teach worldwide: Keynesian economics. I happen to think Keynes was all wrong and keynesians have never been able to predict the consequences of their interventions more than a few months/years forward. There are economists from other schools who predicted 15 years before it happened, before the first euro was even circulating, that the euro would lead to: too many houses in spain, too many public servants in France, too many industries in Germany and who explained by which mechanism Greece and Spain would eventually default. Not a single Keynesian has ever been able to do a prediction that precise. That's all I need to know about "economics": that the mainstream is all wrong.

I do also think you put way too much faith in doctors: these people really aren't nearly half as expert as you think in their field. And _they_ are the ones getting replaced _today_ by sofware and robots. There's simply no way a surgeon can be as precise and have as many axis of rotation compared to _today_ robotic arms (explained to me by a surgeon friend). There's also simply no way a doctor can read blood samples and other exams results and be able to correlate that with hundreds of thousands of other results and hence make more correct deduction as to what's going on.

If we eventually end up one day with true AI then _everybody_ becomes meaningless because that day there ain't going to be doctors nor economists anymore.

Until that day programmers (even the one knowing nothing besides 0s and 1s and how 0s and 1s move around) are going to be more and more like the technopriests.

<comment><USER4> I didn't read it as a stab at nerds or young programmers but more like an advice that domain knowledge still is important beyond pure programming skills. Maybe the comment was formulated a littel bit over tthe top, but well, I'm doing that quite regularly.

I completely agree that the world is running on software right now, but the world isn't software ITSELF (well, not yet).

On the other hand, people being cracks in there field claiming that there field is the only one that counts are just arrogant. No mater if they a programmers, accountants, mech. engineers, doctors, car mechanics or what not. And yes, software written by people without the slightest idea of the purpose of said software tends to be not so good.

<comment><USER5> > without the slightest idea of the purpose of said software

In the OPs specific example, the purpose of the network is to carry packets, and your job is to make sure packets are delivered. Whether they carry orders to launch nukes, or donations to charity isn't the purpose.

<comment><USER6> The point is that you need to be well acquainted with the problem that you're trying to solve. If you're developing a new network protocol then yes, you don't need to know what kind of information is going to flow through the network, you need to know about network protocols. On the other hand, if you're developing a business application then you better know how that business works.

</comment></comment></comment></comment></comment><comment><USER7> In science and engineering, it's common to hear of "Computational X" where X is "Plasma Physics", "Geodynamics", "Ocean Science", "Electrical Engineering", "Aerodynamics", or any of a myriad of other disciplines. In these fields, the primary task is formulating Science/Engineering questions that can be effectively answered using computation, then writing the software to do so.

There is also the more generic field "Computational Science and Engineering" (CS&E) [1], which is primarily the development of methods and software that is applied in many specific disciplines. I work primarily on the library development side of CS&E, working with many applications to understand their needs, often finding ways to satisfy those needs with better software reuse and better ultimate flexibility, then implementing any components that belong in libraries. Additionally, we do basic research by recognizing unexploited common themes and designing new algorithms that will benefit existing and potential users.

There is currently a great deal of demand for Computational X, for CS&E through the postdoc level, and for CS&E in industry and national labs. It is recognized that a _versatile_ practitioner of CS&E can effectively assist Computational X for many values of X, since there really is a lot in common. Once you've put in 10000 hours of CS&E, plus 1000 hours in a handful of disciplines, you should be able to get orientedy quickly in new applications.

At the faculty level, support for CS&E is highly variable. At some universities, X departments have the view that all their faculty should "X first, computation second", while the mathematics department wants to see theorems and isn't overly concerned with following through to see the method applied to obtain a new science or engineering result. When hiring committees say "we need CS&E, but some other department should have the CS&E faculty", it drives a lot of talent away from teaching roles (e.g., into industry), perpetuating the relative lack of early education in CS&E fundamentals. On the other hand, the trend is for universities to have more direct interest in CS&E (sometimes recognizing it with a dedicated department or inistitute). It helps that computation stimulates many interdisciplinary collaborations, leading to more diverse funding possibilities.

[1] We have a big meeting next week: <http://www.siam.org/meetings/cse13/>

<comment><USER8> What sort of backgrounds do people working in this field have? More specifically, I have a bachelor's degree in materials science and currently work doing run-of-the-mill web development (were the typical background of my peers is a bachelor's in CS). What steps might I take to move into computational engineering?

<comment><USER7> There are a couple journals dedicated to computational materials science. Two active fields are phase field models and molecular dynamics.

Phase field models are mesoscale continuum (PDE) models based on the Cahn- Hilliard and Allen-Cahn equations, and are useful for things like predicting crystal grain growth and reorganization under strain, as well as fracture and many other uses. In phase-field modeling, the interesting physics is a consequence of the free energy functional, which is phenomenological and different for each material, so software should make it as easy as possible to turn specification of the free energy into an accurate and efficient massively parallel simulation. One such approach is outlined in this paper [1] from some colleagues. The resulting discrete systems are stiff and have positivity properties that must be preserved, so scalable implicit solvers (like multigrid) as well as methods for variational inequalities are necessary.

In molecular dynamics, there are many parallel scalability and expressivity challenges. Fast algorithms for long-range interactions (such as the fast multipole method) lead to less regular computational, but huge asymptotic (O(n) versus O(n^2)). Since better algorithms become more important as our hardware allows us to keep scaling up the problem sizes, Fast methods need to be applied in more places.

There is also a lot of activity in multiscale modeling and numerical homogenization, where explicit microscale models (often kinetic) are used to provide missing components of meso/macro-scale continuum models.

[1] <http://dx.doi.org/10.1016/j.commatsci.2011.07.028>

</comment></comment></comment><comment><USER9> The lack of this kind of domain knowledge - either from being unwilling to go find it, or not being given the time and the resources to do so - is a big problem for tools development in games. People doing the scheduling and planning tend to assume that if you put enough smart programmers in a room and give them detailed specifications, they'll be able to solve all the problems faced by some artists and writers in another room, even though they don't know anything about art or writing. Sometimes this results in the kind of obvious mistakes that you might otherwise assume only happen when you're writing software for the government.

In a sense it's kind of sad: In building traditional software, understanding the customer is one of the hardest steps because you can't simply walk over and observe them going about their daily work, or ask them questions on a regular basis to understand their issues - you're separated from them by a sales process and probably some automated support tickets and a PR guy who won't let you have open discussion in public. People building tools for game development can have their customers sitting a few desks away!

<comment><USER10> > In building traditional software, understanding the customer is one of the > hardest steps because you can't simply walk over and observe them going > about their daily work

One of the nicest things about the Agile fashion at the moment is that my customer (or a reasonable representative of him) is a couple of desks away and I really can go and ask him about what he wants. It's incredible how much time is saved by avoiding doing things he doesn't care about and how much happier he is with the end result.

</comment></comment><comment><USER11> This particularly resonates with me. I have been working in a bank as a graduate developer for the last year and a half, getting by without much care about how instruments are priced, traded, recorded, audited, etc. To me, I was moving a button around and colouring things using WPF. To me, the "Yield" column was just another column with numbers that were supposed to be 2 decimal places and turns red if negative. All the while I was dreaming I wished I worked at Google on 'technology'.

Which, in hindsight, was a little misguided. There is so much value in learning and understanding the domain in which we are working in because it makes us so much more effective. The realisation came when I became frustrated in meetings where we would discuss ideas on financial models and I could not add any value to the discussion.

I then imagined working at a company like Google, let's say, doing stuff I wouldn't normally be interested in. Would I bother learning the domain knowledge? I couldn't say yes with 100% conviction.

I love programming but I also want to be effective in what I do. To me now, understanding the problems we are solving is probably just as important as writing maintainable code.

</comment><comment><USER12> My take is that one of the main improvements in programming languages will be to reduce the gap between domain experts and programming experts.

Now we should face three cases: 1) the programmer needs to learn the domain; 2) the domain expert needs to know how to develop; 3) something in between.

Most of developing is done in 1). There are some brilliant cases of 2). I once talked with a biologist doing some multi sequence alignment that told me that some routine in C was quite slow and was far better rewrite that routine from scratch in assembly. I was quite speechless.

In order to create better programming languages we could: 1) express domains in a better way. Actually, just be able to express domains would be really cool (and not so easy). 2) provide higher levels of abstraction.

<comment><USER13> Every programming language from the dawn of time up to the present has made that claim at some point. This time it would be different.

I think it is just a people problem. Programmers tend to seclude themselves from their customers. Whole IT departments tend to seclude themselves from their users.

When you are looking for underwater welders for the off-shore industry, what is better, teaching a welder to dive or teaching a diver to weld?

(that's a serious question with a real answer).

It is much easier for a programmer to acquire the required domain knowledge than it is (usually) for a domain specialist to learn how to program. But you can only do so if you're prepared to 'dive in'.

<comment><USER14> My guess would be the first, teaching a welder to dive.

I base that on the fact that the core value, the welds, will be higher-quality and that's more important than the diving execution.

The diving might be off, but it shouldn't be _that hard_ to learn well enough to survive and be effective. Of course, I'm neither a diver nor a welder.

Did I win?

<comment><USER13> > Did I win?

Yep. But a drowned welder is also not much ;)

</comment></comment></comment></comment><comment><USER15> The line I found most insightful: >>"Software is much more intertwined with the institution commissioning it and the people using it ..."

Given that, I'm surprised at the emphasis on 'reading' as the primary source of gaining domain knowledge. There are just 2-3 mentions of speaking/collaborating with the domain experts that are driving you to build the software itself. If you are lucky enough to work with acknowledged domain experts, spend time talking to them. Pick their brain. Two techniques I use: a) forward interesting articles to them with a question or an analogous concept in my domain b) resist the urge to show them a 'better' way. E.g.: In the HealthCare domain, I learnt people don't really want quicker or lesser clicks. They would prefer a set, stable workflow. If you cater to senior- citizens, keyboard shortcuts are less important than instructions in large font.

I still suck at engaging domain experts. So, I'd love to learn more techniques to hold an interesting conversation with domain experts. Ideas?

<comment><USER16> I can read a book faster than I can speak or hear words.

In addition, books can usually be found, on almost any topic, which are intended to bring a novice up to a basic level of conversancy. Reading one (or two) such books will make discussions with the experts much more productive.

Plus: it's fun to learn about new things.

<comment><USER15> Oh, no argument on the fact that reading is extremely useful. I read too. In expressing the balance between reading and collaborating, I felt that your article emphasized too much on reading - but I fully recognize that you do collaborate.

>>"I can read a book faster than I can speak or hear words."

I disagree that this is an argument in favor of reading. Reading is easier but I think its not always as high in quality as collaborating.

>> "Reading one (or two) such books will make discussions with the experts much more productive."

Totally agree. I try my best to read as much with the end goal being picking the brains of my colleagues.

<comment><USER16> > _I felt that your article emphasized too much on reading_

You've mistaken me for Jacques Mattheij.

<comment><USER15> Ooops. Mea culpa. Sorry.

<comment><USER16> No worries. It's kinda flattering.

Plus "Jacques" is an uncommon name in the anglosphere, apart from South Africa.

</comment></comment></comment></comment></comment></comment><comment><USER17> I've held programming jobs in: Water Treatment Process Control, Workflow Management, Clinical Trials Management, Electrical Power Monitoring and Simulation, and Medical Imaging. In each case my natural curiosity led me to learn as much as I could about the field. I always enjoyed talking to the domain experts at each company and asking them as many questions as they could handle. There are usually one or two people who relish answering these questions and I especially like the ones who talk fast, mock astonishment at my ignorance, and proceed to try to fix it.

In water treatment, I learned about oxic/anoxic bacteria and how they're grown and recycled in the process to treat waste, how to write chemical metering logic in a PLC because I was the only one left on-site to do it, how motors are controlled with variable frequency drives, how proportional-integral- derivatives are used to prevent oscillation in feedback based controls.

In clinical trials management, I learned how double-blind studies are made, the process of randomization and dispensing drugs, medical coding and the life cycle of the trial.

In power systems simulation, I learned about three-phase power transmission, resistive and capacitive loads, active and reactive power, the challenges of hooking up a lot of solar panels our existing grids, how data centers are build and cooled and powered, microgrids, power meters, intelligent breakers and more.

I feel privileged that my skills at software development have exposed me to a variety of fields and that I know how several important processes in our word work. And I got to take home a nice salary while gaining that exposure. I do lament that, unless I pick a field and stick with it, I'll never get to work on the difficult programming problems that require a decade or more of experience and knowledge.

</comment><comment><USER18> HN is understandably filled with programmers who value programming above all else and believe domain knowledge can be picked up quickly. It would be true for someone hired as a programmer who implement a published algorithm or port existing software to newer systems or different platform; in other words, improving existing systems. I believe it requires equal depth if not not more for domain specific knowledge to innovate in non-computational fields. For my field of bioinformatics/computational biology, many open questions cannot be answered because of computational hurdles. Reading textbooks won't lead anyone to them, nor would reading survey papers. It requires expert knowledge in both biology and computer science to even know what is feasible and interesting. We want to find the driver mutations for cancer, discover mechanism of gene regulation, uncover subtle interaction of heredity and environment. Computation is intimately involved because observation is indirect, noisy, and massive. Only with knowledge in both fields can answer questions that domain experts care about but cannot do because of computational/quantitative obstacles.

I find researchers (I am in academia) in both fields cross-talk too much. Computational/quantitative experts try to shoe-horn biological questions into their small corner of research area, while biologists don't care about computational efficiency, statistical robustness/efficiency, and the mathematical implication of their simple methods; no one cares about software quality. This is unfortunate. It is also unfortunate hiring committees do not look favorably towards multi-disciplinary researchers because one is not a trained geneticist/cancer researcher. I definitively do not encourage computer scientists go into support roles in academia; they are poorly paid and get little respect.

</comment><comment><USER19> I am currently working on a web software project in the medical/health space. Of course its really good to know how the people that use the software work and what they expect and i am eager to learn those things, but i will not dive into a sector i am not really interested and absorb any and all information i can find, since i probably wont need it for the next project and it personally does not interest me a lot.

For technical domain knowledge i agree, but it also happens that this is often of personal interest to me anyway.

</comment><comment><USER20> I agree about the importance of gathering as much domain knowledge as possible.

One thing that I have always had issues with when gathering requirements around something for an unfamiliar industry is that people who are in that industry will often neglect to mention things that are both important and non- obvious/counter-intuitive to someone unfamiliar with the industry.

This is probably because they are so familiar with the quirks of the way that the particular industry works that such things seem so obvious as to not need mentioning (and they probably don't see how it could possibly be any other way). Basically similar to how we are often amazed by assumptions some people have about the way that computers/software works.

The paradox of this though is that to deliver truly good software for a particular industry one must really know that industry as well as somebody who has years of experience in that area. At which point you start to feel that you could do their job too.

Another alternative is to have a very tight feedback loop with someone who has tons of domain knowledge and is the target user. Basically sit next to them as you develop the software and have them review every single change you make.

<comment><USER21> I think in order to create good software that fits the industry's current best practices then you do need a really in-depth domain-specific knowledge. If that's the goal then learn everything possible about that industry.

To create good solutions that are also innovative, I think that programmers only really need enough knowledge in that domain to be dangerous - to know more or less what happens but with enough gaps to not really know what's doable and what isn't. But, this knowledge is only useful if you can combine it with bits and pieces from several completely separate domains.

If innovation is the goal then I think there is a point where domain knowledge actually hurts you.

Of course there still needs to be at least one specialist to keep everything on track though - and I completely agree with you about having someone with deep knowledge on board. I think it should be someone who has been in that industry and will stay in that industry.

I can't see the point in programmers trying to become experts in areas that they're not interested in working in for the long haul. It's easier to learn (and actually apply) a little about a lot than a lot about a little.

</comment></comment><comment><USER22> Actually I think domain knowledge is overrated. A good hacker can pick up the domain knowledge needed to contribute to a project very quickly.

Now, if you're designing a product to solve a problem in a particular domain you need the knowledge ahead of time, sure. But if you're a shit-hot coder and a fast learner, brought in to make things work, who cares?

<comment><USER23> Because, as the article clearly mentions, there's a difference between making something work and making something work right.

<comment><USER22> I disagree that it's important unless you're the person designing the solution. If you're not (and in many/most teams you won't be) it's far less important.

<comment><USER24> I guess the key is how often are we just handed a spec and asked to code it up. In my roles, I've never worked like that, I've nearly always had some impact on design - but hey, that's just my experiences.

I would agree with your original point though, that domain knowledge can be learned quickly by a good hacker. Which leads to a more interesting question; what techniques can we use to learn a new domain?

<comment><USER4> I agree that domain knowledge can be learned by decent hacker quickly up the degree necessary to write good code for that domain.

</comment></comment></comment></comment></comment><comment><USER25> This is a very true post, but I don't think the solution is at the university, at least for undergrads. Schools barely have enough time in 4 years to create entry level programmers. Lopping off half the coursework in exchange for domain knowledge leaves grads unprepared.

My observation is if you can learn to program well, you can learn any field of knowledge. A programmer can learn consumer products easier than a brand manager can learn Python. Similarly a CS major can learn bond math easier than a Finance major can learn database design. (Yes, these are generalizations)

What's this mean? That bridging the Tech/Client divide is on the shoulder of the technologist. In addition to learning the latest frameworks, we have to learn our customers business. In addition to tech credentials, we should add theirs too.

<comment><USER16> The degree gives you a tour of the _foundations_ of the solution domain.

Mastery of the solution domain and knowledge of various problem domains cannot be taught in a 3 or 4 year degree.

<comment><USER25> Agree completely.

</comment></comment></comment><comment><USER26> Programmers should learn more about other domains and domain experts should learn how to program. Programming is becoming nearly as basic a skill as writing.

</comment><comment><USER27> Does anyone here find the work of Lave and Wenger ('situated learning') of any use in their attempts to understand a problem area for a customer?

<http://www.infed.org/biblio/communities_of_practice.htm>

Basically, some organisations make their processes easily visible to most employees, and some don't. The ones that do can train people more quickly and improve their processes more quickly. Organisations that make 'peripheral participation' easy might be better customers for developers than those that don't. You might not have to make many sails or use a height gauge too often to 'see' what the issues are, just interview knowledgeable people _carefully_ and cross reference the results with observation.

As a concrete example, the original author invested a considerable amount of (quite expensive) time in learning about sail making and lathe operating. In some of the 'business applications' I have to use daily, it is pretty obvious that the customer was a manager higher up and that the interface we have to use to populate the database that generates the wonderful reports has not really had much time spent on it!

</comment><comment><USER28> So I don't work in a scientific field, and I'm not a "programmer" or "software engineer". I am a business analyst. I am a business analyst who CAN code. My code isn't _always_ pretty, and I recycle a crap ton of boilerplate and hack the hell out of django apps. And I read the heck out of HN and have spent 5 years slowly refining my design chops. But most importantly, I know top-to- bottom the ins and outs of my business. So when our call center shopped around for a software solution to provide a call center full of agents realtime access to their stats, we were given a 3 month time frame and quoted $100k+ for a solution. So I wrote and deployed a web based results dashboard of realtime stats over two weekends. And we were just quoted a price on a quality management tool for $225k. Guess what's next for me? I've been an agent on the phones. I've sold in a retail environment. I've been the corporate trainer dealing with the LMS. Domain knowledge plus tech chops has proven a powerful combination for me.

</comment><comment><USER29> I believe this is actually the major problem faced by outsourcing projects. When I was in the cable industry, I saw several projects fail when the "Systems Engineers" (who were in charge of writing the specifications) were unable to convey enough information to the developers.

There's a real limit to the amount of "truth" you can put into a specification, and at some point you have to trust the developer to "do the right thing". If they don't have domain knowledge in the industry they're writing for, they don't stand a chance ... and so your project fails even when everyone works hard and has good intentions.

</comment><comment><USER30> I agree, but this is something I've found resistance to in the past. For example, last year I was building an automated shipping system for a client and I wanted to spend a few days in the shipping department - this was flat out refused as the management didn't see it how it would be useful, since the process was fully documented. Turns out, much had to be rewritten because the shipping staff were (predictably) doing 'undocumented' things to speed up their workflow, the new shipping system messed this up and made them slower.

</comment><comment><USER31> Jacques is right-on. For a lot of the work in my life, most of the effort was coming up to speed on a domain rather than just technology. Much of my work has been in 'artificial intelligence' (for some definition; never liked that term because it is too general) so domain knowledge is central if you are trying to get human level or better performance in some narrow domain.

Having to spin up on new domains also keeps work and life interesting.

</comment><comment><USER32> Turning the tables around: perhaps the software (or even physical products) that we use where we think, "this is stupid! why would anyone build it this way?" were similarly built by people with no domain expertise in the product.

Introduce a software engineer with an interest in the subject matter into that environment, and provided it isn't too big (like government), it might be self-correcting.

</comment><comment><USER33> OP might be right if they choose to write software without collaboration with clients or subject matter experts.

IMHO, with collaboration, it's more a matter of providing a hyper-rational process by which the purpose and priorities of the target audience(s) are focused and honed, and then producing the software as feedback, automation, and a usable compliment to their needs.

</comment><comment><USER34> This article is talking about what I learned as classic Systems Analysis and Design. It is an interdisciplinary intentional practice of seeking to fully understand the business processes involved.

See <http://en.m.wikipedia.org/wiki/Systems_analysis_and_design> as a starting point.

<comment><USER35> So have you ever tried what the articles suggest? Ever spent a week working on the 'shop floor'?

In my experience of public sector software projects, the programmers seem to be kept as far away from the end users as possible.

<comment><USER34> As a independent contractor / systems analyst, yes I have. However I agree, most solutions providers don't bother.

</comment></comment></comment><comment><USER36> I think domain knowledge is important, but sometimes it can be a trap that hinders inovation. As Pierre Bayard put very nicely in "How to talk about books you haven't read", when we don't have domain knowledge we open ourselves to questions that we wouldn't make otherwise.

</comment><comment><USER37> Reminds me of the old "what the customer actually wanted" comic:

<http://imgur.com/NXHbZ>

</comment><comment><USER38> Perhaps we should all work in compilers ;)

</comment><comment><USER39> Another metaphor for necessity of Domain Knowledge is translation. Give an average translator a technological text full of idioms from this technology domain and you will laugh your ass off.

I remember reading reports about some SAP installation process (written by idiots) full of stupid special terms such as "System Landscape" and "User Privileges" translated by an English teacher.)

Why we have this as a top news? Isn't it obvious that you must know the slang before you're trying to speak, let alone translate?

Well, most of coders use a slightly different strategy - jump right into IDE and pile it up, using all that containers and design patterns they have heard of (without understanding, why bother?) until it satisfies the manager (compiles) who know absolutely nothing (this is why everything _must_ be statically typed). Then test it like a black-box - correct input produces correct output (never try incorrect or unexpected) and then ship and forget.)

</comment><comment><USER3> Sadly in some domain it's not possible. I've had cases where to understand a particularly complex business logic case it turned out _nobody_ had any idea how that case should be resolved. Lawyers / jurists, employees, managers, etc.

We tried to go up the chain up to someone, anyone, who could explain how that case should be resolved but nobody could tell.

Why? Legalese. And just like most legalese documents: there's more than one interpretation possible because the very concept of legalese (based on thousands years old tradition) is inherently flawed and open to interpretation.

So, somewhere, some politicians, probably out of bikeshedding fashion, decides to vote an amendment exceedingly badly written and exceedingly complex. Then it becomes law. And law has to be followed. So that case has to be taken into account by the software but isn't (yet).

Everything is all and well until that specific case appear. The day it appears all bets are of. It's not working and nobody knows why. Nobody knows what is not working and why it's not working, nor how it should work. The law is bogus and the business case cannot be resolved without contradicting with the law(s).

Trying to determine this ended up with the programming team receiving a PDF with tens and tens of pages of legalese text that nobody up the chain (including lawyers) could explain to us. Probably that the politicians who voted these changes couldn't even themselves explain it.

We simply couldn't make the changes.

How did it end up? Someone very high up saying: _"That's what should be done in this particular case"_ and then everybody covering its arse.

And there came the technopriests: fixing the production DB...

<comment><USER40> > How did it end up? Someone very high up saying: "That's what should be done > in this particular case" and then everybody covering its arse.

This is usually how it ends up.

I've been close to similar situations (but while creating something, not changing something that already exists), but usually, if nobody understands how this is to be done, the fact that you can't code it is second in importance.</comment></comment>


Ask HN: Why are VCs needed? - <AUTHOR>

My father worked in a bank and one of the main tasks of commercial banking was to give loans to start businesses. The entrepreneur has full ownership of the company and loan was repaid at normal interest rate. Why dont tech companies use this method and why do  they need VC funding instead. If the entrepreneur is confident of his revenue model why not get a bank loan and start his company <comment><USER3> _Why dont tech companies use this method and why do they need VC funding instead._

Because they need more money than banks are willing to lend, their present circumstances do not imply collateral/predictable revenues/etc which would justify an underwriting decision to lend more, and their implied failure rates would make lending at commercially acceptable interest rates a prohibitively expensive proposition for the bank.

For example, take stock of two guys in their mid-twenties with $30k of their $40k combined net worth tied into a business. The business has proven revenues of $10k. They seek $2 million in capital to expand to their next milestone. _No bank in its right mind_ will loan them $2 million -- they're literally incapable of making the interest payments on it, to say nothing of predictably paying it back. By comparison, a VC firm might assign a notional value to their business of $3 million (the bank would say "It's, literally, worthless: liquidation costs swamp accumulated value of capital."), put in $2 million and own 40% of the company, and see 10 similarly situated investments _fail totally_ to sell this one company for $200 million 5 years from now.

<comment><USER4> _and see 10 similarly situated investments fail totally to sell this one company for $200 million 5 years from now._

That's the important point. Lots of VCs aren't really investing in a company, but are aiming to have invested in the next Google or other large tech company. They are playing blackjack.

<comment><USER5> Practically all VC invests this way; it's the model.

</comment></comment></comment><comment><USER6> Startups have no collateral.

</comment><comment><USER7> The goal of a bank is to minimize risk, as they have a capped return. On the other hand, the goal of a VC is to maximize return, as their is no cap on the return. The business models are different, and both have their places.

</comment><comment><USER8> A VC is your business partner. If you fail, they fail as well right along with you to the tune of their money.

A bank is not your business partner. If you fail via a bank loan, the bank still wants their money AND interest.

<comment><USER9> > If you fail via a bank loan, the bank still wants their money AND interest.

If your business goes bankrupt, the bank only gets their money if they required you to personally cosign for the loan. Of course, if your business isn't profitable yet, it's likely that they'll make you do exactly that, as a condition of getting the loan in the first place -- especially for tech companies that don't have many assets that can be liquidated in case of failure.

<comment><USER8> True but bankruptcy would be the step after failure. They _want_ their money but doesn't mean they will get it back.

<comment><USER10> For a tech company, common sense would require to make the founders liable to the debt, otherwise they can pay themselves a good salary -with the money borrowed to the bank - and then bankrupt the company.

For this reason - as well as other reason people here already mentionned - <USER2> banks won't lend so much money to a young tech company.

</comment></comment></comment></comment><comment><USER11> "Why dont tech companies use this method and why do they need VC funding instead"

Banks do not have as much vested interest in a startup as VCs. So their risk appetite is much lower than VCs. VCs lend money based on future potential of making it big and they take a lot more risk than a usual lender/bank.

Thats just the money part. VCs always provide a network of connections and key contact (mostly) who can also help your startup. Good VCs will provide mentorship and valuable help.

</comment><comment><USER12> VCs are needed as an asset class because there is a market opportunity to service a small segment of the population that are trying to create high risk, capital light, and high growth potential businesses that do not fit the risk/collateral/historical cash flow characteristics that banks need to believe that you can service their debt. VC money is EXTREMELY expensive and can be thought about as similar to credit card debt and payday lending. Sure, VCs have value added services like contacts and expertise that help portfolio companies potentially have a higher chance of success, but their primary motivation to help you is to return money to their limited partners (and themselves through management fees and carried interest). I'm an entrepreneur and know many amazing VCs who hopefully will someday fund my business but I'm realistic in acknowledging the nature of the relationship.

</comment><comment><USER13> The first rule of banking is you HAVE to get your principle back. I worked at Capital One and with 30% and fee's for everything you can lose money, key is getting paid back. Banks will loan money for working capital, if your startup needs a lot of working capital to finance inventories etc. banking might work.

</comment><comment><USER14> A good VC brings more than money; they bring expertise and experience. They have networks and connections that you probably don't. If you really want to grow, VCs can give you the kind of resources and expertise to actually do that...a bank can only give you money.

</comment><comment><USER15> A VC can also offer mentorship, provide some advice, and one of the most important thing is connections. They can introduce you to another VC or investor that might boost up your startup.</comment>


Augmented Reality Shooter - <AUTHOR> http://www.theshootar.com/ <comment><USER2> Hmm, I really don't see how this could possibly work. Phones will have to be in communication with each other to see if you hit another player and GPS isn't that accurate. Cool concept tho.

<comment><AUTHOR> I think it uses also a built-in compass and a central server for communication. There is also a small bullet spread.</comment></comment>


Captain Disillusion: World's Greatest Blenderer Live at Blender Conference 2018 - <AUTHOR> https://www.youtube.com/watch?v=1qSTcxt2t74 <comment><USER2> He has another video of a talk where he talks about his channel in general. He's a great presenter, on top of putting together some great stuff for the world to watch.

[https://www.youtube.com/watch?v=MQrzcwsGYy8](https://www.youtube.com/watch?v=MQrzcwsGYy8)</comment>


Logisland "Event Mining at scale" - <AUTHOR> Logisland provides a stream analytics solution that can handle all enterprise-scale event data and processing<p>https://github.com/Hurence/logisland <comment><AUTHOR> The main goal of LogIsland framework is to provide tools to automatically extract valuable knowledge from historical log data. To do so we need two different kind of processing over our technical stack :

\- Grab events from logs \- Perform Event Pattern Mining (EPM)</comment>


Japan's Rail Workers Pointing at Things (2017) - <AUTHOR> https://www.atlasobscura.com/articles/pointing-and-calling-japan-trains <comment><USER2> When I worked on a large historical sailing ship that required a dozen crew to perform tasks like raising sails, tacking, or reefing, we followed a call-and- response verbal command system for many of the same reasons.

When the helmsman would yell out "Ready about!", we would check the surroundings and respond "Ready!", then we would listen for "Helms Alee!" and prepare to switch sides and trim the sails. This process made sure that all of the crew were synchronized as to the current step in the process.[0]

[0] [http://lrsailingcenter.com/posts/tacking/](http://lrsailingcenter.com/posts/tacking/)

<comment><USER3> When I used to do manual labour, I used to do this when told to do tasks. e.g. if someone said "Go and sweep the leaves and put them in the bin", I'd clarify and say "So I'm sweeping those leaves and putting them in the bin?".

It worked well in making sure everyone was on the same page about what I was actually supposed to be doing. I eventually stopped doing it though because people got annoyed and thought I was stupid or just not listening to them, which was ironic because that's exactly the opposite of what was happening.

It's a shame really, because it did minimise errors. There's nothing more annoying for everyone then when someone spends hours doing the wrong task because of poor communication.

<comment><USER4> Whereas at the automotive shop I used to work at, everyone else picked that habit up from me. I'd picked it up from experience in aviation line service during high school. My coworkers acted annoyed for the first week, but they quickly realized I didn't expect a response and it made communication in a noisy shop clearer.

Especially after the day that a coworker got confused about which truck was which, and drilled a 3.5" hole in the bed of a brand new truck (thinking it was getting a gooseneck hitch). After that, everyone else started repeating verbal instructions as well.

<comment><USER5> OUCH, what happened, did your shop end up going through insurance to get the bed replaced?

I am only curious because this almost happened to me... and I was so glad when I found out they didn't put in the holes yet.

<comment><USER4> We ended up giving the customer a free gooseneck hitch. Thankfully he had intended to install one eventually, but it wasn't a pleasant day.

</comment></comment></comment></comment></comment><comment><USER6> > While some workers point-and-call more enthusiastically than others

Yes, I have seen this. Rail workers are great at it, but in other places, it can get worse. I saw a guy pointing to both sides of the sidewalk - to assure that it was free of people - before letting a truck get into a parking lot. His colleague will barely move the hands. It looked slightly awkward.

> Japanese commentators have theorized that Western employees feel "silly" > performing the requisite gestures and calls.

I guess that this is what humans are bad at. We overvalue our awareness, and we put a lot of much weight on any act with social implications.

While I was at Fuji, I saw what it seemed a guy training alongside the train driver. He laughed time to time at his own movements. They both had a great time. So, even for Japanese, seems that the situation is slightly awkward.

<comment><USER7> I wonder why we evolved to feel silly. You'd think the safety aspect of looking silly would outweigh the social aspect of doing things that cause mocking in others.

<comment><USER8> We evolved to overvalue the opinion of our peers. Back when we lived in tribes of 20-50, it was incredibly important to fit in and be accepted. It's maladaptive when the same mechanism is at work when doing something modern that is silly on an individual social level but incredibly important/beneficial on a rational one.

</comment></comment></comment><comment><USER9> I would be prepared to completely ignore (and definitely not laugh at) rail personnel performing a naked rain dance if it meant that the trains would arrive on time more often. Hell, I'd join in if that helped.

<comment> crooked-v That sounds like a Shadowrun plot hook.

</comment></comment><comment><USER10> The book I'm reading currently 'modular habits' uses the Japanese train conductors usage of this finger pointing an example of how to reinforce habits - the accident reduction noted with this technique was quite significant.

On another note - how strange is it when you learn something new of which you haven't known about your whole life only to several days later see it appear on hn.. is there a name for this sort of thing?

<comment><USER11> [https://en.wikipedia.org/wiki/Baader%E2%80%93Meinhof_effect](https://en.wikipedia.org/wiki/Baader%E2%80%93Meinhof_effect)

<comment><USER12> A subset of that I've noticed is whatever type of vehicle I'm driving seems way more common the road. Whether that's a motorcycle, a convertible, or a bland rented sedan.

<comment><USER13> I believe as a running gag, in some of the Grand Theft Auto games, whatever vehicle you are driving in will appear significantly more often. Not sure if this is still the case, but I always found it amusing, since yeah, I also noticed this effect in real life (even if it's just fallacious.)

<comment><USER14> I have read, though I'm struggling to find an original source, that it was due to memory constraints - it was easier to spawn a vehicle if it was already loaded than to keep paging between them.

<comment><USER13> That sounds like it is probably true. I have never heard any official confirmation that it was a gag, so I think this explanation must be the correct one.

</comment></comment></comment></comment></comment></comment><comment><USER15> I do something similiar with my keys: "I'm putting my keys on the sideboard".

Before that I occasionally "lost" my keys because the location was never safed to my long term memory. At least that's reproducably the error why I sometimes just couldn't remember.

<comment><USER16> Having been locked out at annoying, inconvenient times of day I started follow the same process a few years back. I feel like I'm going mad when I'm doing it though, stepping out of my flat stopping, staring at my keys and consciously placing them into my pocket. I'm so glad someone else does the same.

<comment><USER17> I always lock my front door _from the outside_ when I leave the house. This requires using my keys (unlike locking it from the inside). This means I never leave my keys behind. It does require remembering to lock the front door but I don't have any problem remembering to do that.

<comment><USER18> My front door can only be locked with a key.. that effectively prevents me from forgetting my keys inside.

</comment></comment></comment></comment><comment><USER19> I use a similar system when deploying builds to production. The deployment itself is a multi-step process where I have to pick out two artifacts, verify that their git commit hashes are correct, then pick out the correct jenkins jobs and run them in a specific order (providing artifact numbers as input). At every stage I point to my screen, read out the information and only click on things that I'm pointing at. This may be anecdotal but multiple times I have stopped myself from clicking on the wrong thing only after saying its name out loud.

<comment><USER20> Er isn't that what scripting is for?

<comment><AUTHOR> Not everything can be scripted, automation doesn't always repay the work expended in creating and maintaining it[0][1], and sometimes it's just worth having a human in the loop to know what's going on.

So, no, it isn't.

[0] [https://xkcd.com/1205/](https://xkcd.com/1205/)

[1] [https://xkcd.com/1319/](https://xkcd.com/1319/)

<comment><USER21> The process described is not only easily scriptable, but are things for which a human could very commonly make a mistake. You can add things in to include a human in the loop, maybe hitting return at each step, or hitting y, but deploying to production should never depend on a series of manual steps except when absolutely necessary

<comment><AUTHOR> martinkus> _... I have to pick out two artifacts ... pick out the correct jenkins jobs and run them in a specific order ..._

russdill> _The process described is not only easily scriptable, ..._

From the description given you can't know that.

russdill> _... deploying to production should never depend on a series of manual steps except when absolutely necessary._

So you, without knowing exactly what this person is doing, are declaring that it's not absolutely necessary? That's very bold of you.

<comment><USER21> They listed exactly what they are doing. The artifacts they are picking out should already be tagged with the release. The script to push those to production can use those tags to know what to push and what git commit hashes to check.

ETA: I'll add that when pushing production, the amount not just you can waste, but everyone down the line from users, developers, testers, etc, etc, can be huge. Calculating how much time _you_ would save isn't useful.

<comment><USER22> I don't want to say you are wrong, because there are a lot of situations (most?) where deployment automation can greatly reduce errors.

However, there can also be a number of reasons why builds and deployments could not be automated safely:

\- "Production" is not a single environment, but multiple customer environments with multiple deployment version targets based on need/contract. Customer environments might not even be accessible from same network as build/deploy machines.

\- Code is for industrial/embedded/non-networked equipment.

\- Policies dictated by own company or regulatory body require builds are manually checked and deployed by a human who can validate and sign off.

There really is no way of knowing. Automation can save hundreds and thousands of man-hours and reduce margin of error; but it is not applicable to every scenario. Sometimes manual work reinforced by good habits and processes are the tool for the job. As much as it pains be to say, as my job is automation.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> NYC's conductors do a similar thing when they pull into stations[1].

The urban myth that I grew up with was that they were pointing at a hidden camera to show the dispatcher that they're awake, but the article I linked below suggests that it was taken directly from the Japanese railway.

[1]: [https://www.nydailynews.com/new-york/mta-conductors-point- st...](https://www.nydailynews.com/new-york/mta-conductors-point-stopping- subway-station-article-1.3502286)

<comment><USER24> They point at a horizontally narrow sign board with diagonal black and white strips on it. In any station, you can find the exact middle of the platform by standing under this sign.

[https://imgs.6sqft.com/wp- content/uploads/2016/05/12133255/N...](https://imgs.6sqft.com/wp- content/uploads/2016/05/12133255/NYC-subway-zebra-signs-2.jpg)

So if you want, you can meet someone on a specific train car if you stand somewhere in relation to the board.

I used to meet up with my wife who worked 2 stations north of me using this technique without either of us disembarking. It was pretty handy.

<comment><USER25> Does that mean the train cars and doors are not numbered? On Tokyo subways one can say "I'm at door A of car 12" to arrange meetings.

<comment><USER26> They aren't. Well, they are numbered but they're basically car serial numbers, not anything all that useful in terms of standing in the right place when waiting for the train.

<comment><USER18> In Tokyo (and elsewhere in Japan) there are signs indicating where your car (e.g. car 4) will be when the train has stopped, so you just wait there. And when the train stops, the door is right in front of you..

</comment></comment></comment></comment></comment><comment><USER27> Hand signals are common for many blue-collar team jobs. Cranes, aircraft ramp operations, marine work, military - where getting it wrong is deadly or at least expensive. It's only rare to white-collar types.

It's the opposite of "move fast and break things". Heavy-lift companies and marine salvage companies (there's overlap) are in the business of "move slowly and don't break things". Mammoet, Titan, and Smit all have videos on line of some of their jobs. They are way into overpreparing. They have more gear on site than you'd think was needed, they prepare for as much as a year for some operations, there are detailed, written plans and backup plans which have been rehearsed and talked through by the people involved, and then on the big day, everything goes so smoothly it's dull. Watch some of those videos and you'll see some explicit hand signals.

<comment><USER28> Long ago I spent a good bit of time in Rotterdam Harbor. What I distinctly remember is that when I first got there it was all a huge mystery to me, some kind of machine that moved by itself without any indication of what was going on and what would happen next. Then, over time I started to learn how to 'read' the dockside, and a good part of that was learning how to interpret the handsignals of the various crews to know when it was ok to pass and when it definitely wasn't.

</comment></comment><comment><USER29> When I was at Google, my team and other SRE teams around us adopted a similar approach to sensitive operations - deploys and data migrations and the like. We'd have one of us on the keyboard operating, and another looking over our shoulder. The operator would type a command and they verbally confirm the action they were going to take. Their partner would look it over and give verbal acknowledgement. We certainly still had mistakes, but I found that environment very helpful - and it was an almost necessary part of zero-blame postmortems, because every action was not one person, but equally shared between two.

<comment><USER30> I used to use check lists for this sort of critical tasks obvisly much smaller systems back then a 16 machine cluster was a big deal

</comment></comment><comment><USER31> Many basketball players, after shooting a free throw for a technical or flagrant foul (where they are alone at the free throw line and no one else is lined up on the key) will reach out and slap the hands of their imaginary teammates like they would after a normal free throw. I always wondered if it was superstition, unconscious habit, or a developed habit.

<comment><USER32> Makes me wonder if they practice that way. They probably don't break form and high-five a teammate when they're practicing...

</comment></comment><comment><USER33> (2017).

Previous discussion [https://news.ycombinator.com/item?id=14011793](https://news.ycombinator.com/item?id=14011793)

</comment><comment><USER34> It's effective for more than just safety. I suffer from mild anxiety over whether I have taken certain actions in a variety of every day scenarios. This behavior (pointing and verbally acknowledging) helps me cope with that sense of unease.

<comment><USER35> That makes sense to me. Logging and measurement are also used for this purpose --increasing productive control over a (human in this case) system.

</comment></comment><comment><USER36> I came up with a new phishing avoidance scheme based on this, point at the url bar before typing your password.

</comment><comment><USER37> "I'm reading an article on HN about Japanese rail workers pointing at things." "Done."

"I'm composing a snarky comment about Japanese rail workers pointing at things." "Done."

"I'm pressing 'add comment' to post a snarky comment about Japanese rail workers pointing at things." Wait, what? No. I know better than that. Abort.

</comment><comment><USER38> It's kind of strange to see a country as dilligent as it is, and obsessed with flawless execution as one finds its citizenry to be (Japan really does make some of the best stuff) that there's some sort of emotional toll that leads to a high suicide rate and low birth rate.

Which is really a bummer, because on some level you tend to think, to buy into a stereotype, that the Japanese have their shit together, and you admire that, but the negative space of these qualities is that they never step out of line, and when they do, it's the end of the world.

<comment><USER18> It's.. not really that. The step-out-of-line thing, I mean. But the pressure on young people is extremely hard, it's literally passing an exam to enter every step of your education (exam when finishing a step, a new one to enter) from kindergarden and up (and even earlier, for really obsessed/concerned parents). Extremely long hours (and a lot of that comes from culture, so yes that's also a part) for students and workers alike. The moment you feel unable to handle the pressure things will fall apart quickly.

</comment></comment><comment><USER39> One of the most interesting things I saw on the rails when I was in Japan this year was on the Shinkansen (Bullet train) from Kyoto to Tokyo (and back again).

Every time the train guard went through, when he got to the front of the door he'd turn around, do a 180 spin to face the passengers and give them a salute before 180 spinning back and going to the next carriage in front. I know it's a cultural thing but it's a nice touch.

<comment><USER18> Yes, it is nice, isn't it? I remember the first time I came to Japan. From the airplane I could see three of the baggage crew -- white gloves, and all three of them did a bow to the airplane before they started working.

</comment></comment><comment><USER40> This is interesting, I remember watching "Carrier" and noticing that the 'shooters' at the catapult controls followed the same process of pointing at their board (and even out the window at the plane) as they went through their launch checklist.

<comment><USER41> All aircraft handlers use hand signals, such as the crew who direct the plane on deck after landing, the crew that directs the jets onto the catapult, the catapult deck crew, and the pilots.

</comment></comment><comment><USER42> Similarly for climbers: [https://opp.uoregon.edu/climbing/topics/signals.html](https://opp.uoregon.edu/climbing/topics/signals.html)

<comment><USER43> True, didn't even think of it, I don't like climbing with people that don't do this.

</comment></comment><comment><USER44> This also works for stuff like switching off the stove or locking the front door. If you find yourself second guessing whether you did it...just narrate the activity as you do it. Sticks much better

</comment><comment><USER45> Why drop the "why" from the title? Without it I assumed this was about behavior they carried over from what is otherwise just another mandatory workplace policy.

<comment><AUTHOR> I used the marklet to submit this directly, so it got lost somewhere in the automated process - it wasn't deliberately omitted.

</comment></comment><comment><USER46> I am not sure I understand how it works, but if I had to take a guess it is because normally your thoughts and attention are invisible to others, but if policy mandates you to use body language to indicate your attention, then the employee realizes any lapse in attention will be visible from afar, so the employee who doesn't want to be seen losing attention it becomes mandatory to constantly show that yes you are in fact still paying attention...

</comment><comment><USER47> 'Shooters' in a US aircraift carrier doing 'point and call', showing you can have fun and be safe at the same time: [https://www.youtube.com/watch?v=GFqlwAWuMTg](https://www.youtube.com/watch?v=GFqlwAWuMTg) It's a choreographed checklist, which is great because others can notice if you miss anything.

</comment><comment><USER48> I've learned that the best way to make sure I don't forget to put my phone charger in my purse when I go to work in the morning is to point at the outlet and say "Charger, set!".

I got the idea after the last time an article about this phenomenon was posted, and it's worked beautifully since.

</comment><comment><USER49> If Japanese rail does x, x is probably worth looking into.

<comment><USER50> Best start wearing white gloves then!

<comment><USER51> Wouldn't be surprised if maintaining a crisp uniform is part of keeping up a sense of attention to detail, which again, would feed back into safety/efficiency.

<comment><USER52> I was at an arcade recently that had these "denshade" train driving simulators. The cabinet had an uniform to put on.

It sure helped get into the role.

</comment></comment></comment></comment><comment><USER53> I think it's neat. It visually and auditorily confirms to others that you are checking what needs to be checked, and reinforces the check in your own mind, letting you think about whether _you_ are doing it properly.

Similarly, Japanese sysadmins must write down -- and get approval for -- every single shell command they intend to execute on prod before actually issuing the command, specifically to reduce the number of 'rm -rf /' oopses (and other breaking changes).

It may look unusual, but I wouldn't call such a thing silly. I've noticed that Japanese workers do just about everything so patently deliberately that there must always be a reason for it being that way.

</comment><comment><USER54> I do this in every day life, it makes sure I don't forget things and gives me assurance that I did it. no more "did I turn off the oven?"

</comment><comment><USER55> I see this all the time on the New York Subway too when conductors lean out and point. Must be the same thing?

<comment><AUTHOR> Yes, and it's been mentioned both here in this thread[0] and in the article itself[1].

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

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

</comment></comment><comment><USER56> If I point at my code will I make fewer mistakes. :-)</comment>


Advanced Redis Tutorials - <AUTHOR> https://github.com/iamtrk/advanced-redis

<comment><USER2> I was hopping to see like this [http://tarantool.org/doc/book/replication/index.html?highlig...](http://tarantool.org/doc/book/replication/index.html?highlight=replication) but for redis.

</comment><comment><USER3> That's taking the term "tutorial" quite loosely...

<comment><USER4> Also the term "advanced"... :) But it looks WIP so maybe it'll pick up</comment></comment>