Ask HN: What do top engineers you know do that others don't? - <AUTHOR> Just wanted to get into the top 0.01% axons. :> <comment><USER3> I boil it down to two things:

#1 Rapidly Climb Learning Curves

The ability to quickly learn enough about new subjects to be useful. New technologies or APIs; new algorithms; mathematical or statistical subjects; and most importantly, your problem domain. Some of this ability is a skill, "knowing how to learn", which covers google-fu, reading comprehension, prioritization, time management, etc. Some of this ability comes from having enough aggregate experience that new information just clicks into place like jigsaw puzzle pieces. Some of this ability comes from the confidence of having climbed enough seemingly insurmountable learning curves that this next one is "just another day at the office".

A sign you're doing this wrong: "I need training!"

#2 Understand The Customer

IMHO, the best engineers are half product managers. You can easily get a 10X improvement in productivity by building the right features and not building the wrong ones. Yes, professional product managers are great, but technical limitations often impact product design. A great engineer knows when to push back or suggest alternatives. This requires empathy not only for the customer, but for the product management team. This ability is also tightly coupled with #1 - you need to quickly come up to speed on the problem domain, whatever that may be. If you wan't to be a great engineer, don't study algorithms (until you need an algorithm, of course), study the particular business that you're in.

A sign you're doing this wrong: "Whatever, just tell me how you want it and I'll make it that way!"

<comment><USER4> That's a rather poor attitude you have toward your colleagues if any of them dare suggest they need a little training.

<comment><USER3> "I need training!" says that _you_ need to figure out how to make _me_ good at this role. It shifts responsibility onto the organization; if I suck at the job, it's someone else's fault. A great engineer figures out what to do no matter how dysfunctional the organization.

It's not that it makes you a _bad_ engineer if you can't thrive in an imperfect organization. All organizations are varying levels of imperfect. _Great_ engineers figure out how to be great anyway.

<comment><USER5> What if training is simply the most efficient way to get the required knowledge and it has nothing to do with the level of perfection of the organisation?

<comment><USER6> Maybe, but it means the guy who can teach himself via google is going to get his similar project done a lot faster.

<comment><USER5> I don't think Googling is the fastest way to learn things in general.

But I was mostly thinking of stuff that can't be found on Google, e.g. the last time I said I needed training was when I was going to do maintenance at some company, on some internal application that I had never seen. I didn't know the domain either. But I had heard that a two-day training course for users existed (also given by internal people). So I said I wanted that training (developers before me hadn't), people thought that was a good idea and it turned out to be very helpful.

</comment></comment></comment></comment></comment></comment><comment><USER7> * Better googling. Time-restricted, url restricted, site restricted searches. Search with the variant parts of error messages removed.

* Read the source of upstream dependencies. Fix or fork them if needed.

* They're better at finding forks with solutions and gleaning hints from semi-related issues.

* Formulate more creative hypothesis when obvious lines of investigation run out. The best don't give up.

* Dig in to problems with more angles of investigation.

* Have more tools in their toolbelt for debugging like adding logging, monkey-patching, swapping parts out, crippling areas to rule things out, binary search of affected code areas.

* Consider the business.

* Consider user-behavior.

* Assume hostile users (security-wise).

* Understand that the UI is not a security layer. Anything you can do with PostMan your backend should handle.

* Whitelist style-security over blacklist style.

* See eventual problems implied by various solutions.

* "The Math."

<comment><USER8> > _Assume hostile users (security-wise)._

Ah, a personal favorite of mine which often makes other people uncomfortable.

1\. Users are like Marines, if it can be broken, it will be broken. If it's use is not clearly marked, it will be used incorrectly. If it can be fucked (literally or figuratively), it will be fucked.

2\. Users are malicious and are actively trying to backdoor everything you do. Why? Because it's the first thing I do with a new product / what I do with the competitions products.

3\. It is the developers responsibility to mitigate the above cases.

<comment><USER9> > If it's use is not clearly marked, it will be used incorrectly.

In my experience clear markings aren't enough to stop it being used incorrectly.

<comment><USER8> Ah yes. Should be revised to "unless it is clearly marked, it will rarely be used as intended. Even when clearly marked, users will misuse in ways you couldn't imagine"

</comment></comment></comment></comment><comment><USER10> One thing I havent seen posted which I mention in threads like this one anywhere I am online: humility

I don't care how good you are, if your personality is hostile and toxic, you're not making the team productive. If you can't take honest feedback during peer review, or QA or even from the client, then you need to evaluate why.

The best engineers I know are humble. They don't freak out when you point out a bug, they look into it and figure it out, then they share with you what they found vs what you found in order to determine if it is indeed a bug. Then there's developers that think all their code is perfect and sacred. Nobody likes working with those kind of developers.

<comment><USER11> There is a grey area where a non-technical manager wants to make a decision without understanding the long term impacts of that decision. Is the good engineer submissive here and go with the flow or does the good engineer put their foot down and suggest that that is not a good idea?

<comment><USER10> No, of course not. Humility doesn't mean you become completely submissive. There's a fine difference between a great engineer blurting out "THAT WILL NEVER WORK, WHAT ARE YOU EVEN SAYING!?" and... "Hey, Jim, I think that's a reasonable proposal, however, I have some concerns ..." which do you think sounds like the professional / good engineer, and which one sounds like a Junior whose ahead of themselves?

I've met people who literally believe humility to be a weakness, I think a lot of people misunderstand what it means to be humble these days.

<comment><USER11> It is one thing to understand that you are not perfect and you could learn something from everyone and to respect your co-workers.

It is another thing to be a legitimate expert and to not voice your opinion to avoid conflict. I have seen smart people who avoid direct conflict at all costs. Even if that means working on something you know is a bad idea.

<comment><USER10> They do it out of fear of conflict probably, or in other cases you're so burned out you don't want to argue anymore. I've been burned out enough to where I didn't care anymore I just wanted it to be over with.

</comment></comment></comment></comment></comment><comment><USER12> 1\. Don't bitch about legacy software

2\. Are willing to help with getting proper requirements

3\. Don't need a JIRA task for everything

4\. Don't say they are done if something is untestable

5\. Are willing to do stuff other than their skill (eg. one of the graphics required for the project is too big, top engineer opens up gimp, resizes and continue. Bad engineer will report to manager that design team did shitty job, reassign JIRA ticket, write two emails and wait for new a graphic)

6\. Top programmers deliver well packed, documented software, keep repository clean with easy setup steps accessible for everyone.

7\. Top engineers enjoy what they do, and are making the project enjoyable for everyone, keep high morales and claim responsibility

<comment><USER13> > 3\. Don't need a JIRA task for everything

Genuinely asking: how so? Tickets are not just some bit of bureaucracy, they are also a living log of what has been done and why that thing was done.

<comment><USER14> My personal heuristic: if it is worth doing, and it takes less than an hour -- just do it now. Organize your team so engineers feel free to knock off quick tasks at their discretion.

If you try for an hour and it's still not done -- make a ticket.

There's nothing more annoying than seeing the same trivial task get shuffled around 4 sprint planning meetings, taking mental overhead from 8 people.

And nothing comes out of sprint planning with less than a quarter day allocated. You've turned a 20-minute task into a whole day of wasted effort.

<comment><USER13> > My personal heuristic: if it is worth doing, and it takes less than an hour > -- just do it now.

Sure, but that doesn't mean you can't create a ticket for it. It just means that you have tickets which fall outside your sprint planning flow.

<comment><USER14> My point is that the overhead of writing up a ticket description becomes a significant fraction of the total work involved. Write a commit message if you want it documented.

There's no need for a ticket for small tasks, unless you are being evaluated on number of tickets closed (which is a separate problem)

<comment><USER15> Like all things in life it depends on the team and workflow. I have my PM's make tickets because many times I am in the middle of a different feature or bug and don't want to have to have the mental load of remembering what the issue was. Secondly I work with very solid PM's who document the ticket very well and it saves me time having to reproducing the issue. My team does have a lot of tickets but we make it work for us and our process flow.

</comment></comment></comment></comment></comment></comment><comment><USER16> I can't recommend Gary Klein's Sources of Power enough, it is stuffed with awesome mental models, real life parables, research findings, and one quotable passage after another on expert decisionmaking.

From the book, things experts do more/better/faster/etc than novices.

* Identify patterns faster and successfully predict future events more often.

* Recognize anomalies - especially negative anomalies i.e. something didn't happen that should - quickly and take appropriate actions.

* Identify leverage points within their architecture to solve new problems and deliver new features faster and with less effort.

* Make finer discriminations of events and data, at a level of detail novices don't consider.

* Understand the tradeoffs and consequences of an option.

* (I like this one) Recognize expertise in others and defer as many decisions as possible to that expertise.

* Their ability to "context switch" when describing a situation to other experts vs novices vs non-particpants.

And one that's not explicitly from the book but is contained in its wisdom:

* Skate where the puck is going, not where it is.

<comment><USER17> All great advice - will have to check out the book

</comment></comment><comment><USER18> 1\. NEVER practice Coincidence driven development.

If you get lost, and no longer know why something is not working, do not just keep fiddling and changing things.

Simplify the problem. Disable all confounding variables and observe your changes. Open up a repl and try to reproduce the issue in your repl.

Read the source code of your dependencies. I have seen this a lot: People fiddle with dependencies trying to get them to work. Crack the code open and read it.

2\. Choose your battles. Not every hill can be the one you die on. You cannot control every part of a code-base when you are working on a team. People are going to move your cheese and you need to learn to not let that affect you.

3\. Learn to lose. Similar to the last one. Treat technical discussions as discussions, not a competition. Use neutral language that frames your ideas as NOT your ideas, but just other options. Keep an open mind and let the best idea win.

4\. Write tests. There are outliers here, but the majority of talented engineers I have worked with are all on the same page: If you don't have tests, you cannot safely refactor your code[0]. If you cannot safely refactor your code, you cannot improve your codebase. If you cannot improve your codebase, it turns to mush.

5\. Simplicity is golden. Keep your projects simple, doing the bare minimum of what you need, and do not refer to your crystal ball for what you might need later. Single responsibility principle. Keep your Modules and your functions simple and small, and combine them to create more complicated behaviour.

6\. Quit shitty jobs. If you are not learning at a job, or they are abusing you, you need to get the hell out of there. Burn-out is real. Burn out on something cool that helps YOU, not pointless toil for some corporate overlord.

0: Martin Fowler's Refactoring 2nd edition

</comment><comment><USER19> I call myself a scientist, not an engineer, so I conveniently rule myself out of contention. But I think the best engineers...

* Multidisciplinary

* Quantitative

* Scientific

* Curious, skeptical

* Thorough

* Willing to abandon a bad idea

* Willing to advocate a junior colleague's good idea

As an add-on question: Which of the properties mentioned in this thread do your organization actively drive out of people?

</comment><comment><USER20> Know when the juice is worth the squeeze, whether it be a refactor, a political fight, or even the job itself. There are not a lot of hills I'll die on anymore, while when I was younger everything seemed life or death. Now I got other things to worry about.

</comment><comment><USER21> A few I don't see mentioned:

They are strategically lazy, putting a lot of thought into how to simplify at all levels. Great engineers loathe complexity and indulge in it reluctantly. Solutions should never be more complex than what the problem domain demands.

A corollary to above: they use language features and constructs to solve problems, not to show off how smart they are by constructing the most "clever" bit of language gymnastics with which to waste the time of those who have to maintain the code later (including the author!).

They know assembly language and the basics of CPU architecture regardless of what language they use so they understand what is actually happening. They also have a grasp of other aspects of the system like networking and storage even if they do not do much with those directly.

They know the history of computers and computing and how things have been done at various points in the past. This helps them spot fads and rediscoveries of old things that have been tried already as well as generally deepening understanding.

They are skeptical of fads and don't instantly adopt whatever thing is trendy unless it's a genuine improvement.

</comment><comment><USER22> The best engineers I've worked with always ask the question "what are we trying to solve here" whenever working on something that involves more than a trivial time investment. Nine times out of ten, answering that question clarifies critical issues and avoids going down to a high cost path.

</comment><comment><USER23> They have a great mental model of the inner workings on the product. Even for a part of a code they haven't seen in a long time. When you debug code with such a person, you notice that they seamlessly translate the piece of code on the screen to the mental model and back (it probably takes hours for Jr engineers to piece those together). Neo deciphering the matrix is a good analogy.

</comment><comment><USER24> * More interested in working methodically than frantically. (If the alarms are firing but they still follow method over shotgun approach.)

* Reads the docs of dependencies rather than blindly googling.

</comment><comment><USER25> 1\. Research & Finalize architecture design before jumping to code

2\. Take code as documentation. This helps to debug things faster

3\. Focus more on problem solving than language/tool priorities

4\. Listens more and always towards exploring and experimenting new things. This improves breadth knowledge

<comment><USER26> 1.5. Be willing to rethink the architecture when it turns out problematic. I have seen systems that probably looked good as a diagram before a line of code was written, but had to work around their own architecture with gross hacks.

Architecture is important, but organizations employing "software architects" tend to be bad at software.

<comment><USER26> The second part may read as a non-sequitur. The connection is that in organizations that have separate architect roles, architects are shielded from their mistakes because they don't work on implementation, and their work usually isn't questioned.

The worst thing I remember is a web API where some call could fail but didn't tell you, it just gave you some kind of plausible looking inert data. The call to query system status was separate, so there was always a time of check / time of use problem. Also there was a transition period when the original call did return an error but the system status API didn't yet. Nobody (I hope) comes up with such a disaster while implementing and testing it.

</comment></comment></comment><comment><USER27> The #1 trait is they will dig until they fully understand the problem. When writing code if the first draft Is not good they will rearchitect until it makes cohesive sense.

Time spent getting it right the first time saves significantly more time than dealing with the fallout of not doing the right thing.

<comment><USER28> So many people stop when it works, without understanding why it works. Or not caring how ugly it is.

They have no long-term perspective about the future cost of support - <USER2> bugs, adding features, or just understanding what was done.

When something changes and their snowflake solution breaks, their first reaction is to blame the external change for causing their poor solution to fail.

Top engineers don't do this. They understand why their solution works, they know its limitations, and their solutions are understandable and supportable. This significantly lowers the total cost over time and is what helps projects deliver on time with quality.

<comment><USER29> > So many people stop when it works, without understanding why it works.

Most work environments train programmers to act that way. I find this is especially the case at workplaces that (sort of) follow scrum and agile. In most of these places, junior to mid-level programmers are given a task to work on that already has an hours estimate on it. Managers like to optimize efficiency and programmer time, so that estimate is always tight. Asking why we're doing this task is rarely received well and the tight time estimate means there's barely time to make the change work in the first place, let alone understand why it works.

We're literally training our devs not to be top devs.

<comment><AUTHOR> The reverse side of the coin is an engineer who has complete leeway on what they do and they spend time "redecorating" their code ad nauseam. I think there is a golden mean to be found.

</comment></comment></comment></comment><comment><USER30> Key to good app performance starts at the data structures used in the app. If those algorithms have good run / insert time the app will run good. Cache layers is another key to good app performance.

It is important to test the code base.

The central bank system is making every day people poorer as they print new debt. They got wage inflation imported from cheap globalized goods wrong. This part is annoying to know since most do not understand this flow fully. It's engineering but financial such. New printed money is flowing to automation and are deflationary. Understanding other engineering areas other than your own field and seeing strength/weaknesses in those.

</comment><comment><USER31> # Prefer simple or replaceable solution. Avoid unnecessary layer of abstraction. If you can't explain to others within a few words, you will forget how it works and it will be unmanageable few months later.

# Prefer un-opinionated framework. This comment is opinionated. From my own experience, opinionated framework only looks good in the first 5 minutes. You always need to implement a more difficult solution to solve problems afterwards.

# Offload your task to your subordinates People can only gain experience by failure. It won't become a serious problem if you can give guidance and review. The major benefit is you can spend more time on anything else.

</comment><comment><USER8> 1\. Knowing when it's okay to implement a "good enough" solution versus taking the time to implement the "academically correct" solution.

Or otherwise put, knowing when to do things by the book, and when it's okay not to.

<comment><USER32> I'd go further:

\- knowing how to make the solution "the right level of good", as opposed to "academically perfect" or "unmaintainable hack".

\- being able to design and implement a "good enough" solution that is still reasonably maintainable (if needed) much better and/or faster than others

<comment><USER8> "Correct enough" is the phrase I usually use here.

Knowing where on the scale to set that mark requires being able to bridge speed of implementation, execution, maintainable, upgradability and the overarching business goals you're building for.

So really a broad range of understanding that only "excellent" senior developers will possess

</comment></comment></comment><comment><USER33> The most impressive engineers that I've worked with were great at focusing on the task at hand and finishing them without getting distracted by other issues that they came across in the process. They didn't optimize things prematurely or try to come up with new abstractions for things that might come up in the future. They didn't get into stupid arguments over minor details and were focused on completing and shipping features.

</comment><comment><USER34> Have the ability to distinguish causes from symptoms.

</comment><comment><USER29> They're interested in things other than their primary domain. Some of the best web developers I know spent some time making video games, programming microcontrollers, designing telecommunications systems, etc. They take the experience and knowledge they've gained from those other areas and use them to make better web applications.

</comment><comment><USER35> Being able to type/write accurately and quickly. Seriously overlooked skill.

Huge in the terminal, huge on the business/product side.

</comment><comment><USER36> A lot of good points were made. I'll add one I think was missed (and I'll avoid the title "engineer"): A top developer knows that the stack does not matter to the user. The stack provides interest or a familiar or economical grounds to said developer but the user - they couldn't care less.

</comment><comment><USER37> Tact: They have a broad and inclusive means of understanding/managing perceptions, and motivations that starts from humility.

Their ability in troubleshooting, problem solving, risk-assessment, is detail oriented, and seeing the forest for the trees. Being keen-sighted, and maintaining a field of view, and depth of field.

Informing, teaching, educating: They have a pervasive means of being able to explain, walk through a problem and/or solution to a verity of audience types. Some of the best at ELI5.

Understands the Intent, over just the labeled end goal. (As basically what the US Military defines Intent as.)

Ability to give and take critique (also sharing with Tact above). This always seems to infer just the negative, criticize/criticism, and the opposite is often overlooked.

</comment><comment><USER38> If you're working at the edge (or beyond) of your competency _that's normal_.

</comment><comment><USER39> They understand the difference between essential and accidental (I prefer the term incidental) complexity. This isn't a simple categorization as something that may seem extraneous, may have a near-term benefit making it somewhat essential. What's absolutely undesired is that which is added by complex designs that serve no pragmatic purpose for the user or developer, other than the satisfaction of an executed grand design. This can sometimes be summed up as that uncommon form of common sense.

</comment><comment><USER40> Great thread, great answers!

Follow-on question: OK, so how does your company's interview process test for these traits?

It's mind-boggling to me how many organizations understand that the most important traits of a great engineer are "soft skills" (how many answers here are about really understanding big-O complexity or pointer math?)... and yet are content to interview candidates with whiteboard algorithms problems.

Interview for greatness, not for having-brushed-up-on-Djikstra's-ness!

</comment><comment><USER41> * Consider ethics first.

* Happy to ask the uncomfortable questions early.

* Will ask technical questions proactively without caring about maintaining face.

* Has good discipline and communicates well.

</comment><comment><USER42> The best engineers I worked with were very respectful of my work (UI Design) and were always happy to share their knowledge. They also ask me questions and ask me about how we can do things better. They are constantly looking for ways to improve our products for the customers, in contrast to the developers who have an attitude of "this'll do".

</comment><comment><USER43> There are many qualities, which have also been listed by others but I found to be extremely common is this:

Be very organized / systematic..

\- in their thoughts and how they articulate their points during discussions

\- in building their personal knowledge base

\- in how they approach problems, be it during solving a customer problem (adding a new feature) or debugging code

</comment><comment><USER44> Trust your intuition, but don't be a dick. Pick your fights. Software is more art than science. Learn from those who have gone before you. Also: [https://www.youtube.com/watch?v=E86phiV8w2M](https://www.youtube.com/watch?v=E86phiV8w2M)

</comment><comment><USER45> One thing I haven't seen mentioned yet that I think to engineers do is read the side code of the third party libraries and frameworks that they use. Usually when they are trying to figure why something is broken, but sometimes just when they are learning how to use it.

</comment><comment><USER46> Then don't hesitate when choosing a simple and maybe old-fashioned solution if it's the right one for the problem. This could go from simple algorithms, database engines, languages, to architectures and system design.

</comment><comment><USER47> If you believe Uncle Bob Martin it's the ability to pair. He recently tweeted "If you don't like pairing, don't pair. But be prepared for the folks who have developed the pairing skill to fly past you."

</comment><comment> chance-name The best engineers I know do their best to discover the core problem. They ask why a problem should be solved. They also challenge "known" assumptions and do their best to discover the real constraints to a problem.

</comment><comment><USER48> Top engineers understand. The hardware, the OS, the protocols.They use that understanding to solve problems. The comprehension is the differentiator between top and anyone else.

</comment><comment><USER49> listen this talk by DHH you might get an idea

[https://www.youtube.com/watch?v=9LfmrkyP81M&app=desktop](https://www.youtube.com/watch?v=9LfmrkyP81M&app=desktop)

<comment><AUTHOR> I had missed that video, it's great!

</comment></comment><comment><USER50> From 50,000 feet: \- Top engineers are able to solve a problem, and are hired to do so. \- Others are able to solve tasks, and are hired to do so.

</comment><comment><USER51> Are there any books you know that have been recommended to you by top engineers? Preferring recommendations for books with exercises.

</comment><comment><USER52> They're better owners. They ship, and follow up on bugs until they're proud of what they shipped.

</comment><comment><USER53> Whenever someone talks about senior engineers, two close friends spring to mind immediately, one of which is my brother (software development).

Even Though I am convinced that experience (and thus age) contributes to the segregation between engineers and _senior_ engineers, I also think that it is a special frame of mind which enables some people to truly become the top of the crop. Despite my inflated self image and overly optimistic assessment of my own intelligence, and despite the fact that I am convinced I would have little trouble convincing an f500 company to give me the title of senior engineer, I know that I can never attain the 'seniority' my brother and friend already possess.

Having scanned through the responses, I didn't immediately see the specific behaviors I have found in top engineers. First of all, I disagree with the humility trait. I would not call top engineers humble. I would not call them arrogant either. Top engineers have strong opinions, yet are flexible. They have their ideas about best practices, yet are 100% comfortable adopting something else.

Using a stupid example in software development, tabs or spaces. Number of spaces. Top engineers will have their preference, whichever it is. And they have thought about it, deeply. Not just from their perspective, but from the perspective of all engineers, future, present, and past. You may probe as deeply as you want, they will have looked at it from every possible angle and will be able to explain to you in every detail why they prefer the one over the other. And! This is so, so important... And! They will put their preferences immediately to the side if that's just not how things are done on this particular project, in this particular team. I wish I had better words to convey this thought...

Top engineers will work with what they have to get to where they want to go. And, that's not just the technology, it's also the team. Senior engineers in your team will automatically make everything better. Sometimes their value is educating the entire team on best practices, sometimes it is just driving towards success despite the all of the feces.

Sometimes they might come over as arrogant, because they can speak with confidence on certain topics. That's another thing that sets top engineers apart from junior and regular engineers, whenever they speak with confidence, it is because they are in fact confident. And they are only confident when they have analyzed an issue sufficiently deeply and from everyone's perspective that they are comfortable being probed deeply.

When they do not speak with overzealous confidence, it is because they are still learning about the subject. And they will learn and analyze it deeply if that is necessary.

A single inconsistency, or a single counter example, or even a single ambiguity is sufficient for them to reconsider their position completely.

Also, senior engineers will never assume they know anything. They tend to listen attentively whenever anyone is talking. When someone says something 'stupid' they won't assume that the person is stupid, or said something stupid, they will assume they did not understand something and ask for clarification. They tend to not jump to conclusions... If something is ambiguous, they will identify it and ask for clarification. As a result, they will often ask for follow-ups in the future... such as: "Thanks for the information, can I get back to you if I have more questions?" Now that I think of it, I don't think I have ever seen someone whom I consider to be a top engineer not keep that door open....

I hope this helps.

</comment><comment><USER54> Maybe some don't subscribe to narcissistic worldviews.

</comment><comment><USER55> Play video games. I am actually serious.

<comment><USER56> I'm curious, could you please elaborate?

<comment><USER55> Much like a codebase, some of the brilliant engineers I've met relish the video games that lets them scour around the universe, think about strategy, and get into action. It's like watching someone attempting an Olympic weight- lift move.

<comment><USER57> What games do you recommend?

<comment><USER55> Unfortunately I don't play games myself. But Anno 1800 is something my very good colleague plays these days.

</comment></comment></comment></comment></comment><comment><USER58> Care about their responsibilities

</comment><comment><USER59> De-risk. De-risk. De-risk.

</comment><comment><USER60> They say No.

</comment><comment><USER61> Abstraction.

</comment><comment><USER62> Code all day and all night.

<comment><USER63> For the most part, no. That's what wannabes do, trying to prove they're top engineers. Most top engineers quit when they're tired, because they know that if they keep going when mentally tired, they create more problems than they solve.

There are a _few_ top engineers that get bored when they're not coding, rather than getting tired after doing it too long. But that's kind of orthogonal to whether they're a top engineer or not. In over 30 years, I've known _one_ person who was both a top engineer and a "code all day and all night" (or at least all evening) person.

<comment><USER62> You just said I was right lol

<comment><USER63> Wrong. Doubly wrong, in fact. Wrong in your first post, and wrong now. I did not say you were right, no matter how you try to spin it.

</comment></comment></comment></comment><comment><USER64> UX don't matter

</comment><comment> rv-de overengineer and prematurely optimize everything because a pragmatic approach to software development is too boring and you couldn't use a lot of fancy tools and features otherwise.

tongue in cheek, yes, but with a grain of truth, I'd argue.

<comment><USER63> I'd argue that those who do so are "top engineers", but not actually top engineers. They have the reputation (especially in their own minds), but they're not the real deal.</comment></comment>


How car dealers tie Detroit's hands - <AUTHOR> http://www.newyorker.com/archive/2006/09/04/060904ta_talk_surowiecki

<comment><USER3> Isn't this exactly what bankruptcy is for? Put GM in a pre-packaged bankruptcy ([http://www.investopedia.com/terms/p/prepackagedbankruptcy.as...](http://www.investopedia.com/terms/p/prepackagedbankruptcy.asp)), and one of the planned actions should be shedding these unprofitable brands and severing the relationship with these dealers. The dealers made a bad bet on a brand, they are entitled to nothing.

<comment><USER4> > severing the relationship with these dealers.

That's actually hard to do - there's a myriad of state and federal laws that make this all but impossible. It cost about a billion dollars for GM to deep six the oldsmobile brand, buying out old dealers franchises, etc...

<comment><USER5> IANAL, but can't they just stop renewing the franchise contracts? It would take a few years, but eventually they would be off the hook at ~zero cost.

Another option might be to simply stop updating the models of a given brand. Dealers survive for a few years servicing the currently existing models until they eventually switch to other brands.

<comment><USER6> "IANAL, but can't they just stop renewing the franchise contracts?" - <USER2> will cause the dealers to revolt. And as the article says, collectively they have the states in their pockets.

There's no way for GM to strip the dealers of their franchises without the dealers fighting back. Without the big stick of Chapter 11, GM doesn't stand a chance.

</comment></comment></comment></comment><comment><USER7> I've never really seen the appeal of franchising. You get a packaged business, but then the franchiser has you by the balls forever. Plus what I've read suggests that most franchise owners barely eke out a profit. Car dealers are probably better off, since they have service revenue independent of the parent company, but they're still dependent on a single supplier.

<comment><USER8> "McDonald's exemplifies the role of small businesses in Americans' upward mobility. The company is largely a confederation of small businesses: 85 percent of its U.S. restaurants -- average annual sales, $2.2 million -- are owned by franchisees. McDonald's has made more millionaires, and especially black and Hispanic millionaires, than any other economic entity ever, anywhere."

\-- [http://www.washingtonpost.com/wp- dyn/content/article/2007/12...](http://www.washingtonpost.com/wp- dyn/content/article/2007/12/26/AR2007122601485.html)

</comment></comment><comment><USER9> This article parrots Detroit's "take what you're given at shut up" view. Dealers see things differently. My family ran two automobile dealerships. The one that dealt with Detroit (Ford) had little choice in what they were given to sell, and complained in particular of Detroit shoving lots of big cars and trucks at them when the demand was for a size or two smaller.

</comment><comment><USER10> Why don't they just stop making Buicks? Or are they obligated to provide a certain number per month?

</comment><comment><USER11> a billion to kill a brand that costs you money is not that bad. It costs them something like 1-2 billion to bring a car from concept to production, so they'll save that money the first time they avoid having to redesign a new model.

But why kill? Sell it off...you are going to lose all that value anyways, so even if you sell Buick below market price, you still make more than if you just close the doors

<comment><USER12> To put that "billion dollars" in perspective, General Motors' current burn rate is apparently $6.9 billion a month. Ouch!

</comment></comment><comment><USER13> Don't Honda and Toyota have the same problem? They seem to be coping.

<comment><AUTHOR> Honda and Toyota aren't wishing they could shed unprofitable brands.

<comment><USER13> True, but I also have to wonder how big a deal an "unprofitable" brand is. If the brand was genuinely unprofitable, wouldn't the problem dealers eventually go out of business?

And how much does it actually cost to keep a brand alive? Can't GM just slap a Buick label on a Cadillac and ship however many of each are needed?

<comment><USER8> You can't put a Buick logo on a premium car like a Cadillac. First, a Cadillac costs more to make than people are willing to spend on a Buick. Second, doing that would reduce the demand for Cadillacs (since nobody wants something that is the "same as a Buick").

For non-premimum brands, GM and other manufacturers already do sell the same car with different names--even across coompanies. Most obviously, the Eagle Talon is/was the same as the Mitsubishi Eclipse except for the spoiler, and the Chevy Camero and the Pontiac Firebird were the same car with different body trim for a long time. Similarly, the Ford Taurus and the Mercury Sable are the same car except for some body styling. Toyota Corolla is the same as the Geo Prism, the Toyota Matrix is the same as the Pontiac Vibe, Ford Focus is sold under three different brands.

Doing this keeps the prices of the good brands high while selling cars for a discount when necessary. If you bargain the price of a Ford Taurus down far enough, the dealer will tell you that you can't have the Taurus for that price, but you _can_ have the equivalent Sable.

<comment><USER6> He wasn't arguing that you could turn a Buick (cheap car) into a Cadillac (expensive car). He was arguing that if they can't entirely dispose of a brand, they could turn a Buick (car labeled a Buick) into a Cadillac (car labeled a Cadillac) with a simple label change.

A Cadillac is a car that has been labeled a Cadillac by the legal owner of the Cadillac trademark. Maybe "a car" is extraneous, too, though I suspect dealership contracts would have something to say about being turned into a Cadillac Pencil dealership. But still, I would imagine GM has a lot of discretion about what gets called a "Cadillac". (Maybe not, but that would be awfully far-sighted of the dealers to get a clause defining what a Cadillac is in their contracts and I would salute them for their legal prowess if they do have such clauses.)

Also, I have now typed "Cadillac" so many times it is no longer a word to me.</comment></comment></comment></comment></comment>


How I Upgraded My iPhone Memory 800% – In Shenzhen, China - <AUTHOR> https://www.youtube.com/watch?v=rHP-OPXK2ig <comment><USER2> Had a great time watching this video last night. What that man does in his videos is truly cyberpunk.</comment>


Rethinking Agile in an office-less world - <AUTHOR> http://37signals.com/svn/posts/3641-rethinking-agile-in-an-office-less-world

<comment><USER2> Perhaps the point of the article was to stir conversation, but I'd prefer it if they'd actually propose some ideas, rather than saying that it's different now.

I'm not a huge fan of Agile, but I do think it encourages some good ideas. That said, I'd love to hear what the analogs are for remote work from the perspective of a company that really does it.

<comment><USER3> To me, the point of the article is to promote the upcoming book

</comment></comment><comment><USER4> This is just a fluff article to tangentially promote their upcoming book, Remote. Why this is going to be upvoted is beyond me.

<comment><USER5> It is getting up voted because it is a real question for people. I've worked in a 100% remote environment for 5 years, and a part-time remote environment for another 4 on top of that.

Creating great software in those environments is a challenge, and worth discussion, regardless of the motivation of the original author.

</comment></comment><comment><USER6> One of the odd misconceptions I've had to deal with, 1/3 of one of my teams is offsite, is the idea that Daily Stand Up has to be in the morning. We change the question from "What did I do yesterday?" to "What did I do in the last 24 hours?"

Easy.

The next mountain is to change what is said from status to communication, which is the point of the meeting in the first place.

</comment><comment><USER7> These are largely solved issues. Standups can be done over a web chat, and may actually be even better with todays screen sharing capabilities, where you can actually SHOW everyone what you are working on. Tools like tmux have had the remote pairing issue solved as well. Face to face is good here and there, but I see no reason why agile cannot be practiced just as effectively remotely.

<comment><USER8> I believe this is what he means when he says "the hacks that makes that setup more workable". Your technological solutions assume synchronous work, which limits the pool of employable people to those with similar preferred workdays, where DHH would ostensibly like to work with people around the world.

<comment><USER7> Email or Voxer work for async communication.

<comment><USER9> I actually find 37s' Campfire works for both async and synchronous communication.

It's obviously a chat-room for immediate talking, but the highlighting and ease of scrollback (without having to have irssi or similar running constantly) mean you can easily catch up and pick out messages left for you when you were offline.

Which makes me think the post is just about the upcoming book.

</comment></comment></comment></comment><comment><USER10> I thought agile was supposed to be a preference for useful flexibility, rather than a fixed set of practices?

The canonical remote collaboration tools are IRC and mailing lists.

There are various sites that allow some sort of remote pair programming, I'm not sure if it's just screen sharing plus audio chat or if there's more structure to it.

At work we have conference calls, often with presenter-to-group screen sharing. (We use cisco webex, does anyone know an open alternative?)

For larger meetings we've been experimenting with videoconferencing between meeting rooms in different cities. Since being on video is annoying, maybe this would be an alternative to stand-up meetings? (I'm pretty sure whatever we use for this is proprietary as well, what's a good open alternative?)

The point of many Agile practices is to increase communication. How can you best capture the ease of walking 2 cubes over to have a chat with your coworker? If everyone's remote you don't have as good a natural indication of how busy or available everyone is. If you build something to provide that indication, the boss can monitor it and it will stop working right.

If people are talking in the next cube over, I can ignore it or jump in if I hear something interesting or that I can help with. But in some cases the discussions are things that wouldn't be discussed where certain other people might be able to overhear. How do you capture when communications should be _available_ to some part of the group without interrupting them (so no acknowledgement needed from the recipient), but hidden from some other part of the group? And without requiring the people initiating the communications to explicitly bother to set this up? This is naturally baked in to physical-world interactions, is it useful enough to try to duplicate?

I've heard suggestions of a "virtual office" for voice chat, where you have a grid layout with cubes or conference rooms or whatnot and people have locations on that grid and can hear eachother (or not) based on how close they are. Is there anything that actually does this? Is it useful (or if it doesn't exist, would it be useful to have or is it just gimmicky)?

From what I understand, electronic text-based communications tend to be archived for a long time for legal reasons. How far does this apply to voice communications, and does VoIP vs telephones make a difference? How far does this affect what is or isn't said? I know at work, some conversations only happen in person or over the phone rather than IM or email. How important is this effect, and how does it impact getting work done?

<comment><USER11> > I thought agile was supposed to be a preference for useful flexibility, > rather than a fixed set of practices?

It is. To too many people "Agile" means "Scrum" (or, whatever particular set of fixed practices they've adopted, but Scrum seems far and away the most common.)

<comment><USER12> It is, but the Agile Manifesto isn't, on the face of it, remote-worker friendly.

      6. Close, daily cooperation between business people and developers

      7. Face-to-face conversation is the best form of communication (co-location)

So, I can see why people think there's a need to work out how to do remote working in an Agile manner or to find a viable alternative.

<comment><USER11> Remote working is always a trade-off sacrificing communication bandwidth for some other gain. Mitigating that cost -- because the gains to be purchased with it are often attractive -- has long been an issue in Agile circles, and its not really a "rethinking" of Agile to address that.

Sure, the Manifesto states that Face-to-face conversation is the best form of communication -- that doesn't mean you can't use other forms of communication in an agile process, it means that you need to be aware of the costs and to do it only as a conscious decision weighing the communication costs against the benefits, and ideally doing what can be done to mitigate the communication costs.

</comment></comment></comment></comment><comment><USER13> <rant>This is nerd-bait, and I'm quickly getting my fill of "hey, we need to rethink things!" without there actually being any rethinking going on.

Yes, we need to rethink things. We constantly need to rethink things. Introspection is the root of all improvement. I think we've got that by now.

I don't mean to vent, but what the tech community is really interested in is _results_ , not more bloggers with opinions. Got plenty of these guys already. So show me you've tried something and it works, I'll collect the details, and over time and hundreds of experiments, we can start to draw some correlations. A few stories and an upcoming book ain't going to cut it.

What I'm seeing in the tech community is this rise of, for lack of a better term, dimestore pundits. Some guy gets a big contract for XCorp, tries working with people dressed up like chickens. Now he has a website and a book on how we're all supposed to dress up like chickens when we work.

It's always been like this -- the folks with the megaphones drowning out the folks who plod along trying to spot patterns and share stories without becoming dogmatic. But lately people are climbing on this bandwagon where in order to grow, you should be teaching something. So hell, everybody with a keyboard is now a teacher. That's not a recipe for helping folks, that's a recipe for generating widespread cynicism.

I wish the 37Signals the best of luck in these marketing efforts. I understand they're quite awesome. I just get tired of being baited with half-assed conjecture sitting on top of a few anecdotes. Things have changed. The world moves on. We're the tech community. We get that. So show me the startups that are changing the world with remote teams. Show me the consulting companies that are killing the competition by using distributed teams. Show me the companies that are clamoring for distributed and remote teams because they're finding them so efficient. Show me a bunch of data. Then you can wave your hands around and we can all have a nice sing-a-long about the brave new world we're headed into. Otherwise it's just self-gratifying noise.</rant>

<comment><USER14> Not nerd-bait...really you bring up some good points.

</comment></comment><comment><USER15> We have being doing Agile in distributed teams since 2006.

This is bit late, no?

<comment><USER16> No. Many people are have a bias against distributed teams, especially in the case of startups, since they believe that it's harder to collaborate, and because they prefer the feeling or appearance that comes with having an office.

<comment><USER15> Funny, that you give startups as example.

As stated on my previous comment, I have been doing Agile projects, with distributed team across the globe, in the enterprise world since 2006.

While it is true, that it had its share of issues while we were discovering how to apply agile concepts in a distributed manner, I would expect most of the issues would be quite known in 2013.

Specially in the startup world, which tends to be more flexible in regards to the enterprises.

The human factor is actually quite important, but in many cases it is not possible at all to have everyone on the same place.

</comment></comment></comment><comment><USER17> Please stop posting DHH shit. Going to his articles feels like I'm being Rick Rolled.</comment>


We May See a Chrome OS Netbook Mid-2010, But Not For Sale - <AUTHOR> http://www.thechromesource.com/we-may-see-a-chrome-os-netbook-mid-2010-but-not-for-sale/ <comment><USER2> Hopefully Google starts selling a developer version. I want one.</comment>


How to Choose Colours Procedurally - <AUTHOR> http://devmag.org.za/2012/07/29/how-to-choose-colours-procedurally-algorithms/ <comment><USER2> I'm somewhat late to the party, but I spent some time playing with procedural colour picking using space-filling curves (the Hilbert curve in particular). I describe the basic technique here:

[http://corte.si/posts/code/hilbert/portrait/index.html](http://corte.si/posts/code/hilbert/portrait/index.html)

And you can see what this looks like when used to visualize sorting algorithms at large scale here:

[http://corte.si/posts/code/sortvis- fruitsalad/index.html](http://corte.si/posts/code/sortvis- fruitsalad/index.html)

And here:

[http://sortvis.org/](http://sortvis.org/)

I've also published an Open Source project that might be useful to anyone who wants to play with these ideas:

[https://github.com/cortesi/scurve](https://github.com/cortesi/scurve)

There are some limitations to the process as described - most obviously the fact that I'm using the RGB color space which is not the best match for human color perception. RGB is convenient because it is a regular cube and therefore easy to map onto the Hilbert curve, but with a little work the process could be generalized.

<comment><USER3> Thank you for the explanations! I learned about Hilbert curves in part from your website before constructing a "color clock" some time ago:

[http://justinpombrio.net/show/color- clock.html](http://justinpombrio.net/show/color-clock.html)

</comment></comment><comment><USER4> One thing the article doesn't mention: getting a set of maximally visually distinct colours. The best algorithm I'm familiar with for this is to iteratively choose colours as far away as possible from each other in Lab space (while still being able to map into RGB). You can also make sure that the colours stand out against your background by pre-seeding the space with your background colour.

However, it's not a fast algorithm. The more colours you choose, the slower each iteration gets, since you have to calculate the distances from a growing set of colours. Also, after ~10, the distinctness seems to drop off pretty quickly. Lastly, assuming you're seeding with the same colours, you'll always get the same result, so it's really best to do the calculations once and then cache them.

<comment><USER5> That's not the worst method you could choose, but just be warned:

CIELAB space was designed with the goal that any pair of colors separated by about 1 unit (i.e. ΔE = 1) would have a similar degree of apparent difference. However, apparent color differences are a highly non-linear property, and so by the point ΔE gets past 5 or 10, a specific color difference in one direction or one part of the color space will be substantially different than a same-distance color difference in another part of the space.

Often, the reason you want to carefully pick a color scheme is to make sure that two areas of a graphic are easily visually distinguishable along an edge. Because human vision mainly uses a monochromatic color signal for distinguishing shape, texture, and the finest details, the most important difference to make between a pair or set of colors is to separate them in the lightness (in CIELAB, that's L) dimension. If you have sufficient lightness contrast, then any particular choices of a and b (or hue and chroma) will work fine. If you don't have sufficient lightness contrast, changing the other color components won't help much: even if you maximally separate them in the color space, they'll just appear to mush together in a clashing way along edges.

[edit: removed asterisks from L*, etc. because HN thinks they should be for italicizing]

<comment><USER6> To supplement your point about L being the most important ordinate for distinguishing bordering colors: that is certainly true, but there are three other properties one wants for data visualization:

1\. Once you've seen a colored element in the graphic, you want to quickly match it to its corresponding element in a legend (or vice versa). Having distinct hue and chroma is more important for this, because lightness is so vulnerable to your brain's tendency to 'correct' it based on contextual cues.

2\. Hues should be aesthetically pleasing.

3\. Lightness tends to impart connotations to an visualization: class X is more important than other classes if it is substantially darker or lighter. Same goes for chroma. So one wants to bound lightness and chroma to within a specific range when using them for class labeling.

Another deep complication is color impossibility, which is another way of saying that for any reasonably perceptually uniform color space like CIELAB, there is no straight-forward parametrization of the space that is both linear and avoids impossible colors.

My gut instinct is that space-filling curves could play a greater role in parameterizing the valid portions of such color spaces. Desiderata 3 is suggestive: we want some parameter that 'wiggles' within the allowed range of lightness and chroma to achieve both good distinction between nearby parameterized colors, and good global uniformity of color and chroma.

This wiggling could also 'absorb' the 'nooks and crannies' that color impossibility produces.

Still a research project, though.

</comment></comment></comment><comment><USER7> Brewer palettes ([http://mkweb.bcgsc.ca/brewer/](http://mkweb.bcgsc.ca/brewer/)) are hand- picked colour ranges that were originally meant for cartography but are useful for general data viz, where it is important to maintain perceptual regularity while displaying quantitative data.

There are Brewer palettes geared for sequential data, where you further need to express proportionality along a scale; and "diverging" data that has a natural zero point with two extremes where you need to present a spectrum. In all these cases it's important that one category doesn't appear "heavier" than another, and that subjective notions like "about twice as intense" reflect the underlying data.

</comment><comment><USER8> I like the "HSP" color model a little bit better than HSV: [http://alienryderflex.com/hsp.html](http://alienryderflex.com/hsp.html)

</comment><comment><USER9> The golden ratio method looks neat; but I think it can be forked into two algorithms. In the site version, they know ahead of time how many colors are needed. If you need n colors, you could use the multiplicative inverse mod n to pick angles along the color wheel. This results in every color being unique and as far away as the other colors as possible.

In the case you don't know how many colors you will need at the time of first picking you can use the golden ratio method to pick colors.

<comment><USER6> We use this trick in Mathematica, for what it's worth

</comment></comment><comment><USER10> Plug: I made a color space derived from CIE LUV to help generate colors procedurally.

[http://boronine.com/husl/](http://boronine.com/husl/)

<comment><USER6> Nice project. Do you know about HCL? [http://hclcolor.com/](http://hclcolor.com/).

There is also uniform perceptual LAB: [http://www.brucelindbloom.com/index.html?UPLab.html](http://www.brucelindbloom.com/index.html?UPLab.html) which is a slight tweak to LAB to reduce the 'blue -> purple' effect that happens when you tweak chroma.

<comment><USER5> UPLab is not a "slight tweak" of CIELAB. It's a lookup table for going back and forth between CIELAB and a slightly rotated version of Munsell space, [https://en.wikipedia.org/wiki/Munsell_color_system](https://en.wikipedia.org/wiki/Munsell_color_system)

<comment><USER6> You can look at it that way. You can also see it as a modification of cylindrical LAB.

Explain your "slightly rotated" comment?

<comment><USER5> From Lindbloom's site: "The mapping was done such that Munsell hue 2.5RP has a UP Lab hue angle of zero degrees. This particular rotation was chosen to allow greater chroma encoding of blue colors in the lower right quadrant of the a/b plane."

Also, to be completely precise, it should be noted that the lightness dimension of UPLab was left the same as CIELAB's lightness, rather than using Munsell value. Only a and b were adjusted to reflect Munsell hue/chroma.

</comment></comment></comment></comment></comment><comment><USER11> I read this article a while ago. I was very excited to _finally_ see a use for the Golden Ratio in graphics design that actually makes any sense at all :)

(there is no proof that humans perceive phi as a more pleasing proportional ratio than others, and it's not really that ubiquitous in Nature either)

<comment><USER12> I once used a Golden Ratio to space out a bunch of overlapping rectangles. Each one was put 1/phi of the total space away from the last. That gave me the least probability of rectangles overlapping.

</comment></comment><comment><USER13> how would one optimize this for color blindness? Say, for red/green color blind individuals as an example...

<comment><USER14> One thing I noticed as someone with red-green colour blindness is that while the article claims that "darker magentas are more distinguishable than lighter ones", I saw lighter magentas as being more distinguishable than darker ones. So the perceptual distances between colours are probably different for us.

If high contrast between colours is desired, you could take some further precautions in some of the suggested algorithms, e.g. if you're choosing certain hues as a basis of your palette, then making sure that none of the pairs are problematic. If your algorithm checks the distance between colours to generate high-contrast pairs, then you could add in a check for problematic pairs as part of that step.

<comment><USER15> > I saw lighter magentas as being more distinguishable than darker ones.

How do you know that? How do you know you are looking to equivalent distributions of lighter and darker magentas?

I have some uncommon kind of color blindness, I have problems with blue and green. I don't even know what colors I can't see, I'd love to know the procedures for that.

<comment><USER14> I was looking at the sample image provided on the linked article for hue differentiation where for each of the three rows, the strips of colour differ by 5%. The three rows differ by brightness only. The article used this image to illustrate that "lighter blues is more distinguishable than darker blues, while darker magentas are more distinguishable than lighter ones", but to me both lighter blues and lighter magentas were more distinguishable than the darker counterparts.

<comment><USER15> Oh, of course.

I didn't understand that. Thanks.

</comment></comment></comment></comment></comment><comment><USER16> [http://tools.medialab.sciences- po.fr/iwanthue/index.php](http://tools.medialab.sciences- po.fr/iwanthue/index.php) is another great resource for picking optimally distinct colors.

</comment><comment><USER17> Great article. I'm working on a procedural (but stable) color library right now and I'm hoping it's useful for somebody. Color perception is a lot more complicated than I could have ever imagined.

<comment><USER18> What language is your color library for?

<comment><USER17> JavaScript. I was thinking it would be neat to have some sort of library that hashes (for lack of a better term) keys into colors. That way you don't have to pick the colors or store them, but they are stable. For a given key, you'll always get back the same color.

Generating colors is not hard; the hard part, as evidenced by this article, is getting them to look decent and getting them to appear distinct.</comment></comment></comment>


Alzheimer's gene neutralised in human brain cells for the first time - <AUTHOR> https://www.telegraph.co.uk/science/2018/04/09/alzheimers-gene-neutralised-human-brain-cells-first-time/ <comment><AUTHOR> "The experiment is particularly significant because it took place in human cells."</comment>


Show HN: Automate your lead research (MailChimp, Intercom, HubSpot, Segment) - <AUTHOR> http://go.drift.com/daily <comment><USER2> interesting, I'd like to know / learn more without signing up. Is there a YT video or something?

<comment><AUTHOR> hey boris - here's a blog post that has a quick video in there for you [http://blog.drift.com/introducing-drift- daily](http://blog.drift.com/introducing-drift-daily)

this post might be helpful too: [http://blog.drift.com/automated-lead- intelligence](http://blog.drift.com/automated-lead-intelligence)</comment></comment>


Rocket Will Be Recaptured in Midair with a Helicopter - <AUTHOR> http://motherboard.vice.com/read/americas-newly-announced-rocket-will-be-recaptured-in-midair-with-a-helicopter

<comment><USER2> This is certainly an interesting approach, but more interesting to me is the fact that ULA's new rocket (the first they are actually building) won't launch until 2019. As SpaceX have been launching their own since 2010.

Also interesting is the reasoning behind capturing parts of the rocket (and it is only parts) in midair. ULA say this is because the expensive bits are small, and essentially imply that they can get most of the 'wins' with not much effort when compared to SpaceX's "land it on a boat" approach. This may well be true but it seems SpaceX's approach is thinking in wider terms of the re-usability required for frequent space flight, rather than cheap space flight.

I have a keen interest in space flight and SpaceX in particular, so take my opinion with a pinch of salt, but this article reads to me like SpaceX are well over a decade ahead of the ULA, much more forward thinking, and overall the more exciting player in the commercial space-race.

<comment><USER3> You probably already know this, but just want to point out that SpaceX's approach goes way beyond "landing it on a boat". For today's launch (and launches in the near future), they'll land it on their barge. But after the landing system has been proven, they'll land it on the launchpad it took off from. Work is already underway at Kennedy Space Center to make a launch site capable to have a rocket landing.

Pretty cool animation here: [https://www.youtube.com/watch?v=4Ca6x4QbpoM](https://www.youtube.com/watch?v=4Ca6x4QbpoM)

I do wonder how much this will save SpaceX in logistics cost once it's in place. Seems a lot cheaper than coordinating a helicopter to catch a rocket engine in mid air, land it on a barge, and ship it back to shore.

<comment><USER4> Don't forget that SpaceX aims for that red rock out there. Reusability in this case may go much farther than saving on convoluted blocks of metal but also includes gathering data and experience for a surefire way to get there _and back_.

</comment></comment></comment><comment><USER5> Hooray for 1950's technology!

This is how they used to recover corona/keyhole spysats.

They lost one in Mexico.

[http://news.discovery.com/space/history-of-space/the- first-r...](http://news.discovery.com/space/history-of-space/the-first- recovery-from-space-130812.htm)

Edit:

Uh, the Mexico thing may not be commonly known, it turns out. The chute failed to deploy properly on a mission in '74, bounced off a C-130, and slammed into a field in Mexico, but the payload canister was still intact. It's apparently commonly written up as a UFO sighting called the "Coyame Incident".

</comment><comment><USER6> I'm underwhelmed, and not surprised. Typically for the big, slow defense industry players, they're planning a more complicated system that does less and will not be ready until 2019.

Meanwhile, SpaceX will be attempting to land their _entire_ first stage again _this afternoon_.

<comment><USER7> I think it is more nuanced than simply ULA's system is _more complicated_. I do however thing that the ULA system is a primarily-mechanical solution while SpaceX is using a primarily-computer based solution.

Background - I have a BS in mechanical engineering, work professionally as a software engineer now, and spent a few years in the defense industry working on nuclear submarines.

Both approaches have key mechanical and computer/control challenges. However ULA's primarily relies on increased mechanical complexity with relatively simple computers. They are adding separation between the tanks and the engines in the first stage. This is relatively proven tech - we separate stages all the time - but it will complicate the piping and structural design of the first stage considerably. There are also mechanical components related to the hyper cone and the parachutes. The whole thing then follows a relatively simple trajectory and then relies on the skill of human pilots to capture the falling engines. We have done this, but again they're using mechanical systems & proven techniques to recover the engines.

Meanwhile, the Falcon 9 doesn't use a whole lot of extra mechanical components to be reusuable. Arguably the only extra bits are the legs and the grid fins. The grid fins are very simple. The legs are a bit more complicated, but probably less than what it takes to separate the entire engine assembly. SpaceX puts all the complexity in the control _software_. The engines are re- firing multiple times, and during the last few minutes of landing the computer is doing some serious work to balance everything out. At the end of the day, there is no human interaction on the landing.

You often see this trade off between mechanical complexity and software complexity in systems that bridge the domains. I'd personally bet on the company using the primarily software driven approach nearly every time. Software is hard, but mechanical systems are even harder. The economics of software are also way better. Manufacturing costs are pretty much linear to number of rockets, there isn't that much scale in the current market to reduce unit costs. Software costs are relatively fixed compared to number of launches, plus lead times are dramatically different.

<comment><USER8> You perfectly expressed what I feel (and tried to say in my comment below).

To emphasize on "always bet on software": As seen on the landing video of the (marginally failed) attempt today/yesterday, they are having issues with the dampening of their control software during precision landing. While the field of control software is hugely complex, once the parameters are known, it is trivial to set these values and (later) tweak them. You cannot do that with a (largely) mechanical system. Furthermore, it's easier to run simulations with different sets of control parameters than redo all the FEM-et-al. stuff needed for a modified mechanical design. If ULA wanted to take a slighly different approach than what they proposed here (e.g. when the first tests don't work as expected), they'd basically need to redesign the whole propulsion "stage". SpaceX can alter just their software.

[As always, it's not black-or-white. ULA may also fix (most of) their issues with software updates. SpaceX may need to add more fins or legs, re-distribute weight, or require more fuel for the landing. That does not invalidate the point above, though.]

<comment><USER8> Correction: It seems that the tilt maneuver at the end is intentional[1] to not hit the barge full force if something goes wrong. Instead, the control system did not account for (all of the) lag in the propulsion system (time between command and applying force).

[1] based on multiple comments, e.g. [https://news.ycombinator.com/item?id=9386127](https://news.ycombinator.com/item?id=9386127), and a (presumably deleted) tweet by @elonmusk

</comment></comment></comment></comment><comment><USER9> Why use a helicopter, when a system like the Fulton surface-to-air-recovery system already exists? Inflate a balloon from the top of the parachute, use a C-130 to grab the line.

Batman even used it in _The Dark Knight_ :)

[http://en.wikipedia.org/wiki/Fulton_surface-to- air_recovery_...](http://en.wikipedia.org/wiki/Fulton_surface-to- air_recovery_system)

<comment><USER10> The idea is to keep it out of that nasty salt water (cold salt water + hot rocket engines is a bad combination...).

That's why they're going for a Corona style recovery.

<comment><USER9> Corona used a C-130 system as well.

[http://en.wikipedia.org/wiki/Mid- air_retrieval#/media/File:C...](http://en.wikipedia.org/wiki/Mid- air_retrieval#/media/File:Corona_recovery_sequence.PNG)

Thinking about it, it might be a weight constraint to cause them to use a helicopter. The sudden capture of an object weighing a few thousand pounds by a plane flying 350 mph could be too dangerous.

<comment><USER10> The major difference between Corona and Fulton is that Fulton is not mid-air (and therefore involves the thing being retrieved getting a saltwater bath).

</comment></comment></comment></comment><comment><USER8> Interesting concept, but – as others said – it seems rather hacky. Sure, from one engineering perspective it's straightforward to only collect the engines. Others say that re-assembly and especially the proposed collection process adds its own complexity.

I think that the collection process is more involved (concerning number of "moving parts", i.e. requiring a number of independent systems to work in perfect synchronicity) than what SpaceX does. The F9R does have a more complex navigation and guidance system due to the landing option. But apart from the fins and legs[1] (which are of minor complexity), there's no additional subsystem required for the landing capability. Everything's already there and used in other parts of the launch – including major parts of the _landing_ navigation and guidance system. And SpaceX could launch another F9R with the same 1st stage on the same day – ULA would need days, at least.

So I think ULAs approach is over-engineered and does little to improve on the idea of launcher reusabilty.

[1] Actually, the legs may be used before launch in the future, so one less surplus subsystem ;)

<comment><USER11> I'd hope that SpaceX spends more than a day examining the engines for fractures and potential problems before launching the thing again.

<comment><USER12> In the beginning, sure, but it is reasonable to expect they'll iron out the kinks and the engines will eventually have < 1 day maintenance delay.

</comment></comment></comment><comment><USER13> It is an interesting approach by the ULA, but I have concerns.

From [1]:

 _Vulcan, slated for its maiden launch in 2019, will be powered by either a pair of exotic Blue Origin BE-4 liquefied natural gas main engines for 1.1 million pounds of thrust or two conventional Aerojet Rocketdyne AR-1 kerosene powerplants for a million pounds of thrust._

I'm also concerned about using fewer larger engines. While this can be more reliable (less moving parts means less chance of failure), it also means there is no engine-out capability to continue the mission. This also means a lower production volume, which means higher cost per engine, all other things being equal (which they aren't).

The word 'exotic' also gives me pause.

At any rate, it should be interesting. I hope they post testing videos!

[1] [http://spaceflightnow.com/2015/04/13/ula-unveils-its- future-...](http://spaceflightnow.com/2015/04/13/ula-unveils-its-future-with- the-vulcan-rocket-family/)

<comment><USER10> What do you mean by fewer? Vulcan is replacing the Atlas and Delta platforms. Both use a single engine per core (the Atlas uses the Russian RD-180, while Delta uses Aerojet's RS-68).

This will actually double the number of engines they're using.

<comment><USER13> _What do you mean by fewer?_

1 or 2 vs. 9 for a Falcon9 core.

<comment><USER10> Falcon 9 is a SpaceX rocket, not a ULA rocket.

There are advantages and disadvantages to both approaches. ULA has a long track record of going to space very reliably on single engine platforms.

<comment><USER13> _Falcon 9 is a SpaceX rocket, not a ULA rocket._

Yes, I'm aware of that.

 _There are advantages and disadvantages to both approaches. ULA has a long track record of going to space very reliably on single engine platforms._

That's true. Both the Atlas and Delta programs have been pretty reliable.

</comment></comment></comment></comment></comment><comment><USER14> Here are a couple of relevant articles that people may find interesting:

An overview of a 2008 ULA proposal for mid-air recovery of first stage rocket engines: [http://selenianboondocks.com/2008/09/partial-rocket-reuse- us...](http://selenianboondocks.com/2008/09/partial-rocket-reuse-using-mid- air-recovery-a-review/)

An article about Hiller's 1965 proposal for using a giant helicopter to recover an entire Saturn V first stage: [http://www.thespacereview.com/article/1045/1](http://www.thespacereview.com/article/1045/1)

</comment><comment><USER15> This is unimpressive at best, and impractical at worst.

Rather than ULA expending the intellectual effort to build the control and guidance systems needed to land the entire rocket as SpaceX does, they took the lazy route and added a few steps to their existing process.

The fact that they're willing to suggest that something like this is innovative is just further proof that the entire ULA is staunchly resistant to change. I'm not entirely sure this system will even have a chance to be used.

</comment><comment><USER16> Doesn't this mean there will need to be a dynamically detachable connector between every fuel/gas line and every electrical wire that runs between the tank and the engine?

Isn't that introducing quite a few potential points of failure? Or was this all thoroughly solved in the 60s and is boring and not an issue?

<comment><USER13> _Doesn 't this mean there will need to be a dynamically detachable connector between every fuel/gas line and every electrical wire that runs between the tank and the engine?

Isn't that introducing quite a few potential points of failure? Or was this all thoroughly solved in the 60s and is boring and not an issue?_

This happens at lift-off for all rockets. The rockets are fueled at the pad, and the connections stay attached until the last moment.

This kind of thing was also done with the Space Shuttle.

</comment></comment><comment><USER17> There's a lot to like about this rocket:

1.) It's good to see ULA stepping up to the plate and actually innovating. SpaceX will need some competition by then, to keep the industry healthy.

2.) The name, "Vulcan", is pretty badass. Certainly far better than the other, embarrassingly jingoistic candidates they were considering.

3.) The inclusion of innovative NewSpace companies like Blue Origin and Xcor is pretty exciting, even if ULA hasn't actually committed to using their technologies yet.

That said, there are ways in which the Vulcan seems like it was designed by a committee, and doesn't quite seem fully-baked. In particular: the "dial-a- rocket" approach of strapping on solid boosters is at fundamental odds with the economics of reusability.

In an expendable rocket, solid boosters are used because you need a lot more thrust early in the ascent (to overcome gravity losses), and solid rockets are a relatively cheap way to achieve that. (Solids generate a lot of thrust during a short period of time, but their efficiency over long-duration burns is relatively poor, which is why they're generally not used all the way to orbit). You could accomplish the same thing by using more liquid fuel and more engines in the primary booster stage -- but turbopump-driven liquid engines are a good deal more expensive than solid boosters, so it doesn't make sense to do this if you're going to dump them in the ocean after a minute or two.

On the other hand, if you're recovering the engines, then using more of them is _absolutely_ the right thing to do. In that case, the tradeoff isn't between the cost of liquid engines vs. solid boosters; it's the difference between the cost of _refurbishing_ liquid engines (and some extra fuel) vs. solid boosters. In this case, the latter is likely to be more expensive by an order of magnitude. So if your hardware is reusable, then it's better to have one or at most two vehicle configurations, and simply accept that most of the time your vehicle will be oversized for its payload. You also get some additional benefits from doing this, such as greater mass-produceability and engine-out capabilities, etc.

I suspect that the problem is that aerospace engineers are used to doing high- level trade studies using a crude $$$/kg costing for the cost of a rocket -- at least, this is how I've frequently seen them do it. If this is how you think, then you want your vehicle to be no larger than the payload requires -- and that's what the dial-a-rocket approach allows you to do. But it's kind of like assuming that a truck costs $$$/kg, and therefore if you need to carry a load across town, you should build a truck which is as large as you need and no larger. This makes sense if you take it as a given that you will always be building your trucks by hand, and that they will be thrown away after every journey. But if both of those assumptions are false, then so too is the "build the truck to fit the payload" design philosophy.

It doesn't look like ULA has figured this out yet -- but they've definitely realised that there's a fire under their tail, so hopefully they will do so eventually!

<comment><USER13> Yeah, I don't get the sense that they're trying hard enough to optimize the operational cost that well.

The SpaceX approach sacrifices performance, in the sense that you need to leave some (heavy) fuel in the tank for recovery. That is delta-V that you could use to loft a heavier payload.

I'm impressed by the SpaceX approach in general. They're using and re-using the most proven technologies in an innovative way. I think powered landings are the way to go.

</comment></comment><comment><USER18> I haven't heard the phrase "human related" in relation to this. Anyone know if ULA will seek human spaceflight rating for this rocket?

<comment><USER19> It would be somewhat surprising if they didn't.

I imagine that they won't want to talk about humans until they can reliably get them off the pad without blowing up.

</comment></comment><comment><USER20> Rocket engine, not rocket.

<comment><USER11> If the only thing missing is a fuel tank, that's like saying it's not a pen until you have an ink cartridge loaded.

<comment><USER21> I think the distinction is important, especially for a headline. They _aren 't_ capturing the full rocket, just the rocket engine. That's a much lighter load to capture, and likely much more feasible than catching a full rocket.

</comment></comment></comment><comment><USER12> I understand there is some engineering rationale provided, but it seems to me just like showing off, a spaceflight version of "longest e-penis" competition. "You can land your rocket at a ship? Well, then we'll catch ours mid-air!".

<comment><USER22> Seems kinda hacky, instead of investing the time & money needed for full reusability, they'll do a fraction of the work and hope for a successful helicopter recovery, which seems kinda hard. I know they tried a capture like that with some probe and it failed. I can't figure out it that's brilliant or stupid.

<comment><USER10> Catching things falling from space is actually something that was done pretty regularly in the past. Before we had digital imaging sensors spy satellites had to rely on film. Orbiting imaging platforms would 'drop' film canisters, which would be caught by waiting aircraft, and flown back to a processing center to be developed.

[https://en.wikipedia.org/wiki/Corona_%28satellite%29](https://en.wikipedia.org/wiki/Corona_%28satellite%29)

<comment><USER22> Nice catch!

</comment></comment></comment></comment><comment><USER23> "Vulcan will be partially reusable (eventually)" Haha what a joke. The whole point of reusability is to be able to land the rocket, refuel it, and send it back up the next or even same day!

"ULA says it's going to try to capture only the most valuable parts of a rocket"

So... how about when we fly NY -> LA in our 777 we only bother to land the passengers in the remaining "valuable" parts of the airplane? See the point ULA? We're trying to make spaceflight just like commercial airline traffic. That's the ONLY way to make it commercially viable. Your cost-plus methods of building expensive as possible single use bottle rockets are over man!!</comment>


Show HN: Showing a single AWS architecture from 9 different perspectives - <AUTHOR> https://app.ilograph.com/demo.ilograph.AWS%2520Distributed-Load-Testing <comment><AUTHOR> I chose to diagram this solution because I thought the architecture diagram that comes with the source ([https://github.com/awslabs/distributed-load- testing-on-aws](https://github.com/awslabs/distributed-load-testing-on-aws)) was pretty underwhelming and needed to be broken up and expanded on. Would love to know your thoughts!</comment>


Tidal crashes out of top 700 apps in US download chart, boosts Spotify sales - <AUTHOR> http://www.independent.co.uk/arts-entertainment/music/news/tidal-crashes-out-of-top-700-apps-in-download-chart-boosts-spotify-sales-10194219.html

<comment><AUTHOR> "Spotify's resurgence in the iPad chart began on the day of Tidal's launch last week, suggesting that in spite of its criticism of the app, Tidal ultimately just increased public awareness of Spotify."

Kayne West also deleted all of his tweets that mention Tidal [1]

[1] [http://www.ew.com/article/2015/04/22/kanye-west-deletes- tida...](http://www.ew.com/article/2015/04/22/kanye-west-deletes-tidal-tweets)</comment>