Ask HN: Do you prefer to learn by watching videos or by reading books/articles? - <AUTHOR> I'm curious which kind of learning do you like more and why. <comment><USER4> Definitely reading. Videos take too long to extract information from. This is especially true if it is a topic I'm somewhat familiar with. I can just skim while reading until I hit something I'm unfamiliar with or if I find I'm confused later I can just go back and reread. This is much more difficult to do with a video.

<comment><USER5> Every so often I'll encounter a video that is delivering content at the exact level that I need. But most of the times I'm skipping through it to get past the intro. I worry that im skipping something important, though.

It would be interesting to see some sort of summary (text?) that would help a viewer determine what subjects are being covered in different portions of the video without having to watch the whole thing. Or perhaps even markers that indicate shifts in topic, etc.

<comment><USER6> Yes. Random access and indexing are two areas where books kill videos.

Also, a fast reader can absorb information at a considerably higher rate than what you get from normal speech.

There have been experiments that indicate that it's possible to understand speech at significantly higher than normal rates (i.e., you can speed up the video and still get just about the same information from it). The "chipmunk" effect is a little distracting, but you get used to it.

</comment></comment></comment><comment><USER7> I would have said reading, until I realized that some things can be made more explicit in the video. But in most cases, it is by reading. Specific examples were I liked videos explaining something better (or perhaps as good as the book) are: Unix System Calls ([https://www.youtube.com/watch?v=xHu7qI1gDPA](https://www.youtube.com/watch?v=xHu7qI1gDPA)) and Suffix Trees ([https://www.youtube.com/watch?v=hLsrPsFHPcQ](https://www.youtube.com/watch?v=hLsrPsFHPcQ)). A lot depends upon how much effort has been put into making of a video. Codeschool's guide ([https://gist.github.com/olivierlacan/4062929](https://gist.github.com/olivierlacan/4062929)) is a great start.

One issue I see with books/articles is typos. Not many technical book writers are diligent about typos and outright mistakes and coming up with updates for a book is perhaps hard. I become especially infuriated and it stalls my progress when a particular concept/paragraph written in the book is either wrong or I am confused about it and the author is not immediately reachable for clarification. Same might be true with videos, but many videos are live talks and such mistakes are rarer in those settings.

<comment><USER8> > One issue I see with books/articles is typos.

This is why my book is hooked up directly to GitHub. You can ask questions and get clarification with two clicks.

</comment></comment><comment><USER9> Neither. I prefer to learn by doing.

It's not even close and it's always been this way.

In school, I really had trouble following lectures. Taking notes helped. It was hard to focus reading at night. Writing in the book helped. For homework, whenever I wrote or solved problems, I retained it forever (it seems).

At work, I rarely understand what someone's talking about when explaining or demonstrating something new to me. So I invariably say, "Stop! Tell me what to do and I'll do it." If they go too fast, I tell them to slow down. This has been the single most important thing I've done with learning in business, for myself and with others. I never teach by lecturing or writing (except here one the internet, of course); I always make the student do it while I tell them what to do. This is the only real way I've ever been able to assure myself that they'll remember.

Just this morning, I had trouble with the credit card swiper at the store register and asked for help. The attendant jumped in and starting hitting buttons. As usual, I yelled, "Stop! Tell me what to do and I'll do it. How else will I learn?"

As the old Chinese proverb said:

      Tell me, I'll forget
      Show me, I'll remember
      Involve me, I'll understand

<comment><USER10> Absolutely.

I absorb information fine by reading but I get too bored to keep focused. Usually I already know what I want to build so I like to just be shown a reference documentation, example usage welcome. I can't do books on programming languages/webapps/technologies because it's such a slog through dense material, usually with a boring example project, and at the end of hundreds of pages you only end up knowing enough to "get started".

Videos are usually better for "big picture stuff" for me. Broad views on the architecture of a service, advice, or the story of why things are the way they are. I hate having to go through long tutorial videos and screencasts.

</comment></comment><comment><USER11> I really hate it when I am searching for some quick info and I am forced to endure a 20 minute video out of which only 20 seconds were what I was looking for. At least with a written article you can skip through to the part you need.

</comment><comment><USER12> Reading - especially reading concise articles on a focused problem domain, and on the other hand, reading actual code. I think over the years I've gotten a sense for recognizing good, readable code.

</comment><comment><USER13> Reading. Much easier to adjust pace to match my understanding, and referring back to the material is far saner. Inevitably any time I learn from a video, I find myself scrolling the slider back and forth hunting for the key piece of info I want to rewatch.

</comment><comment><USER14> Reading, unless it's something _really_ suited to video. Programming is not, as far as I'm concerned: I can't scan things quickly, I can't grep, it's harder to skip around, and I can't cut and paste. I hate videos for anything having to do with programming.

<comment><USER15> I've just finished my first online course, in Python. I'm not new to programming but was completely new to Python.

I find the spoken word helps me with engagement, so listening to someone talk through something helped me to maintain focus.

In this case the Coursera course website allowed me to do listen to the whole lecture course at 1.5x speed - as part of the screen shows the work area with the code/slides at all times it was also easy to skip on once I'd grasped the point being made or when all I was doing was scanning over a new syntax and I felt I didn't need to listen (at higher speeds the software didn't make the audio clear enough). Similarly I could easily scan the video if I wanted to review something. The lectures followed a book, but I never used the book - <USER2> part because it was online rather than a proper book and bizarrely I don't really like reading long texts on a screen.

Before this I've only ever done formalised education using books. Though I've learnt to throw pots (on a pottery wheel) largely from watching YouTube videos.

My intent here is not to disagree but to add some complexion.

<comment><USER14> > Though I've learnt to throw pots (on a pottery wheel) largely from watching > YouTube videos.

Something like that I could see making sense. Still pictures might not give you as good an idea of what's going on as continuous video.

</comment></comment></comment><comment><USER16> Videos have several advantages for some kinds of tasks. Also less spam (eHow etc). For example, to learn how to shuffle a deck of cards, I would go directly to Youtube. Or how to clean a car. Or how to do a margarita. I would watch several videos about the subject and see what each guy does differently. Stuff that post on eHow would miss.

This guy is showing how to write a game from scratch, by recording his screen and face for 2 hours per day. [https://www.youtube.com/user/handmadeheroarchive](https://www.youtube.com/user/handmadeheroarchive)

It would be very hard to to learn that amount of tricks and details from a text.

</comment><comment><USER17> Videos are good for something that is generally informative and interesting, but which I don't need to learn anything specific from. Like a conference presentation or a documentary. I learn from watching them, I'm entertained, and the experience is enjoyable. That's the whole point.

On the other hand, there are times where I just need some reference material to figure something out. That's when I need text. Videos-as-reference-material are generally terrible; they're slow and hard to seek and scan through. The only time a video is worth the compromise is when the content can't be explained any other way.

</comment><comment><USER18> Both. Each has their strong point, I usually divide them into:

* Directed learning by reading.

* Undirected learning by videos.

That is, if I know what I want to learn then I can usually go straight to it in books. If I just have a general fuzzy idea then videos tend to offer a higher level view that can help me to clarify my understanding.

I think videos are a poor medium for highly detailed learning. If you're looking for specific information then a book is much more easier to skim than a video is, it's not a good prospect to spend time watching a video to discovered that only 1% of the content was novel and relevant.

</comment><comment><USER19> Definitely reading. Personally, videos are annoying, especially when big part of it is useless -- speaker introduction, "jokes" and other unrelated small talks. Of course, the biggest shortcome is that you simply can't ctrl+f a specific keyword your are interested in and it takes much longer to find related info in a video. The only exception is social sciences, arts and humanities where context matters more and information I am looking for is broader than "what's the function name that does X".

</comment><comment><USER20> Apparently, according to my dad who's a psychologist, there are four major learning styles, and people can fall into any of those as a "preferred" learning style:

\- Learn by reading how to do it (books, articles, etc)

\- Learn by being told how to do it (audio lessons, in-person teacher, etc)

\- Learn by seeing someone do it (video, demonstration, etc)

\- Learn by doing it yourself (tutor, coach, instructor, etc)

Neither of those modes is superior to the others. Some people find one mode works best for them. Others find another works best for them. Everyone has a preference. Everyone is _capable_ of learning in any of these modes, but is better at one or two of them.

So, I would suggest to all those whose comment summarises as "I think learning works best by doing A, not B, C or D" to consider that as the original question implies, this is a preference, not a universality! Everyone's different.

<comment><USER21> I would say that 1-3 are superior, because 4 costs more than 1 person's time. The others can be done for a group and/or redistributed. Additionally, I'd say 1 can be superior to 2 and 3, because 1 can take significantly less time with practice...

That being said, I play tut videos on fast speed in the background, I've learned a lot this way. Type 5: Osmosis.

Realistically, everyone probably benefits from multiple factors. There's understanding to test, to do, and to discuss. They are often learned at different times.

</comment></comment><comment><USER22> There is a third option - listening.

I use a service - [http://www.narro.co](http://www.narro.co), I built it - <USER3> extract text from any web page and listen to it via podcast. It's great for listening/reading to articles and blogs while doing other things.

</comment><comment><USER23> Reading. In college I discovered that I just don't have the brain wired to absorb knowledge from someone talking. This is not just about videos but also about teachers in front of a class. When there is difficult stuff that _really_ requires deep meditation to understand, I'd rather have deadlines to learn something (an exam, e.g.) and be given the proper written material to learn it. It needs to be of good quality however -- not just bare powerpoint slides with a couple of unexplained equations.

On the other hand, integrating highly interactive visualizations is, in my opinion, a key aspect of learning, and that's where video should be used most. Developing intuition behind equations/code is what triggers connections and understanding.

</comment><comment><USER24> Programming and configurations: reading, particularly on the same machine where I'm following along with my own working code so I can copy/paste samples, and skip around.

UI/Tools: video, especially when several tools are being used together in a somewhat complex workflow.

</comment><comment><USER25> I prefer to learn from short, focused articles, tutorials, book chapters or answers.

Nonetheless, I've learned a lot of interesting concepts from video lectures like "Software as a Service" by Armando Fox and David Patterson, and "Functional Programming Principles in Scala" by Martin Odersky. But when I need to apply those concepts I will look for written matterial, like "Engineering Software as a Service: An Agile Approach Using Cloud Computing" by Fox and Patterson (covering the subject matter of their video lectures), or "The Neophyte's Guide to Scala" by Daniel Westheide, explaining particular topics about how to write idiomatic code in Scala.

</comment><comment><USER26> Doing. - Tutorials and step by steps via video or reading sometimes assist in this, but often they are to slow. This assumes we are talking about "learning" how to do something-- not for instance "learning" who the first 5 presidents of the US had been. In this case though "research" \-- using multiple sources and short bursts of reading from those sources relative to the topic provide the longest lasting knowledge for me. Then toss something in like a long form biography or history book after the research has established interest, or even doing more research after the book has established more interest.

</comment><comment><USER27> Given the general trend, I find it surprising that I learn a lot better by watching videos. Though, the videos have to be clear, stay in the topic and move on fast enough. Reading books and/or articles is slow and exhausting and for some reason I cannot see the full picture of the underlying concept. On the other hand, videos give me larger and deeper understanding of almost any subject, programming included. I consider learning the concept and the theory is far more important than copying and pasting examples. Fortunately, there are a lot of tutorials that offer documentation, examples and videos altogether.

</comment><comment><USER28> A third option: I prefer to learn by working with an expert. Pre-fixed materials can only go so far. Just by watching someone do it you can absorb much more than the equivalent video. Then you have the opportunity to switch roles and the expert can watch you, providing vital feedback at the critical moment. It's all about having tight feedback loops, and the crude indicator of "did I succeed" or whatever doesn't provide the same level of insight.

Worse yet, if you learn a concept from a book or video and don't effectively apply it correctly, there's a danger you can have the wrong idea about a thing.

</comment><comment><USER29> I prefer to read and do projects. But I think it's important to mix learning modalities.

While the idea that different people may be more or less effective with different learning styles seems reasonable, I don't think you want to focus too much one method.

As an earlier poster said different modalities have different strengths.

But beyond that I think there's a synergistic effect when you combine modalities. There's insight you get by comparing what you learned via different techniques that you can't achieve by using one method alone.

</comment><comment><USER30> I often like to _listen_ more than watching and reading. There is a tremendous amount of online lectures which can be listened to while working out or while running. Some Podcasts are also instructive. I would never have "read" GTD by David Allen if I hadn't gotten the audiobook, some topics don't interest me enough from the get-go (non-technical books) or have started to feel like a waste of time over the years (fiction) to really convince myself to sit and focus on the actual book.

<comment><USER22> I'm the same way! I've recently created a service that will take any web page and extract the text and read it back to you in high-quality TTS: [http://www.narro.co](http://www.narro.co) \- Your feed is available as a podcast, so you can have new readings immediately sent to your phone/whatever. I think you'll really really enjoy it!

<comment><USER30> Thank you very much - this is wonderful, great work (usability, privacy policy and especially the quality of the voice synthesis)!

</comment></comment></comment><comment><USER31> Reading.

Videos take longer, and I have to following their flow and pacing instead of my own. Also, there are very low standards of quality for videos these days, especially in the tech world, where it is now OK for someone with poor speaking abilities and presence to be on-screen. Clearly, most people are not bothered by this, but it bugs me. To each their own.

I will use video if reading just isn't getting the point across to me. But I will look for specific points in a video to see a specific visual example.

</comment><comment><USER32> I agree, doing is the best way to learn. But it is most effective when what you are"doing" is attempting to solve a problem. However, since learning can't be done without any teacher or access to a repository of the knowledge you need, you must seek out this knowledge. For me, consulting books or sourcing opinions from those considered knowledgeable on the web seems to work best for me.

I almost regress in knowledge by watching videos.

</comment><comment><USER33> I do reading a lot, because i can skim through all content and look what is the big picture. It save my time to decide "should i read this?" Or "is it solve my problem/make me more understand after reading it?"

And whenever read are not enough or i'm not fully understand i watch some video from Khan Academy. For example, when i learning about Laplace Transformation i watch some video from Khan Academy

</comment><comment><USER34> Most of the time reading for the reasons others have stated(scannable, copy examples, etc). That said, there are times where I read something a number of times and the concept still doesn't click. In those instances a short video of just that specific concept is great. Short, hyper-specific screencasts are useful where exhaustive videos are not as much (to me).

</comment><comment><USER35> Books and tutorials. Apart from a sport, I don't think I've ever learned anything by watching someone do it, and even then it took hours and hours of repeating what I had seen to actually learn it.

Where video can shine is when it comes to explaining concepts or using analogies to clarify things, much as a lecturer would. Watching someone code is coma-inducing to me.

</comment><comment><USER36> I start with reading, and that's sufficient most of the time. If I just don't get it, then I'll look for a video. I'll set playback to fast to reduce the time it takes to get through it. When I heard what I needed, I hit stop.

Just did this recently with the new async/await keywords in c#. I just wasn't getting it, but a few videos did the trick.

</comment><comment><USER37> I prefer both.. that is a nice video along with an accurate transcription and code samples directly below it. It's the best of both worlds..

example: [http://railscasts.com/episodes/222-rack-in- rails-3](http://railscasts.com/episodes/222-rack-in-rails-3)

^ that's the kind of thing I'd whip out the plastic for any day of the week :)

</comment><comment><USER38> I actually do both, Simultaneously. Put a lecture on one screen, read up and google things on the other.

</comment><comment><USER39> Unless it's a physical activity, I prefer reading. I find the rising prevalence of explaining by video annoying. It takes too long to extract information that I could have read in 30 seconds. That, and most videos are crappily done and distract from the content.

</comment><comment><USER40> Really depends on the subject but I find myself reading more than watching videos.

Probably because most videos I happen to watch are either bad quality (both in content & literally), too slow or too fast. But then again, some things I understand better when seeing them.

</comment><comment><USER41> Both, plus doing. I like watching a video to get an overview of what I'm learning is and what it does, then I start my own project using what I'm learning and read up on things that I need to know to get my project finished.

</comment><comment><USER42> Definitely reading. For programming stuff, you can't skip around videos, you can't copy/paste and you have to watch the author tabbing between windows, typing commands and waiting for things to happen (like compilation).

</comment><comment><USER43> Books. Definitely. And printed books at that. You can't scan a video quickly for relevant content (I don't mean digitally scan, I mean look at quickly), and it's easier to flick through a book than an e-book/pdf.

</comment><comment><USER44> I prefer bashing it out myself with a mentor within arms reach: "Hey, when you're free..."

But of the two given options, it's reading, because it's _much_ easier to reread an important bit than to go back in a video.

</comment><comment><USER45> Reading, no question. Even more so if it is a question of programming, or configuration, where step-by-step examples -which I can copy-paste into the terminal- are orders of magnitude more useful than a video.

</comment><comment><USER46> While I find reading way more productive, I'm a fairly lazy person, and I find I tend to bear with whatever I need to study better when watching videos. I simply lose focus too fast with books.

</comment><comment><USER47> It depends on the subject. I need to read -preferably examples- to learn/evaluate a programming language, and, obvoisly, you'll look for videos in order to learn/evaluate a GUI.

</comment><comment><USER48> Reading. But videos are occasionally useful if there is something tricky with the user interface. I think I needed a video to help me link objects in Xcode the first time I used it.

<comment><USER6> Videos are good for stuff that involves hand manipulation (tying knots or dragging stuff around in a GUI). Text is good for stuff that involves mental manipulation.

</comment></comment><comment><USER49> Doing / reading seems to be the most effictive..

Video's are way to slow for me, when a book has an easy chapter (eg. on a topic i already know things from). You can just skip it

</comment><comment><USER50> It depends what I'm learning. If its software development related learning I'd prefer to read. If its for learning a new recipe I'd rather watch a video.

</comment><comment><USER51> We need something new. Something disruptive. Adaptive learning, with audio, video, questions, answers. Everything. A wiki for knowledge. A search box of knowledge.

</comment><comment><USER52> Definitely reading. Specifically I like structured, linear reading such as books. Jumping around from blog post to blog post just boggles my mind.

</comment><comment><USER53> I use all of them depending on the subject matter, but usually the more difficult the subject is the more strongly I lean on printed books.

</comment><comment><USER54> Reading. It's faster for me, and too many videos don't have closed captioning so I miss too much of the information in them.

</comment><comment><USER55> Reading for the most part, although videos work if they have the 1.5x speed enabled. This way I can watch it faster.

</comment><comment><USER56> depends. i mostly learn by doing. like cars/physical things, i get some tools out, and go to work. might take a while, but i always get there and usually learn a lot in the process.

same with computer stuff, although then there's a lot of looking at examples as well

</comment><comment><USER15> Preferred learning medium is very context sensitive for me too: why are you enquiring.

</comment><comment><USER57> Definitely reading and videos for design stuff or when I want to discover a new tool.

</comment><comment><USER58> Books, especially the kind with exercises at the _end_ of each chapter/section.

</comment><comment><USER59> Videos for getting a broad overview of a topic.

Reading for looking for something specific.

</comment><comment><USER60> In my case i prefer Text tutorials with copy/past able code scripts

</comment><comment><USER61> Reading, but with direct examples (formulae, code, screenshots etc).

</comment><comment><USER62> Reading - because I can go at my own pace. Videos are like tl;dw.

</comment><comment><USER63> None of the above : I'd rather have one on one tutoring.

</comment><comment><USER64> Reading

</comment><comment><USER65> Reading.

</comment><comment><USER66> videos

</comment><comment><USER67> Well, before I get started ... can you read this? I can't tell. Well, I'll get to my answer in a minute.

I'll get started in a few minutes but how many of you liked your lunch today?

Yeah ... yeah...

Huh?

Did any of you see that movie last night? I think it relates to this. What was it called?

Ok. Ok.

Now, if you're all ready. I'll get started. You can all read this right?

What I'd like to write about today is my preference for reading about something compared to watching a video.</comment>


2010 Nobel Prize for Peace Awarded to Liu Xiaobo  - <AUTHOR> http://nobelprize.org/nobel_prizes/peace/laureates/2010/

<comment><USER2> > Of course, equating the Nobel committee with the Norwegian government is as > wrong as equating a newspaper editor printing Islamic cartoons with it, then > torching down an embassy.

This is very western way of seeing thing, which I happen to agree. The current Chinese education system has been trying very hard, and quite successfully, to mix these concepts together: country, geographic land, government, ethnic group in order to make the current political system legitimate by "natural".

Now, if you ask me what will happen to liuxiaobo, I'd bet 80%+ on that he will stay in prison. Based on my observation of the a few years after the tian'an'men massacre and the economic position China is having right now, I don't expect Chinese government to back off on this particular issue under external pressures. What'll happen is the news will soon move on to the next interesting topic and what's going on with China will continue on its path.

As a Chinese, I'm quite impressed by the fact that the Nobel committee has the gut to take the risk and stick with their own decision. I'd, humbly, call this the triumph of humanity since it values human rights and the pursue of personal freedom over pure economic considerations.

<comment><USER3> _This is very western way of seeing thing, which I happen to agree. The current Chinese education system has been trying very hard, and quite successfully, to mix these concepts together: country, geographic land, government, ethnic group in order to make the current political system legitimate by "natural"._

I agree as far as the current situation, but I don't think it's anything inherent about western or non-western ways of thinking, just a result of where Europe and China happen to be currently in their politics. Mixing country/land/government/ethnic-group into a "natural" whole used to be a very European idea as well, and was probably the dominant view of nation-states throughout the period of European ethnic nationalism in the 18th and 19th centuries.

I think that today it's unpopular in Europe partly because it's so associated with 20th-century fascism: no mainstream German today would want to promote the idea that the German people, the German land, the German state, and German culture are some sort of natural, unified whole, because that sort of rhetoric marks you out as a member of the far-right.

</comment></comment><comment><USER4> I don't think the Nobel committee has ever given out the price without having been slammed by someone or some government. The price is political so it's no wonder. Apparently, Chinese foreign affairs has already stated that this may damage Chinese-Norwegian relations (sorry no citation). Of course, equating the Nobel committee with the Norwegian government is as wrong as equating a newspaper editor printing Islamic cartoons with it, then torching down an embassy.

<comment><USER5> here's your citation:

Chinese Foreign Ministry: _The Nobel Committee awarding Liu this prize, which runs contrary to the principle of the Peace Prize, will bring damage to two- way relations._

<http://www.bbc.co.uk/news/world-europe-11499931>

<comment><USER6> here is the official citation

<http://www.fmprc.gov.cn/chn/gxh/tyb/fyrbt/t759532.htm>

</comment></comment></comment><comment><USER7> Congratulations to Mr Liu - his imprisonment remains a sign of how far China has yet to travel.

<comment><AUTHOR> Apparently, China blacked out both CNN and BBC when the announcement was made (<http://twitter.com/joCNN/status/26731788647>).

<comment><USER8> I wonder what a google search would return.

<comment><USER9> google.com.hk has the prize winner listed as the third link with the terms "nobel peace prize 2010".

Google.cn still redirects to google.com.hk for searching.

[http://www.google.com.hk/search?hl=zh- CN&source=hp&b...](http://www.google.com.hk/search?hl=zh- CN&source=hp&biw=1824&bih=1293&q=nobel+peace+prize+2010&aq=f&aqi=g1&aql=&oq=&gs_rfai=CzfX- GDuvTMjOApSEygTtsoWHBQAAAKoEBU_QIu0a)

<comment><USER10> Baidu also has search results relating to the subject:

[http://www.baidu.com/s?wd=Liu+Xiaobo&n=2](http://www.baidu.com/s?wd=Liu+Xiaobo&n=2)

</comment></comment></comment></comment></comment><comment><USER5> It will be interesting to see whether China is going to follow through with their threat to downgrade their political relations with Norway now.

<comment><USER11> This is not an award given by the Norwegian government. It is given by the independent Norwegian Nobel Committee. If the means anything for the chinese I don't know, but it is a huge difference with regard to the two countries political relations.

<comment><USER12> Yes, an independent committee whose "five members are appointed by the Norwegian Parliament and roughly represent the political makeup of that body".

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

<comment><USER9> That may be true, but they aren't speaking with the authority of the state. There is a difference.

<comment><USER12> Sure, I don't disagree, I just wanted to provide some nuance to the word "independent".

</comment></comment></comment></comment></comment><comment><USER13> It should be marked as the most "unpeaceful" night of Nobel Peace Prize. As to date, More than ten people in Beijing and Shanghai who voluntarily celebrated the event were taken into custody.

</comment><comment><USER14> Two most well-known Chinese liberals share the same name -Xiaobo, what a coincidence! The other one is Wang Xiaobo, whose name is much more influencial in China.

</comment><comment><USER15> Now you've done it! Hacker News probably just got blocked out of The Great Firewall of China[tm).

All Norwegian sites will probably blocked out too.

BTW. I live in Norway.

<comment><USER16> No, it did not.

<comment><USER15> Great.

</comment></comment></comment><comment><USER17> Is the linked website real? "Photo: Wikidemia Commons" ??

This link may be more informative: [http://news.google.com/news/more?ncl=dbvIvqx2eu3bnMMiDfa9ho_...](http://news.google.com/news/more?ncl=dbvIvqx2eu3bnMMiDfa9ho_irbCyM)

China is going to be really mad! I hope they don't harm him for this. I guess the world is watching - now, but later? And secret less noticeable stuff?

Anyone know if he agreed to accept the prize?

<comment><USER18> I don't think one spleling mistake is enough to condemn a site as fake.

It's clearly legitimate; highest rank on google for "nobel", listed on wikipedia as the official site, etc etc etc

<comment><USER17> It wasn't the spelling mistake, it was the complete lack of content. I would expect more of a writeup of why they they are giving it to him, etc, etc. The spelling mistake really caught my eye though - it just seemed unprofessional. It's just not what you expect when you hear "Nobel prize".

<comment><USER19> The peace prize is awarded by the Norwegian Nobel Committee, and not the 'normal' Nobel Institute. The official site for the peace prize is at nobelpeaceprize.org and the official announcement is at <http://nobelpeaceprize.org/en_GB/announce-2010/></comment></comment></comment></comment>


Moderators who had to view child abuse content sue Microsoft, claiming PTSD - <AUTHOR> https://www.theguardian.com/technology/2017/jan/11/microsoft-employees-child-abuse-lawsuit-ptsd <comment><USER2> Duplicate of what was already posted 10 hours ago:

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

</comment><comment><USER3> Since they did have the choice to switch jobs, I think the most they should be able to claim is councelling fees.

<comment><USER4> It is just not allowed for an employer to offer a job that will seriously damage employees' health. It doesn't matter if employees have the choice to switch jobs or even if they let them sign some waiver to acknowledge they accept the health damage. Laws have been put into place to prevent this, basically to protect naive employees against themselves.

</comment></comment><comment><USER5> One possibility is that the employees are looking for easy money. Maybe they think it'll be easy to shock the jury into ruling in their favor.

I wonder if it makes sense to hire pedophiles to do this job. Especially if this lawsuit holds, pedophiles wouldn't be able to make similar claims. And you already need security measures to prevent them from stealing customer emails and such.

The other solution is to push more of this work onto a computer program, but no matter how well that works they'd probably want to have a human check it before sending customer data to the FBI.

At the very least, if it's a real problem they should probably screen people for having thick skins and make them sign a waiver or something.

<comment><USER6> I wouldn't be too dismissive of their claims - see this [1] long article on the subject, and particularly this [2] HN thread.

[1] [http://www.theverge.com/2016/4/13/11387934/internet- moderato...](http://www.theverge.com/2016/4/13/11387934/internet-moderator- history-youtube-facebook-reddit-censorship-free-speech) [2] [https://news.ycombinator.com/item?id=11502242](https://news.ycombinator.com/item?id=11502242)

</comment></comment><comment><USER7> yep, seen the first pic, if the job was so disgusting he should pop up and asking for a relocation or just quit and search for something else. anyway ... the opportunity of a millionaire lawsuit to Microsoft is always appealing, apparently</comment>


Ask HN: How do you build applications that require zero maintenance? - <AUTHOR> Is it even possible? How do you as a developer, not become a lifetime maintaimer? <comment><USER2> No 100%, but close.

1- Shield away from dependencies. Use languages that are robust (no JS, no PHP) and if possible, generate native .exes (Delphi, Rust, Go,...).

Langs with large runtime/deps (Java, .NET, Js) are always trouble in the long run. I re-enter with .NET Core and have regretted heavily it (because maintenance, not performance or dev productivity).

ie: If a lang/tool/ecosystem is for large teams (java, .net, c++), is not for zero maintenance.

How easy is to setup and get running something (without resort to auto- installers or docker images) is a high evidence in how good will be for this metric.

2- If possible (mobile) use iOS. Android is not robust at all for long term prospects

I made a enterprise iOS app that is also nearly worry-free. My only job is to upgrade xcode and recompile from time to time.

I enter android late in the game, dreaming that android become more or less good. Not.

3- Important! If possible, split the programas between what could be "zero maintenance" and high maintenance.

I have made one in Delphi that is running 10 years in some places with zero calls after the first 3 years of tweaking.

Is split in 2 parts: The Delphi side have stay solid, and the "business" side that requiere more changes are in scripts in python that I integrate with the Delphi side.

Even the python side is now near worry free, but I need to do changes here and there.

4- If need JS, pick VERY carefully how use it. JS is the anti-tesis of zero maintenance. The web is hostile in this area. You could lower damage if VERY carefully know what to use.

5- Stay away of stupid "is for scalability" traps. Micro-services, nosql and similar are the best way to destroy productivity. Modular code yet running in a monolithic (or maybe in a REST api + client) will be more than enough by long margins when coupled with postgresql or sqlite. Again, a solid RDBMS is what most need. "Eventual" consistency is a stupid choice most of time.

P.D: I'm solo developer, and have not time or high pay to cover for bad choices, so i try to perform very well in this metric.

<comment><USER3> > JS is the anti-tesis of zero maintenance.

If you know what you are doing you can write zero dependency code that works well with old and modern browsers alike. This isn't as hard as it sounds either.

<comment><USER4> Sure you can, but it might take you 2-3x as long to get the same results as you could have got by using modern JS features and APIs that aren't supported in older browsers, and it might take you 10-20x as long if you also have to reinvent the wheel for everything instead of using a few good libraries. For most projects in the real world, that is not going to be a trade-off worth making.

<comment><USER3> The only way that is true is if your friendly abstraction is producing your test automation for you.

Having no understanding of the DOM and the standard APIs then writing without dependencies might take 1000x longer. I was assuming a competent developer when I mentioned this isn't that hard.

</comment></comment></comment></comment><comment><USER5> 1: A slim stack

Every part of the stack will need maintenance every now and then. Some parts even introduce breaking changes and force you to alter your own code. The slimmer the stack, the less often you have to fix it. And the less often you have to fix or refactor your application.

2: A stack that values stability

Linux is a good example. Linus Torvald: "We do not break userspace!"

PHP is a another one. The core developers rarely introduce breaking changes. And when they plan to do so, there is usually an intense fight over it.

3: Acceptance Testing

In the simplest form that means sending http requests to your web application and check if it returns the expected output. In my experience, acceptance tests find more real world issues then unit tests.

4: Write less code

Writing the same functionality with less code has multiple advantages. One of them is that it will break less often. Much more could be said about it. Paul Graham brings up the value of terseness frequently:

[https://twitter.com/paulg/status/1068483193605681152](https://twitter.com/paulg/status/1068483193605681152) [https://twitter.com/paulg/status/1126403387044573185](https://twitter.com/paulg/status/1126403387044573185) [https://twitter.com/paulg/status/1056858408039735297](https://twitter.com/paulg/status/1056858408039735297)

Less is more. This is actually one of the reasons why I named my account no_gravity.

<comment><USER6> > 2: A stack that values stability

> Linux is a good example. Linus Torvald: "We do not break userspace!"

Sadly the people making things in userspace don't seem to mind breaking it frequently.

</comment></comment><comment><USER7> There are different kinds of "zero maintenance":

* sqlite says it's "zero maintenance" because nobody has to keep a database server running, and your .sqlite3 files don't need a defragmentation step or similar.

* There are middlewares like RabbitMQ where an upgrade through the OS installer generally Just Works [TM], no additional steps necessary. Yet somebody should monitor the RabbitMQ instance, just in case the service does go down, or reaches resource limits

* There are tools that have very limited scope and API surface to stay stable for a looong time, those are also kinda "zero maintenance".

In my experience, all serious business applications that automate workflows or otherwise create value do need some kind of regular maintenance.

Depending on the installation base and maintenance effort, striving for zero maintenance might not be cost effective.

> How do you as a developer, not become a lifetime maintaimer?

A maintainer is a developer.

Depending on the project, things you can do if you don't want to burden yourself with maintenance:

* Build a community around the project, and hand maintenance to the community

* abandon a project

* leave lots of documentation that makes it easy for others to maintain it

* pay somebody to maintain it

* work as a consultant/contractor, and fire the client after the initial development phase (might not be the best for your reputation, could be OK if you are up-front about it and make a _very_ good handoff).

* If most of the maintenance is keeping it up at all, engineer for availability over consistency (if applicable to the business domain).

* Accept that maintenance is part of the normal lifecycle

The appropriate strategies highly depend on the kind of project.

<comment><USER8> >and your .sqlite3 files don't need a defragmentation step or similar

They do benefit from a VACUUM from time to time [0].

[0] [https://sqlite.org/lang_vacuum.html](https://sqlite.org/lang_vacuum.html)

</comment></comment><comment><USER9> I built a side-project 3 years ago: [http://www.thecaucus.net](http://www.thecaucus.net)

I spent quite a bit of time getting it off the ground, but over the last 2 years, I've spent maybe ~10 hours in total keeping it running.

The only times when I've had to invest time into it, is when a certain piece of my tech stack gets deprecated or discontinued. For example, I had originally done login-auth through a SaaS provider, which then got acquired by a larger company which discontinued their API. I then had to go through their migration process to keep the site running. However, the above doesn't happen all that often, especially if you choose stable technologies and companies.

Besides that, I had consciously designed the site to be completely free of manual maintenance, even if it involved more upfront costs. Examples:

\- Going serverless via Heroku

\- Using SaaS services like RDS, S3, SendGrid etc

\- Using scripts and cron-jobs/heroku-schedulers to automate anything that needs periodic maintenance

\- Relying on "push" alerts as opposed to "polling" alerts. Ie, when something goes wrong, your server should notify you immediately. Instead of waiting for you to periodically check some dashboard

More details: [https://software.rajivprab.com/2018/04/29/caucus-tech- stack/](https://software.rajivprab.com/2018/04/29/caucus-tech-stack/)

</comment><comment><USER10> Two things are going to make Zero Maintenance kind of difficult. Assuming Ubuntu on an AWS EC2 instance here.

First one is taking OS updates that are security critical - as anytime you take an update theres a chance something somewhere gets broken.

Second one is AWS instances themselves being switched. From time to time (very infrequently in my experience) Amazon will send you an email indicating your EC2 instance is being migrated to a new physical host and to initiate this you must manually restart your instance.

As for the rest, a script in root's crontab that does:

1 - Delete log files older than X (because running out of disk space is not a good situation)

2 - Hit Lets Encrypt for new certs if necessary ( because expired certs give a lousy customer experience)

3 - Preemptively bounce any application servers (Nginx, PHP FPM, Tomcat, what have you )

4 - Setup all hosts such that your critical software restarts at boot time in the event of an unexpected reboot situation (gives you the ability to cron schedule nightly reboot command)

Additionally:

* If you're running any database regardless of where, be sure you allocated enough space that you don't end up running out of database storage

* Implement some downtime monitoring to tell you when there are issues

* It's a good practice to be changing passwords on any authenticated resource at some interval too

The practices listed here (off the top of my head - not an all inclusive list) are about as close as I attempt to get to Zero Maintenance myself. Customers pay for systems to be developed and they should expect some level of ongoing care and feeding as entropy is pervasive.

But its a good excuse to sell your customers a maintenance contract right?

<comment><USER11> > Preemptively bounce any application servers

Do you mind explaining this?

<comment><USER10> I personally like to stop/start any application server or web sever running on my hardware over the weekend with cron. I say "Preemptively Bounce" on the assumption that which is not periodically rebooted will at some point crash. Id rather take a few minutes outage at a time of my choosing. It's basically just cheap insurance for the paranoid.

</comment></comment></comment><comment><USER12> I've built 4-5 web apps over the last 5 years that have required zero/little maintenance.

There are only three reasons I've been drawn into some projects: 1) A bug occurs and needs to be fixed 2) An external dependency breaks something

\- Write tests and/or have high confidence in code/infrastructure behavior (using tools you know really well helps). Avoid cognitive complexity in code constructs aggressively. \- Limit integration w/ 3rd parties EXCEPT the ones that reduce your goal of zero-maintenance. \- Create interfaces/tooling which make automating tasks easy. \- Get notified when things break

</comment><comment><USER13> No-maintenance software must live in an environment which never changes (certain microcontroller code, and kiosk-type installations fit this definition). If you are devloping software exposed to the "normal" world, then change is inevitable as the environment evolves around you. Maintenance is a part of life. The key is to minimize the cost of that maintenance through good architecture and robust error handling.

<comment><USER14> Indeed, even NASA probes have mechanisms to be updated.

The blessing and curse of software is it's mutability.

</comment></comment><comment><USER15> Even if your business requirements never change, security updates are a thing. Many libraries have stated support policies after which a given version no longer receives updates. Fixing your application at a point in time and never updating dependencies etc is a liability. Assuming you update dependencies, at some point, you'll have breaking changes. (not really getting into the nuance of whether or not everyone will obey the rules of semantic versioning)

This all assumes your application is like most being built these days: you're using a framework on the web. If you put your application on a machine that never is exposed to the web, or you create an application with zero dependencies (including OS-level dependencies) you might get away with never updating it.

</comment><comment><USER16> Think about it this way, every line of code you write will become obsolete one day (e.g. business will change or new version of the language comes out). Every external dependency, where you deploy, how you deploy, the OS where you host the application, even how the user consumes your application will change.

So to avoid any maintenance, minimize - code, complexity and all dependency and use a language and platform that can last a few years. Essentially, in today's world this will be very difficult and doing this will also cost you development time, there is no easy way around it.

For example, you can build your whole app in Clojure, which is rock solid and stable, but even then you will have to patch the OS, JVM, DB etc. With traffic changes you will have to scale up / down.

</comment><comment><USER17> I've developed a couple of apps that only required a few hours a year essential maintenance. The biggest obstacles have been with being forced to upgrade libraries to work with changes to third party APIs (e.g. payment APIs, ad APIs), upgrades to do with OS changes (e.g. new versions of Android) and applying security patches to dependencies.

To decrease maintenance, generally you want to reduce your dependence on external services that might change, minimise the use of complex third party libraries that might have security problems later, and keep your app as simple as you can to reduce the chance of bugs.

It's hard to predict what changes are going to be required for a given ecosystem (e.g. Android, Mac, Chrome Web Store, web browsers) so sometimes it's a matter of luck unless you can guarantee the OS, hardware, APIs etc. are never going to change.

I'm currently working on a Chrome extension ([https://www.checkbot.io](https://www.checkbot.io)) that doesn't require a lot of essential maintenance besides keeping up with changes Google have been making to make extensions more secure. Bracing myself for what breaking Manifest v3 changes are announced.

</comment><comment><USER18> It's really hard to answer if you don't provide any context :) Zero maintenance for a blog, small webshop or some Kubernetes controlled madness running a zillion pods? For the first two:

1) Make everything static, HTML, CSS, don't manage your own servers

2) Use as few dependencies as possible when dealing with JS

2 a) For backend try to find a service that do the work for you without you deploying your servers

2 b) Maybe cloud functions are enough?

3) Write tests

4) Don't write bugs :D

5) Setup alerts (uptime robot)

<comment><USER19> > 2 b) Maybe cloud functions are enough?

I generally agree, but eventually you're gonna start getting emails saying things like "We're deprecating Node 8.x in our Lambda / Cloudfunction / etc"

<comment><USER18> Zero maintainability should mean 0.01% maintainability :) But that's true, one should go for a compiled language like Rust or Go.

</comment></comment></comment><comment><USER20> I have 100% zero maintenance software running on customer's site.

It is a Debian-powered machine, not connected to internet, which is performing various tasks and controlling some hardware. The software running on it was built 6 years ago in C++ and using OpenCV and CUDA. The machine powers on and off itself on a specific routine due to on-site checks.

It clears old logs automatically if older than X days or bigger than Y MBytes.

Until today, no software or hardware failure occurred. The whole disk is snapshotted with dd command. If hard drive failures occur, it's easy to swap it and start again.

</comment><comment><USER21> That's an amazingly useful thread. My 2 cents regarding the tech stack :

1\. Don't use a build system. Use scripting language that comes preinstalled on Debian / Ubuntu. Peel 5 is still my weapon of choice for robust small web apps. Look at python too.

2\. Avoid JS / Ajax. I can bet that security restrictions will break it in the future, however good old form POST works still pretty good.

3\. Use own hardware. Raspberry PI with HDD or some banana PI works quite allright. Also provisioning is easy by keeping a copy of your image.

4\. Don't use managed services. Use database on the very same machine that you host the app itself. Backup is an extra step you can achieve via those, but don't use External service, since it will most probably break.

</comment><comment><USER22> What applications? A bit more specifics?

Apps can not be zero maintenance by definition. Apps are literally alive, apps mature, evolve, get older, there will always be some kind of maintenance. As world changes, apps change with it.

If ZERO maintenance is a HARD requirement, then think about total isolation. No packaging, and NO ENVIRONMENT CHANGES. With constant, isolated env, it is possible to have a minimal maintenance app.

<comment><USER22> also FYI, with zero maintenance requirement Agile approach will not work. Throw anything agile out of the door, you need a strict top to bottom waterfall with set requirements.

Another argument that Agile can not be a hammer for every nail. Common sense with project management and architecture is extremely important.

<comment><USER23> You're product will be developed at some point - that is when it doesn't matter how the product was built. Agile is not an indefinite process.

</comment></comment></comment><comment><USER24> In order not to become a lifetime maintainer, you need to end-of-life applications. For technical reasons, we aspire to making applications have a long life, but from a business point of view, it's both unnecessary and difficult.

Don't plan for an application to live for more than five years, especially v1. Put enough work into architecture and maintainability to be able to throw it out and redevelop after five years. Be clear about this upfront. In five years' time you won't even be able to find devs to maintain what was developed today.

In order to 'maintain' an application properly business needs to keep _investing_ in modernization of the application, which is more than just maintenance. Let's say they need to invest 30% of the original cost per year. Most will not do that saying 'It is a capital asset that I paid for and it should work as expected for as long as I need it' \- okay but in five years time it will be so out of date that it will need to be redeveloped.

</comment><comment><USER25> >> Is it even possible?

No. The only code that requires no maintenance is the code you do not write. In other words, "No code is easier to maintain than no code." Add that to the nihilist coding attributes:

No code runs faster than no code.

No code has fewer bugs than no code.

No code uses less memory than no code.

No code is easier to understand than no code.

No code is easier to maintain than no code.

<comment><USER26> what?

<comment><USER25> Any code written will require some amount of maintenance.

The actual effort required to maintain the code will vary depending on what the code does, the environment the code runs in, and the needs of the code's end users.

Unmaintained code will ultimately fail the same way that all other things that humans build do. If someone does not maintain the code, it will eventually degrade and fail.

Anytime you write code, especially for a long-lasting endeavour, you should consider how the code you write will be maintained and what might cause it to fail sooner than expected.

<comment><USER27> That doesn't make any sense. I have code running on micro-controllers, that has been running 24/7 for 10 years. It's never going to "degrade", the hardware may fail but the code is solid.

I also have a maintenance contract for one of these: [https://arsandbox.ucdavis.edu/](https://arsandbox.ucdavis.edu/)

It turns itself off at night and back on in the morning. 3 years running now without touching it once, used by hundreds of people daily.

</comment></comment></comment></comment><comment><USER28> Don't build it.

Entrepreneurs occasionally ask me to take their idea and make it a reality. Their most common request is for me to build them a website so that they can sell stuff. Sure, I could take their money and build it, but it's much better for them to sell on an existing e-commerce site or learn how to use a CMS.

</comment><comment><USER29> Have it do one thing very well and document it clearly so users can build it into their own processes.

If it is more complicated than that ( i.e. must do several things very well with ever-changing needs ), document it clearly and include a link to the source code and build instructions.

</comment><comment><USER30> Render to static html, upload to Netlify or S3. Just works.

<comment><USER31> S3 requires an active AWS account with billing, etc., and upload to Netlify implies that you're trusting that Netlify's platform will be free forever.

<comment><USER32> The requirement was zero maintenance, not zero cost. If you have a web app, a hosting cost is expected.

<comment><USER33> I think the implication here is that you have to 'maintain your credit card'. Not an issue until you switch banks or have some sort of issue with a corporate card that you use with your AWS account.

I think it's being nitpicky for the purposes of this discussion but I think there are probably several HNers who could tell you about how their product hosted in AWS went down because of a credit card issue.

</comment></comment></comment></comment><comment><USER34> Unless you're building an application that doesn't interact with external systems, chances are your job is never finished, even if you choose to consider it finished.

If you don't want to be a lifetime maintainer, then you have to transfer ownership to someone else or consider the project to have reached its end of support.

Consider an analogy to building houses, it may appear that the builder has finished their job since the house is fully constructed, but like any system, it requires maintenance for the entire duration of its lifetime.

Systems degrade over time without maintenance.

</comment><comment><USER35> A noted mainframe programmer, Roy Burnam, once said that "A program that requires no maintenance is a program no one uses!"

Perhaps this should be elevated to "Burnam's Law".

</comment><comment><USER36> You don't. You develop it as sloppy as possible and then make yourself indispensable to your company by being the only one who can maintain the pile of junk.

Seriously speaking the following things help alot:

1.Reduce external dependencies. The less integration with 3rd party apis and services the less maintenance you will be doing. 2\. Reduce external dependencies. 3\. Reduce external dependencies. 4\. Unit Tests 5\. Integration Tests 6\. End to End Tests 7\. Reduce external dependencies.

</comment><comment><USER37> I have some simple serverless code that has run 500M+ times without issue. It took some extra work to get setup and monitored, but SQS and Lambda are amazing beasts.

</comment><comment><USER26> a few thoughts from someone who makes a living designing and building stable- multi-year projects.

1\. KISS, keep it simple, stupid.

Keep your code as simple and straight forward as possible. You can do that in a few ways: \- As others have said, focus on keeping dependencies to a minimum. This can include libraries but also other 3rd party vendors/external apis. \- try to keep feature creep out. the more complex the codebase the more likely it is to suffer failures. Keep things focused on solving specific problems.

2\. Build software that is meant to be delegated.

You can't remove all dependencies. Whether its libraries, external apis, or hosting, every piece of software needs something to run. If you don't want to be stuck as a lifetime maintainer, then you'll need to ensure your code can run without you. There are many ways to do this: \- use existing, well tasted, stable technology that is supported and maintained by your org, not something new and fancy for each project. \- enlist others to help early on, sys admins, hosting providers, or whomever. Build your software in a way that is supported by those providers.

</comment><comment><USER38> I run a few small apps that require zero maintenance, one being [https://upcoming.fm](https://upcoming.fm). All of them have a few things in common:

* Hosted on Heroku, which gets you continuous deployment and Let's Encrypt

* Completely automated, even the smallest manual task

* Low traffic, which may be the most important. Apps with large and growing user bases are very difficult to manage hands-off.

<comment><USER39> This looks like it is dependent on Spotify's API? So if Spotify changes said API it would need maintenance.

Anything that depends on other stuff really is susceptible to changes and needed maintenance.

</comment></comment><comment><USER40> 1\. Try to make the software tolerable to the wrong input.

2\. Develop tools which allows end-users to adjust the software, make as many settings as possible.

I don't think that those options are actually good in the end. If your software is tolerable to the wrong input, it might just work wrong and nobody will notice it. If there are too many options, nobody will know all of them and in the end they'll either ask you or configure it wrong. If you'll have too much of flexibility, then developers who will need to extend your software, will be forced to work bounded by inevitable restrictions.

I like software that's precise and does only one kind of thing. It crashes on wrong input, so I can either blame someone who's responsible for wrong input (I mean service, not ordinary user) or fix software. It must not be flexible, but it should have flexible architecture so I can just adjust or extend code to adapt it as necessary.

</comment><comment><USER41> Zero maintenance is not the same as becoming a lifetime maintainer.

You haven't provided enough context here, but since we even patch software on Mars I doubt you can built a bug free, feature complete software that will last "forever", so you'll need to find ways to delegate maintenance to someone else.

</comment><comment><USER42> By keeping it simple. Probably too simple -- If your app has any complexity, in the code, the infrastructure, or the features, it will need maintenance. If your app is literally just a static web page that does one thing, and never will need a new feature, then it can sit up on the web without maintenance.

But the odds of something that simple meeting your goals is unlikely.

</comment><comment><USER43> You keep the feature set of the application as small as possible.

And have no outside integration other than the most common of protocols.

</comment><comment><USER44> Any application with dependencies will require maintenance at some point. applications without dependencies don't exist. You may remove all your node modules. But you'll still depend things like a programming language, hardware, lightning strikes and solar storms not happening,...

</comment><comment><USER45> \- write code that you expect to fail, handle all errors you can anticipate and keep monitoring up for those that you can't resolve programmaticly \- use a managed hosting service for webapps like heroku \- aggressively reduce code complexity. single responsibility principle is key.

</comment><comment><USER46> You can program defensively, which is a learned skill, and your app might run for years without complaining. But some dependency might change something and a regular push bring everything crashing down until you fix it.

So program defensively and expect to have to do the occasional bit of maintenance.

</comment><comment><USER47> Maintenance means change. Any time something changes, you will need to update the application.

An application with zero maintenance means that it either has a very, very targeted function that doesn't change, or it isn't being used after a certain period of time.

</comment><comment><USER48> Handle every error possible in every code path and don't make new features at all.

</comment><comment><USER49> I think your code and documentation should empower others to become experts in your place - write simple code, be very consistent, use minimal dependencies, test it thoroughly.

</comment><comment><USER50> Why would you want to? The maintenance phase is the point where most projects finally get into the black after being a net loss for several years.

</comment><comment><USER51> Half way joking, but write them in a stable stack, perl or COBOL? Maybe common LISP? Seems better than some stack that is in constant flux.

</comment><comment><USER52> Yeah, you can build apps with zero maintenance but you have to pay a couple of bucks per month for microservices.

</comment><comment><USER53> Build a game. If you build a good audience, you can automate almost all the work.

</comment><comment><USER54> \- Have all binary dependencies part of the repo

\- Never upgrade

\- Cloudflare for SSL

</comment><comment><USER55> have a business model that never changes. use the ecosystem that you are most familiar with and have fewer surprises.

</comment><comment><USER56> Build it in Lisp and name it Hacker News.

</comment><comment><USER57> Easy, build applications with zero users

</comment><comment><USER58> For me, most important, no dependencies.

</comment><comment><USER59> Don't write the application.

</comment><comment><USER60> Desktop, web or mobile? My guess is that you'll get very different results based on this.

Overall stick with technologies that have been around for a long time and have proven themselves to be stable and their developers do value stability. Sadly most developers prefer to run fast and break things, regardless of tech, so your options will be limited. Also avoid anything latest, greatest, shiny and new - even if their developers promise stability, at least for the initial versions until the tech matures a bit.

If you see anything that uses semver run away. Semver might sound like a good idea on the surface in that any breaking change means increasing a major version. But the flip side of that coin is that by choosing semver the developers communicate that they _do_ plan on breaking backwards compatibility at some point. Despite the excuses a lot of semver enthusiasts will tell you, there are very very VERY few reasons to break backwards compatibility and the vast vast majority of them are imposed from outside (e.g. the sort where your OS drops 32bit support and there isn't anything you can do about it or the architecture you were relying on isn't supported by anyone anymore).

On the desktop stick with languages that either have multiple independent implementations (independent not only in terms of who developers it, but also in terms of codebase) based on a standard, like C and C++. This way you can switch between implementations in case something goes bad. Also do not use the latest versions of the standard unless every implementation (and by "every" i mean "really, truly, every" not just the popular ones) implements it with more or less the same features (stick with the least implemented ones). This gives you a greater set of choices to switch when you decide to switch.

For desktop UI on Windows use the Win32 API or roll your own. If you plan on being cross platform, roll your own anyway since the only thing you can rely on (at least for the foreseeable future) on Linux is X11 - anything else is bound to break and/or not exist in your users' computers. Note that if you also plan on supporting macOS rolling your own may not be liked over there and you should seriously consider if it is worth the hassle since as Apple has proven many times they do not care about backwards compatibility so you'll need to maintain your app regardless (though you can try and minimize that to just a recompile).

For web i do not know much, but i'd stick with stuff that do not break. PHP and Java _seem_ stable. Client-side things tend to be very stable though Google does give me the impression that they'd like to flex their muscle to drop some stuff they consider "bad".

For mobile abandon all hope, it is the most ephemeral platform.

Beyond that, make either very small programs that you can easily modify or make modular programs that you can swap out things without much hassle.

Personally i work with desktop. For my own stuff i stick with C89 and Free Pascal. The former doesn't change, the latter does change but very very infrequently and it is all statically compiled anyway so assuming the underlying stuff do not change they'll work. Lazarus on Linux will eventually be an issue because Gtk2, but there isn't much that can be done about that (the author of FPGUI - that only relies on X11 - says that it can be used with the LCL FPGUI backend, but personally i haven't tried it and i think the backend isn't very mature). Win32 stuff is practically eternal (and funnily enough on Linux Win32 via Wine is the stablest ABI - essentially making x86+Win32+C89 the most stable combo even if Microsoft drops it :-P).</comment>


From College Dropout to Senior Engineer in One Year - <AUTHOR> https://medium.com/@dylanerichards/from-college-dropout-to-senior-engineer-in-one-year-how-to-leverage-self-worth-to-create-727d2b884598#.kghnkiprs <comment><USER2> I wrote a giant explanation about this and then deleted it out of frustration.

Basically, I believe that Senior Engineer is much more than what this article claims. These points are all about mental strategies and confidence, but these have nothing to do with actual technical skill, or plain old _experience_.</comment>


Android Tutorial Blog - <AUTHOR> http://androidcompetencycenter.com

<comment><USER2> Looks like it's abandoned (last post was in October of '09).

<comment><AUTHOR> Its not exactly abandoned. We will soon start posting new content there. Been completely flat out with projects for last 6 months and were short on time.</comment></comment>


Trees That Survived California Drought May Hold Clue to Climate Resilience - <AUTHOR> https://www.npr.org/2019/10/16/766200948/trees-that-survived-california-drought-may-hold-clue-to-climate-resilience <comment><USER2> Neat. I wonder what they are doing to survey for remnant populations and how they control for local conditions.

Total aside, but I'm working on a project doing disease mapping for an agency in California. Its like watching a train wreck in real time. Human influence and climate change* are rewriting the macroflora of California in real time. Get your pictures now boys and girls because your state _will not be the same_ in 10 years.

Whew. California is pretty much toast.

<comment><USER3> Genuinely curious, in what ways will it not be the same?

<comment><USER2> The biggest contributing factor (imo) is disease. I think the general public lack an understanding for the subtleties of _how_ and _why_ climate change, even a touch of it, is such a big deal for plant communities. Couple this with anthropocentric influence and you've got a bit of a dogs breakfast.

I'm not a beetle expert by any stretch of the imagination, but I'm going to use the case of the golden spotted oak borer to demonstrate why these factors combine to become far more impactful than either would be singularly. The golden spotted oak borer (GSOB) is a oak specific beetle disease that is native to north america (northern extent of its native range is apparently Arizona, majority in n. Mexico). In its native range, nights are very cold, summers are very hot. This results in enough generational dieback that it does not become a devastating disease.

Some time in the early 2000's it was introduced to eastern San Diego county. The generally accepted assumption here is that it was moved on firewood from Arizona. The mountains in San Diego have seen a massive decrease in the overall coldness of winters, and amount of winter snow. Likewise, oak is a very popular wood for home heating, and in eastern San Diego county, many people rely on burning wood for winter heating.

So lets spell this out: more mild winters: less generational dieback of the disease; more disease: more dead trees; more dead trees: more 'free fire wood'; more free firewood: more people moving around the disease.

The winters aren't cool enough (any longer; this could be argued about) in San Diego county to knock back the disease. People grab up firewood and move it around. The result is that the GSOB disease state has been moving like wild fire throughout the state. Some early estimates of habitat suitability indicate that its northern extent is likely some where north of Humboldt county/ south of Oregon.

Now, couple this with sudden oak death (moving south to north), fusarium dieback (north to south), and you've got a relative shitnado coming at the California oak woodlands. What happens when GSOB gets into some sudden oak death infected trees? Or if it becomes a vector for fusarium dieback? Humans have moved this disease into places that don't get cold enough or hot enough to kill it. Likewise, in areas where it _may_ have gotten cold enough to knock back the disease, it just doesn't get as cold any more (a few degrees colder, a couple times during the winter would do the trick).

<comment><USER4> Do you have a link to the project?

<comment><USER2> [https://ucanr.edu/sites/gsobinfo/](https://ucanr.edu/sites/gsobinfo/)

The above is a good resource for information regarding the disease. The work I'm doing is related to this, and we aren't making any of our results public at the moment.

<comment><USER4> thank you

</comment></comment></comment></comment></comment></comment><comment><USER5> Get Ginkgo Bioworks on the case! They've been curious about tree cloning...this is the chance.

[https://www.ginkgobioworks.com/2010/04/13/ginkgo-tree- falls-...](https://www.ginkgobioworks.com/2010/04/13/ginkgo-tree-falls-in- japan/)

</comment><comment><USER6> "Inside a greenhouse at her Tahoe City field station, Maloney shows off a sea of young green trees in their own containers. These 10,000 sugar pine seedlings grew from seeds Maloney and her team collected from 100 of the surviving sugar pines."

This is interesting; seems like artificial and natural selection combined. It does _seem_ to solve the current problem, but what would be the implications? Aren't the dying trees beneficial to the ecosystem in some way (clearly they are food for the pine beetles, which are food for other animals...)?

<comment><USER7> A typical problem with invasive species is that their predators don't also make the trip. It's not a given that anything is eating them, micro or macro.

Dead wood left on the forest floor can help improve soil quality and water retention though, and the decay microbes and invertebrates do have their own food chain that goes as high as foxes and bears. It's an old idea we haven't practiced much, in part because of misguided fire suppression, and miscategorizing it as waste, instead of fodder.

<comment><USER8> The blocker being the contingent that considers the forests as nothing more than a potential strip-mine, being that said contingent has the reins currently.

</comment></comment></comment><comment><USER9> Archived copy without GDPR nag screen:

[https://web.archive.org/web/20191017140046/https://www.npr.o...](https://web.archive.org/web/20191017140046/https://www.npr.org/2019/10/16/766200948/trees- that-survived-california-drought-may-hold-clue-to-climate-resilience)</comment>


U.S. to China: We Hacked Your Internet Gear We Told You Not to Hack - <AUTHOR> http://www.wired.com/wiredenterprise/2013/12/nsa-cisco-huawei-china/ <comment><USER2>
      In the U.S., military espionage is heroic and economic espionage is a crime. In China, the line is not that clear.

Let me say this: BULLSHIT, a thousand times.

Who says this? Any of the companies who have been lying to their customers? Any of the government agencies which have not explained anything about the NSA activities (not that they would know what is going on)? Any of the officials caught lying, one and again?

The US will not perform economic espionage as long as the US has a technological edge (which is probably not anymore the case in lots of areas).

Which brings us to an important observation: OCDE rules forbidding economic espionage are designed to keep the current technological status quo; any country is well advised to sign them to be accepted to the club, and immediately throw the rules to the garbage bin. Because we can be sure that any country capable of doing economic espionage has been doing it, is doing it, and will continue to do it, no matter the rules, no matter if they get caught, no matter the hypocrital public posturing of their leaders.

Those rules, and the whole "Intellectual Property" apparatus, is there for the suckers to respect them. The US, in particular, has never respected those rules.

<comment><USER3> One of my coworkers actually expressed this sentiment to me. He's generally a smart guy but I don't know how you get across how damaging this is to basic commerce.

The NSA is destroying the American technical industry piece by piece. How do we approach this existential crisis, when the folks behind the NSA apparently don't give a shit what damage they do to America?

<comment><USER4> The money is what matters politically. Interestingly in this case, while that's one of the most sickening aspects of US politics these days (the extreme dominance of money), it's also the one we can count on here. Enough damage - which seems to be a matter of time now - and a lot more companies will stand up and 'force' their politicians to dismantle the NSA's programs.

Either that or the military industrial complex has reached a point of scale where it's basically going to end up destroying itself by bleeding out the economy and the tax dollars required to fund such a massive beast.

I'd argue that there's no scenario in which the military industrial complex survives intact going forward, short of WW3. That's particularly fitting timing wise, as America has reached all sorts of crossroads in its path forward (huge generation changing issues on debt, education, standards of living, war, jobs).

edit:

Another thought - it's also going to self-cripple the military by eroding the US technology sector (capital seeds tech companies in other countries instead of the US as a response, so more technology is created outside the US in the future, in a downward spiral, potentially depriving the NSA and military of all sorts of technology and access). The relative US technology lead has been a massive competitive advantage for the military for a century.

<comment><USER2> Isightful. And the follow-up question is: since the military industrial complex has probably already reached this conclussion, will they force war? I mean, in a more direct way than what we are used to ...

In this light, trusting the USA to responsably handle the nuclear arsenal may prove to be the biggest mistake that the international community has done since WWII.

<comment><USER4> The nuclear arsenal is for Russia and China and self-defense, it's useless in WW3 unless mutual assured end-of-civilization is desired (or as a one-off response to someone like Iran or Pakistan using a nuke or a small number of them). That arsenal is no more risky in the US hands than in, say, the hands of Russia or China or Britain or France.

The military industrial complex wants money and power, not global annihilation - always remember it's run by people, and they want what most people in power want. It's not a complicated beast, it's mostly about the world's largest slush fund, $700 some odd billion up for grabs every year, and they want all of it and more if they can get it. The military people want to play military, and the industrial people want to play industry, and they leverage each other to that end.

Yes, I think they'll force more wars. Something that big and powerful, in a state of desperation for survival, is scary indeed. I think that's what the play in the 'sandbox' (the middle east, aka where you can launch wars and suffer no domestic enemy retaliation and you can't hardly 'lose' in a classic historical sense) has been largely about, excuses to spend large amounts of money and build & experiment with shiny new war machines. If it had been about economics, oil for example, we'd already control most of the oil in the middle east (we'd have taken Saudi Arabia and Iraq's oil through force). I think that explains Wesley Clark's shocking admission about the Pentagon planning all the wars far in advance:

[http://www.youtube.com/watch?v=bSL3JqorkdU](http://www.youtube.com/watch?v=bSL3JqorkdU)

</comment></comment></comment></comment></comment><comment><USER5> Is it just me or does this seem to be a tortured argument - the US suggested that huawei might be implementing backdoors in their product out of the box, is not the same thing as the US security agency actively searching for exploits for the product. One is a collaborative effort to sell someone a defective product (could be fraud) the other is a adversarial effort that is a natural part of the security industry cycle.

<comment><USER2> Are you aware that the NSA is actively planting exploits into products by intercepting shipments? Your are not buying a Cisco product: you are buying a Cisco + NSA product, with a backdoor. Which is exactly the same as buying a Huawei product with a backdoor.

<comment><USER6> Did you even read his comment? Of course he's aware - it's forms the premise of his entire position.

<comment><USER2> The NSA is _planting_ exploits. It is not only exploiting existing security holes: it is creating new security holes, by manipulating the hardware. Is is effectively working together with Cisco / any other company (maybe not willingly, but who cares) to manufacture a Cisco/NSA router, with a backdoor easily accessible to the NSA.

According to his comment he is not aware of this, otherwise he would not differentiate between Cisco/NSA and Huawei.

And according to your comment, you do not even understand what I am saying.

<comment><USER6> The concern with Huawei is that a security apparatus would be inserting backdoors/Trojans into _every_ device. The NASA's targeted attacks of a few hundred (thousand?) devices is entirely unrelated.

<comment><USER2> Previously the story was "the chinese are inserting backdoors". Afterwards the story was, the NSA is spying everyone. Now the story seems to be that the NSA is spying _and_ planting some backdoors. How many? 1% of devices? 10%? 99%?

Let me clarify two things for you:

\- We do not know how many backdoors the chinese are planting. Maybe none, maybe in all devices.

\- We do not know how many backdoors the NSA is planting. Maybe just in some devices, maybe in most devices.

In light of this, how are you so sure that "these two situations aren't even in the same universe." Do you have any other knowledge that you would like to share?

<comment><USER6> Because one involves all manufacturers, regardless of origin. The other doesn't.

One involves devices destined for certain people, the other doesn't.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> You can download the documents from CryptoMe:

ANT Files (16.2M ZIP) : [http://cryptome.org/2013/12/nsa- catalog.zip](http://cryptome.org/2013/12/nsa-catalog.zip)

QUANTUM Tasking (5.7M) - [http://cryptome.org/2013/12/nsa-quantum- tasking.pdf](http://cryptome.org/2013/12/nsa-quantum-tasking.pdf)

QUANTUM Theory (2.5M) - [http://cryptome.org/2013/12/nsa- quantumtheory.pdf](http://cryptome.org/2013/12/nsa-quantumtheory.pdf)

<comment><USER8> CrypTome, Mr President.

</comment></comment><comment><USER9> It's important to note that during the USG vs Huawei discussions there were no actual proofs brought by the USG about the allegations it pressed on Huawei. Huawei even wrote an open letter just two years ago asking for investigation and denying all the allegations [http://www.huawei.com/ilink/en/about- huawei/newsroom/press-r...](http://www.huawei.com/ilink/en/about- huawei/newsroom/press-release/HW_092875)

Later on Huawei testified before the US House [http://www.youtube.com/watch?v=ApQjSCUpt4s](http://www.youtube.com/watch?v=ApQjSCUpt4s)

To my knowledge, no response has been made by USG justifying the allegations it was making when it was openly called by Huawei. Given all of this, I find it ironic the comments here such as "backdoors in Huawei's devices" are taken for granted. Now with the latest leaks exposing hacking by the USG itself the tone of the conversation (including the comments in HN) has not changed. What am I missing?

The only noticeable change seems was the decreased tone of the US media (CNN alikes) who used to shout extremely loud that _' Those Chinese are hacking our systems!'_. At the very least frequency of such news got decreased ever since the leaks.

</comment><comment><USER10> hey,guys. i am from china. I just wanna say, happy new year. and internet has not border.

<comment><USER11> Yes. Our governments may act like asses, but we don't have to. Happy New Year.

<comment><USER12> Same to you. Happy new year.

<comment><USER13> Peace! :)

</comment></comment></comment></comment><comment><USER14> Why do you think the US was so concerned about buying gear from China? They just realized that since they're doing it, China is probably doing it as well.

<comment><USER15> The liar's punishment is they can trust no one

<comment><USER11> The problem with liars is not that they lie, it's that sometimes they tell the truth.

</comment></comment></comment><comment><USER16> I guess at this point, its fair to ask all those previous commenters who were telling us: "It just doesn't work like that.. We were in the dept of defense.. you guys don't understand" to comment..

</comment><comment><USER17> Time seems ripe for open source networking equipment movement. Can't trust closed source solutions.

<comment><USER18> That's a nice but naive sentiment. You can rest assured your hardware is similarly trojaned - whether it is your CPU, your Ethernet controller or your network switch. No, I do not have first hand knowledge about CPU trojaning by the NSA. But given everything else, I'd be surprised if they don't have access to the CPU itself.

<comment><USER19> What would the point be of intercepting shipments if the job is already done? Are you saying they are doing this work redundantly?

Also we don't know what percentage of shipments are intercepted. If this is the primary means of attack it seems a bit shy of "you can rest assured" that _your_ hardware in particular is affected. (Or at this rate perhaps we can wait for the next revelation to show us. :P)

<comment><USER18> > What would the point be of intercepting shipments if the job is already > done? Are you saying they are doing this work redundantly?

Have you ever seen a government job that wasn't redundant?

But seriously - if you want to make sure that what you are doing works, you have to use redundancies. Many of them, in fact.

> If this is the primary means of attack it seems a bit shy of "you can rest > assured" that your hardware in particular is affected. (Or at this rate > perhaps we can wait for the next revelation to show us.

I'm sure it is not the primary means of attack. Here's a hypothetical scenario: You work at Cisco or Intel, designing firmware / microcode. The NSA appears at your door with an NSL saying you can't disclose anything, not even to your boss - and a carrot: Get $200K to insert this backdoor into the new x86 / megarouter. And also a stick - if you don't comply, showing your wife all of the correspondence you have with your mistress (which they gleaned from earlier interception) or giving the DEA a recording of you asking your friend to bring some pot over.

You think that's crazy? Ladar Levison, Joseph Nacchio and Edward Snowden indicate that's business as usual. I have no knowledge of anything other than what I read in the guardian/hn etc -- but given all that is public, I'd be surprised if this scenario hasn't played out a few times. Or a few hundred times.

</comment></comment></comment></comment><comment><USER20> The consistently frustrating thing about all these 'revelations' is that the US government allegedly do it only for national security concerns where as other nations does it for corporate espionage.

<comment><USER21> US spied French aerospace industry in 90's and there is no indication that they won't do it every time they feel US might get advantage from it.

</comment></comment><comment><USER22> Continuously stock piling exploits cannot lead to any desired end game. It's probably beneficial there's some deflating of all this stuff.

</comment><comment><USER23> It's a good way to think about it, that the US is now in a Cold War with the entire rest of the world.

<comment><USER11> Not quite.

[http://cphpost.dk/news/denmark-is-one-of-the- nsas-9-eyes.761...](http://cphpost.dk/news/denmark-is-one-of-the- nsas-9-eyes.7611.html)

<comment><USER24> Governments are "now in a Cold War with the [citizens of the] entire rest of the world."

Better?

</comment></comment></comment><comment><USER25> Messing with the manufacturing base for maybe 80% of all USA non-food goods is probably a very bad idea.

Sure we can open source our router software for review but what if their hacks are right in the chips being made in China.

Don't US fighter jets and bombers use some electronics made in China too?</comment>