> SpaceX update: The engine did not explode

No, it just became a "Falcon 8" while enroute.

All joking aside, as a former NASA Space Shuttle engineer I'm very impressed by this private-enterprise venture into heavy-lift launch services. People have often speculated about how much cheaper launch services might be if they were in the private sector -- now we can find out. The preliminary signs are very good.

My favorite part is the tongue in cheek title for Tim Berner-Lee: "Web Developer". That's an understatement (as well as a perfectly accurate one).

How to be an Excellent Programmer for Many Years

(Excellent==Successful. Money & fame are more difficult to control.)

1. Choose a small subset of available technology, learn it intimately, and embrace it. Then evolve that subset.

2. Understand the pros and cons of various data structures, both in memory and on disk.

3. Understand the pros and cons of various algorithms.

4. Understand your domain. Get away from your computer and do what your users do.

5. Be ready, willing, & able to deep dive multiple levels at any time. You must know what's going on under the hood. There is a strong correlation between "number of levels of deepness understood" and "programming prowess".

6. Use your imagination. Always be asking, "Is there a better way?" Think outside the quadralateral. The best solution may be one that's never been taken.

7. Good programmer: I optimize code. Better programmer: I structure data. Best programmer: What's the difference?

8. Structure your data properly. Any shortcomings there will cause endless techincal debt in your code.

9. Name things properly. Use "Verb-Adjective-Noun" for routines and functions. Variables should be long enough, short enough, and meaningful. If another programmer cannot understand your code, you haven't made it clear enough. In most cases, coding for the next programmer is more important than coding for the environment.

10. Decouple analysis from programming. They are not the same thing, require different personal resources, and should be done at different times and places. If you do both at the same time, you do neither well. (I like to conduct analysis without technology at the end of the day and start the next morning programming.)

11. Never use early exits. Never deploy the same code twice. Never name a variable a subset of another variable. You may not understand these rules and you may even want to debate them. But once you start doing them, it will force you to properly structure your code. These things are all crutches whose use causes junior programmers to remain junior.

12. Learn how to benchmark. Amazing what else you'll learn.

13. Learn the difference between a detail (doesn't really make that much difference) and an issue (can end the world). Focus only on issues.

14. Engage your user/customer/managers. Help them identify their "what". Their "how" is not nearly as important.

15. Write a framework, whether you ever plan to use it or not. You'll learn things you'll never learn any other way.

16. Teach others what you know, either in person or in writing. You'll accidently end up teaching yourself, too.

17. Always tell your customer/user "yes", even if you're not sure. 90% of the time, you'll find a way to do it. 10% of the time, you'll go back and apologize. Small price to pay for major personal growth.

18. Find someone else's code that does amazing things but is unintelligible. Refactor it. Then throw it away and promise yourself to never make the same mistakes they made. (You'll find plenty.)

19. Data always > theory or opinions. Learn the data by building stuff.

20. At some point, run your own business (service or product). You will learn things about programming that you'll never learn as an employee.

21. If you don't love your job, find another one.

Those who are interested in this subject and want to discuss it, you may be interested in seeing the points - good and bad - that have been made on previous occasions that this has been submitted. Here are a few previous discussion:

http://news.ycombinator.com/item?id=232192 (indiangeek.net) 75 points 4 years ago 33 comments

http://news.ycombinator.com/item?id=554338 (indiangeek.net) 83 points 3 years ago 33 comments

http://news.ycombinator.com/item?id=1022394 (indiangeek.net) 67 points 2 years ago 40 comments

http://news.ycombinator.com/item?id=1949915 (starling-software.com) 155 points 1 year ago 106 comments

http://news.ycombinator.com/item?id=2823912 (indiangeek.net) 12 points 1 year ago 1 comments

http://news.ycombinator.com/item?id=3434350 (starling-software.com) 2 points 9 months ago 0 comments

Discussions like this can be of value, and no doubt some of the newer people on HN may have points to add. OTOH, many points will already have been made, so seeing the past discussions may be of benefit.

One of the best things to happen during this launch is that an engine exploded. You can see engine 1 eat itself at 1:31 in this video:

http://www.youtube.com/watch?v=tRTYh71D9P0&feature=youtu...

[Edit: First the video was public, then it was made private, now it seems to be "unlisted" but viewable. So no guarantee that it'll still be there in another minute...]

Why is this a good thing? Because it proves a point: the rocket automatically adjusted its trajectory, and continued on its course as if nothing had happened.

The Falcon 9 is the first American rocket since the Saturn 5 with an engine-out capability. Its multiple symmetrically-arrayed engines allow for it to compensate for a sudden loss of thrust from one side: the other side reduces thrust as well to stay balanced, and everything else just burns a little bit longer. That was the theory, anyways. Today they put it into practice.

For any other rocket that you've seen launched in the last 35 years, that would have ended the mission catastrophically -- but the Falcon shrugged it off like nothing had happened. They always said they could do that, and now they've done it. Congratulations, SpaceX! Creating a fault-tolerant rocket is much better than creating a faultless one (since that's impossible).

[Edit]: In the absence of the video, the engine anomaly is being widely reported on Twitter: https://twitter.com/spaceteam/status/255128401927610368 https://twitter.com/visionik/status/255128010653593600