Ask HN: Do coding coaches exist? - <AUTHOR>

When I used to play online poker, I had weekly coaching sessions over Skype with a pro who reviewed my play, or talked me through particularly difficult hands, and gave me things to work on. It was incredibly helpful.
I am wondering if any similar thing exists for programmers. I would love to have guidance to improve my programming by someone that is better at it than I am, and be able to get opinions and guidance on my thinking and decisions about particularly complex problems.
I do read a lot, and I have discussions with other programmers, but what I am looking for is something more in depth. I would like a situation where I can get regular, specific feedback.
I haven't heard of such a thing before, and would love to know if there are people out there doing this, or that would be interested in doing this. <comment><USER2> I've often thought about doing this. I have been coding for a LONG time, and during that time I, like most programmers, have learned through others and experience that the practical lessons that are difficult or impossible to teach in more formal settings (and that includes the usual training programs that companies put their new recruits through) are much easier explained in a one-on-one setting, often at the whiteboard or through pair programming.

One of the things I've realized is that I love to teach this stuff. I'm not talking about syntax and "what is an object" and all that stuff; I'm talking about stuff like:

\- Programming is simultaneously much easier and much harder than you imagine. The trick is to determine what your mind and society just convinces you is hard (before the fact) versus what ACTUALLY separates average or beginner coders from the masters.

\- In anything but the smallest script or test application, architecture is EVERYTHING. But architecture is more of an art than a science. It takes more skill than most imagine to figure out what to name things, how few or how many "buckets" to construct such that current and future functionality fits in the right bucket, how to recognize when your current architecture needs to be amended or replaced, yet how to restrain yourself from designing a cathedral when all you need is a two bedroom apartment, and how to develop the discipline and leadership to keep other programmers (and yourself) within the architecture that you've laid out.

\- Along the same lines, how much easier it is to code something when you have thought through the overall concepts in your head, not in the world of your favorite programming language.

\- The skills you need to learn new programming languages in minutes or hours rather than days or weeks.

\- It is fun and enlightening to understand what's happening at the bits, bytes, and machine code level at the same time you understand what's happening behind the layers of abstraction that your programming environment provides. By connecting concepts "all the way down", I've seen many wonderful "a-ha!" moments.

\- The notion of "audience". Just as you must design your top level interface to the audience of your end-user, so must you design the layers of your code to the audience of the programmer-user who will use that layer to implement higher layers. Truly understanding that programming at each layer is about designing the best, most usable interface you can for the layer above you is, I've found, one of the quickest routes to respecting and appreciating architecture.

\- The true barriers to becoming a great programmer are not often the technical ones. Things like algorithms, idiomatic coding in a certain language, database design, performance analysis, and design patterns are challenging and are worthy to learn, but they are almost unlearnable in a vacuum. When you're just getting started, the same can be said for just learning how to program at all. In my experience, you MUST have a project in mind. You can read all the "21 days" books you can find, but in the end if you don't have an idea that you just can't wait to implement, you'll be sitting there with a blinking cursor and nothing to type but the examples in your books and tutorials. I don't care if it's Space Invaders, you have to have SOMETHING in mind.

\- Debugging is often a more important skill than coding. You must be able to shake all superstitions and approach problems from a rational basis. Just like an experimental physicist, you have to learn how to form reasonable hypothesis, understand what would falsify them, and then go about doing so in a methodical fashion (in a process that often looks a lot like binary search). I still occasionally make use of fancy graphical debuggers like those in Xcode and Visual Studio, but the more I studied and mastered the art and science of the debugging process, the less I relied on those things. Nowadays, it is often faster for me to debug a problem with nothing but print statements. I also find debugging to be extremely enjoyable rather than a necessary chore. I think it's because of the "gather evidence, hypothesize, test, iterate" cycle.

\- In the end, programming is the reification of "thought structures". I think this is what I find so appealing about the craft: it's the closest we have to magic. When you truly learn to create and reason about these structures in your mind and in your heart, and then learn to translate that into the magic words of your programming language, you will be on your way to becoming a master (or at least be able to create something useful of which you are proud).

<comment><USER3> As a middle aged man who has spent the last year teaching himself javascript and the prior year teaching himself basic programming concepts using C++ I can contest there is no substitute for developing a deep kinesthetic learning and having a project that drives you. I would really like to read your opinion on what exactly the skills are to "learn new programming languages in minutes or hours rather than days or weeks." Thanks for this post, it was a good read.

<comment><USER2> Thank you for the compliments.

> I would really like to read your opinion on what exactly the skills are to > "learn new programming languages in minutes or hours rather than days or > weeks.

In this there is no substitute for practice and a little drudgery. It is a lot like sight reading sheet music. At first each new piece is a struggle (more so if you are learning the instrument at the same time). But over time, you naturally develop a set of "meta skills" that make you much better at sight reading. Many of these skills you are not even totally conscious of, but they do develop and before long you can play most new pieces just as you can immediately read most new books (though it still takes a deeper read to appreciate the nuance).

So, here's some advice for developing this skill:

\- Learn a lot of programming language and, if possible, learn them simultaneously or in rapid series. You're not shooting for mastery of each, just understanding and casual proficiency.

\- Again, having a really cool mini-project helps. If you're a math guy, Project Euler is a good way to start building your personal Rosetta Stone. If not, pick a game or some simple app. It needs to be something that fairly well exercises the 20% of each language that is used 80% of the time, but also has enough complexity to warrant playing with the remaining 80%.

\- The "Rosetta Stone" example is, I think, apt. Your goal is not to build yourself a personal decoder ring such that you can just match up the equivalent symbols, but for something deeper. You're aiming for something that aligns the concepts in each language such that the superficially similar things are blindingly obvious, but the deeper differences still abstract out to a higher-level similarity that you can train your mind to see when new languages come along. For example, how are object-orientation and functional decomposition, though dramatically different in form and theory, both just translations of a single higher level concept or two? I can't tell you that, because I would be wrong or, at best, trivial. You have to discover those deep mappings yourself. Only then will they really speak to you.

\- Syntax is just, like, the language designer's opinion, man. No, really. Stop caring about the syntax while you're learning. Just accept that you're painting with someone else's idea of a paintbrush and move on. As you get more advanced you'll come to have "aesthetic taste" in syntax and you'll know which languages look, to you, like beautiful paintings and which, to you, look like so much angry scratching. But when you're learning a new language (or 10), it's best to put your aesthetic judgements aside and just let it ride. Haskell is a good example of this. At first I absolutely HATED the kind of "sharp" syntax and bizarre ordering of things. The language felt "pointy and argumentative" in the area of my mind that has developed this weird "code sense synesthesia" that has developed over years of looking at so much different stuff. But I put that aside to really learn the language, and while it's still not my favorite language syntactically (that goes to Clojure or CoffeeScript), it became more beautiful and ordered in my mind and took on a kind of beauty that, like certain forms of architecture, is only visible once you understand a bit of the purpose. But in any event, really, ignore the syntax and just treat it as "the rules of the road" until you become more adept.

\- Similarly, just because a language LOOKS difficult doesn't mean it is. Tell yourself that it's "just code" (I use this term a lot) and struggle through. Before long you'll invariably look up from your frustrations and say "oh. This isn't as hard as it looked." _cough_ Scala _cough_

\- When learning about a language, read about the history of its development and guiding philosophy first. It helps to understand a language more when you know where the designer was coming from. You may not AGREE with the designer(s), but you'll appreciate that there's a reason behind the apparent madness.

\- I'd recommend learning the following types of languages simultaneously or in rapid succession to shake yourself of the "different == scary" prejudice that's only human in all of us:

* Something comfortably high level and "cozy", like Python or Ruby

* Something "enterprisey and conventional", like Java or C#

* Something really functional, like Haskell or F#

* Something really object-oriented, like Smalltalk (just go with Smalltalk here)

* Something "industrial". Go with C here or maybe C++

* Something lispy, like Clojure or Scheme

* Something theoretically foundational and bootstrappable, but not lispy. I'm thinking FORTH

* Something painful and to the metal. Assembly language for your favorite architecture.

* Also, do yourself a favor and write at least ONE thing in pure machine code (as in manually write a hex file that will execute). In the DOS days, I wrote a COM file that printed something to the screen using a BIOS interrupt. Load up DOS in an emulator and do that, or do a system call in your environment. This little exercise will be tedious and suck unless you're a hexadecimal masochist, but you'll be forever better for it, because you will have broken the ultimate barrier and actually done the thing most people think of as "ultimate wizardry"... and it won't be as hard as you think.

Keep in mind that this is an intellectual exercise. It's not job training. It should be treated as a hobby at first, because it can be frustrating but rewarding... like a really hard jigsaw puzzle.

Finally, I'd have to recommend picking up a copy of Petzold's Code. Once you read that, get yourself into an online TECS (The Elements of Computing Systems) course and follow it all the way through. Go to <http://www.nand2tetris.org/> for starters.

This is all very time-consuming and difficult, and at times it will be extremely frustrating, but it's more than worth it. Once you REALLY get how the machines work and how the various languages above machine code (even assembly language!) are just the result of various people's opinions on what kinds of abstractions to stack on top of the wires, you'll be a better programmer for the rest of your life. You'll also, with continuing practice and education, run rings around everyone at work :)

Good luck!

<comment><USER4> I can't stress how much I agree with the last point. Probably the single hardest CS course I took in college was an upper-level seminar on compiler design, in which we built a simple compiler (for Appel's Tiger language) over the course of a semester. I've never poured more hours in to doing harder, more frustrating work in my entire life... and I've found that I haven't looked at code the same way since. I've found that you can get a similar experience by really, really groking C, but it still doesn't hold a candle to really getting to the innards of the machine.

</comment></comment></comment></comment><comment><USER5> It's funny that this turned up today. Last week I was browsing craigslist for quick side gigs, and came across a post of someone wanting a Django/python tutor. I pinged the person - and decided to help her out. The problem is: I am not comfortable taking money to help someone learn something, since I am not a professional tutor or teacher. Fortunately in this case she was also about to apply for a job at the university I work at, so payment for the tutoring couldn't happen at all (due to potential conflict of interest issues). So instead we worked out a deal where I will help her learn if some of her learning projects are stuff we need to do at my local hackerspace, and helps me with some of the pages I do as volunteer work for charities.

We were talking and have come to the conclusion that this arrangement might be somewhat scalable for learning - an apprentice model for coding, that benefits 3rd parties. It certainly gets around some of the weird power dynamics of traditional apprenticeship/mentoring and paid tutoring. Further it is a good way to get some needed talent to good non-profits that may not be able to otherwise arrange such a thing.

Finally, and this is the kicker - it gives novices practice in real development, and it gives experienced people (who may be hiring) access to people to see how they are at problem solving in a real environment, rather than interview tests, potentially faked code samples, etc. (Not to mention, someone willing to go through the effort of something like this is probably already a great candidate on the strength of "wants to learn more and actually takes effort to do so", which I have found to be a strong indicator for a good employee).

I don't know where you are located, but if you want to get into some more discussions about setting up something like I described above, feel free to email me:

      $HNUSERNAME at gmail.

<comment><AUTHOR> Thanks for your reply. It sounds like what you are doing is admirable but not along the lines of what I'm after.

I don't think that there is really any weird power dynamics in this kind of coaching, at least not in my experience. On one hand we are dealing with a domain in which reason is the ultimate method of arbitration, and a good coach would not be presenting me with opinions or ideas that I could simply disagree with due to some difference in personal belief. Instead, they would be challenging me with different ways to think or different ways to approach a problem, and be able to explain its benefits if they weren't obvious to me.

On the other hand, the trust that can be built in this type of relationship can be quite useful for the learning process. Having someone that I respect as a programmer as well as a coach allows me the comfort to know that I could come to them with either a specific problem of general deficiency and get the kind of response that will give me the most enlightenment in the long term, which is often different to what you'd get when asking a question online.

<comment><USER5> I'm pretty sure I was unclear in my original reply (not enough coffee at that point to be replying to the internet I think :) ), I think we actually agree more than disagree. Perhaps I can explain what we thought of as problems and solutions a bit better now that I'm fully awake:

First the idea of paid, but not directed tutoring is a bit weird. When a person is paying they exert an influence over the person they are paying. So in a tutoring situation, the student can say "no I don't want to focus on that fundamental thing because I don't see it as important and you have to do what I say". This can turn off a lot of tutors, because they honestly know that understanding that bit really helps (e.g. knowing about how HTTP works, even if you are just writing DJango apps and never deal with anything other than an abstracted object representing the request). The goal of a lot of tutors is to help people learn, and not just make money. Further it is a bit sticky, because if the student decides not to learn stuff, and can't get a job or doesn't really gain skills, it reflects poorly on the tutor - a bit of a problem if that is your business.

The reverse situation exists in programs like internships or company-internal mentorship programs. The mentor/boss always holds a trump card of "because I am higher in the hierarchy and say so" which can influence the student/learner to not want to rock the boat or express disagreement or initiative. This sort of thing really has the same fundamental "I need to work and keep working to afford life" pressure on it.

The traditional solution to this is a mentorship program (basically what you've been describing). This is generally a safe place to be able to express opinions and disagree, and I completely am on board with your entire post in this sense. One of the problems with mentorship generally is that it can be hard to really get deep tho. Conditions like NDAs on work can really limit shared context - problems are kept in the abstract and specific code review/pointers can be lost. This makes the problem hard. Further, finding mentors can be hard, because from the mentor side doing that task falls into the volunteer/contribute to fun oss projects/hobby category, and therefore the task is in competition with other worthy tasks.

So this is why we were talking about the structure I described. It provides a mentorship opportunity with all the benefits you stated, with the added benefit of easily allowing shared context for the mentor and learner, and reducing the opposition of "competing choices". Essentially it is a way to foster mentorship in a way that everyone wins, with the benefits for all parties being a bit more clearly defined and in focus.

A final note about the software field:

At the end of the day - there are lots of equally good technologies, and people, even the best, will have preferences and beliefs on what is a better solution. Things like architectural style (e.g. event driven or threading?), language (python, ruby, clojure?), and on and on don't actually have a "right and well reasoned" answer. It is hugely style/belief/experience driven. Even at the code level this is true - is a facade or strategy better here is regularly unclear. Is a decorator or descriptor the better way to do this thing in python? How should I break up my classes is a huge source of disagreement even amongst people subscribing to seemingly the same philosophical set (e.g. srp, dry, yagni).

Sometimes the decisions made are based on subtle factors that are impossible to easily clearly explain, and it sounds like hand-waving: "down the line it will be easier to refactor for what we actually need rather than figuring out perfect right now" is a statement of belief and experience, not of reason and fact. Particularly when the same person will say "lets do it right - we won't want to change this later" on a seemingly similar problem. I do that. I try to explain why to my team. It really comes down to "because it just is in my experience - the problems are not similar on a human/project level, not a technical or reason level and those human factors are really hard to pinpoint or don't seem relevant, such as the way the boss reacted to a particular statement, or past experience with the client on a completely different project"

My point is that one of the reasons to ask for advice from an experienced person is that they have an opinion and experience in things that you can't just write a book or set of rules about. Ideally they guide you through the minefield of non-deterministic decisions and consequences when there is a lot of choice and no clear obvious solution.

I've guided a lot of people through stuff like this - very bright people who I learned a lot from and who were very good at learning. The biggest problem wasn't "I don't know how to do this" but "I see so many ways to do this and don't know how to choose". It's a weird thing that comes up in engineering and software: how to be wrong in the right way.

I hope this helps clarify what I was trying to say. Best luck with your finding a coach!

<comment><AUTHOR> Thanks for this thoughtful reply. I think you articulated the power dynamic between tutors and students very well. I was reluctant to use the word "tutor" in my post, and picked "coach" instead, for this very reason, but I did a poor job of explaining it.

</comment></comment></comment></comment><comment><USER6> My employer does this in-house, by pairing a programmer up with a more experienced programmer or architect in roughly the same field, and having them review the programmer's work on a regular basis. I bet there's many firms with a system somewhat like this.

That said, if your team does peer code reviews, you get a lot of that coaching that you ask for, directly from your team members.

In fact, if your workplace doesn't have any way by which you can regularly collect feedback on your work, I'd be very worried. If nobody cares about the quality you produce, chances are small they care much about what you do at all. In any sufficiently important team, code reviews are a _must_ in order to guarantee a sufficient level of quality.

<comment><AUTHOR> I work in a small psychology research lab in a university. I am one (the senior) of only two programmers. I work here because I am passionate about the problems I get to work on, as well as the freedoms afforded to me. Since I am in this situation, code reviews and pair programming are of limited value to me, although we do them so I can help my junior colleague.

</comment></comment><comment><USER7> I coach full-time at Facebook, and I coached for various clients part-time for a decade before that. We work a bit on technical stuff like how to design, test, or refactor, but honestly the technical work is mostly to establish trust so we can work on more personal issues--time management, multi-level thinking, communication skills, principles of programming. For example, a couple of recent students had ADD. We worked on finishing one thing before starting the next, mostly using techniques that I developed for my own use. After a month of daily one-hour sessions the change was noticeable.

<comment><USER8> Is the word 'coach' in your title, or is coaching just something you do as a good manager?

I really enjoyed your recent post about incrementally escaping local maxima. It would be cool to read some of your coaching tips and stories someday.

</comment></comment><comment><USER9> There's Rails Mentors - <http://www.railsmentors.org/>

I've been a mentor on there for ages and I've "mentored" several people - probably around 7 or 8. The reason I put quotation marks around "mentored" is because of all the people who have applied to be mentored with me, only one has actually applied themselves to the task at hand and consistently requested feedback and guidance.

As a result, that was really the only rewarding mentorship interaction I've had via that site, which is a bit disappointing. One of my colleagues signed up too, years ago when that site launched, and I think he's had better luck; he has a postcard on the wall near his desk from someone he successfully mentored in China.

The reason I bring this up is because I think anyone who wants to be mentored must realize that the relationship goes both ways: you want a good mentor, but your mentor in turn wants a good student - and anything less than that is disrespectful.

</comment><comment><USER10> This is a great idea.

I'm not sure if others work the same way, but I know my coding-brain is much more receptive to learning and improvement when the feedback is on code that I've already (tried to have) thought through.

I could read 100 books on Advanced Ruby Theories and "learn" a lot, but take a block of code I've already written and tell me how I could make it better and my synapses will go wild :)

<comment><AUTHOR> I couldn't agree more. This is exactly the experience I had being coached with poker. Sometimes you get some insight or way of looking at a problem that you probably would have never worked out on your own no matter how much time you were given. Having an external person who is invested in your success is really powerful as a tool for learning.

</comment></comment><comment><USER11> This is something I've done before, and I quite like it.

I didn't realize how enjoyable it would be until I was a team lead in the early 2000's and I started doing code reviews and established peer reviews in my team. The team would review the code with someone else in the team, and when they couldn't find any issues they'd pass it to me for final review and deployment. The process was sort of gamified (without realizing it, I later found out their goal was to get it by me without me flagging anything).

Since that experience I've been freelancing, I usually try to establish the same environment in the teams I work with. I sometimes do _pure_ mentoring, where I'm not working on the day to day aspects of the project, and am just reviewing pull requests and offering suggestion; but this isn't quite as common yet.

Lately I've been getting more gigs to act as a mentor, and that's pretty cool, but I don't think it's something I would want to do full time. I've found the mix of working with the team _and_ mentoring feels perfect to me.

</comment><comment><USER12> I've done this for money a couple times, and informally for a few friends. (Plus, a bit more regularly lately as a student at Hacker School, which you ought to check out.)

When I did it for money, both clients were appreciative, but I think it went better with the one I'd previously written a lot of their backend code for, who were also well-heeled. This gave me specific knowledge and more time to give them.

(I could be available for some more of this after the Hacker School term is over, late December.)

<comment><USER13> Is there a HackerSchool alumni discount? :D

<comment><USER12> It's more like, that makes me more likely to do it. :) It's hard to justify much of it at the rates you can get programming instead.

</comment></comment></comment><comment><USER14> How about contributing to a nice little opensource project? "I had weekly coaching sessions" - Pick/Create 1 Issue/Task every week :P "I would love to have guidance...." - Discuss your plans with the project maintainer/other contributors. "I am looking for is something more in depth......" - Heh you ll be writing code... don't you think that's enough depth :P "regular, specific feedback" - Every merge request you send..... you get a nice code review, and specific feedback... and a ton of suggestions for improvement.

Since "coding" itself is a huge field, just be sure you pick a project that interests you and has a lot of scope instead of $random_famous_opensource_project.

Good Luck :)

</comment><comment><USER15> I've been thinking about something like this for awhile.

As a developer who works mostly freelance from home, I do engage with some other developers when working on agency contract work, but these engagements are infrequent and I find most of the team to be on the same skill level as myself. The bulk of my other work is solo projects for smaller businesses.

With that being said, for somebody like myself, I find it tough to meet other people who I would consider a mentor.

The only mentor types I have met have been very short lived relationships due to the short term nature of our contracts. I have felt it would be unprofessional to contact them outside of the work and after the working relationship has ended.

For the better part of this year, I have read something computer science related almost everyday. I have made it a day by day mission to better my skill set and understanding of everything computer science. Going at it alone isn't easy sometimes.

I actually wouldn't be able to put into words how grateful and happy I would be, to able to meet and have a long term friendship with a "mentor", even somebody I checked in with just once a week through email, irc, telephone, etc.

So hacker news, where can I find somebody like this?

</comment><comment><USER16> It does exist! Check out Avdi Grimm's pair programming/coaching services: devblog.avdi.org/pair-programming-services/.

If you're looking for a real reboot, consider Hacker School (hackerschool.com) or App Academy.

Disclaimer: I'm one of the founders of App Academy. Read here (<http://qr.ae/8QbUb>) for how experienced devs thought that App Academy helped them level up.

</comment><comment><USER17> When we launch LiveNinja ( <http://www.liveninja.com> ) in about a week, we will have coding experts/coaches available for you to hire and video chat/screenshare with. If you have any questions or would like to know more please email me at firstname.lastname@example.com

Please also email me if you'd like to be featured on the site as a Ninja/Expert for our launch.

Thanks!

</comment><comment><USER18> What you're describing is very similar to a 1-1 with a lead/manager at a good company. Usually you'll meet once a week, talk about any problems you're having, and work through any hard design problems you're encountering. If the company is well managed, your lead will be very experienced and know how to help you become a better programmer.

</comment><comment><USER19> My local Ruby on Rails organisation, in Australia, has a list of mentors available for different topics. I've both given sessions and attended them and they are always educational.

<https://github.com/rails-oceania/roro/wiki/Available-mentors>

</comment><comment><USER20> Internships. Find a great company w/ top-notch developers who aren't too stuck up or arrogant to give proper advice.

<comment><USER21> Amen to this.

Tutors w/o industry experience are useless. And virtually no one with the experience will do the tutoring outside the work.

</comment></comment><comment><USER22> Unless programming is a hobby for you, I would recommend you look for a job that has mentoring built in. I remember that at Google -- which hires pretty decent coders to begin with -- there were plenty of both educational and 1-1 opportunities to get better. In fact you had to pass a 'code readability review' with senior colleagues before you got access to check in any code.

If changing jobs is not an option, then, yes, remote coaching/pairing works pretty well. Lately, I have been starting remote study groups to master new technologies with other developers. Take a look here for an example: <http://scalafp.pbworks.com> and <http://scalapro.pbworks.com>

</comment><comment><USER23> I've been approached by 2 people to mentor them in coding, and neither worked very well, but it was primarily my fault. In one case, we just had a lot of communication problems for a few weeks (probably mostly my fault) but expectations weren't set on both sides early on (regular times to meet, goals, etc). In the other case, we ended up discussing things a bit more and decided that's not what he was really after.

That said, feel free to reach out to me if you'd like to discuss it, and perhaps we might be a fit (or I might know someone who is for your needs).

<http://phpmentoring.org/> is a site set up to help people match up with each other, but I've no idea what sort of success any of them have had.

<comment><AUTHOR> I will check out that site, PHP is one of the languages I work in regularly. Thanks!

</comment></comment><comment><USER24> I do this. My best success story? I started mentoring my little brother in July when he graduated with a B.A. in philosophy. I code reviewed, wrote assignments, helped him choose his own projects, gave advice on what study, and pair programmed with him on weekends. He worked hard; just started his first job as a software engineer last week.

I used to be a schoolteacher before getting into development, mentoring combines my two favorite things: teaching and programming. Feel free to contact me, I'm open to take on one or two select individuals interested in working hard.

<comment><USER25> @JackMorgan - what's the best way to contact you?

</comment></comment><comment><USER26> Well, what I am doing right now, just trying out so can't say for sure how effective it is. I was working with a a freelancer who knows python and is more experienced than me so I say I'll pay for your time for pair programming, design review, etc...

What I would do is to code the way I would and then go over it with him via teamviewer or something and we chat over skype. For me, the difficult part is creating the right classes and refactoring, making unit tests and making code scale. I also have design questions. Perhaps I'll make a post when I have more feedback.

</comment><comment><USER27> I'm sure there are online communities that would provide what you're looking for. I've been a member of cboard.cprogramming.com for over a decade and that community is exactly like what you're looking for. It's focussed on C/C++, but people who post their code either with specific questions or asking for general feedback will get a wealth of advice on how to avoid common pitfalls, how to do things better, and how to be more standards-compliant. For other languages, ask around for the good communities - they must be out there.

<comment><AUTHOR> Online communities are useful, but not what I am looking for. I already have access to online communities. Coaching is different - it is more personal, more focused, and is based on a longer term relationship.

</comment></comment><comment><USER28> I've thought a lot about this problem. Trying to remedy it I built <http://coderook-beta.herokuapp.com>

Still just playing with it.

</comment><comment><USER29> I think this is something that could be very helpful. In college, I didn't get so much feedback on code, so I would be interested in having a "coding coach".

In fact, I wonder if anyone would be interested in helping a small group get better at coding. The coach would provide feedback and answer their toughest questions. I guess it would be like a small independent coding bootcamp. I'm not sure how compensation would work, but I wonder if anyone would be interested in it?

</comment><comment><USER30> I've benefited from having coding tutors. My path was to pick a project I wanted ti work on, start coding it myself, and then find people who'd be willing to help me figure it out.

The thing that took me a while to understand was that lessons tend to be much more effective when I ask the teacher for help with building a specific feature, including architecture, refactoring, and testing.

Chris Pine's Learning to Program was a very helpful book, too.

</comment><comment><USER31> I can tell you it exists since I'm doing exactly what you describe: providing short sessions over Skype/shared-screens, on various topics including pure coding, freelancing, or ETL.

I only do that on a lightweight volume (and I am paid for that since this year).

I believe Avdi Grimm does something similar too.

This is something I really enjoy doing, and I'm surprised that it's not more widespread.

</comment><comment><USER32> I am planning on creating a startup that would do something along these lines. This would be a great opportunity for me to learn about coaching through Skype. If you are interested, I would love to devote a few hours a week to code coaching.

I wouldn't consider myself an expert, but I have been coding for 9 years or so now. What level are you at, and what level would you prefer your coach to be?

</comment><comment><USER33> I'm a coding coach. I'm only 16 but I am the programming captain of my school's robotics team and I teach a small class.

I have to do _just that_ to help the kids along, to learn, to fix small things and generally become more independent.

I love it.

</comment><comment><USER34> There's a company called Software Carpentry ( <http://software-carpentry.org/> ) that runs workshops for scientists but they might do the same for other programmers or have an idea of who might.

</comment><comment><USER35> Hi there, check Codersumo (<http://codersumo.com>).

We're still in alpha stage, but the idea is to solve challenges and get feedback and reviews from more experienced programmers.

</comment><comment><USER36> Slightly off topic, but I've had a great learning experience by asking the right question on the Code Review Stackexchange <http://codereview.stackexchange.com/>

</comment><comment><USER37> Perhaps you should consider <http://devbootcamp.com>. I'll be graduating in a week, and it's been a good experience.

</comment><comment><USER38> CodeHS.com is an online introductory programming that offers feedback from engineers. The focus though is more on beginners.

</comment><comment><USER39> Depending on your level, I might be interested in doing that for you. Contact me at kliment [at] 0xfb.com if interested.

</comment><comment><USER40> They're called tutors. wyzant.com has a lot of tutors. But beware they take a large commission so prices are inflated.

</comment><comment><USER41> I have done this quite a bit over the last two years, and was paid for it. I love it.

</comment><comment><USER42> This is something I've offered informally before. Is it something you'd pay for?

<comment><AUTHOR> This is something I'd insist on paying for. Investment in a relationship like this goes both ways, and having a coach that was not incentivized to continue would be a deal-breaker for me.

<comment><USER43> The problem is this. Any coach who you want to listen to can make more programming for themselves than you can afford to pay them.

Getting the incentives right is tricky. Money is often not going to be the right incentive here.

<comment><AUTHOR> I agree, money isn't the only incentive. Some people (myself included) have a passion for teaching. Money is just an extra motivator.

I don't think its true that they can necessarily make more programming themselves than I can afford to pay them either. Remember, I am not wanting to hire someone full time, but for only a few hours a week. If I have to pay multiple hours of wages for an hour of high quality coaching, that is perfectly fine with me.

</comment></comment></comment></comment><comment><USER44> I would pay for this. If anyone is interested please contact me to discuss.

</comment><comment><USER45> Did you try oDesk?

</comment><comment><USER46> I would like for a site to exist where I can go and find an expert on whatever I need and consult with them over whatever communications method they prefer (Skype, Google Hangout, Phone, etc). The experts would work for tips/donations, an hourly/15 minute fee, wishlist items, credits, bitcoins, barter, etc.

If anyone is interested, I have a more detailed roadmap for this idea, a couple of domain names that would work as well as technical and financial resources at my disposal. One of the domain names is ExpertHour.com, which I think is decent enough. I don't necessarily want to co-found this with you, but I might want to commission it or invest what I have for a very small return. Email me if you want to know more.

<comment><USER17> At LiveNinja we are doing exactly this and we are launching to the public next week. Check us out at <http://www.liveninja.com>

If you'd like early access email me at firstname.lastname@example.com

Thanks!

<comment><USER46> Can't wait to see what you've got!

</comment></comment></comment><comment><USER47> I kinda like the idea but...

Coaches for online poker had that convenient that you could get a coach whose prices would always been within your reach: if you were a regular winner (or break even) at, say, $25NL then you probably had a few $25 buy-ins you could use to pay a coach begin a regular winner at, say, $50 NL or $100 NL and both of you could find value in doing that.

Then there was also this idea that you could learn from someone only a bit better than you: someone who was beating one or two levels above yours had already stuff to teach you and would be unlikely to give you bad habits.

But for programming I'm not too sure: it's not really a good idea to learn from someone who's just "a bit better" than you. And if you want to learn from someone who can do $100/hour consulting then it may cost you an arm and a leg to learn anything from him.

<comment><AUTHOR> When I played poker (at reasonably low-medium limits) I think I paid $100/hour for coaching if memory serves me correctly.

I don't mind paying for quality coaching at all. I see it as a worthwhile investment in terms of both productivity and happiness (I love learning!).

On the whole, I think high level education is very undervalued. When you think about it, how long is the payback on a $100 coaching session if you get just one really good insight that improves either the efficiency or quality of your code?</comment></comment>


Babysitting the Economy (Paul Krugman) - <AUTHOR> http://www.pkarchive.org/theory/baby.html <comment><USER2> If you cannot convince your point rationally, you bring a analogy into picture prove a point and then you conclude that since my point is proved in analogy my original theory is also proved. [http://en.wikipedia.org/wiki/False_analogy](http://en.wikipedia.org/wiki/False_analogy)

someone has got to tell krugman about this.</comment>


Two thirds of children don't know what a floppy disk is - <AUTHOR> https://yougov.co.uk/news/2018/04/26/two-thirds-children-dont-know-what-floppy-disk/ <comment><USER2> And in 1995, two thirds of children didn't know what an 8-track was. Is this in any way a) surprising or b) a problem?

<comment><USER3> I never even saw an 8-track, and I lived thru them. They were an option on cars, and we didn't buy the sort of car with any options.

<comment><USER2> Similarly, a lot of kids in the floppy disk era lived with families that couldn't afford home computers and attended schools that didn't have them either.

</comment></comment></comment><comment><USER4> I last used a floppy in anger around 2000. Is this that surprising a finding?</comment>


The 'titans' of venture capital: Entrepreneurs, we're here to serve you - <AUTHOR> http://venturebeat.com/2008/05/07/the-titans-of-venture-capital-entrepreneurs-were-here-to-serve-you/

<comment><USER2> "Also, Doerr recalled that many of Amazon's first orders tended to bundle programming books with how-to sex guides, which should tell you something about the company's early customer base."

Ouch!

Or perhaps we're all part of the "continuous improvement" crowd.

</comment><comment><USER3> I like this little tidbit:

In fact, Moritz said the firms have partnered for a total of 50 investments. The company names have started with the entire alphabet except for H, J, Q, V, X, Y and Z, and Moritz hopes to eventually cover all 26 letters. Maybe that news will help prospective entrepreneurs who are still searching for a company name</comment>


Tesla Model S Owner Blames New Car Smell For Deadly Accident With Bicyclist - <AUTHOR> http://insideevs.com/tesla-model-s-owner-blames-new-car-smell-for-deadly-accident-with-bicyclist/

<comment><USER2> Its a bull __ __reason, but the man stayed at the scene of the crime.

Generally speaking, when you are involved in a deadly pedestrian or bicyclist crash... but you stay at the scene, the Police generally do what they can to try to let you off easy (differs from district to district of course). A misdemeanor seems a bit _too_ easy to me however.</comment>


Ask HN: "Competition is for losers", but it seems YC investments ignore this - <AUTHOR>

Take EventJoy for example - at a glance, it seems like they're niche. Event registration. You've likely never heard of an event registration company before unless you're in the industry or have hosted an event. It seems like it would be a very small subset of web development available, but then you look at a this[1] and it's obvious that there are literally dozens upon dozens of companies offering very similar services.<p>It seems like there are very few YC companies that are even close to being unique, so I don't understand why they are pushing this as being so important.<p>[1] http://www.quora.com/What-are-the-best-mobile-event-apps-for-conferences-and-corporate-events <comment><USER2> Competition is for losers _if you 're a winner_. The problem is that winning requires beating all the losers.

The context of Peter Thiel's quote is that the really profitable companies are all ones where there are no real substitutes in their problem domain. But that's looking at the situation after-the-fact. In the process of getting there, they usually had to enter a very crowded market with a unique take on the problem; over time, other people realized their take was better, and so when the market consolidated, they were the last one left standing. Google entered a crowded search market (Altavista, Excite, Infoseek, Hotbot, etc.), Facebook entered a crowded social networking market (Livejournal, Xanga, EZBoard, MySpace, Friendster), Dropbox entered a crowded filesharing market (YouSendIt and dozens of clones).

If you read Steve Blank's books, one of his points is that it's basically impossible to take over a market where a single firm controls >74% of the market, and if a single firm has >26% of the market, you must spend 3x them in sales & marketing to have a chance. So the only markets that _can_ be attacked by startups are the ones that are very competitive, or the ones that nobody knows exists. Of course, not all of those competitors are going to survive.

I suspect YC _does_ select for companies that have a unique take on the market: "What do you know about the market that your competitors do not?" has been on the application form forever. They may not always get it right, but then, they don't have to: YC's unique take on the market is that they can fund hundreds of startups, take a small amount of equity, and still raise the expected value of your startup enough to be worth having as an investor.

<comment><USER3> That's a great explanation. It's unfortunate that Peter Thiel chose to express his idea is such a confusing way, and also to imply that what he was saying somehow was counter to conventional economics.

<comment><USER4> He expressed it in a bit of a one-sided way, and did that with a few other things too. I think he has the common tendency to do this when the _other_ side of the equation is over-represented in popular discussion.

For another example, he takes a virtually opposite position to some versions of the Lean Startup dogma -- he advocates making plans and thinking conceptually instead of just engaging in "gradient descent" to find a product- market fit. But the truth is that both approaches have their place and are important. The latter is just over-represented in the popular mind these days, largely as a reaction against the rash of high concept "this should work because we've reasoned that it should work" failed startups in the late 90s. (Lean Startup itself is a reaction against the late 90s.)</comment></comment></comment>


Queue and schedule your digital life - QueueBot.com - <AUTHOR> http://queuebot.com

<comment><AUTHOR> Hello all, I've been working on a web-app on my spare time over the last few months and it's finally ready for some public feedback. The site is basically a queue scheduler - where the queues are chains of web-related tasks like sending an email, SMS or posting on twitter, etc. Individual actions or queues can be periodic or scheduled so users can build things from simple reminders to more complicated, timed sequences. For now the interactions with the queues are fairly basic, but I hope to add more advanced functions in the future.

 _Queues are the heart of QueueBot. Assign actions to a queue from the range of possible tasks, such as posting on Twitter or sending a text message, and they will be executed in order at regular intervals or on a schedule._

I posted a link on Reddit about a week ago and made some tweaks related to that feedback. Now I would appreciate your feedback as well! It's in closed beta at the moment, but I'll activate a few accounts if people are interested.</comment>


Plasma physicist discusses the Wendelstein 7-X stellarator - <AUTHOR> http://phys.org/news/2016-02-plasma-physicist-discusses-wendelstein-x.html <comment><USER2> "We had to search every corner of Europe to find a company that could mill the segments of the central ring with such accuracy. In the north of Italy we found CLP, a family business in a small village"

Such amusing imagery. When you think of small villages in Italy you tend not to think of them having companies with the ability to do such cutting edge engineering.

<comment><USER3> This is the company: [http://www.officineclp.it/en/](http://www.officineclp.it/en/)

Northern Italy has its own character, so maybe not so surprising to find precision engineering.

<comment><USER4> Trust me, Italy is FULL of highly talented engineers, mechanics, etc, and small companies like CLP.

Unfortunately for them, they're not the best at selling their services globally.

Source: I am Italian.

</comment></comment></comment><comment> 2Pacalypse- Very interesting interview about very interesting topic.

One minor complaint: answer to the second question seems to have missed/ignored the question? I assume the true answer lies in the fact that the technical realization of the stellarator are even more complex than that of a tokamak and there is more global experience with tokamaks.

<comment><USER5> I can give this a shot. There is a sort of simpler explanation of what happens in a stellarator, or at least, why the shape is so weird:

When a plasma is confined in a torus, it is spinning (naturally). However, this creates an effective centrifuge, which means that the hottest atoms -- which are also the "lightest" \-- will move towards the outside of the ring, and ultimately will escape confinement. This cools the plasma.

The stellarator solution is basically to turn the torus into a Möbius strip, so that ions which have drifted outside are naturally shuttled to the inside (for the same reason that the "inside" and "outside" of a Möbius strip are the same). However, in order to retain rotational symmetry, the strip has five twists, rather than just one (the topology remains the same).

Unfortunately, calculating the dynamics of a plasma shaped like this is hard -- really hard. It requires good computers, so for many years stellarators were mostly an object of theoretical interest. Additionally in order to deal with other instabilities the Wendelstein has an even more refined shape than the five-twisted strip.

ITER was conceived in 1987, and at the time it was necessary to go with a technology that was well-tested and understood, and which people felt confident would perform as expected. At that time, using a stellarator made as much sense as writing Firefox OS in Rust or something.

<comment><USER6> Thanks for a layman-lucid explanation. Does the Polywell design also fit into the overall fusion research picture as yet another design that might one day contribute parts of itself to the final working design as the Max Planck director suggested would happen with the tokamak and stellarator designs?

<comment><USER5> The polywell is an interesting concept, but it is extremely different from every other confinement mechanism, so it's hard to see how the ideas could be incorporated. To be precise, there are two "shapes" of "electromagnetic fields": curl-free (electric (unless magnetic monopoles exist)) and divergence-free (magnetic or electric), and each kind of field lends itself to a different kind of degree of symmetry in a confinement mechanism. Specifically, a divergence-free field cannot admit a spherical confinement because of Green's theorem, whereas a curl-free field requires a very unrealistic charge configuration to generate a toroidal confinement.

Tokamaks use a combination of divergence-free magnetic fields and divergence- free electric fields to make a donut. Stellarators use only magnetic fields to make a twisted donut. The polywell uses curl-free electric fields generated by an electron gun to make a sphere. There are other variants of inertial electrostatic confinement fusion, including that currently under development by Lockheed Martin, but it's generally received less attention.

</comment></comment></comment></comment><comment><USER7> I wonder what's up with Lockheed's reactor prototype at this point. This is some truly badass engineering, but the complexities involved inevitably make you wonder if there's an easier way. "Only Germans can build it" does not bode well for mass production worldwide.

<comment><USER8> Since this is a research reactor, they probably had to make more structural compromises to accommodate more sensors, injection ports, etc than what a power plant version would need. I bet once they played with it for a few years they would have s better idea of what they actually need for a more practical version.

<comment><USER7> This design is fundamentally hard, I don't think the removal of ports will make it much simpler. Same with Tokamak. Lockheed's design (as disclosed) is much simpler. OTOH Lockheed's design is also vaporware until they publish their experimental data. They've supposedly done hundreds of firings by now, but haven't disclosed any data.</comment></comment></comment>


The most depressing image on the Internet, courtesy of Udacity - <AUTHOR> http://imgur.com/ObzzrZo

<comment><USER2> I'm assuming these people are junior-level. They're not designing a UI from scratch or anything.

For front-end stuff, it doesn't take a rocket scientist to do the kind of work that a junior employee would do, especially if they're not designing anything.

What kind of person would you prefer became a front-end web dev? It doesn't require a CS degree to be great at it, even though a CS degree certainly helps a lot.

</comment><comment><USER3> I'd have taken the pro golf route...</comment>


New Firefox Preference Center, Feels as Fast as It Runs - <AUTHOR> https://blog.mozilla.org/firefox/new-firefox-preference-center-feels-fast-runs/ <comment><USER2> Nice in general but really despise the hard-coded white backgrounds in our darkened studios. System colors exist for a reason!</comment>


Things I Think PG Monitors, But Probably Doesn't   - <AUTHOR>

Just to be clear, PG probably doesn't monitor these things because it would be a little underhanded. At the same time, these metrics might be useful in some way when deciding whether to fund a person or not.
1.) noprocrast habits -- whether a user uses it, how long they set it for, and whether they used to override often when that option was available.
2.) The user's upvote/downvote ratio on his own comments.
3.) Most visited sites, by monitoring clicked links.
4.) Most upvoted user(s). <comment><USER2> We don't consider these or any other metrics when deciding who to fund. The only way HN affects interview decisions is when we recognize the username for making smart comments. But since there is no way for software to detect those (if only), it's necessarily informal.

<comment><AUTHOR> I figured as much. :-) Just a thought I had the other day. I imagine it's difficult, if not impossible, to prove a relation between any numerical metric on this site and start up success.</comment></comment>


Man tests to see if Google is listening through microphone, result is surprising - <AUTHOR> https://www.youtube.com/watch?v=zBnDWSvaQ1I <comment><USER3> That first click on the dog toy ad likely caused all other tabs to show related and/or exactly this ad.

It doesn't explain first ad though, but we know nothing about his setup - <USER2> phones and other devices he has and what software is currently activated on them.

</comment><comment><USER4> I don't see this as conclusive at all. I tried it out on my macbook air in chrome and did not get any ads for the item I talked about.</comment>


Show HN: Checkout Page – quick, code-free way to sell with Stripe - <AUTHOR> http://checkoutpage.co/ <comment><AUTHOR> I made Checkout Page to create a way to use Stripe for both developers and non-developers.

Checkout Page lets you really easily create one page sites where people can pay you on. The use cases are endless, but think of selling courses, ebooks, physical products, advertisement spots or getting invoices paid.

With future developments I aim to make Checkout Page an unopinionated way to sell online. On the roadmap are things like Zapier integration, dynamic pricing, webhooks and dynamic return URL parameters.

I would love to hear your feedback!

<comment><USER2> It will be interesting to see if you can convince developers to use this because if I understand correctly, you are essentially replacing the need to write server side code to process stripe payments. For developers like me, it would be a hard sell because I have got stripe code running on servers already with my own business logic as needed. A fixed fee of $29 or $49/Month plus additional 1% of each charge will not be worth it for developers like me.

For non developers though, I think it will be a great fit but then you will be competing with similar services like paddle etc.

<comment><AUTHOR> That's correct. When I said developers, I primarily front-end developers who don't write backend code. People who are able to build static websites and usually make them interactive with plugins, extensions and services.

I need to think how I can make Checkout Page interesting for full stack/backend developers. It would then mostly be a time saver, for which the fee is indeed too high.

What kind of pricing structure do you think would work well for a developer like you?

</comment></comment></comment><comment><USER3> Looks nice, but doesn't Stripe already offer this functionality via Stripe Checkout [0]? Why would I use your third-party service over the first-party offering from Stripe?

[0] [https://stripe.com/checkout](https://stripe.com/checkout)

<comment><AUTHOR> Thanks! The functionality of Stripe Checkout is similar, although when using it you still need to process the payment on your own server. Checkout Page does that for you.

</comment></comment><comment><USER4> How are you going to block the underlying resource (for example, the ebook someone could be selling) and only allow access to it for people who paid?

</comment><comment><USER5> Love it!! I could really use this for a few things and if you do subscriptions, I'd have a few more uses for it. Are you considering subscriptions?

<comment><AUTHOR> Awesome! I am considering subscriptions as well but it is further up on the roadmap.</comment></comment>


The Wrong Eating Habits Can Hurt Your Brain, Not Just Your Waistline - <AUTHOR> http://www.npr.org/sections/health-shots/2016/12/30/506433671/the-wrong-eating-habits-can-hurt-your-brain-not-just-your-waistline?utm_source=pocket&utm_medium=email&utm_campaign=pockethits <comment><USER2> _> He says something similar may happen in human brains when people eat a diet high in fat and sugar. Davidson says there's a vicious cycle of bad diets and brain changes. He points to a 2015 study in the Journal of Pediatrics that found obese children performed more poorly on memory tasks that test the hippocampus compared with kids who weren't overweight._

These assertions raise doubts in my mind regarding the study as a whole. Fat and sugar (a carbohydrate) account for two of the three most common macronutrients, the third being protein. Eating a diet that's low in both fat and carbs would imply a mostly-protein diet which can lead to illness[0].

The further implication that a particular macronutrient ratio could cause obesity is particularly concerning. Weight gain/loss is determined strictly by whether someone consumes more or fewer calories than their body burns in a day. The ratio of macronutrients may effect other health indicators like lean body mass, but a diet of 100% sugar and fat will still lead to weight loss if the total caloric intake is lower than what the body requires thereby requiring the body to burn muscle/fat for energy[1].

While the researchers have found a correlation between memory function and obesity, they appear to be making spurious claims that the foods the obese people eat are a contributing factor. There's no indication they made any attempt to control for the fact that healthy people also regularly enjoy ice cream and bacon, just at a lesser rate than those who are chronic over-eaters and therefore obese.

[0] [https://en.wikipedia.org/wiki/Protein_poisoning](https://en.wikipedia.org/wiki/Protein_poisoning) [1] [http://articles.latimes.com/2010/dec/06/health/la-he- fitness...](http://articles.latimes.com/2010/dec/06/health/la-he-fitness- twinkie-diet-20101206)

<comment><USER3> This is the "a calorie is a calorie is a calorie" argument, and it's not true. Sugar upsets the metabolic process in disconcerting ways, leading to fat accumulation and insulin resistance; sugar is also more addictive than cocaine[0]. Meaning that when you consume calories from sugar, you crave more sugar calories. The foods you eat _do_ make a difference in how fat you get, because they alter your metabolism and behavior -- but Western foods are so loaded with added sugar that sugar becomes difficult to control for.

[0] [https://www.ncbi.nlm.nih.gov/pubmed/23719144](https://www.ncbi.nlm.nih.gov/pubmed/23719144)

<comment><USER4> Yes, macro break down, thyroid issues, metabolism, illness, meal timing, GI, insulin spikes, hormone levels etc do make a difference. To grab at a generous figure lets say they make up 25% of the puzzle. With calories in VS calories out been 75%. And i think that 25% is very, very generous.

Stating calories in VS calories out is not true because of X, Y or Z is like building a house by starting with the doorbell. Before you lay the foundations. Fundamentals before details.

</comment></comment></comment><comment><USER5> This falls into the category of "things I didn't know, but I assumed anyway."

I don't know why the brain and body are still presented as being so distant-- it's all one system!

If you're treating your body poorly, how is that _not_ going to negatively effect the most important and complex organ of said body?

<comment><USER6> I think this has much to do with commercial interests.. if there where a higher stigma around the actual cognitive effects of junk-food and sugar it could generate fewer sales.

A fitting Terrance McKenna quote:

We do not think of ourselves as a meat/sugar/alcohol culture. People do not walk around saying "Oh wow, I'm so high on meat, alcohol and sugar!" but they ARE!

<comment><USER7> My takeaway from Michael Pollan's books was that we are essentially a corn culture, but a "meat/sugar/alcohol culture" works too I suppose.

</comment></comment></comment><comment><USER8> I'm not seeing how this evidence points to overeating --> brain impairment. To me it implies brain impairment --> overeating.

> He did that by studying rats that had very specific types of hippocampal > damage and seeing what happened to them.

This researcher started with mice that had damage, and observed they overate. This implies brain impairment --> overeating. The other memory studies in the article with obese or lean subjects cannot infer causality.

> However, even though we are beginning to understand that obesity affects the > brain, we don't exactly know how [...]

Perhaps the connection is people with brain impairment (either genetic or damage from the environment) tend to overeat, since the brain plays a role in hunger and satiation. Is there evidence that the article omits that backs up the headline?

<comment><USER9> It doesn't directly imply that brain impairment causes overeating either. Perhaps something else is causing both. Causation is hard.

<comment><USER10> That's true- and on that note I wonder if it's the gut in general and it's all related in a cycle. (Given the compounding evidence your gut directly affects your brain.)

From [http://www.hopkinsmedicine.org/health/healthy_aging/healthy_...](http://www.hopkinsmedicine.org/health/healthy_aging/healthy_body/the- brain-gut-connection): "For decades, researchers and doctors thought that anxiety and depression contributed to these problems. But our studies and others show that it may also be the other way around," Pasricha says.

</comment></comment></comment><comment><USER11> I don't buy that they "forgot they were full" because of diminished short term memory. When people overeat, I do not buy that it is because they actually forgot that they already ate.

Some other brain effect could make sense, but this one seems weak.

<comment><USER6> They are talking about the rats, with people, it's the fact that people don't feel full - they still feel hungry, so they continue to eat.

<comment><USER12> How do you know it's not the same for the rats? :P

</comment></comment></comment><comment><USER13> I notice a moderate effect on my cognitive ability due to weekly or monthly alcohol consumption (longer term than the hangover cycle). There have been a few times in my life (such as when studying for my PhD comprehensive exams) that I quit drinking completely for over a month and I was quite surprised at how much more clarity of thought and memory I had. Not enough to make me abstain from drinking altogether, but enough that it's helped me drink substantially less.

<comment><USER14> People _reeeeally_ overestimate just how many drinks and with what frequency it takes to cross into that "it's negatively affecting my health" threshold.

The mayo clinic recommends these standards

Up to one drink a day for women of all ages.

Up to one drink a day for men older than age 65.

Up to two drinks a day for men age 65 and younger.

The limit for men is higher because men generally weigh more and have more of an enzyme that metabolizes alcohol than women do.

A drink is defined as:

12 ounces (355 milliliters, or mL) of beer

5 ounces (148 mL) of wine

1.5 ounces (44 mL) of 80-proof distilled spirits

Most people from my experience:

\- Pour a glass of wine way over 5 ounces \- Drink pints of beer at the bar, which are 16 oz, not 12, and drink at least 2 or 3.

The moderate part is the key, both in frequency, and amount. Not drinking all week, then binge drinking is worse than simply drinking one drink every day of the week.

<comment><USER7> Indeed...furthermore, people severely overestimate the amount of calories they burn through exercise and vastly underestimate the amount of calories they consume.

</comment></comment></comment><comment><USER15> Assuming sugars and all saturated fats are both equally to blame is not in tune with modern research, though of course a lot of competing voices exist.

<comment><USER14> Saturated fat in itself is not the problem. Caloric excess in the form of saturated fat is. Athletes consume more saturated fat because it increases testosterone production ([https://www.ncbi.nlm.nih.gov/pubmed/9029197?dopt=Abstract](https://www.ncbi.nlm.nih.gov/pubmed/9029197?dopt=Abstract))

A hamburger won't kill you. A hamburger if you live a sedentary lifestyle will.

<comment><USER16> Also, a single hamburger will not kill you. Eating 5 Guys for lunch every day is going to be a problem.

</comment></comment></comment><comment><USER17> Having been on a ketogentic diet (low carbs, high fat) for the last 5 months or so, this is in line with what I've seen.

I went on the diet because of the promise of a clearer head, as well as general health improvement. It made sense, as I'd been plotting my work efficiency with and without sugary products. The complete removal of all carbs has done nothing but improve my life.

The carb addiction component mentioned elsewhere lines up as well. At the beginning of the diet, there's a period called the keto flu that lasts a couple weeks. It's described as mental fogging, headaches, dehydration, etc. While this is also attributed to the switching of metabolic pathways (more water and electrolytes are needed daily), the effects were very similar to caffeine withdrawal.

And of course I indulged in sugar through the holidays, and found myself figuratively face down in a gutter each time ;)

</comment><comment><USER18> At first the article claims that saturated fats and sugars are to blame, but then all the evidence discusses obesity regardless of diet composition and claims we don't understand the mechanisms. Not a well written article...

</comment><comment><USER19> Hire someone overweight who might have issues with stress, memory, may require additional time off due to health issues or hire someone who looks relatively healthy. If not explicitly, implicitly this type of discrimination must happen.</comment>


Lessons Learned from Writing Over 300k Lines of Infrastructure Code - <AUTHOR> https://blog.gruntwork.io/5-lessons-learned-from-writing-over-300-000-lines-of-infrastructure-code-36ba7fadeac1 <comment><USER2> All of the points are very valid and valuable. But by reading only this post, you will have basically no idea how to go ahead and do all these things. You have to scour the internet, and collect every blog post and video ever produced on the subject, and intone them all, and start experimenting, and just sort of create your own version of what these things are.

I'm going to interviews right now where people are trying to hire a "Senior DevOps Engineer". They seem to think hiring this somewhat low-level employee will magically imbue their organization with DevOps principles, and suddenly everything will be cheaper and faster. I tell them it may take them 2 years to build a solid DevOps practice, assuming they do everything right, and they frown. Why can't we just have the DevOps right now? To that I reply, go hire a company that specializes in DevOps. And again they frown.

I don't think it should be this hard. I think we can consolidate all the important knowledge and pre-packaged work, collaboratively, to empower teams to actually get shit done quicker and better. I think we can make it so nobody ever has to go through the painful process of learning by trial and error ever again. And, of course, I think it should all be free. So I've started a wiki, and I hope I can convince a few more people to help contribute content.

GruntWork, I love what you're doing, but I'm also hoping to make your business obsolete. :)

<comment><USER3> _> I think we can consolidate all the important knowledge and pre-packaged work, [...]. I think we can make it so nobody ever has to go through the painful process of learning by trial and error ever again._

Just an fyi... that goal is only possible for ideas that have stabilized and broad consensus has converged into widely accepted best practices. Yesterday's "hacks" that are insanely complex get vetted (or modified and replaced) and eventually get folded into the _baseline of Normal Things Everybody Knows_. But... the world isn't standing still and it evolves in complexity. Therefore, there's always _new complexity_ that requires new hacks that everybody reinvents.

At a high level, the cycle looks like:

      chaos --> create order --> new chaos again

We see a chaos of hacks and complexity. We then notice recurring patterns in the disparate hacks and extract some unifying principle that can "simplify" the complexity. If we stop here, it seems we've tamed disorder and everything should be able to be documented and people can stop wasting time repeating everyone else's past mistakes. But all we've really done is raise the _baseline_ of systems sophistication. There's always a _new delta_ of chaos and complexity.

E.g. In the 1980s, sysadmins might implement a rudimentary sync of userids with a shell script and copying "/etc/passwd" files around. But we notice that's chaotic and stupid and doesn't scale. So we rationalize the system with a more unified technology such as a LDAP identity server. But utopia is still not achieved because while LDAP might be ok for employees' sign-on accounts, it's not suitable for millions of customer accounts of a B2C web business. The complexity treadmill is neverending!

 _> GruntWork, I love what you're doing, but I'm also hoping to make your business obsolete._

If companies like GruntWork and AWS are properly doing their job, they will _never_ be obsolete because the changing world keeps throwing new demands at us and this constant delta of new chaos is always there that needs to be "solved".

<comment><USER2> Well sure, but it's not like they're in a vacuum. Anyone working in the industry sees the changes. We all could use a place to share information, and a place to discuss and remember over time. I think a forum (or mailing list?) could be used to manage the chaos, and its conversations used to help govern the order of the Wiki. Not that Wikis need order... It just sort of emerges over time.

</comment></comment></comment><comment><USER4> I recently replaced ~2000 lines of code written my predecessor with about 200 lines. The resulting code also performed 1000 times faster.

After many years of real world experience I developed the following rule of thumb. A competent, experienced developer should produce about 20 lines of code per day, on average, to have any hope for a decent code quality. I am talking about high level languages with big standard libraries and reach ecosystems like python. At that rate 300,000 lines of code is ~41 menyears.

<comment><USER5> > A competent, experienced developer should produce about 20 lines of code per > day, on average, to have any hope for a decent code quality.

That's simply measuring the wrong thing altogether. Lines of code per day produced is simply not a valid metric at all. It's just a bad metric period no matter what number you put on it. You cannot measure the quality of a dev by the lines of code he produces, at all.

<comment><USER6> The OP isn't saying "20loc/day implies good developer", his implication is the other way around. That is, at least how I read it, a good developer -- with high-productivity tools -- nets about 20loc/day.

<comment><USER5> > That is, at least how I read it, a good developer -- with high-productivity > tools -- nets about 20loc/day.

And I'm saying that's still a terrible measure and not accurate. LOC is simply not a valid statistic to even look at. It's an example of lying with statistics; you could take a thousand good developers and you'd probably find their LOC per day counts all over the board. The amount of code you write is not a measure of how good a developer you are whether it's high or low. That's not how you measure a good developer.

The OP is trying to say looking for high LOC counts are not a measure of a good developer, and he's right; but he's failed to realize yet that the metric itself is what's bad, not the values derived from it.

Good developers don't have to be highly productive, but they might be; what matters are the results of their efforts. Do they produce good programs, with few bugs, that age well over time, and are easy to change to adapting circumstances. Good developers write good code; some write more than others, but LOC tells you nothing about how good a developer is whether that number is high or low.

Like any writing, it's the quality of the code that matters, not the quantity. You cannot measure quality by looking at quantity.

<comment><USER6> Of course it's quality over quantity. 20 lines is not a lot and I think that's the point; whether you're measuring LOC -- which is a well-established bad metric -- or something equally spurious (e.g., semicolons per kilobyte hour) the fact that a very low number was chosen is telling. LOC is just used as a proxy here for something quantifiable; accuracy is somewhat irrelevant.

Writing is not the best analogy -- because of the typical churn-edit cycle -- but to use your example, of course reaming out pages of text in one day will, on average, be of a lower quality than a virtuoso author who carefully chooses his/her words and maybe produces, on average, a paragraph a day. If you were to tell a layperson that a good writer can output a paragraph a day, they'd probably find that counter-intuitive because it's such a minute amount; "Surely anyone can write a few sentences in eight hours? Even I could do that!" They're making the same false-entailment, without seeing the craft that went into those paragraphs/day, or realising that there will be days when said author writes nothing and others where they're in the zone and write an almost-perfectly-formed chapter. That doesn't stop "paragraphs/day" from being a bad metric, nor does it imply that anyone who writes a paragraph a day will end up with anything good.

</comment></comment></comment></comment></comment><comment><USER7> I stopped coding long before I ever got proficient enough to say I was a "coder", but have spent enough time struggling with "intro to x" beginner code writing courses to get a hint of what goes on when writing programs.

I'm presently going through something similar to the authors situation as I'm migrating my leads into Microsoft Dynamics and learning to make the platform for my use case (real estate brokerage). It's not "infrastructure" but it's the foundation for my business

I can say that even something as simple as correct implementation of software is not something that should be done at speed, or without serious consideration towards portability.

For example, because I'm solo and also working another full time job, my emphasis is on completing the migration ASAP energy though I'm aware of small errors in the database that might bite me later.

Also, while I'm comfortable with MS's record of maintaining enterprise software, it's slightly suffocating to feel that I will effectively loose my time investment should they decide to abandon Microsoft Dynamics

<comment><USER8> They're not gonna abandon Dynamics. If anything, they're doubling down on the whole 365 suite. (And they should, SharePoint and OneDrive for Business are really good.)

</comment></comment><comment><USER9> I'd like to hear the logical conclusion of "Large Modules Considered Harmful." Is he implying infrastructure code (e.g., terraform or ansible or cloud formation) should be split between the repositories for each component? Or just saying, "be smart about how you layout the infrastructure repo"?

<comment><USER10> More of the latter. Don't put all your eggs in one basket. Don't create a single "module" (i.e., single deployable thing) with 100,000 lines of code and all your infrastructure in it. Break things up into small, reusable, composable pieces. This is what you typically do in any general purpose programming language, and it turns out it's a very good idea with infrastructure-as-code languages too.

<comment><USER11> So much this. I've gotten so tired of seeing the same story again and again: Someone sees something that's done by multiple pieces of code and goes "I´m gonna write a framework for that!". Two months later you've got an unmaintainable behemoth of a god class that does _everything under the sun_ and drives everyone insane who has to look at it (a Cthulhu class, if you will).

So, yes, I got to the same conclusion. Basically, solve every part of the problem:

\- in isolation/as focused as possible

\- as a library

\- with the easiest to use and most composable API you can come up with

After that, if you have to, you can still glue them together into a framework- like thing. But at least, anyone can pick any feature out of it without succumbing to madness. Also, this is a great way to avoid the whole "Big Ball of Mud" problem that forces you to pull a whole ecosystem into your project although all you wanted to do was log something.

</comment></comment></comment><comment><USER12> Writing infrastructure code is a pain because it's so much more than everyone think it is. I think this article puts it well and hopefully makes it easier for folks to explain it to their team/boss. There's many single-devops out there facing this challange.

<comment><USER13> I'd say it's mostly a pain because it interfaces with parts of the system that you only touch a few times a year if it's working correctly, but yet is totally outside of your domain expertise. Nobody works with directly Ansible or EC2 instances enough to be an expert at it.

Like how every time I need to renew a SSL cert, I need to reread the man pages for how to make certs and cert requests. You'd think a replicable procedure could be documented, but there's just enough variables so that it's slightly different every time.

</comment></comment><comment> yjftsjthsd-h Definitely appreciate the prod-ready checklist; it's super useful to have a sanity check that you didn't miss anything.

<comment><USER14> Here is their full checklist: [https://www.gruntwork.io/devops- checklist/](https://www.gruntwork.io/devops-checklist/)

</comment></comment><comment><USER15> There is a simple way to make it much easier. Use hosted platforms (eg PaaS) instead of self-maintained infrastructure.

Unfortunately, most enterprises are still not willing to outsource their IT platform to the real pros and thereby make it someone else's problem to keep that infrastructure up and running. They want to build their own in-house competency. But the problem is, if you're a true DevOps pro, why would you work for some random company in which IT is considered a cost center, rather than working for either a hosted platform provider or a (for lack of a better phrase) "independent provider of DevOps"?

IT and security managers are able to convince business executives that IT infrastructure needs to be kept in-house, even though today's typical enterprise has no chance of actually building and maintaining a infrastructure that is 1% as good as what they could rent from a dedicated provider.

<comment><USER16> The problem with your theory is that even in hosted platforms, IT is a cost center.

"The real pros" you speak of are also under the same cost pressures as everyone else. I have encountered many such services where after the "real pros" have set up a system, they are replaced by low cost staff who can maintain and minimally extend while billing...

</comment></comment><comment><USER17> Is it just me or are we constantly repeating the same lessons, the same messages, over and over and over again?

<comment><USER18> We do and do again and do it again again.

And if you finally have it more or less done it in your local environment / company, you switch and suddenly you start again.

But you know, my salary still increases anyway so _shrug_ (still looking for a solution)

<comment><USER17> So if I made an open source solution that automates a lot of this ... I guess it would help a lot of people.

</comment></comment></comment><comment><USER19> _The vast majority of developers don't know what those details are_

Let me fix this for you. Vast majority of developers are actively denied access to the infrastructure by their managers. They pretty much know everything what an infra eng knows (and even more, after all all this catchy cutting-edge apps like Kubernetes/Elasticsearch/etc. was written by them) or even more.

Blame the managers and no-one else.

<comment><USER20> Are the developers-who-are-denied-access that you describe also on-call and watching monitoring alerts for when something goes awry?

I've worked in companies where "DevOps" was thought to mean: "Devs have a lot of access, even root/dba/etc. access, and while they're sleeping or if they get stuck on something, they should punt it over half-finished or half-broken to the infra eng / devops group"

^^ This is so incredibly common, especially in small/startup environments. It's a nightmare I actively aim to fix when I join / consult at companies.

There's instability in the environment, inconsistencies, or just a mess, and you parachute in there to fix. Step 1, kick out all devs from any systems they have too much access (unless they're special, knowledgeable ones and know and understand what you're trying to do), Step 2, stabilize the system. Step 2 involves environment separation, real automation that more than one person can use, setting up monitoring, and much much more.

<comment><USER19> > _while they 're sleeping or if they get stuck on something, they should punt > it over half-finished or half-broken to the infra eng_

By the description of it, the root cause of the problem is your setup. Dismantle the infra eng team and make the dev team to monitor their own apps.

By reading of your explanation devs should have more access and responsibilities.

You set up a half baked process and you are blaming the devs for it? Not cool.

<comment><USER20> I've never seen anything like that, nor have my dev and DevOps buddies, ever seen anything like what you just suggested.

Dismantle infra eng and make devs do everything? I support that, for one reason: a year from now I can charge consulting dollars when I come to fix these unstable, poorly documented, environments with minimal automation and HA.

<comment><USER19> Well I did that in the startup I worked in previously. And no, they are not gonna call you for your shitty service. They are pretty stable.

Guess what? We knew how to configure private clouds, loadbalancers, sharding and high availability. We pretty much know everything about Kubernetes/Amazon ECS et. al and related technologies and we didn't have any problems with monitoring or low level networking among others either.

Anyone can learn this shit. There is nothing special about it.

Don't hold your breath for seeing your consulting dollars, LOL. :D

</comment></comment></comment></comment></comment><comment><USER21> Like: the emphasis on tests, with real pointers to testing Terraform plans. That's legit, and hard advice to come by.

Dislike: 300K lines of infrastructure code, but all he talked about was DevOps issues? Surely he learned something about writing good code, too, and I hope he didn't write 300K lines of Terraform code.

<comment><USER22> > hope he didn't write 300K lines of Terraform code.

If you look at the company, their product is providing infrastructure code, it was not a byproduct.

</comment></comment><comment><USER23> ... , then replace all that Terraform code with Cloudformation templates. You will get 5x less code, native vs third party tool v0.11 and my respect :)

<comment> yjftsjthsd-h You are the first person I've encountered who preferred cloudformation over terraform. CF has far worse ability to cope with out-of-band changes or problems in general (in contrast to TF, which can usually just `apply` things back into compliance), and somehow gets feature support slower than TF in spite of being 1st party.

<comment><USER23> > just `apply` things back into compliance

If your things are wandering out of compliance by themselves, you have bigger problems, imho.

<comment><USER24> Likely the commenter is referring to development environments, where it is common for infra to be put in bizarre states by actors performing changes. Terraform alone is does not constitute change control.

</comment></comment></comment></comment><comment><USER25> > Make sure your team has the time to master these tools

What a luxury!

<comment><USER12> Really though, if you can't master the tools, maybe you should avoid them.

<comment><USER26> There are degrees here. Depends what kind of scotsman we are talking about. Having a general understanding of the uses of the tool, understanding what feasible in general, some best-practice rules of thumb and knowing how to google for details gets you most the way there. You could call that mastery. It certainly requires greater expertise than "I read a blog post and changed a few things until it seemed to work." But the bar is much lower than: is familiar with the source code; or even you can use the tool for common uses cases without recourse to the documentation.

I think you do need to invest in getting over that initial learning curve such that your tools aren't "magic." You have a conceptual mental model of what is going on. And I agree that takes much more than a token effort. Yet for me, that also stops short of mastery.

<comment><USER12> Well, it should at least be possible to become master. "I know how this works but someone else did the grunt work".

I always aim for simple to use tools, if I need to I can dig deeper and just- fix-the-problem. Or replace it at a whim.

So I agree with you.

Infrastructure code is really tough when it's scaling, so keep your modules in shape/order and small/easy.

</comment></comment></comment></comment><comment><USER27> Are there any good "worked examples" of infrastructure as code out there? Something one can learn good practices from?

<comment><USER28> The [https://github.com/gruntwork-io](https://github.com/gruntwork-io) & [https://github.com/cloudposse](https://github.com/cloudposse) examples spring to mind.

As for example implementations review cloudposse in depth or take a look at the [https://github.com/travis-ci/terraform-config](https://github.com/travis- ci/terraform-config) repo.

This answer is skewed towards _infrastructure_ as code. Often conflated are things such as configuration management & provisioning.

</comment></comment><comment><USER29> Several good tips in here, but slides 60-72 are probably the most valuable - don't do anything by hand, find some tools and automate everything using those tools.

</comment><comment><USER30> LOC is a very very bad metric. How exactly is it counted? Include mass refactoring? Is there a better metric? Yes, a long list of testimonials from happy customers.

</comment><comment><USER31> One glaring omission is metrics.

In the production grade checklist, there is nothing mentioned about metrics.

Infact there is no mention in the post of metrics or graphs.

This implies that everything is done via logs, which is just horrific at scale.

Everything should emit metrics: o hits per second? metric o Memory use? metric o upstream service response time? metric o That new lib you wrote? metrics

This is especially important with microservices. Open trace is grand, but thats for after you've found where the problem is. Your metrics should be your single pain of glass that indicates the health and performance of your system.

<comment><USER32> i think it's called monitoring in the checklist.

</comment></comment><comment><USER28> Lots of people in this thread bashing on LOC as a metric, which is fair. I'd just like to point out that infrastructure code is incredibly verbose as is, so the number is way overstated to start.

It's a pretty good example of doctoring headline worthy titles. IIRC the author gave a talk of a similar name at the hashiconf recently.

</comment><comment><USER33> Is there a version of this that is //just text// instead of a whole bunch of images and other resources that don't load without scripts enabled?

<comment><USER10> There's a transcript of the talk on the HashiCorp website: [https://www.hashicorp.com/resources/lessons- learned-300000-l...](https://www.hashicorp.com/resources/lessons- learned-300000-lines-code)

</comment></comment><comment><USER34> anyone care to take a stab at defining what the author means by 'infrastructure code' ?

<comment><USER35> Infrastructure as code is starting to be a big thing. Lets say you want to provision a new AWS EC2 instance, you could go into the UI and click around to do it, but at a large company, that's probably not the best idea. That's not really scaleable and leaves a lot of room for human error.

You could instead use something like terraform, which allows you to write code specifying your requirements and then run that code. This allows other devs to review your code, takes a lot of human error out of the equation, and is much more sustainable.

When he says infrastructure code, I think he means code that keeps the infrastructure running.

Some examples that come to m would be terraform files, dockerfiles/docker- compose files, jenkinsfiles, bash scripts, etc. Basically, code that keeps the servers running.

<comment><USER36> So a JCL then?

The largest code base I worked on (a map reduce based billing system), also had for the time early 80's a fairly complex set of JCL that could compile and build all the systems module's on dev and also push it out to the 15-16 or so live systems.

This also handled all the glue that held together the map reduce.

<comment><USER37> It's not procedural. You write what you want your infrastructure to look like in the case of CloudFormation yaml or JSON.

The first time you run your template it creates all of your infrastructure and is usually smart enough to figure out dependencies.

After you make changes to your template and run it again it knows based on the changes in your template whether it can modify the existing resources or whether it needs to delete and recreate your resources.

<comment><USER26> Procedural certainly can be "Infrastructure as code." It just isn't the most modern way to do it, due to additional complexity and the potential to be more error prone. I'd certainly prefer CloudFormation over writing a bunch of python/boto code, but it could be done.

Interestingly, Dockerfiles brought back a bunch of procedural configuration management. We had migrated to ansible for all our server-level configuration. But as we've adopted docker/containerization in recent years, simplifying our applications (now separate containers, rather than severs on common servers) has such a reduced level complexity such that simple docker files with `apt- get install foo` are much preferred.

</comment></comment></comment></comment></comment><comment><USER38> The issue with configuration management is it creates a DAG above a build system that does the same, as in its superfluous.

<comment><USER39> Configuration management provides opinionated abstractions over inconsistent and frequently user-unfriendly systems. You might as well say that C is superfluous because it all maps down to assembly.

<comment><USER38> I'm saying creating two DAGs is superfluous, fbsd, obsd, nbsd, etc all don't do this. If you want to abstract the CLI tools why do it in a non-portable implementation specific language?

</comment></comment></comment><comment><USER40> nice. it's rather on-point.

</comment><comment><USER41> That your writing too much code?

<comment> yjftsjthsd-h Are you criticizing the abstractions, or amount of infrastructure?

<comment><USER41> Thats code on top of frameworks, to do roughly similar things. As a software engineer I wouldn't be happy writing, and definitely maintaining so much code.

His points are fine, but shocker its the same principals that apply to all code, infra isn't that special, thought we established that years ago.

Also starting by boasting about the number of lines of code you have written to achieve something is asking for trouble.

It feels like many in the 'devops' community that are from an ops background are rediscovering software principals, this chap isn't alone in that!

<comment><USER37> Infrastructure is special - if I make a change to my code, it usually won't kill a whole database, load balancers, knock out connectivity, etc.

<comment><USER41> A load balancer is not much use if the application on the other side is borked because of the application code is faulty, I don't really see your point.

What I do see is 'devops' typically changing code in critical areas without taking sufficient care, but thats more a cultural thing than infra code being special.

<comment><USER37> If you make a minor mistake in application code, it usually doesn't affect the whole site. Besides, when you are deploying code on a group of servers, hopefully you have sense enough to at least do a rolling deployment and are using automated health checks to make sure that your whole site isn't down during a deployment.

<comment><USER42> Nor does my infra code, because I write tests, and have a pre-prod end to test it in a controlled ci approach.</comment></comment></comment></comment></comment></comment></comment>


The Search for the Killer iPhone App - <AUTHOR> http://www.businessweek.com/technology/content/mar2008/tc20080311_060174.htm?campaign_id=rss_tech <comment><USER2> The $100M dollar iFund certainly grabs the headlines. You have to wonder though if they didn't just slap on another zero to beat Google's $10M prize for their Android developer challenge.</comment>


Apple is Wall Street's #1 Growth Stock - <AUTHOR> http://money.msn.com/business-news/article.aspx?feed=IVPL&Date=20120124&ID=14722856

<comment><USER2> Anytime i hear things like this, i back out of any long positions i have in it. When people at cocktail parties tell you buy company X, its a bad sign (overcrowded trade).</comment>