Ask HN: I've been a programmer for 6 years, and I can't solve basic CS problems - <AUTHOR> Hi HN.
My fianceè is currently enrolled on CS50 Introduction to Computer Science online.
I'm a programmer and have been for around 5-6 years, I started with VB.NET since I first started learning, then progressed onto Web Development at a large agency for 4 years (PHP, JS, React) and I'm now back with VB.NET.
I've worked with a few "complicated" (they were to me) projects in the past, but now I'm being tasked with guiding my fianceè with this course.
Some of the problems which she is expected to solve are pretty simple problems, but I just can't seem to get the hang of any of them on my own.
I would have thought that my last 5-6 years of experience would at least help me here. I can point out basic syntax errors and help with debugging, but when it comes to me trying to solve these problems on my own, I don't know where to start.
It makes me question how I was hired in the first place.
Sorry for the rant, but I was just wondering if anyone else felt like this. <comment><USER3> Think of it this way: application development, software engineering, and computer science (and data science and ... etc) sometimes use the same tools but are all different disciplines.

Universities traditionally focused on Computer Science and their graduates would often need a lot of grooming before they could really be independently and reliably productive in the commercial words of application development or software engineering. Importantly, it was less grooming than someone who studied something like English or Sociology or History, but it was still a different discipline than what the job market demanded.

You jumped into the job market directly. You learned to develop applications, research API's, study trends, and participate as a team member in development workflows under commercial pressure. You don't know how to compose and compare sort functions for abstract sets of N elements because you never needed to. You just use sort().

And that's okay! Inventing new algorithms with theoretical significance is not your job! You have other skills and they're of much more immediate value!

<comment><USER4> What's the difference between application development and software engineering?

<comment><USER5> You can apply software engineering to develop an application, but you can also do application development without any proper software engineering.

Software Engineering is a design discipline, management discipline, and engineering discipline. Application development is (principally) the act of building an application by writing code. It doesn't _require_ design, management, or engineering discipline to accomplish. But it's better if you've done those things (minimally, the engineering and design portions).

At the same time, a junior software engineer may not be responsible for anything _but_ the writing of code, where others have determined the design and engineering aspects and are conducting project management for them. Or with only limited responsibility (such as developing tests for the aspects they're responsible for developing, which is a part of the engineering discipline: V&V).

</comment></comment></comment><comment><USER6> Honestly, I'm appalled by some of the stories being shared in this thread; smug interview panels pressure-cooking candidates as they try to whiteboard obscure CS gotchas is a system perfect only for assholes and masochists.

I've now run three tech companies and hired dozens of developers by having really intense, thoughtful conversations with them. I asked them to tell me war stories and encouraged them to share insights on how they solve problems.

I only rarely look at code, because it's self-evident when you're talking to someone that is passionate about programming + intellectually curious-to- hungry + an interesting person who demonstrates empathy and seems like someone you'd want to spend 7-9 hours a day with.

I hire like I'm trying to form a rock band: I don't tell them what to play, I give them permission to show me what they've got.

Here's the thing: the more we, as a class of developers, put up with these devolving interview processes, convince ourselves that this is somehow our failing and our inability to FizzBuzz in six languages with a sharpie and people watching... the more we allow it to be considered okay, and the more normal it will be to expect this nonsense.

I know that being cash-starved sucks, but you know what? If you walk into an interview and they bust out the markers and ask you to start sorting, I sincerely hope that we can collectively find the strength to laugh at them and politely tell them that you'd never waste your time at a company that insults your craft.

Find your pride and tell them why they missed out. If they want to understand what just happened, tell them to take you for a drink. If they are dicks about it, you really didn't miss out on a damn thing. I promise you that.

<comment><USER7> From my perspective on interviewing and talking to lots of dev's, I take at least some of the horror stories with a grain of salt. I've seen some "pressure cooker" scenarios really just be interviewers who were not very good at interviewing. Conversely, I've gone deep in conversations with a developer on how BS interview questions are, and while imaging some crazy graph algorithm or something they come out with "Yeah they tried to get me to implement a Set" (at a high level, in Javascript). That's not a challenging or obscure problem, this person simply lacked technical depth and was jumping on the bandwagon.

Which is all to say, I can agree in general with obtuse CS problems being a bad proxy. But I think asking someone you are hiring to write code all day to write code as part of the interview is reasonable, and at this point I'd be suspect if I were interviewing somewhere and they _didn't_ ask me to write at least _something_.

<comment><USER8> What's the point of reimplementing a set though? It already comes with the language, and the language's implementation is probably miles better than what you'd come up with anyway.

I'd be more interested to know whether the candidate knows what a set is, and how it differs from an array or an object, and when might it come handy. But reimplementing what already comes with the language? A waste of time, and (hopefully) not representative of the work they'll be doing day to day.

</comment></comment></comment><comment><AUTHOR> Thank you to everyone who has replied to my rant.

I felt of low value for not being able to provide immediate help for most of the problems that she's being taught to work on.

Some of the examples (since some of you were asking for them): [https://github.com/cs50/docs/blob/master/_pages/2018/x/psets...](https://github.com/cs50/docs/blob/master/_pages/2018/x/psets/2/caesar/caesar.adoc)

[https://github.com/cs50/docs/blob/master/_pages/2018/x/psets...](https://github.com/cs50/docs/blob/master/_pages/2018/x/psets/1/credit/credit.adoc)

I realise that I may have written my original post a little hastily as I was feeling quite strong about having inadequate knowledge to solve these problems.

You've all been super nice to me, and I can understand where you are all coming from.

Again, thank you.

As an aside, the problem that I was stuck on earlier, I managed to solve through a bunch of trial and error, so I'm chalking that one up as a win for tonight.

<comment><USER9> What exactly did you have trouble with? These really are simple problems, all you need are an understanding of loops, ASCII character codes, and basic arithmetic.

To be honest, I'm surprised a seasoned developer of 5+ years can't do these, or at least have a decent stab at them.

<comment><USER10> Why would you expect the modern application developer to even know what ASCII is?

There is a chance I wouldn't know what ASCII encoding was if my exposure to programming didn't start in the 8 bit era. C is foreign to a lot of self taught programmers.

<comment><USER11> In this modern time, no one needs to know what the ASCII code for @ is, but I think it is logical to expect people to know that some encoding exists and that letters can be mapped to numbers.

Also, all the ASCII you need to know to solve the problem is explained at length in the problem description.

<comment><USER12> I couldn't tell you offhand how to convert between an int and an ASCII character.

...But if you give me a second...

Now that I've typed "ascii character codes" into google, I can tell you how to convert between an int and a character.

You don't have to memorize everything. Well over half of our job is knowing how to find information quickly.

</comment></comment></comment></comment></comment><comment><USER13> Programming isn't the same thing as computer science, in the same way that writing isn't the same thing as journalism.

Writing code is the easy part. It's tedious, requires lots of practical knowledge and troubleshooting skills, but is for the most part a straightforward exercise. Computer science is about the theory. It involves solving problems in the abstract, using (and in some cases creating) new conceptual tools with which to think about, model, and solve a problem.

Many jobs in the software industry require only programming skills, and with those you can get along decently at any one of thousands of companies which are basically just building the same kinds of applications over and over again. But doing anything _truly_ interesting requires venturing into the world of computer science, which requires years of study to master.

<comment><USER14> That's a good point. Now, how do you find interesting job which involves computer science skills?

<comment><USER15> I work in CAD and my experience is similar to the guy who works in the games industry. I invent new algorithms pretty much all the time. It's a more conservative environment culture-wise. "Science programming" (when all your clients have PhDs and work in academia and you do models of something or other or interpretation of experimental results) is also very intellectually challenging and the CS skills are a HUGE differentiator. It's not for everybody though as in those jobs you rarely work with other programmers or have good code to learn from.

</comment></comment></comment><comment><USER16> Okay, I'll give you the "triage" presentation. It's a combination of "where to start" and "what I've actually used in industry."

1) Algorithmic complexity: Study why naively adding to the end of an array or the end of a string results in O(n^2), while doubling the size when you increase the storage results in O(n). That one tidbit has comprised some embarrassingly large fraction of the "consulting" I used to do working for a language/VM vendor.

2) Graph theory. Study BFS and DFS and implement them a few times to do things like solving a maze. Get comfortable with those until you can "run" them in your head when looking at a problem specified on paper containing a graph, and you can see uses/consequences. This will both keep you out of trouble and can be a starting point for further study.

3) Concurrency. Learn about race conditions and deadlock. Figure out some tools and patterns for dealing with them. Use them to write a chat server and figure out how to automatically QA it until you can break it.

4) Transactions. ACID. Read up on why you have ACID transations, and what can go wrong.

That right there is good for some huge percentage of what could really get you into deep trouble.

<comment><USER17> Could you explain why adding to the end of an array results in O(n^2)? From what I can find, it appears to be O(1). If you increase the size of the array by 1 each time and copy the old array elements over, wouldn't that be O(n) to copy the array plus the additional add, O(n+1) which is just O(n)?

<comment><USER16> _Could you explain why adding to the end of an array results in O(n^2)?_

If an operation does that n times, then it's O(n^2). It's very common for self taught programmers to write operations that do the naive addition many times. There have been entire consulting trips caused by basically that, including, so I heard, the one that brought a consultant into the Chrysler C3 project and sparked the invention of Extreme Programming.

</comment></comment></comment><comment><USER18> I do have a CS degree, but I manage a software development team that is mostly composed of people with non-CS backgrounds. Having done this, I can assure you that you don't need to be able to solve toy CS problems to produce sophisticated, useful applications.

That's not to say a CS degree isn't useful- My observation is that a good foundation in computer science (algorithms, data structures, type theory, programming language, and systems) does help improve code quality and tends to be insurance against "hitting a wall" when problem solving, but my team members without CS degrees generally just as productive in delivering value. Its all learnable outside a university as well- one of the guys on my team with a liberal arts degree has picked up so much theory of the years I'd call him the "most CSey" of all our people.

The repeating problems I have with my team members lacking a CS degree general are misuse of type systems (IE- never creating interfaces, not inheriting, copy and paste reuse, etc...) , not doing functional programming right (or at all) in Type/JavaScript (this really stinks when Promises are involved), and a lack of awareness about performance consideration (hey! I think I found the problem! There is 9 levels of loop nesting, and each call inside the loop does a web request). These are areas my CS education really helped with, even if I didn't know it at the time.

On the flipside, the "CSey" crowd on my team (including some self taught people) sometimes lose productive chasing non-issues that don't conform to some platonic ideal we were taught (yes I know the array only ever has 3 elements in it, but I got the operation to run in O(n) time!).

In short, I'd encourage you to try to learn these toy problems and the concepts behind them as they do have value, but hardly a core requirement to deliver value creating software in most circumstances.

</comment><comment><USER19> Programming has become so generic activity that the word "programmer" tells very little of what people are doing and what their skills are.

From the description of what you have done, you are working in "software assembly" type programming job. You clue things together and get the job done. You know the API's and some standards. Most of the programmer jobs are what you are doing. It's very different from the classical algorithmic programming type jobs and programming.

People who build machines have wide variety of job descriptions: mechanic, welder, machinist, mechanical engineer, and so on. But somehow it's assumed that if you can do "web development", you can do do it all.

</comment><comment><USER20> There's a common belief that you can learn everything you need to program through practice. And that is true in the sense that you can eventually learn how to write working programs. But understanding the theory behind programming and algorithm design is a very different thing.

As a concrete example, while in high school I participated in programming competitions. One of the questions required writing a parser for a context- free grammar. Being completely unaware of recursive descent parsers I managed to fudge together an awful program with probably disgusting algorithmic complexity. After taking an "intro to CS" course (as an extra curricular activity), I immediately knew how to write basic parsers for CFGs correctly. It's not that I was suddenly much better at programming, it's that I now had learnt some theory that helped me know how to approach a problem.

You can't really "pick up" algorithms. You have to learn it through some kind of study (self-study is also acceptable). There are thousands of man-years that have been spent on algorithms. It's probably not a good idea to start out from scratch. In this respect, I would argue that programming is far closer to mathematics than engineering.

</comment><comment><USER21> "The first lesson is that computational complexity theory is really, really, really not about computers. Computers play the same role in complexity that clocks, trains, and elevators play in relativity. They're a great way to illustrate the point, they were probably essential for discovering the point, but they're not the point.

The best definition of complexity theory I can think of is that it's quantitative theology: the mathematical study of hypothetical superintelligent beings such as gods. Its concerns include:

If a God or gods existed, how could they reveal themselves to mortals? (IP=PSPACE, or MIP=NEXP in the polytheistic case.)

Which gods are mightier than which other gods? (PNP vs. PP, SZK vs. QMA, BQPNP vs. NPBQP, etc. etc.)

Could a munificent God choose to bestow His omniscience on a mortal? (EXP vs. P/poly.)

Can oracles be trusted? (Can oracles be trusted?)

And of course:

Could mortals ever become godlike themselves? (P vs. NP, BQP vs. NP.)"

[https://www.scottaaronson.com/blog/?p=56](https://www.scottaaronson.com/blog/?p=56)

<comment><USER22> I thought complexity theory was based on the fairly intuitive Turing machine model (of computation) and not religious concerns

<comment> Ono-Sendai Scott Aaronson gets a bit carried away sometimes :)

<comment><USER21> Doesn't he have a license to get carried away?

<comment> Ono-Sendai I'm not sure, would have to check with the home office.

</comment></comment></comment></comment></comment><comment><USER23> Computer science is not the same as professional software development, even though it makes for a good educational foundation. Often even those of us who studied computer science are separated from it by enough years or abstractions such that we have to take a step back and think about fundamental problems when they are presented. So don't feel bad, unless you believe this actually indicates an area for professional growth.

Said another way - I haven't needed to write <sort> in twenty years, so if I had to, it would take me just as long as it takes you.

</comment><comment><USER24> I heard somewhere that a computer science degree is actually a history degree in how we have solved problems in the past. Programming is a creative problem solving process, but certain problems took decades to solve and it's only by knowing the history that people are able to resolve some of these hard problems. Don't beat yourself up for not knowing all of history and give yourself a break for not being able to immediately solve problems that took dedicated researchers their whole careers in the early days of computing.

<comment><USER25> Knowing things like binary trees, heaps, B-trees, queues etc. are not history. They are fundamental to writing applications. Using one data structure or a particular sort method will make your application much faster. Supposed you have had a billion elements to sort, but you knew every element in that array is between 1-100. I mean a bucket sort would be much much faster than using a quick sort.

<comment><USER26> > They are fundamental to writing applications.

That's funny, I must not have written any applications in the past 14 years. (Seriously though, I read one algorithms book when I was 16, and used those algorithms approximately... five times... in the past decade and a half)

<comment><USER27> Serious question: How do you know that in the applications that you have written in the past 14 years, there aren't any spots that could be considerably improved in runtime behavior and cost?

I remember being a programmer before studying formal computer science, I definitely wrote some slow and bad code that I just didn't know could be much better, and/or simpler.

<comment><USER18> This remains a serious problem on my team- Over half my team members don't have CS degrees. They get an enormous amount done, but there is often a perf or maintainability cost.

I have no intention of swapping them out because they ultimately provide enormous value, but it's noticeable.

<comment><USER26> Is it the algorithmic efficiency that's the problem, or the ability to scale the application?

I've seen things some people wouldn't believe. mod_perl 1.4 on Apache 2.0 handling 350,000 hps dynamic traffic on twenty archaic 1U's. Five tiers of caching, serialized objects on local disks, NFS in production. C-beams glittering in the dark near the Tannhäuser gate. Who cares about inefficiency if it scales?

<comment><USER27> Putting aside the damage that issues with correctness can cause, the problem is exactly that if you e.g. wrote something that grows with n^2 instead of n log n, you cannot scale by "brute force" anymore, as the inefficiency very quickly outgrows the amount of resources you can add. Seriously, your thinking that "algorithmic inefficiency" can be countered by "scaling" is almost proving the point.

CS is by far not just about runtime complexity, but it's one thing that can bite you.

Also, all the components you mentioned were likely written, at least in significant parts, by people knowledgeable about computer science.

<comment><USER26> Scaling an application's operation does not directly relate to its algorithm's efficiency, is my point. Of course a really inefficient application can eventually become unusable, but even terribly performing applications can be "worked around" and thus scaled higher.

Say your app is using bubble sort. Egads!!! What a shit design. Clearly this is going to become a nightmare in real world scenarios. But wait - we can theoretically get to O(n) if the list is already nearly sorted. How can we achieve this? By monkeying with the dataset, queueing and batching operations, invalidating operations that take too long, artificially limiting the number of requests per second, or just passing the request to a completely different app depending on use case. It sounds insane, but if you can perform any of these things quicker than redesigning your app, so that it can continue performing under load, that's an example of "scaling" despite the application's poor performance.

Another example is the "scalability" of application development. Say you have an application which is basically O(1), but one day you find a bug in it. Even after you write and commit the one-line fix for the bug, if it takes you between four hours and two days to deploy it to production, or the validation process takes a month... You still have a bug in production for hours, days, or weeks. "Scaling" the development process can significantly reduce the amount of time needed to solve problems, or complete new features. It can be more beneficial to be able to ship code faster and more reliably, even if it isn't the most efficient code.

<comment><USER27> _but even terribly performing applications can be "worked around" and thus scaled higher. [...] How can we achieve this? By monkeying with the dataset, queueing and batching operations, invalidating operations that take too long, artificially limiting the number of requests per second, or just passing the request to a completely different app depending on use case._

And that's a good thing? Part of my point is that this can be avoided, or at least have a higher probability of being unnecessary, if the proper basics were learned.

Wouldn't you wish the author would have just known how to properly sort a list[1] in the first place?

 _" Scaling" the development process can significantly reduce the amount of time needed to solve problems, or complete new features. It can be more beneficial to be able to ship code faster and more reliably, even if it isn't the most efficient code_

Agreed to that, but as said, computer science is not just about runtime complexity. Knowing computer science might help you avoid those situations, or resolving them quicker.

I know that shitty stuff can work, even work "well enough", but going back to my original comment: Maybe it could work _much_ better, simpler, more profitable if that's your favorite metric, with just the application of some basics, if they are known.

[1] Noting that "sorting a list" is a stand-in for all sorts of tasks that benefit from CS-knowledge.

<comment><USER26> Yes, absolutely it all could work better with CS knowledge. But CS is also definitely not a prerequisite to having functioning apps that can scale well.

CS can help you design the software equivalent of a Formula 1 race car. But most of us only need to work on things ranging from a Honda Civic to a semi truck. It's interesting how little of an education you need to work on a semi truck, even though it's a complex machine that does a tremendous amount of work, compared to the education you need to work on Formula 1 cars.

In the US, we have a big lack of tech talent, and I think part of the reason is the way people propose the requirements or education required to do these jobs. If it's a Honda Civic-level programming task, people shouldn't go through the expense and difficulty of a CS degree.

<comment><USER27> I think we managed to get on the same page then, I can agree to all of that.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> 80% of all software is glueing frameworks together to do CRUD. There's an art to do that right as well, especially very large systems with lots of legacy. Readability, SOLID, safety. It's not something everybody has a talent for.

But it doesn't need particular deep CS knowledge. There are people that program for 30 years, get paid six figure salaries and "never needed that shit". And they're really good at their jobs. But sometimes (less often than it's required to pass for an interview) you're really expected to dig that deep because you need to solve problems that existing frameworks and libraries don't handle.

Background: learning basic CS stuff after 20 years of programming professionally. You will _never_ learn it on the job.

</comment><comment><USER29> Application developer is to computer scientist like car mechanic is to physicist.

You've been conned into thinking Computer Science prepares for Software Engineering. That's not true.

While you may need some Computer Science knowledge from time to time (and in fact there are some rare jobs heavy in Computer Science knowledge) almost all typical development and especially entry level software engineering jobs are all about knowledge and skills that are not taught at school.

You've spent past few years learning other important skills. You don't need to know how numbers are divided, you don't need to know how cuckoo hashing works and you don't typically implement A* from scratch to get your company's systems implemented.

I don't want to say it is not helpful to know these stuff. It certainly is. But to spend couple of years of your life getting in debt instead of earning money and useful experience -- that's something everybody has to ask themselves if they think to get into Computer Science as a way into software engineering.

<comment><USER30> I'm happy I studied EE to work in Software/System Engineering. I always found it more helpful to think in terms of complex systems.

</comment></comment><comment><USER31> You've already gotten a lot of good perspectives. I have two tangential observations.

First: a lot of applied software engineering has the overarching goal of allowing developers to quickly build useful, stable, and secure products with relatively little knowledge of complexity principles or the implementation of the underlying system. Your successful career demonstrates the achievement of that goal. This is good. But it has absolutely nothing to do with your ability to _build_ the tools you use, any more than a writer would know how to manufacture a pencil from raw materials. They're completely unrelated skills. _But that was the whole point from the start of the profession!_

Second: your spelling of "fiancée" is incorrect. The word comes from the French word _fiancer_ , to betrothe. In French, you add the equivalent of the -ed suffix by changing -er to -é. Then for a female subject, you add another e. So "fianc" \+ "é" \+ "e" = betrothed woman. Using a è (backward accent) at the end of a French word isn't just wrong; it's more or less impossible (at least I can't think of a word that ends with è). Compare a snippet of JavaScript like if )a == 3) { b = 3: } You're an experienced JS developer, so you can spot the two syntax errors from a mile away. That's what "fianceè" looks like to a reader for whom accents are significant. Just stick with "fiancee" without accents, and you can't go wrong.

Sorry to hit you when you're down.

<comment><USER32> I completely agreè on your first remark!

</comment></comment><comment><USER33> I'm a little annoyed by the people who call these simple problems. There are no simple problems. Calling something simple is very insulting and demoralising.

It really depends on your experience and knowledge for what is simple for you.

You can have 20 years of experience developing projects and acquired a ton of valuable skills but when I shove a whiteboard in your face and tell you to solve some algorithm it's completely new and not simple at all.

Just as someone with a lot of theoretical CS knowledge will struggle if I present them with a failing dependency tree of 30 thousands NPM packages. Good luck solving that when you have never done it.

<comment><USER11> > Just as someone with a lot of theoretical CS knowledge will struggle if I > present them with a failing dependency tree of 30 thousands NPM packages. > Good luck solving that when you have never done it.

Honestly that problem is kind of self created. The amount of trivial NPM packages is mind blowing.

</comment></comment><comment><USER34> I'm going to disagree with all the positive comments in this thread. I feel like they're all "feel good" comments instead of being realistic. CS 50 is a freshman level introductory CS class. It's not a theory class, it's not a class teaching you how to implement sort behind the scenes.

I would agree that an algorithms class does not equate to success as a software developer, but if you're having issues with an intro class, there are certainly gaps in your knowledge. They might not reflect in your current job but may reflect in the future. I'd recommend actually brushing up on your fundamentals.

</comment><comment><USER35> As others have pointed out, a lot of application development rarely requires solving typical CS problems. One can go a long time building things without such formal knowledge. I agree with that and I'm glad that the field is available to anyone that loves to program regardless of schooling. BUT

The problem is thinking that "It's ok!" to spend your career in ignorance because your job doesn't involve inventing new algorithms or pondering theory. That's just lazy. I know, I did that for years too, not knowing why I should bother since I'm doing just fine without it! That is the arrogance of ignorance at work. I guarantee that you don't know how miserable you really are.

It's not about passing whiteboard interviews, it's about achieving a deep understanding of fundamentals. It will change and improve the way you think and approach problems. It will improve your software regardless of whether or not it involves an actual "CS problem" because your mind will be elevated. I did the same thing for years, I whined about "whiteboard interviews that don't effectively display my skills and unique gifts to do the job". It's a dumb mindset.

My advice as an internet nobody would be: Now that you've seen that you are struggling in this area, work on it! Don't let these people encourage you to remain ignorant. Advocating for ignorance is shit that propagates shit.

Ultimately, understanding the principles of your field will make you better. It's not about the damn whiteboard!

</comment><comment><USER36> Interesting, I think a CS degree does not equal a programming job unless you prepare in addition to your CS degree.

CS programs focus more on the abstract parts of the field. For example, you can finish a programming project without having to program a sort function, this is a built in function in most languages, yet that's a basic part of a CS program.

I think generally there's a disconnect between what employers need and what CS programs provide.

Don't get me wrong there are jobs that could not be done without the knowledge CS programs provide but for the average programming job there's a disconnect and you'll have a hard time if you don't have that in mind.

So, yes, I can see how you can have a programming job without being able to solve a CS class problem.

</comment><comment><USER37> You're restricting yourself from some opportunities by not knowing CS fundamentals.

Those are very common problems in programming interviews, and in those cases you would be disqualified.

If that bothers you (and the fact that you posted this question indicates to me that it does), then I would recommend taking the opportunity to learn along side your wife. You don't get the degree that way, but at least the knowledge is free. And your wife might like it, as a plus.

</comment><comment><USER38> I wonder if it can be analogized to a line cook (you) vs someone going to culinary school (your fiancee). In your day job you execute consistently and skilfully, but if you were put in front of a pantry full of miscellaneous ingredients and told to come up with a dessert you might struggle.

</comment><comment><USER39> _Most_ software development is in house stuff, and most of that is very procedural. You don't need a CS degree to do it.

Half of the rest of software development is embedded stuff for PLC or basic software needed to get a piece of hardware working. It is done by EE types that barely have an understanding of the language, much less data structures and algorithms.

Your experience and level of expertise is the norm. And, it's perfectly fine if it gets the job done!

The beauty of technology is that you don't need very many technologists to create something that ordinary folks can use. The field is very far along now so there's many levels of skill, from the guy that can create an AR engine from whole cloth down to the businessman who can do very advanced stuff within excel ...

</comment><comment><USER40> Here is an angle which seemingly no one mentioned: "I'm being tasked with guiding my fianceè with this course" What if the right way to help them is to do nothing, and let them work through it on their own? It's an exercise for a reason.

</comment><comment><USER41> I've been a programming since I was a kid in the 80s and for money since the late 90's and I'd struggle with what a computer scientist would consider simple problems.

It's a mismatch of domains.

Computer science !== Software engineering (though obviously there is overlap).

In practice I find that at least 50% of my job is getting requirements out of people's heads into a structured form I can explain to the high speed idiot.

The rest is working methodically, testing and documentation.

I work in the enterprise domain though so obviously YMMV if you are in machine learning, graphics programming etc.

Programming is a vast field with a huge number of sub-fields, find one you are good at and excel in that and let someone else worry about writing the compiler.

</comment><comment><USER42> That's akin to being a whiz at high school calculus and expecting to breeze through rigorous courses in real/complex/functional analyses. Possible if you're a prodigy.

You already got the practical programming down. Now if you take a course titled "intro to proofs" or "intro to discrete math", you'll be well prepared to kick any CS class' ass.

</comment><comment><USER43> This isn't too surprising. There's a lot of CS stuff that is rarely used in practical programming so you can get pretty far without knowing it.

</comment><comment><USER27> > but when it comes to me trying to solve these problems on my own, I don't > know where to start.

How do you expect to know where to start when you haven't been taught anything yet? Your short resumé does not indicate that you have any background in Computer Science. That's not bad, it's just different.

</comment><comment><USER44> It's certainly not required. I work with a guy whose degree isn't in CS, and he's a fine coder. He doesn't know the theory, but he's paid enough attention over the years that he knows what works, what the pro/cons of the various data structures are — he understands the _code_ that well enough to understand _why_. (And practically, that's probably more beneficial.)

The CS backing can definitely help, though. We've had plenty of problems at my job that involve writing a parser for often very tiny languages. Having an understanding of CS theory here — the various language classes, what an FSM is and where it is useful, etc. — definitely helps. However, often the language at hand is simple enough that a handrolled parser that skillfully uses a few regular expressions to get the job done suffices just as well. Googling for a parser library and just using that suffices, too.

Or we have to build a somewhat custom file format, or parse a somewhat custom file format. I've interviewed a fair number of candidates that are not comfortable _reading or writing bytes to a file_. (And of course, this is not the only question we judge them on. But very few candidates in my experience only miss a single question.) They've worked on innumerable "RESTful" APIs, but seem to have no idea how HTTP works; they've done server side Linux/unix/etc. development all their life, but never worked on a command line.

I hold a CS degree, and what grinds my gears is when it is just dismissed outright. As an example, I've had a coworker who was trying to determine what order various interdependent tasks needed to be accomplished in; to anyone who has been through graph theory, this is simply a topological sort, and there's a rather trivial algorithm that you arrive at in the course of studying graph theory. But at the suggestion of "this problem is a topologicial sort; X is a decent library that implements it", I get told "Now, I don't want to go down some PhD CS thesis rabbit hole." Right.

> _fianceè_

"fiancé" for a man[1], fiancée for a woman[2]. (Pronounced the same.)

[1]: [https://en.wiktionary.org/wiki/fiancé#English](https://en.wiktionary.org/wiki/fiancé#English)

[2]: [https://en.wiktionary.org/wiki/fiancée#English](https://en.wiktionary.org/wiki/fiancée#English)

<comment><USER44> As another example I've found of where the theory is helpful: I have _often_ seen two dimensional data put into a relational database, where the person wants to query over a range of values on both dimensions. (I.e., they want to find everything inside of a rectangle, were you to graph the points.) Broadly, I've found these fall into two categories:

1\. Lat/lng positions (find all rows where lat between [lat1, lat2] and lng between [lng1, lng2]

2\. start time/end time pairs (find all rows where the event is in or overlaps this range)

Then those two dimensions/attributes are put into what is often a B+ Tree or similar index. B+ Tree indexes can really only efficiently query on _one_ range, and only if every preceding attribute in the tuple that the index is built from is specified exactly. The first example w/ lat lngs is particularly bad.

But a lot of developers working w/ databases have no idea what a B+ Tree, or even any tree really _means_. They get that it's a tree, and that it's ordered. But there's a gap between that and somehow being able to think it through and arrive at the fact that the database must either:

1\. walk a lot of rows that aren't going to match (they typically do this)

2\. or do a hell of a lot of range scans (they typically do not do this, and it's not really always possible)

Often I find that they think it is </>/= with each attribute individually, when it is really more like the tuple being indexed _as a whole_ has a < operator implemented for it (by the database). Thankfully the analogy of find all people whose _first_ names start with "Th" in a index ordered first by _last_ name usually clears it up somewhat fast, but it took me a while to find that analogy.

(My CS degree included a course on relational databases. We covered everything from theory, such as relational algebra — operations on sets of tuples — to concrete implementations such as PostgreSQL and how to efficiently store indexes/data on disk. The professor I had was absolutely amazing, though I did not really realize this at the time.)

</comment></comment><comment><USER45> Learn a different language. I would recommend C, Forth or Lisp for stretching your brain.

Solve challenging problems; databases, interpreters, whatever floats your boat.

The only way out of the matrix is to keep pushing boundaries, repeating the same old with different frameworks is the blue pill.

</comment><comment><USER46> I spent 10 years doing web development that eventually lead into a few years of systems and network programming before I went to college for a CS degree. Many CS problems were still challenging even with all of that experience.

</comment><comment><USER47> It's an unfortunate fact of life: You don't know what you don't know ;-) Especially as a programmer, you have to have the attitude that there is no shame in not knowing, or not being able to do things. 30 years or so in this industry and there are _lots_ of things I'm not good at. In fact, as I spend more time, I discover more and more things that I don't know at all.

I've used this analogy before. When you first start, imagine that you are standing on the ground. There are lots and lots of things you can see. There is a lot to learn. Eventually, you get pretty good at everything you can see. But as you get better, hopefully you start travelling upwards. It broadens your horizons and you can see more.

Often this is an unsettling feeling. You think, "I've worked so hard, and there is _still_ more???" Some people give up, "I'm fine doing what I was doing. This other stuff isn't necessary!" However, this will lead to an early exit from this career. Being a programmer is about always learning and always expanding. Things change so fast and you have to keep up.

As you learn more, you keep travelling upwards, expanding your view even more. It's amazing because when you thought there was a lot when you started, as you move upwards, the amount of new stuff you can see starts to accelerate. It's easy to get overwhelmed. Don't worry, though. Just pick stuff you are interested in. Don't rush. You have plenty of time. However, don't stop either.

Eventually, you will get so high that the earth is just a round ball. For a long time nothing will seem to change. You'll probably think, "I've learned everything! I'm amazing!". And then you will run across the moon. "Woah... I know nothing". That's what it's like when you start to get more senior. You keep expanding your view, but things don't seem to change, until you see some new island of stuff that you never really imagined before. Again, it's easy to give up and to think, "I'm a senior developer and I'm world class in X. What do I need with the moon?" But that's a trap. It's the easiest way to ensure that you are seen as the strange old doofus in the corner using crappy, ancient techniques. Learning, learning, learning every day for the rest of your life. That's what being a programmer is.

I hope that helps!

</comment><comment><USER48> Hah, you must be the one who wrote the system I'm now rewriting.. :) just kidding. I went through the same thing- I thought I was a pretty coder too till they hit me with the towers of Hanoi problem in college. When I saw how simple the solution was to that problem, the scales fell from my eyes!

</comment><comment><USER49> Me too. I even invented slightly famous stuff.

It's like this:

There's reality.

Then there's a map of reality which is, for obvious reasons, pretty fucking far from reality.

Then there's the map of the map, which is delusionoid-squared.

In this case you are dealing with the level2 map. Most of us don't take it too seriously.

<comment><USER50> This is the best answer.

Let me paraphrase:

"The map is not the territory. It's not even close."

</comment></comment><comment><USER51> "The Imposter's Handbook" might be something worth checking out...

[https://bigmachine.io/products/the-imposters- handbook/](https://bigmachine.io/products/the-imposters-handbook/)

</comment><comment><USER52> I think I may have felt this once or twice in my career.

I'm 15 years in now. I study type theory and use formal mathematics to model software systems. I don't have any degrees. In my day job I lead teams writing mostly Javascript to build web services and APIs for moving data around. I teach a small group Haskell once a week at lunch. I speak at conferences big and small. I still wonder at times if I know what I'm doing or whether I deserve to have opinions about anything or blah blah blah.

It doesn't help having voices around you all the time that call your skills, experience, and knowledge into question. You have provided value to someone if you're still a practicing software developer. You know how to work in a team, solve problems, and have developed a sense of taste for what problems are worth solving. You understand the tools you use and have an intuition for their strengths and weaknesses. Maybe you even have some experience getting other developers to work together on a large project. That's useful stuff. You are a useful person.

Does learning theory help? I think so. Once I stuck with type theory I started to see structure and abstractions in code I couldn't before. Learning how to formalize programs has allowed me to think about the correctness of complex systems in precise ways in order to discover "bugs" in my designs. These have also helped me find more ways to write simple, reliable code.

</comment><comment><USER53> Most of professional software development is knowing what's out there and connecting them together. It's basically data plumbing. There's nothing wrong with that, running water and sewage are two of the pillars of civilization!

The problem is that lots of companies have high opinions of themselves and even if most of their work is plumbing and plumbing supplies, insist on having a hydrographer and a physicist on staff in case they really really need an R&D program that can produce a O(k) B-tree or some nonsense.

</comment><comment><USER54> I think you are seriously underestimating how valuable you are.

CS 101 data structures is all fun and great but the majority of businesses out there exactly require the skill set that you have.

Sure there are positions that demand deep knowledge on how algorithms but those are few..

You needn't to look further than Google itself.. they have many engineers that can apparently solve BigO problems, yet they fail to deliver a simple email client that works..

You deliver business value to companies, help them grow, create jobs and make profit.

This is something you should be proud of

</comment><comment><USER33> My spouse started a bootcamp last year and I've helped her with many algorithm assignments. Even though I have a CS bachelor degree I still struggled with a lot of the algorithms exercises out there. It requires practice and there are actually a lot of subtleties that you don't experience while working on software projects.

A lot has to to with mathematics as well. You can work on projects with hundreds of thousands of dollars and face zero mathematical problems.

I spend a lot of time, dozens and dozens of hours, helping her with these algorithms on paper, whiteboard and writing them in code. I also struggled along with her through online algorithm and coding interview platforms like Hackerrank. Solving these algorithm is difficult and often ridiculously theoretical and out of touch with the daily routine of a software/web developer.

My spouse was very worried about not being able to solve these problems. She was scared that she will have to solve these things during the internship, but of course there are no mathematical algorithms to solve when you are working as a frontend developer.

I think the trend of mathematics during development courses and theoretical algorithm exercises during interviews are not doing us any good. Most companies are not Google and you can be a very valuable developer for 99% of the companies out there without being a whiteboard algorithm expert.

<comment><USER15> I'm curious, is it the norm for people who do online courses or bootcamps to get help from their spouses? Is it not unfair for those students that are unpaired? I was in university (and thus not really in the pairing off mindset) last time I seriously studied a brand new field but I never got a romantic partner or even a friend to help me directly with my assignments, it would have felt like cheating in a way... but since online courses are targeted to adults maybe it's expected and they see it less academically?

<comment><USER33> Are academic students getting help from fellow students, a tutor, a teacher or their parents also cheaters?

Do you consider tennis players with a coach also cheaters? The player still has to play the match by themselves.

Are developers who ask for help from a colleague also cheaters in your eyes?

<comment><USER15> No, definitely not (at least on the latter two; my school did say take home assignments had to be done independently, if graded. People did get help on the ungraded assignments, though I didn't).

I wondered if bootcamps/online were more like in the adult world (where it's basically always OK to get help) or like traditional degrees (where everything graded has to be done on your own unless a team project). You are saying it is more the former, I suppose.

I just wanted to know if everyone did it. Like are most people in bootcamps friends or spouses or children of working programmers? or are there also people doing this "out of nowhere" like at community college?

</comment></comment></comment></comment><comment><USER55> The point of studying data structures and algorithms that you may not use on a day-to-day basis is that they make you learn to think abstractly about problem solving. That is the whole point of getting an undergraduate degree in CS. I'm sorry that you have trouble with this stuff OP, it would be a good idea to do the cs50 course with your wife until you're comfortable with this stuff. I'm sure it will pay dividends in your future.

</comment><comment><USER56> I don't think it's really just you. Most academia seems to have a hyper-focus on algorithms and data structures. I don't know what kind of jobs they're expecting people to apply for - I'm not writing an implementation of the C++ STL, and I'd argue most of the time it's a mistake to write your own data structures with such a great ecosystem of existing implementations.

Don't get me wrong. It's great to know how binary search works, or to understand algorithmic complexity - those things come in handy. But you probably don't need to know how to find the largest palindrome in a string and you almost definitely shouldn't be writing your own hashmaps in real world code. Most people would benefit a lot more from domain specific knowledge. How do system calls work? What's a load balancer? etc, etc. Even being domain specific, a lot of the ideas can be applied outside of the context it was created in, and so knowing these things is incredibly useful.

Thankfully, most of the interviews I've had have focused a lot more on real- world situations and topics. Maybe academia will some day catch up and at least balance the focus out a bit.

</comment><comment><USER57> I would just start toying around with these problems, there's lots of sites out there that aggregate them for you (personally I like [https://reddit.com/r/dailyprogrammer](https://reddit.com/r/dailyprogrammer)). Solving these kinds of problems really are different from your usual day to day on the job coding activities. I'm by no means the best at solving these things, but the more I do it the easier they are going forward. They are useful mostly just for fun or for preparing for interviews where people might do this crap to you. There's actually a yearly code challenge called Advent of Code ([https://adventofcode.com/](https://adventofcode.com/)) that is starting in December that you can try (though they can be kind of tough). You basically just have to keep doing them and do harder and harder ones and it gets easier, your bag of tricks starts to grow and you realize "Oh, this problem is pretty similar to the problem I did last month, I'll start out with the same approach"

</comment><comment><USER58> Seems like you discovered a gap in your knowledge, congratulations, you're one of the lucky ten thousand [0]!

It might be a good idea to pick up a book about algorithms (others are posted here) or follow an online course yourself to learn about these things. They might give you some insight into problems which you might encounter during your job.

On the other hand, solving algorithmic problems is not equal to 'software engineering'. You have to think about more than solving a (theoretical) problem in isolation and you've build up skills on that area of the past few years. From source code management to soft skills, these are things a compsci degree won't necessarily teach you.

From personal experience though, I find that my background does help me (at times) with solving problems at work. But apart from the utility of learning compsci, consider that it might be fun to learn so and just give it a go.

It doesn't make you less of a web developer by not knowing it though, so don't be too hung up on it. It's just different, as others have pointed out.

[0]: [https://www.xkcd.com/1053/](https://www.xkcd.com/1053/)

</comment><comment><USER59> > It makes me question how I was hired in the first place.

It is called imposter syndrome. It is very real and very common. As a JavaScript developer I encounter this among my peers all the damn time.

First, consider what it takes to be a professional software developer. The requirement is to pass a one time drug test and successfully answer questions in a 30-90 minute interview. Done.

Consider, conversely, all other white collar professions. They have licensing, certifications, educational requirements, and legal compliance. There is greater oversight and compliance to become a truck driver than a software developer.

The closest uniform indication of competence _(if you can call it that)_ most software developers experience is demonstrating experience with a tool or framework. To me this says you more than new and probably better than negligently incompetent. It doesn't tell me that you are an excellent specimen of solving original problems.

Secondly, I suspect you go to work, achieve your assigned tasks, and then forget about programming until the next day. This is problematic because in most cases there isn't much expected of software developers in the corporate world. Most of us are glorified and over-paid button pushers. Achieving conformance to nearly thoughtless tasks that could be better performed by software is not an indication of professional growth. There are many times I have encountered QAs who seemed far more brilliant at problem solving than the developers they were checking.

This is one reason why more ambitious software developers contribute to open source. Their day jobs are boring with no growth potential, but their software hobby is extremely challenging and solves real problems.

<comment><USER60> > The requirement is to pass a one time drug test

Wait what? Where do you live that software developers are drug tested?

<comment><USER59> A drug test and criminal background check are standard at every place I have ever worked. The current employer is a super giant fortune 25 company

</comment></comment></comment><comment><USER61> I've been writing a book series that's partially targeted for programmers like you: those who know how to code but don't know CS. It's called "Classic Computer Science Problems." You may want to check it out:

[https://classicproblems.com/](https://classicproblems.com/)

If you already know Python or Swift, it may be a decent next step for you after CS 50.

</comment><comment><USER62> We're gonna need some examples here. One person's fizz-buzz is another's constant-time radix tree with one register and vice versa.

<comment><USER63> Unfortunately, these are fizz-buzz tier. [https://news.ycombinator.com/item?id=18446313](https://news.ycombinator.com/item?id=18446313)

</comment></comment><comment><USER64> (1) Programming and Computer Science are not the same thing.

(2) Doing similar things over and over may not transfer experience to other things.

</comment><comment><USER65> Depends on your area of focus. Schools tend to be much more focused on the academic / math than practical application development.

CS isn't as critical until you have to worry about efficiency, scale, or creating radically novel solutions. At which people you naturally will pick up more CS as you try to solve these problems.

Building something and building something that can scale are almost 2 completely different tasks. Asking questions like how much disk space will this take? How long will it take to perform a lookup? How do these factors change as the data grow?

Another area where CS becomes more important is when you want to come up with new abstractions.

To do what others have already done you don't need much CS knowledge because others have created libraries for you and have already established the design patterns. But CS becomes more important when you want to invent new paradigms and algorithms.

</comment><comment><USER66> As some others have said: programming and CS are only somewhat related.

I like to compare it to some kind of manual work.

Programming is the tool. There's a hammer, or a screwdriver, or a saw. A good manual worker is able to use most of them. She may not have experience with all of them, but with enough experience she will learn to use new tools faster. The manual worker usually doesn't know much about creating those tools.

CS is like creating tools. You know what properties the tools should have, what materials they should use, etc. Most engineers are probably not as good in actually using them as the above mentioned worker.

So, being a good programmer does not mean being good at CS, and vice versa. What I'm saying is that it's totally fine. You'll learn (using the comparison again) what's the best material for a given tool for your current project as soon as you need it.

</comment><comment><USER67> I work as a data scientist, but sometimes when I have the time to study stats I get stuck on problems. I also write software on our team, and have never taken a CS course or studied algorithms formally.

It used to really bother me, and I still am motivated and invest time and energy into building fundamentals, but I also realize that for some reason, despite this, I'm effective at my job and people respect my work. Meanwhile, people who took all the most advanced PhD and CS courses often are unable to get things done.

As I've grown a little older I try to spend less time worrying about these things, and realize more so every day how large the disconnect is between solving abstract puzzles, and working on a team to get things done.

Although I think the people that have both in spades are something else, and I have a deep admiration for them.

</comment><comment><USER68> The obvious answer is, do the class with your fiancee, and then you'll learn how to solve those problems. Every intro to CS class has advice how to do this [https://www.cs.cmu.edu/~112/notes/notes-algorithmic- thinking...](https://www.cs.cmu.edu/~112/notes/notes-algorithmic- thinking.html)

Break down the problem into smaller ones you think you can solve and start from there, the more practice at this the better you get at solving future problems. Maybe you even turn out to be really good at this and take up amateur theoretical CS in your spare time.

</comment><comment><USER69> I'd recommend a look at this book [http://blough.ece.gatech.edu/3020/focs.pdf](http://blough.ece.gatech.edu/3020/focs.pdf) .It will show you what you've been missing in the preface and the first chapter. An interesting point by the authors was that this was the way they felt CS should be taught, with the fundamentals and all presented side-by-side with the code. But when you think about it(from mathematics for example) we need accountants who use mathematics effectively without having to understanding Fermat's last theorem...

</comment><comment><USER70> > I've worked with a few "complicated" (they were to me) projects in the past, > but now I'm being tasked with guiding my fianceè with this course.

You should not solve those problems for her anyway. Help her with tools and such where necessary, but let her figure it out as much as possible. Don't do homework for her, it beats the purpose.

If the course is any good, the answers to questions are going to be easier when you attend lectures etc. If you cant see them, maybe let her explain you what was said there. Explaining someone helps to understand, so it alone would help her _a lot_ to learn and understand.

</comment><comment><USER71> I felt kind of like that first few years of my programming experience - <USER2> could hack all kinds of things on my own (in assembler, c, vb), but then someone asked me a basic datastructure or algo problem and I would blank out. Or asked me some stupid OOP problem... granted cs education back in the day wasn't quite as formal but still.

Anyways, I'd say don't get discouraged, learn new technologies, get out of your VB and .net and Microsoft cocoon and try new things. Maybe take a cs algo and distributed computing course and read up a book or two.

</comment><comment><USER72> I also worked as a computer programmer for a few years without having a CS degree. I decided to work part time while pursuing a Bachelors in Computer Information Systems (less math than CS, more business, most of the same CS courses). It was totally worth it. Not only did I learn about some really useful/interesting stuff (search+sort algorithms, data structures, etc), my pay has significantly increased. I admit that it wasn't always easy or fun, but it was highly rewarding.

</comment><comment><USER73> i think a lot of the problems you are expected to solve in a CS course are things that are already provided or have workable alternatives in higher level languages. VB and javascript already provide for many different data structures where you might need to know them and be aware of them in the lower-level languages

Also due to the data structures provided in higher level languages you are often less aware of how long something will take to run which i find is a big part of many CS courses

</comment><comment><USER74> A lot of it is practice. There's an old saying about calculus - don't worry, once you've done a thousand integrals, you'll really start getting the hang of it.

Taking one of the popular algorithm and data structures book and working through it, and actually doing the exercises, _will_ improve your skills; specially, the ability to identify the shape of a particular problem.

Pure CS is very beautiful IMO, and rewarding to dive into.

</comment><comment><USER75> You're fine. You don't need it. I'm a Senior Dev and I don't have a degree. I've been a professional programmer for almost 15 years. Not once have I needed to write an algorithm from scratch.

Would I be a better developer if I'd learned that stuff?

Arguably, no. I'd probably be cock-sure and a bit of a dick. I know there's a lot I don't know and hopefully that keeps me humble. I'm always learning and I love it!

</comment><comment><USER76> > Some of the problems which she is expected to solve are pretty simple > problems, but I just can't seem to get the hang of any of them on my own.

So what are some examples of those problems? No one can really tell you if this is something unusual or not without having an idea of what the problems are. And CS courses and algorithms vary from pretty simple to actually really hard.

<comment><USER77> Probably something like implementing a red-black tree or merge sort, stuff no one does in the real world :)

There is a considerable disconnect between programmers who have a CS degree and those who don't.

I've run into programmers who'd never heard of the term "boolean algebra" before and knew about regular expressions but didn't know what a state machine was.

For the most part it doesn't matter, but it's always a little surprising when you find someone who knows AWS very well and then you find a huge gap in their fundamental knowledge.

<comment><USER76> Well, red-black trees and merge sorts don't grow on trees (ahem), even in a real word :)

But yeah, those are gonna be tough to just come up with on the spot without actually studying them. On the other hand, OP could be talking about stuff like tree traversal and similar simple stuff that is also included in introductory CS courses.

Edit: OP chimed in elsewhere in the comments, it's not even about CS stuff.

</comment></comment></comment><comment><USER78> Programmer for 40 years and CS terms are a foreign language to me. My daughter did a CS module at uni but when she phoned me for help I diddnt even understand what she was talking about until I googled the terms and realised I knew them all but without fancy names.

I am pretty sure in 30 years all you current experts in CS will l be scratching your heads with the same.

</comment><comment><USER79> Who cares? I can't remember the trigonometry I studied in school even though I can still work a calculator.

It's useful to understand the basics so you develop an intuition, but don't stress if you can't actually solve the problems. You almost certainly won't need to use them in your career anyway unless you work in some incredibly niche areas.

</comment><comment><USER80> I'm surprised no one is suggesting a basic revisiting of first principles. How optimized is your nutrition? Are you exercising frequently, and getting plenty of regularly scheduled, high quality sleep? Anecdotally, I know that when I stop prioritizing my health—my working memory goes, and it's all downhill from there.

</comment><comment><USER81> Don't worry, I've been building things using Lego blocks for 20 years and I can't build a floating bridge.

</comment><comment><USER82> You may find this thread from 5 years ago[1] meaningful.

As the article emphasizes: _The labels themselves aren't as important as the degree of awareness and understanding that each new "level" brings._

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

</comment><comment><USER83> I recommend everyone read this article, as this is the best article to introduce how to learn CS in the whole human history. No kidding, thank me later.

[https://www.afternerd.com/blog/learn-computer- science](https://www.afternerd.com/blog/learn-computer-science)

</comment><comment><USER84> Now you learned the practice, consider taking CS degree at uopeople.edu to clear "Must have Bachelor degree in CS" and just to learn stuff beyond the day to day stuff. Of course, it really bothers you, it is totally fine just keep going and solve real-world problems (not all of them require CS knowledge)

</comment><comment><USER85> Sorry, but perhaps you should take some time to learn the fundamentals of your field? Incompetent devs like you are the reason the rest of us have to jump through absurd whiteboard hoops. Anyone who can legitimately call themselves a programmer should not have trouble with an intro CS class.

</comment><comment> d--b CS is to professional programming what fluid dynamics are to car mechanics. You can be a great car mechanics and never know about the fluid dynamics equation at all. You do need some basic knowledge (pressure, temperature, etc), but then it's a different discipline altogether...

</comment><comment><USER86> Well, I can solve most CS problems easily but have a hard time functioning as a developer.

Most CS questions are a bunch of concepts that you rarely use in practice. Most development work is implementing your ideas in a way that works with other peoples code and the framework thats used.

</comment><comment><USER87> there are a few books you can get: [https://www.amazon.com/gp/product/1565923987/](https://www.amazon.com/gp/product/1565923987/) [https://www.amazon.com/dp/0262033844/](https://www.amazon.com/dp/0262033844/)

A lot of "classic" problems are so embedded into CS professors that they don't even see them as problems anymore (lazy caterer, pick's theorem, etc) so if you didn't study these classics explicitly in school you have to discover them on your own.

</comment><comment><USER88> You now see that you can't do something and it is very close to what you do.

Act on it.

But if you don't, at least dont wonder why you are doing what you are doing and perhaps not something else. Or why you might not get into some other companies or or or.

</comment><comment><USER89> This might help: [https://medium.com/launch-school/solving-coding-problems- wit...](https://medium.com/launch-school/solving-coding-problems-with- pedac-29141331f93f)

</comment><comment><USER90> If you have been successfully solving problems for those last 5-6 years, your only current problem is your insecurity.

Can your fiancee do your job? Or is your knowledge just divergent?

</comment><comment><USER91> CS algorithm stuff you're talking about has little to do with web development in practical terms. It's mostly mathematics.

You're comparing two very different fields.

</comment><comment><USER92> There's nothing wrong with that.

That said, you should consider learning basic CS. It will help you do a better job, and also make your job more enjoyable. And it's fun!

</comment><comment><USER93> Completely not to the point, but this is driving me nuts: put the accent on the right letter and in the right direction—it's "fiancée".

</comment><comment><USER94> at least on StackOverflow "computer science" and "computer programming" get different pages:

[https://cs.stackexchange.com/](https://cs.stackexchange.com/)

[https://softwareengineering.stackexchange.com/](https://softwareengineering.stackexchange.com/)

</comment><comment><USER95> You can try TDD-ing the problem. Although TDD is usually not the right approach for coming up with algorithms or solving coding challenges, it can guide your thinking a bit. Write a test for most simple input, solve the problem for this input. Iterate and write tests for longer inputs.

I will repeat that TDD will not give you the most elegant answer, but you will at least have an basic implementation. TDD just gives you one of protocols that you can use to solve problems.

<comment><USER96> I don't see any connection to Time Division Duplexing here.

(just another comment pointing out development vs. computer sciences)

</comment></comment><comment><USER97> sure, for the first 20 years that I was a programmer, I really couldn't wrap my head around algorithms at all. It took concerted effort (I'm a slow learner) and repeatedly reading books, talking to people, writing code and having it reviewed before I felt comfortable with hash tables, etc.

</comment><comment><USER98> My brain no longer works that way either, I started getting sick of the same standard code tests asked at interviews while I was a developer (Please write a palindrome detector, please write a function to reverse these sets of numbers).

My point is - computer science teaches you to understand the core of what computing is about, but don't for a second think that much of it relates to real world experience.

</comment><comment><USER99> Code monkey thinks he can help beginner become a researcher? Not so fast, tiger.

</comment><comment><USER100> I'm 2/3s of a way through a CS degree and I cant do them either.

</comment><comment><USER101> Cracking the Coding interview by Gayle

</comment><comment><USER102> programmer is like driving a car.

CS problems is like how to design a proper car and how a car really works.

</comment><comment><USER103> At least you know it :)

</comment><comment><USER104> A _decent_ CS degree, like that of MIT matters a lot.

I could give an example. Once upon a time a stumbled upon this classic article (which I re-read sometimes to feel better):

[https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad- design/](https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/)

When I read this for the first time I have been literally shocked by sudden realization that I have coded some stuff in PHP but never knew it is _such a crap_.

It also taught me that I literally know nothing, that I am merely a stupid coder, not a programmer, so I undertook a serious study of CS fundamentals to be able to _write_ an article like this in the future.

Now, after a few years of studying, I know a half-a-dozen of languages and I know crap when I see it. Ironically, what is going on with the Node ecosystem puts PHP3 into a shame. But it is natural, because most of JS coders have no CS background. People with CS background _sometimes_ produce gems like Go or Erlang, while "mere coders" _always_ produce things like PHP, J2EE and npm.

There is only one thing that I regret - it could save me so much time by not reading bullshit on the web if only I could find the right books (like Programming Erlang, Haskell School of Expression or On Lisp) and right courses (like Dan Grossman's and 6.001 2004 - the last course in Scheme) first. There is a huge, qualitative difference between a well-written gems like these and fucking crap some narcissistic idiots post in their blogs.

I have found the right books and the right courses by literally swimming thorough the sewers for years. A decent school will teach you the right principles, instead of irrelevant details, in ML or Scheme right from the beginning.</comment>


Vulnerability in All Versions of Internet Explorer Allows Remote Code Execution - <AUTHOR> https://technet.microsoft.com/en-us/library/security/2963983.aspx

<comment><USER2> Is that very different from any buffer-overrun bug? Isn't this a common problem in every browser?

The interesting bit is, its been around for so long in this product line.

<comment><USER3> Not exactly. Classic stack-based buffer overruns are _generally_ mitigated by the /GS flag in visual studio and heap overruns are usually caught by heap hardening.

There are normally a ton of memory corruption vulnerabilities in every browser, but given modern memory protections the gaps are in "use after free" bugs, mostly.

UAFs where an object is allocated, then freed somehow, but (ideally) through Javascript you can somehow get a handle to the object, or put something in memory where that object used to be, such that a method gets called on it. Since you control that part of memory, you can control where the method invocation goes.

Typically browsers have additional sandboxing to make UAFs and general memory corruption hard to exploit.

See say: [https://technet.microsoft.com/library/security/ms13-may](https://technet.microsoft.com/library/security/ms13-may)

Search for "use after free" and see how many there were.

P.S: the fact that EMET mitigates this means it's likely the exploit uses a heap spray.</comment></comment>


"Little Box Challenge" Inverters Arrive at NREL - <AUTHOR> http://www.nrel.gov/news/press/2015/21584 <comment><USER2> Previous discussions from when the contest was announced:

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

[https://news.ycombinator.com/item?id=7730042](https://news.ycombinator.com/item?id=7730042)</comment>


Show HN: Pisa – Probably the Fastest Full Text Search Engine Written in C++ - <AUTHOR> https://github.com/pisa-engine/pisa <comment><AUTHOR> We are looking for contributors! Please reach out if you are interested in collaborating.</comment>


Ask HN: Why isn't there a "search" on HN? - <AUTHOR>

<comment><USER2> Ironically not the first time this question has come up:

[https://www.hnsearch.com/search#request/all&q=why+isn%27...](https://www.hnsearch.com/search#request/all&q=why+isn%27t+there+a+search+on+HN)

</comment><comment><USER3> No footer if you have continuous scroll turned on.

<comment> jack-r-abbit Can you point me to the HN setting that turns on continuous scroll? I can't find it in my HN profile page.

</comment></comment><comment><USER4> Check the footer

</comment><comment><USER5> there is... at the bottom of the page.</comment>


Ask HN: Cheapest way to host user submitted images? S3, Beluga, Imgix? - <AUTHOR> People can create listings like craiglist and submit pictures.<p>I want to host and serve these images as cheaply as possible. <comment><USER2> Get a dedicated instance at Hetzner and stop paying for the imaginary "premium traffic" that you have to pay elsewhere. Not a affiliate but a happy customer that is making good use of their unlimited traffic.

<comment><AUTHOR> So save the images directly to a dedicated server's hard drive?</comment></comment>


Epic vs. Steam: the console war reimagined on the PC - <AUTHOR> https://www.theverge.com/2019/4/16/18334865/epic-games-store-versus-steam-valve-pc-gaming-console-war-reimagined <comment><USER2> While I do agree that Steam needs a competitor, Epic hasn't been the one I have hoped for.

Steam has been doing many great things for the industry including the pushing of VR as well as the huge support of Linux gaming - I haven't seen Epic do anything like that.

Instead all I've heard from them were exclusivity deals such as Metro Exodus which not only disappointed many players (See the whole preorder fiasco as mentioned in the article) but seems to turn the whole game industry into what the streaming industry currently is - which I highly dislike.

I will not support the way Epic goes about being a Steam competitor unless they actually become one, with decent features and improvements on their platform as well as more contributions to the industry as a whole.

</comment><comment><USER3> There is no war. Epic's store is clunky and steam is not. For me it doesn't go further than that.

<comment><USER4> Steam is still laggy after being out for more than 10 years. One would think they could get their head around async loading of the images to stop the jank but here we are.

In their defense, epic's client pretty much just came out and has the same issues as well.

<comment><USER3> Fair enough.</comment></comment></comment>


The Horrors Lurking in Your Legacy Codebase - <AUTHOR> https://medium.com/@dylanbeattie/the-horrors-lurking-in-your-legacy-codebase-616d7d631f35 <comment><USER2> I was expecting this to be yet another tiresome Chesterton's Fence[1] violation, but it's actually quite good. The software equivalent of the appendix, uvula, or hiccups. All long-lived systems grow some of these. In a way, they're actually a sign of health. If your system doesn't have any weird callouses, it's most likely because nobody has used it seriously enough to form any.

[https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)</comment>


The Fertility Implosion - <AUTHOR> http://www.nytimes.com/2012/03/13/opinion/brooks-the-fertility-implosion.html

<comment><USER2> This is silly.

> _Usually, high religious observance and low income go along with high > birthrates_

No, usually what goes along with high birthrates is an agrarian peasant society that has to maintain high birthrates because 50%+ of children die before the age of 5, and if you want to have several kids of working age around to help in the fields, you need to aim for 8 or 12 newborns. Agrarian peasant societies happen to be poor and religious, but those are effects, not causes. Other contributing factors: women without independent income and therefore beholden to their husbands, no access to contraceptives, lack of basic literacy and education especially among girls.

Then what happens when places get improved sanitation and healthcare, pretty consistently everywhere we look at the data, is that there's a demographic bubble when a generation has mothers survive all their pregnancies and all their 8-12 kids survive to adulthood. Then in the next generation or two, that falls to 4-6 kids on average because, hey, 50% aren't dying anymore. Then by 2-3 generations after that, it's down to 2-3 kids on average, or in some places even below replacement levels. Other contributing factors: migration to cities, access to contraceptives, and education especially of girls.

If you work in a factory or an office or a store, and live in a city, it's just not convenient to start having kids at age 16 or to end up with 8 kids running around, even if you're poor or religious. Already, 50% of the world population is urban, and within another generation that will be 60%.

> _The speed of the change is breathtaking_

The same demographic changes everywhere else in the world happened or are happening roughly at the same speed. There's an incredible drop in fertility rate within 2-3 generations every time. For example, you see precisely the same pattern happening within the last few decades in rural Mexico, and if you look back several generations, the same pattern sweeping across Europe.

That Brooks thinks the changes in Oman &c. are surprising says more about Brooks than about the changes here.

<comment><USER3> In general what you say is true, but there are some exceptions. The Hasidic Jews are one of the most fertile groups in the US, and they are low income, highly religious, but urban (most of them live in New York City).

You might think they're an insignificantly small group, but the counterintuitively fast nature of exponential population growth means that they'll become surprisingly large surprisingly quickly. They're culturally immune to the influences that caused fertility to collapse in others and they're unlikely to voluntary limit their fertility.

</comment></comment><comment><USER4> >>But, over the long term, it's better to have a growing work force, not one that's shrinking compared with the number of retirees.<<

Why is this true? It seems to be taken as granted that this is true. I don't think that having a growing workforce that is barely earning a living is such a good thing.

It just seems unsustainable to think that we can depend on a growing workforce indefinitely to support the growing number of retirees. Long term it will be better to figure out technological solutions to this problem, i.e. robotics.

Hopefully with a reduced workforce we can focus more on quality of life.

Edit: I guess the reason this quote bothers me so much is that increasing the population in a lot of countries would mean bringing new babies to a life of poverty and misery. Why not focus on fixing the quality of life thing first?

Edit2: This is a response to the comment:

>>A lot of people would be surprised to learn that the impoverished peoples in a many those countries are a lot happier we expect. All-in-all they aren't much less happy than we are.<<

I think you may be right. I was probably just projecting. Still, being below the poverty line brings a lot of problems. Tens of millions of people die just from hunger every year or from diseases that are simple to cure or prevent in the developed world. That is probably the kind of misery I'm talking about.

<comment><USER5> > I guess the reason this quote bothers me so much is that increasing the > population in a lot of countries would mean bringing new babies to a life of > poverty and misery.

A lot of people would be surprised to learn that the impoverished peoples in a many those countries are a lot happier we expect. All-in-all they aren't much less happy than we are.

Not saying that wealth isn't a good thing, but it doesn't seem to be a major determining factor in happiness. Not unless you're too poor to get your 1,800 calories or you think you're entitled to wealth you don't have, anyway.

<comment><USER6> I am not refuting your point ("money does not happiness make") but AFAIK, it is a known fact that people tend to a state of average happiness no matter what their condition is (e.g. if they lack the ability to walk or if they own private jets).

But there is a correlation between the youth/child death rate and the number of kids, and it can be generally agreed death impairs the pursuit of happiness.

(Though, quite likely child death implies many kids, not the other way around)

</comment></comment></comment><comment><USER7> American fertility is heavily stratified by education; less educated women reproduce significantly more:

[http://www.feministe.us/blog/archives/2011/09/28/americas- fe...](http://www.feministe.us/blog/archives/2011/09/28/americas-fertility- crisis/)

<comment><USER8> And race, and wealth, and even political views:

> Mean number of offspring

> Wealthy liberal women (n = 35) 1.60

> Wealthy conservative women (n = 43) 2.49

> The difference is statistically significant. Wealthy white conservative > women average 55 percent more kids than their liberal counterparts.

[http://inductivist.blogspot.com/2012/03/fertility-among- weal...](http://inductivist.blogspot.com/2012/03/fertility-among-wealthy- white-liberal.html)

</comment></comment><comment><USER9> The real moral of the story? Health care startups in the next 20 years will be hot, as most of our world transitions to taking care of an increasingly elderly generation, robotics fill highly repeatable labor, and the resource crunch makes goods last longer.

<comment><USER10> I can already see the reaction to acqui-hires. The sick should love having their services sunsetted.

<comment><USER9> Ah, but direct to consumer isn't necessarily the right play in this market. HIPPA is still a major pain, and the sick (and families of the sick) tend to have less cash. (Though, they have a lot of points where their lives could be made better by software. The low hanging fruit has been done in the app store, of course.)

Further, if you go B2B, the aqui-hire might be more interesting if you have multiple hospital groups that like your product. (for example) In fact, it makes you more likely to be acquired for your technology.

<comment><USER10> Or you may be acquired by a bigco and your product killed to eliminate nascent competition. Frankly, I'm not convinced the usual VC-funded startup ecosystem is a great match for healthcare. If you think consumers might be afraid of companies going out of business, you should see how some of a) large businesses that make all decisions for five years at a time or b) small practices that still use Access and macros from 2001 because they work feel about the situation.

</comment></comment></comment></comment><comment><USER11> On an abstract level it does seem better to have a large number of young people to care for a small number of retirees, but that would create an unsustainable pyramid scheme in a country like China. Many parts of the world are already overpopulated and low fertility is pretty much the best case scenario.

All of that aside, I also think that there are factors more important than the relative number of old people in a given population. Technological development, public health, etc. are all probably more important, and some of those factors are at odds with high fertility.

</comment><comment><USER12> I've always believed in "Quality of Life", over "Quantity of Life". And reading stories like these gives me hope for the planet. I'm not sure we can handle 10 billion people living off of it simultaneously. Just look at all the problems we've got with only 7 billion and the upcoming food and resource shortages.

Smaller populations living great full lives is so much better than massive populations living terribly. Economically, investors don't like shrinking populations because they make their money from growth and consumerism, but environmentally this is wonderful news.

Looks like, in its own way, nature is starting to balance things out once again.

<comment><USER13> I'm not sure why you seem surprised; this is a _very_ long standing trend. It's also pretty obvious. You aren't the only one to value quality of life over quantity; in fact everyone else does too. The only problem is that if you're very poor you don't have a choice. Wherever and whenever the human race manages to claw its way out of poverty, we immediately stop having so many kids. It's not magic.

That being said...

1) What upcoming food shortage? Food production is largely a solved problem. We know how to sustainably produce large amounts of food from a given amount of arable land, and we have plenty of arable land to feed not just the current global population, but the projected maximum global population. It's true! We already have the ability to feed the largest population we'll ever have. True, Africa _currently_ has food shortages, but as soon as Africa stops relying on peasant farming, that problem goes away. We can argue about when (or if) Africa is going to finally have their own Green Revolution[0], but...upcoming shortages? Do you know something the rest of us don't? :)

2) I might ask what upcoming resource shortage, but that's a more complicated question, and probably not worth arguing about. Still, you might want to consider the outcome of the Simon-Erlich wager[1], look at commodity price trends over the last couple decade, and then look at futures prices. Would you take Erlich's side in a repeat of the original wager? I wouldn't, and it's worth noting that Erlich and his ideological allies have repeatedly refused to do so. Again, what do you know that they don't?

3) Also, this is wonderful news for "investors" too (why beat around the bush? Call them "capitalists"; you know you want to...). Trust me, the slavering capitalist dogs are _VASTLY_ more interested in having a rich China full of consumers than in having a poor China full of workers. It might be nice to have cheap Chinese labour making iPods to sell to 300m rich Americans, but it will be _FANTASTIC_ to have cheap robot labour making iPods to sell to 1.3b rich Chinese. (And that's precisely the scenario you're envisioning.) Lower costs and higher sales is how capitalists make their money in the real world.

4) Finally, it remains to be seen how good it will be environmentally. In the short run (say, the next 50 years), it probably won't be. Much as with population growth, we see an inverted curve. Very poor countries can't afford to pollute, and very rich ones can afford not to - but right in the middle you end up polluting a bunch. We went through that period in the late 19th and early 20th centuries; now it's China's turn. They're producing less pollution for every dollar of GDP each year, but their GDP is climbing much faster. The environment is likely to get worse before it gets better. (Of course, look on the bright side: We are conquering global inequality, and the environment will recover eventually. Those are both GREAT. But let's not get carried away.)

[0]: <http://en.wikipedia.org/wiki/Green_Revolution>

[1]: <http://en.wikipedia.org/wiki/Simon%E2%80%93Ehrlich_wager>

<comment><USER14> > _What upcoming food shortage? Food production is largely a solved problem. > We know how to sustainably produce large amounts of food from a given amount > of arable land, and we have plenty of arable land to feed not just the > current global population, but the projected maximum global population. It's > true! We already have the ability to feed the largest population we'll ever > have. True, Africa currently has food shortages, but as soon as Africa stops > relying on peasant farming, that problem goes away. We can argue about when > (or if) Africa is going to finally have their own Green Revolution[0], > but...upcoming shortages? Do you know something the rest of us don't? :)_

(I had a strong personal reaction to your tone; I find your tone really unpleasant. I recognise this is my problem. Sorry.)

You're right that there is enough food for everyone to be fed and live a productive life.[1] But there are still extensive problems sharing that food out.

Just one example: almost half of children under 5 in Nepal are stunted because of chronic malnutrition.[2]

Developing countries spend too much money importing food.[3]

There are problems now that are hard to overcome in future - climate change, desertification, salination, rates of HIV / AIDS in the farming population, migration, etc. Here's a set of photos showing some problems. (<http://www.irinnews.org/photo/Slideshow/43/Too-Poor-to-Farm>)

But there are interesting methods that show some promise - such as 'empowering women'.[4]

I don't think we are conquering global inequality. I think it's getting worse. And the environment might not recover eventually; it might go into runaway heating and boil off the atmosphere. Or it might recover eventually, after having killed off all human life.

[1] (<http://www.wfp.org/hunger/faqs>)

[2] ([http://www.irinnews.org/Photo/Details/201112300839360722/A-y...](http://www.irinnews.org/Photo/Details/201112300839360722/A-young- girl-waits-at-a-flower-sellers-stall-in-Kathmandu-Almost-half-of-Nepalese- children-under))

[3] ([http://www.irinnews.org/In-depth/77872/72/A-global-food- cris...](http://www.irinnews.org/In-depth/77872/72/A-global-food-crisis))

[4] ([http://www.irinnews.org/Report/95038/FOOD-Reduce-hunger- nurt...](http://www.irinnews.org/Report/95038/FOOD-Reduce-hunger-nurture- women-farmers))

<comment><USER13> "I don't think we are conquering global inequality. I think it's getting worse."

I'm sure you think that, but the numbers are clear, and not really under any dispute. Global inequality has been falling steadily and rapidly since 1980; it's the biggest reduction in absolute poverty the world has ever seen. You can interpret those numbers however you like, but those are the numbers.

"And the environment might not recover eventually; it might go into runaway heating and boil off the atmosphere."

Not according to the IPCC and the "scientific consensus". :)

<comment><USER15> Some believe that equality means that the gap between the rich and poor is lessened, and if that was your frame of mind, then it does seem like global inequality has risen.

However, absolute poverty is decreasing just as you said, and i think that ought to be the real measure. Who cares if the richest of the rich is 100million times better off than the poorest, if the poorest is better off already?

<comment><USER13> This stuff is actually not as hard as you seem to be making it. We don't need all these "some believe" or "seem like" qualifirs.

First, what do we mean by "global inequality"? Well, let's break that down. We're talking about a metric measuring income dispersion, which is, yes, a measure of the gap between rich and poor. A common metric is the Gini Coefficient[1]. And instead of looking at the coefficient of a single country, if we look at the entire population, we get a metric of global inequality. Not hard, right?

Second, what have metrics of global inequality been doing since 1980? Why, they've been falling[2]!

So, yes, the "gap between the rich and poor [has] lessened". I have no idea why you or anyone else might think that it seems otherwise. Find an op-ed or column about the global economy from anytime in the past decade, and you've got a good chance of it either talking about how real incomes in the West (ie, the global 1%) are stagnating, or how real wages in China (ie, the global 99%) are booming. There's really no way this could happen and _not_ result in a significant reduction in the gap between the rich and poor. And indeed, that's exactly what's resulted. (And to tie it back to a perennial HN favourite, the mechanism by which this has happened - an unprecedented reduction in global inequality and a massive reduction in absolute poverty - is exemplified by Apple and Foxconn.)

(You're also right that we _could_ have a reduction in absolute poverty even as global inequality increased. But that's now what _is_ happening.)

[1]: <http://en.wikipedia.org/wiki/Gini_coefficient>

[2]: I'm resisting supplying citations because a quick Google search will turn up, literally, _pages_ of results. Still, if you want one image, this one[3] isn't bad.

[3]: [http://media.economist.com/sites/default/files/cf_images/200...](http://media.economist.com/sites/default/files/cf_images/20040313/CSF979.gif)

</comment></comment></comment></comment></comment></comment><comment><USER16> It will be interesting to see how China's single-child-per-family experiment plays out. That decision alone might very well trigger a downfall both in economic and cultural terms.

<comment><USER17> Or they may find the technological holy grail to deal with it. I truly have my hopes on China deciding to spend their growing wealth on making the next decades better for all, rather than sinking it into non-renewable energy and consumables.

</comment></comment><comment><USER18> This is non issue, if needed, nation state can produce arbitrary number of children.

<comment><USER15> a nation state that can coerce its populace into having an arbitrary number of children is not one where those children would like to grow up in...

<comment><USER18> ...and nation state with 90% old people is? BTW im just claiming this is not issue. if need arises for fixing this there are known solutions (it is very easy to reproduce). I dont understand this hype and urgency about aging of europe. Every once and then this headlines appears for some reason.

</comment></comment></comment><comment><USER19> Please prefix the pundit neocon's name to these types of submissions.

Linking to David "Bobos" Brooks is the political equivalent of linking to goatse.

Not to pass judgement, but if Brooks ever manages to tap out anything less than utterly wrong and contemptible, I'm quite certain someone else said it first, only better.

<comment><USER20> I don't know about the rest of the people here, but I'd be interested in hearing why you think Brooks is so contemptible.

<comment><USER19> Unrepentant war monger.

If you really want to get worked up, watch one of his tete a tetes with Mark Shields on PBS (if they're still doing that). I'm surprised Brooks has the brain power to breathe.

Anyway. Is it really too much to ask submitters to prefix their links with the celebrity neocons name?</comment></comment></comment>


Complete list of games playable through Nvidia's GeForce NOW - <AUTHOR> https://gist.github.com/vjanssens/03391d8ca791d3356b071a1d8b6311e2 <comment><AUTHOR> Nvidia released GeForce NOW to the general public today which allows users of low-end devices to play games on Nvidia's servers in high quality. Their site lacks a complete list of games, so this list might be handy for some.</comment>


Pleasent C: it's good, actually - <AUTHOR> https://text.causal.agency/003-pleasant-c.txt <comment><USER2> Correct headline is spelled "Pleasant" \-- typo in submission.</comment>