The Humanities Are in Crisis - <AUTHOR> https://www.theatlantic.com/ideas/archive/2018/08/the-humanities-face-a-crisisof-confidence/567565/?single_page=true <comment><USER2> Previously: [https://news.ycombinator.com/item?id=17840090](https://news.ycombinator.com/item?id=17840090).

</comment><comment><USER3> I received what is essentially a humanities degree -- a math degree from UW in the College of Arts and Sciences -- in 1990. I loved reading Shakespeare, studying Philosophy, etc... and became a member of Phi Beta Kappa. Later I got a PhD in Computer Science, but I always cherished and recommended getting a liberal arts degree. Most afternoons in UW's Red Square you would encounter a myriad of street preachers, protestors, activists of all colors and stripes -- it was the kind of environment where your views would eventually be challenged. Debates were often out in the open and you better leave your straw men and ad hominem rants at home. It toughened me up and even altered some of my views. That is the way it should be.

Things have changed a great deal since then. Much of the liberal arts and related fields have been hijacked by the "social justice warrior" types. Free Speech is almost dead on campuses. Classic liberal and thoughtful progressive views have been overrun by those seeking to silence anyone who has an opinion that deviates from PC culture. Students are now indoctrinated into becoming "professional victims" and endorsing "identity politics" and its ilk. Ironically, in the push for diversity (an important goal) there ends up being very little intellectual diversity at all -- humanity professors think in complete lockstep with one another. Outrage and offense is the new badge of honor. Being "triggered" from "micro-aggression" is the new currency. Students are sheltered and protected from anything that they may offend them -- in the end the become intellectually weak.

I haven't visited Red Square in a long while -- but I doubt you see the same crazy speakers that once frequented there. Why would would any thoughtful young folks who thought "outside the lines" even bother anymore -- students just keep their heads down and focus on getting a degree that has future earning potential. If you fight it, you risk your degree. It is a sad conclusion, the humanities are indeed in crisis.

</comment><comment><USER4> The core problem is humanities have accepted materialism. This leaves two options:

1\. Subjectivity to preserve the values of goodness, truth and beauty

2\. Deny such values exist

However, the humanities are predicated on the objective existence of these values, which is denied by either option. Thus, the acceptance of materialism necessarily kills the humanities.

<comment><USER5> College-based humanities accepted materialism centuries ago, when they got comfortable with the idea of training future clergy that could make a living in nearby towns. Travel the back roads of the U.S., and you'll see that New England, the Midwest and the South are rich with small liberal-arts colleges that began as faith-funded schools backed by specific denominations.

Humanities departments continue to operate with a vocational tilt that made sense in the 1950s (heyday of the GI Bill!) training students to earn Ph.D.s and become professors of the humanities at other, rapidly expanding institutions of higher learning themselves. In this model, which persists today, students learn the current cadences of academic writing. That is its own art form, which is fascinatingly different from all other types of writing -- and generally pretty unsuited to everyday use.

This hasn't worked out so well lately, because faculty job openings in the humanities are far scarcer than the supply of new graduates. So students hoping to make it all the way to a professorship end up stuck. As Prof. Schmidt notes in his piece, it's possible for humanities graduates to find good careers in the mainstream economy, but there are a lot of jitters about how to do so.

What's probably fueling this student anxiety (and a desire to avoid pursuing humanities majors) is an apprehension that the faculty is unfamiliar with career paths other than chasing a Ph.D. and trying to earn a faculty position somewhere.

It's actually quite striking how many anthro majors find their way to UX; English majors succeed in sales, etc. But there's no support from faculty to get there. And while understaffed career-services departments do the best they can, learning how to get here from there is much harder than it should be.

<comment><USER4> By materialism I don't mean earning a living. What I mean is the belief the material world is all that exists. We are seeing the belief work itself out in the destruction of the humanities. However, the science and engineering fields are not immune, since they all depend on the humanities for their credibility. I.e. what sense does science make if there is no objective truth? Or, why worry about engineering good quality products if goodness doesn't exist? Then it's just a matter of what everyone can get away with to get the diploma and the high paying job. Hence the high rates of cheating, plagiarism, faking results, etc.

Humanities education made a lot more sense when the subject of the humanities was believed to exist. Then there'd be reason to have many openings for humanities professors, spin off education jobs in public education, private education, etc.

<comment><USER6> > _Or, why worry about engineering good quality products if goodness doesn 't > exist?_

Why bother reasoning from our intuitions about what we want when we could just pursue our subconscious goals directly? Who needs to be convinced that they want a product to be good-quality?

<comment><USER4> > Who needs to be convinced that they want a product to be good-quality?

Many people, apparently.

</comment></comment></comment></comment></comment><comment><USER7> I got my CS degree from a small liberal arts school, while also pursuing a creative writing major. I also had the chance to perform music, act in plays, study abroad, and do research with my favorite professors. I was never given the tiniest guidance towards employable skills. I would say it was wholly an education in the humanities, as long as you count math (and why wouldn't you?)

I won't try to argue that this education was superior other methods, but I will say I think it's worked incredibly well for me.

</comment><comment><USER8> "A best-selling volume in 1964 warned that a science-focused world left no room for humane pursuits" this basically sums it up. I think non STEM degrees are what gave upper edge to the first world countries. If you observe developing countries like india where everyone just wants to become engineer or doctor, you will see very one minded direction of life. Everyone is pursuing money.

<comment><USER9> I think the issues go deeper than the degree program per se. Often the humanities are part of a liberal arts degree, which differs from other degrees not just in the major subject, but also in that it is broad in focus. Where I went to school, for example, you could get a math major from a college of science and engineering, or from the college of liberal arts and sciences. The difference was largely in terms of how much of the coursework was in major versus out of major.

I bring this up because often liberal arts degrees are predicated on an assumption that a person will be seen as more than their degree, even in the labor market. That is, someone who can complete a liberal arts degree in philosophy with good grades and the right extracurricular experiences, who has taken a lot of the right coursework, can go on to get a master's in computer science, or biochemistry, or a law degree, or MD, or learn the right skills from their employer.

What we have now is a problem where too much focus is put on certification. Employers (or their HR departments?) see a degree as a certification to do a particular skill. They don't want to try to surmise these skills from other experiences, or to train new employees in those skills, they want a box checked that says "this person can do A."

This I think is the source of this trend more than anything. It's an equating of degree major with skillset, or ability, or whatnot.

When you live in a society where having X degree is required, either by employer hiring practices or by law, as a certification of being able to do A, B, or C task--even if you do not _actually_ need that particular degree to do those tasks--you are inevitably going to see everyone want to have X degree. When you create an economic environment driven by rent seeking and regulatory capture of one sort or another, you're going to see people try to position themselves accordingly.

I think the rise in interests in MOOCs, etc., and criticism of traditional educational structures in part is a response to this overcredentialing. The irony is that the liberal arts degree, which is supposed to be a kind of happy medium, kind of has been squeezed out from both sides of that argument.</comment></comment>


Show HN: List of Curated Startup Resources - <AUTHOR> https://gumroad.com/l/KXuUaX <comment><AUTHOR> Hi HN, after trying to research various phases of a startup, I realized there wasn't a curated list or at least I couldn't find any. So I committed to make a list using notion of all the articles I could find (Ideas, MVP, Marketing, etc). It's a working progress but if you have any resources please do share so I can include them in the final product.

Thanks for your support!</comment>


Deep Dive into the Single Responsibility Principle - <AUTHOR> https://medium.com/@danielrusnok/deep-dive-into-the-single-responsibility-principle-3726c5bf736c <comment><USER2> This is actually a very clear introduction to the principle as far as I can tell, and it's nice that the sample code is grounded in something close to a real-world programming scenario (messages, filestores and logs vs the common examples of animals, cars, abstract shapes etc that are often used to model OOP principles)

There's some glaring syntax errors in the gists, which might throw new learners off the scent a bit - if your example GitHub repo really does compile and pass it's tests, you might want to copy and paste the working code directly from there.

Also OP in time you might want to work on improving your written English grammar - it's a testament to the power of the English language (more forgiving than many others), and the well thought-out article content, that it's perfectly understandable just as it is - but many phrases sound jarring to a native speaker and may lead other readers into a false negative response towards the content itself.

<comment><AUTHOR> Thank you, sir, for your kind words. The gist code is copy-paste of the files from repository except one, which is the intermediate state between before and after applying SRP. I am improving English grammar published every and I promise I will continue to improve. I am using the premium version of Grammarly which teaches me a lot.</comment></comment>


First-achievement-unlocked (VLC for WinRT) - <AUTHOR> http://www.jbkempf.com/blog/post/2014/First-achievement-unlocked

<comment><AUTHOR> This is our first beta release of VLC on the WinRT platform and is now only for x86 (not Windows RT).</comment>


Ask HN: How common is it to work on projects with no testing? - <AUTHOR> I have been working in an investment bank for the past months(my first job), and I was surprised to find out out that my team doesn't write any tests at all.<p>There is also no code reviews, you are responsible for your own code. There seems to exist a "hustle" mentality, where you need to ship at all costs, the engineers frequently work from 9am-9pm and then some weekends.
Is this common practice in the industry? <comment><USER2> Testing is valuable but my opinion of it has changed over the years.

On a new/fast evolving product I prefer to have a solid suite of integration/e2e tests and a lighter unit test suite near the edge of a server with no mocking of deps (e.g. if it uses a db, spin up a local instance). I would also test something that is non-trivial to understand or a critical dependency in the system e.g. a rules engine.

The reason being is - the code is in so much flux that the internal interfaces change constantly. In agile new requirements come along and you end up chucking a lot of the old code out of the window and wasting time.

As you move towards completion of the project and the internal interfaces shore up then increase the tests. So when it's in maintenance mode someone else can easily make modifications and has documentation on maybe why something works in a certain way

<comment><USER3> e2e is definitely a thing, but I wouldn't leave unit testing aside. For bigger applications, it makes it impossible to write an e2e for everything. But I get your point, we must definitely be smart about the testing we write and why.

<comment><USER4> Unit testing makes sense when there are some units for which you can define correct behavior. E.g. you may not know _all_ the requirements yet but if you can isolate some components that you're going to definitely need, then you can write unit tests for them. While you're still iterating about what that unit is going to do (and whether you'll have that unit at all) unit tests make little sense.

However, in quite a lot of common scenarios, e.g. a simple user-facing CRUD webapp, _none_ of the custom content functionality is expected to be stable enough, it's all still in flux (and thus any unit tests would have to change at every iteration); and all the components where from the beginning it's clear how they should work (e.g. user authentication, sending of email notifications, etc) aren't really custom, so they're already written and tested, you're going to simply use them from your framework or standard libraries.

</comment></comment></comment><comment><USER5> It's worth remembering that engineers don't get paid to write tests, they get paid to produce software that supports some business need. In most circumstances, some amount of automated testing makes it faster to reliably meet those business needs.

If you're building a lot of small, one-off tools for internal use, it may well be the case that some limited manual QA or UAT is sufficient to ensure that your work is good enough.

If you're working on larger, more complex projects that are frequently updated, the shorter feedback loop that some amount of automated tests provide will probably save time and money by catching problems earlier, avoiding regressions, and reducing the need for repetitive, time-intensive manual testing.

But in any case, your testing needs will always be highly specific to the actual nature and needs of the project.

<comment><USER6> > engineers don't get paid to write tests, they get paid to produce software

I've heard this double-standard before, and it sounds plausible at first glance, but is quite demonstrably nonsense.

1) Automated tests _are_ software

2) Engineers aren't paid to produce software (nobody would pay me to auto- generate a billion "hello world" programs per second). Engineers are paid to solve problems and/or create value. Tests solve problems (finding bugs, demonstrate usage, clarify thinking, document intent, etc.).

3) Software is a liability, not an asset. We should produce as little as needed, and delete it if possible.

4) Engineers aren't paid to perform manual testing (running commands over and over, clicking around web forms to see what happens, etc.)

<comment><USER7> > 1) Automated tests are software

Which is assumed to be free of defects because people are suckers for circular reasoning.

<comment><USER6> What are you talking about? The whole point of automated testing is to confront the empirical fact that all software tends to have bugs, so we shouldn't have much confidence that we got it right.

We can increase our confidence by trying a few examples, but only a little, since the scope for failure is so huge.

Hammering a system with thousands of edge-cases, interleavings, previous regressions, etc. can give us a bit more confidence; but takes a huge amount of time for a person to do manually. It's pretty easy to automate though, and there are a load of libraries and frameworks that make it even easier.

If we want even more confidence in a system, we can verify it against a machine-checkable specification. That's still too hard to automate in most cases.

In any particular situation we need to find an appropriate balance between the cost of increasing our confidence in the system (i.e. how much effort we're willing to spend on prove ourselves wrong) versus the cost of failure.

Automated tests (especially property checks) are so low-cost and high-yield that I find them always worth doing, unless the consequence of failure is near-zero.

<comment><USER7> What logically follows from the two statements below:

1\. "Automated tests are software" 2\. "all software tends to have bugs"

<comment><USER6> It follows that automated tests tend to have bugs. So what? That doesn't at all imply that we shouldn't use them.

You're presumably using a whole heap of software to post your comments, all of which will tend to have bugs; yet you still find it useful.

Boolean logic rarely captures the nuances of real-world situations, and the "rounding errors" accumulate at each step of such arguments, which can lead to some silly (but logically consistent) outcomes. I think you've fallen victim to this here.

In a similar way, it's a false dichotomy to think of software as being either buggy xor perfect; of testing (or any other QA) as proving brokenness xor correctness; or to consider bugginess as implying uselessness.

Notice that I framed things in terms of confidence (in a Bayesian sense) and costs; not absolutes.

</comment></comment></comment></comment></comment></comment><comment><USER8> Yes, this is all sadly common. And those traits you mention all go together!

Let's be clear, most of the software empires of the present day were built on this style. It is possible to ship software like this!

But if you do neither testing nor code review, you almost certainly have a team that thinks downtime is for losers and heroes are coding 24/7\. I believe they get addicted to the twin dopamine hits of cranking out code and saving the company from disasters that their code causes.

<comment><USER9> Let's be clear about something: Their CODE doesn't cause the disaster. The continued performance of known bad practices cause the disaster.

<comment><USER10> Their code because of bad practices can indeed cause a disaster. Misplacing a decimal in finance can mean millions lost. It doesn't mean they are less capable coders, it means that like the rest of us, they're human.

</comment></comment></comment><comment><USER11> > The engineers frequently work from 9am-9pm and then some weekends. Is this > common practice in the industry?

Yes, quite common. I've been a software engineer in the Investment bank industry for about 15 years, worked at various hedge funds, brokerages and asset management firms in Boston, NY and recently in San Francisco.

Just 1 out of 6 firms I worked at had any kind of test driven development. In my experience, the lack of testing is not from a "hustle" mentality. It has more to do with the fact that the Fintech space in general, and investment banking in particular always lags behind in technology and processes. In companies that I tried to incorporate some sort of unit tests and TDD, the push back always was "We don't have time in the project timeline for writing tests. There is a QA team that will do that." Either the benefits of tests in software development process hasn't been "sold" to the IT Managers, or they are completely unaware of it, coming from a traditional waterfall methodology.

Another thing that's been the driven of this workflow is that traders and portfolio manager routine so some sort of un-scalable automation for their workflow. I once worked with a Bonds trader who had an enormous spreadsheet with over 80 tabs, links to bloomberg realtime pricing, a bunch of macros and such. The work that my team used to get was to take that spreadsheet and turn it into a database driven application that wouldn't "Freeze" or "choke" periodically as it used to in Excel.

In such situations, which is also very common and you'll likely run into it, your manager will ask you to work with said trader or portfolio manager and do the conversion. In these type of projects also I wasn't allocated any time to write tests. As soon as a portion of the application is ready, the traders or PMs would themselves run tests against a QA instance. In order to keep my sanity, I would write tests that wouldn't be in source control and wouldn't tell my manager about it.

<comment><USER12> If you're starting with TDD and unit tests, then you're doing it wrong.

You have to start with integration tests, then go down the stack if you have time and resources.

<comment><USER13> > If you're starting with TDD and unit tests, then you're doing it wrong

Source?

Please. This is just plain wrong. Integration tests also belong to TDD.

Unit tests are very focused, individual, component level tests. Suppose, I want to test my mortgage calculator logic, without bothering about caching, data storage, network IO etc. Then, unit tests are the way to go. But, if I want to test the functionality, just like an end user then Integration Tests are the way to go.

You might also use Integration tests to get your stories approved.

One might say Integration tests belong to BDD. I'll say that is just a lower level categorization. At the top, it's just TDD.

<comment><USER14> In a world of no tests, a handful of high level tests on "critical path" functionality can make a huge difference. They can also demonstrate visible wins to unconvinced stakeholders.

I don't know the OP's world, but I can vouch for starting with high level tests being a good strategy in some cases.

</comment></comment></comment></comment><comment><USER15> One of my colleagues once showed me millions of $$$ flowing through functions called `func1`, `func2` etc., both of them are over 1000 LoC. There are many SQL queries more than 100 lines long. Overall it's a huge application with extremely difficult use cases. And yes, there is not a single automated test scenario. But the company is more or less happy with this system and their manual testing. That said, it's a 20 year project and it has probably helped to earn some good money. So, if that project can be successful, any project can. There are bugs and it is has some serious issues, but it is possible to deliver something actually useful w/o tests.

I would assume, it's possible to go without automated testing when your business logic changes every now and then. Not that you necessarily should.

> There seems to exist a "hustle" mentality, where you need to ship at all > costs

I'm still to see a developer with experience in the banking industry, who would praise its working conditions. "Low"-tier workers with 25-50% developer salary usually have to deal with even worse conditions.

Remember, working 60h+ a week can lead to unpleasant health problems, both physical and mental.

</comment><comment><USER16> _Is this common practice in the industry?_

Yes, and so are burnout, abusive interpersonal behavior and the physical / mental problems that inevitably go along with such working environments.

But there's no reason you need to put up with it any longer than absolutely necessary. Do yourself a favor and find another job as soon as you feel you've had enough.

</comment><comment><USER17> Whether it's common or not, is this the right place for you? Stepping into a tire fire for your first job runs the risk of burning you out early and cementing lots of bad habits.

If you do want to stay there, there's a vast happy medium between "no tests at all" and "test driven development". Check out the "git effort" command for a list of the most-changed files in the codebase. (If it's not installed, try looking for a "git-extras" package for your operating system.)

The files changed most frequently are often also the ones most in need of refactoring and tests. If nothing else, you can cobble together a little test suite of your own and be the guy that finds bugs faster and introduces fewer new bugs.

<comment><USER10> Unless you burn yourself out once you have a hard time recognizing in the future so as to avoid it. Not saying it's healthy or correct, but there's a reason these jobs tend to attract the best and brightest. Money is a good motivator when you don't have it. When you have it you realize there are other things that can be important to you, but you've got to get the money first.

</comment></comment><comment><USER18> How common? Very, I'm sure. I've worked with and for plenty of people who focus entirely on getting a MVP to market.

To these people, testing slows you down, costs more and they often can't be convinced otherwise. Even when a massive cascade bug costs them real money, that's seen as your fault, not one in the development process.

If you're facing this, and nobody is willing to help you put it right, run away as fast as you can. This job will destroy your soul and forcibly make you a worse developer.

</comment><comment><USER19> Very common in my experience. In 16 years and 4 different companies, I've only worked on 2 projects (of dozons) that had a well established test process. The 2 projects in question were also, coincidentally, the only greenfield projects I've worked on. Almost everything else has been legacy enterprise stuff.

Most places have had some kind of review process, but not all. My current job has no tests, no reviews, and no restrictions on committing to trunk/master.

The funny thing is, I haven't noticed that big of a difference in software quality, but the places with no tests/reviews are way more productive.

Your milage, of course, may very.

</comment><comment><USER20> The problem is not about the tests but the long working hours. Do not give your time for free, the company just gets used to it and they will fire you the same when they do not need you anymore, or you get personal responsibility that don't allow you to work for so long.

When you get a better job then think about tests. Your health is first.

</comment><comment><USER21> 20 years a contracting maintenance programmer. Almost all systems I've dealt with in that time were a [https://en.wikipedia.org/wiki/Big_ball_of_mud](https://en.wikipedia.org/wiki/Big_ball_of_mud)

Along with this they have had no automated testing, little documentation, one shared dev/qa environment and in most cases not even bug tracking.

I've only worked on one "green fields" project where we did TDD, CI, dev/qa/staging environments, etc. It was a wonderful time and I truly miss it.

</comment><comment><USER22> depends a lot on the industry and what you're building. Like when I was in the web/startup space, literally nobody worked how you're describing; everyone wrote tests. Transactional systems are naturally testable. It's easy to craft or record http requests and play them back, for example.

But now I work in the game industry, and when I talk to game developers, automated testing is seen as being pretty advanced for a lot of the work. The products are extremely stateful, and automating the testing is extremely complex. Real cases that cause bugs are things like "if you stand on this specific rock and strafe to the right and perform a back-jump while z-targeting an enemy to the west you'll clip in between these two other rocks and get stuck". The testing process becomes incredibly hard to instrument, and for that sort of stuff, manual QA winds up being the more common pattern.

what's the cost of automated testing? what's the cost of manual testing? what's the cost of NOT testing? The answers to those vary from domain to domain, and from project to project.

If the cost of automated testing is lower than the cost of not testing, it's irresponsible to NOT do automated testing. That scenario is extremely common in the design of transaction-handling systems.

</comment><comment><USER23> It's pretty common outside of startups and Big Tech. My boss at my first job told me specifically to "not waste time" writing tests, which I thought was insane and I ignored him since the were having me write a system for charging subscriptions.

I'm fine with not writing tests so long as I'm not held responsible when something unexpected happens. Unfortunately for you, they are making you responsible for your own code _and_ have no form of code review.

If you can, you ought to write tests anyway as a part of your work, even if it's just a handful of end-to-end tests to ensure you don't cause anything catastrophic. And if they ask you for an explanation, just tell them that having those tests in place helps you get more work done and not waste time.

There's a chance they're going to be irrational and opt to run their own software into the ground long-term. If they tell you not to write tests, I'd suggest continue working there until you've held your position for a year and, in the meantime, keep looking out for better opportunities. The reason I say that is because if you adopt their cowboy-coding culture long enough, it will sink in with you and it will be harder for you to adopt best practices at your next employer.

<comment><USER24> The truth is that you will be blamed for the mistakes made by that manager. So it's worth taking that extra risk anyway and lying to the manager that you don't really do testing. Those who are against it are also usually unable to read code anyway :)

</comment></comment><comment><USER25> I've also experienced this in many companies. It has led me to question if tests are actually a good thing. The goal is never to write perfect code, the goal is to ship a product and many companies does this fine without testing.

Are we actually doing things too complicated and too good for the business case?

<comment><USER26> I think the key is, how bad is it if a defect gets through? And what kinds of measures (unit tests, functional tests by QA, etc.) will best prevent it? If you're making software that is fairly low-stakes, maybe it's not necessary to have any tests. If you can quickly see if there's a problem, and easily roll back, maybe tests are not necessary. If it's hard (or impossible) to really test the things that are most likely to break, maybe tests are just a placebo in that case and you shouldn't bother.

But the OP's description of his job doesn't seem to fall into any of those cases. Quite the opposite, I'd guess.

</comment></comment><comment><USER27> Testing is always necessary. Automated testing isn't. It generally requires double the manpower early on, and only saves time later on. It's a good way of throwing more bodies at a problem - someone can write tests and not step on the toes of someone else writing the features.

But testing always needs to be done. The most common way of doing it is manually. Huge companies with thousands of employees still do it manually. One company I worked for had hundreds of pages of tests to manually do, because we were building both the hardware and software iteratively. There were logs and automated tests. But the simulated environment can be flawed and logs take a while to spit out. It's more accurate and faster to do all of them manually at the end of a sprint.

</comment><comment><USER28> I've seen this before. It's not common practice as far as I can see but it does happen. I blogged about it here as 'discounting the future to zero'

[https://riskfirst.org/Evaluating-Risk#discounting-the- future...](https://riskfirst.org/Evaluating-Risk#discounting-the-future-to- zero)

Although it's sometimes reasonable to not write tests, this kind of thing usually happens when everyone is being threatened with the sack on a daily basis, rather than lacking engineering skills

</comment><comment><USER29> Tests and code reviews aren't right or wrong, but take this opportunity to form your own opinion of how you would like to work, and be sure to ask about it when you are interviewing for your next job.

Just as some would run screaming from a place without mandatory code reviews, others would run screaming from a place with mandatory code reviews.

You should be able to get close to real answers about these practices during interviews, there may be some bias towards aspiring to have tests and code reviews, but asking for details should filter out aspirations from actualities.

On the other hand, 12 hour work days, with weekends is clearly bad, and it may be hard to tell who is saying the things you want to hear, only because you want to hear it.

Having a good reason to not be in the office crazy hours is something to mention in interviews "i've heard [industry] can be crazy, but i've got a strict schedule because of X, that won't be a problem right?" Bonus points if you can come up with something plausible, true, with positive connotations and something they wouldn't get in trouble for asking about.

<comment><USER30> > others would run screaming from a place with mandatory code reviews.

Why would a peer looking over your code be so terrible?

<comment><USER29> I don't mind occasional code reviews, but I would not want to work somewhere where they're mandatory.

In my experience, mandatory code reviews lead to diffusion of responsibility; because everything is reviewed, changers take less care, even when reviewers treat at least some reviews as perfunctory, leading to preventable errors that weren't caught in review (although I've heard code reviews are supposed to catch preventable errors like this). If changers take more individual responsibility in their change, or a review is a special occasion, demanding and receiving a thorough and thoughtful review, the results seem better from what I've seen by observing groups I work in, and others I'm exposed to.

Mandatory reviews lead to excess communication, and the delays that cause. Stopping to get a review takes wall clock time, as well as the reviewer's time, and causes interruptions (or if done in batches to preserve reviewer's attention, takes a lot more wall clock time). This really breaks the glorious cycle of fast iteration. In my experience, 60 seconds of results from production is worth more than most review feedback.

In case of changes related to production issues, that means any event requiring a change needs two people to respond. Some events may require consensus, but others have clear solutions.

OTOH, it really depends on the cost to make changes, and the cost of making mistakes. In an environment where changes are expensive, and making mistakes is expensive, maybe mandatory reviews and extensive testing and actually having a specification make sense. Thankfully for me and the stakeholders involved, I don't work in such an environment.

</comment></comment></comment><comment><USER31> Quite common. And it's even more common to have lots of tests that test nothing.

<comment><USER32> This is a bit of a pet peeve of mine.

Good unit tests mock out all external dependencies. But, that sometimes means there's little or nothing left to test. Some methods are essentially glorified database calls.

I've worked in places where "write tests" is so heavily cargo culted that those kinds of tests get written. The cost is whatever time it takes to write the test, plus the amount of time it takes to execute the test, every time it's run. You also have to maintain that "test" code, and all these things have costs, which could be avoided by simply thinking about whether to write the test in the first place.

</comment></comment><comment><USER33> Engineers just end up performing the tests manually and with each release. Or they don't and it blows up somewhere down the road.

Some open source projects I've seen don't have too many tests. IIRC the source for uBlock Origin doesn't have too many tests in it. But it's small enough that a motivated maintainer can keep the quality high.

For what it's worth, I worked at a Fintech company that built trading systems for the FX marketplace. They had automated tests out the wazoo and a super thorough and on-the-ball QA team. YMMV.

I'm curious, for the projects you worked on in the Fintech space, how much money could be lost due to software glitches? At this firm I worked for they were responsible for the gain/loss if a bug caused a trade to go into an error state. So it could easily cost ten to hundreds of thousands of dollars in a few minutes during market volatility. A friend of mine had a bug slip into prod and it cost the company $90k.

</comment><comment><USER34> I'd say no tests isn't an automatic red flag. A working build system and some sort of version control are far more important than tests. I've worked on a few large (>500kloc) codebases with no version control, no tests, and no build system (that last bit is the actual shocker). In most cases, I slowly added version control, tests, and CI.

However, convincing management that things like tests (or even version control) are worthwhile can be an uphill battle, and they're right to question why you'd want to do do unnecessary work. I'd say it's quite common to skip unit/integration tests (let alone CI) anytime you're working outside of the tech industry. It's also not necessarily a bad thing.

If the project is mostly a gui with little core business logic, it's actually relatively hard to test what really matters (responsiveness, weird UI bugs on different platforms, etc). That's not to say you shouldn't, just that you should be a aware that CI only gets you so far. Most places I've worked deliberately eschewed unit/integration tests on software along those lines in favor of a very manual QA testing. It's different, but it's not wrong.

And now the war story: The project with no build system was a disaster. No tests are fine... I can live with that. No version control was annoying, but fixable for the future. The lack of a build system was really puzzling. What build system there was consisted entirely of shell scripts (and CSH, at that). I realized while trying to get things to build on a modern compiler that a key binary had not been successfully built in over a decade. No one noticed because the shell script 1) didn't fail when the build failed, and 2) touch-ed the binary even if the build failed. End result was a recently-timestamped binary that was actually last built on RHEL3. It also explained several long- standing critical bugs that the previous developer insisted had been fixed a decade ago.

</comment><comment><USER35> You're talking about an industry where software is a cost. IT is generally a cost for all those companies whose business is "something else". For me obviously this is short sighted, however, that's the way it is. I have experienced once an ecommerce company where there was a single function with something like 15k LoC, and this was handling with global variables the entire shopping flow. Untouchable and obviously untestable. I'll tell you, the same software I am quite sure it's still running and making money. So yes, it's quite common. All those tech talks, software conferences videos, best practices... And then you work on such crap, it's totally demotivating, I know the feeling.

</comment><comment><USER36> Conversely, there are plenty of organizations who rely only on unit tests and no QA team of any kind. This is bullshit. Plenty of bugs slip into production and we have thousands upon thousands of unit tests.

I for one believe unit tests are not the be-all, end-all that most of the industry has swallowed hook, line & sinker.

<comment><USER22> unit tests without integration tests are no good, and people generally don't test their UIs at all. You can have 100% test coverage of your code and still wind up with a broken system if it composes differently in production than it does in testing.

</comment></comment><comment><USER32> I've been in this kind of place once, but it wasn't web dev. I was writing calibration and test software for fiber optic switches. In that particular case, you really can't mock out the real world behavior of a specialized piece of hardware that doesn't exist anywhere else.

Granted, there were theoretically some bits that could have been tested using automation, but those weren't the bits that ever caused any trouble.

<comment><USER37> Do you mean that there was literally only one instance of the hardware in existence? No physical duplicates of it for development/testing?

<comment><USER32> At one point, there was only one instance. We got it pretty much as soon as the hardware engineers were finished with it. It didn't work very well, so that made things a little more difficult for us ( _i.e._ if something happened we didn't expect, it was difficult to decide whether to blame hardware or software).

</comment></comment></comment><comment><USER38> One of my interview questions when interviewing with a potential employer is: "describe your test infrastructure" and then ask them to dig into how they test different facets of their product. I will not work at a company that does not write and value tests. It's not worth the headaches.

</comment><comment> d--b So common it has a name:

[https://en.m.wikipedia.org/wiki/Cowboy_coding](https://en.m.wikipedia.org/wiki/Cowboy_coding)

</comment><comment><USER39> I don't work in Banking but I do work in healthcare and testing is required.

No code makes it to Master if it doesn't have any tests. We do unit tests, integration and EtoE testing with a few full-on regression tests being thrown in here and there when we do a major upgrade.

At first, I thought that maybe we were kind of overdoing it but as the codebase is expanding, I find it actually quite easier to refactor old code when I know there is a test covering that piece of code that I have just replaced.

As for the excuse: there is no time to write tests, you simply need to change the estimate of your story during the sprint planning.

Even for my own personnal projects, I write tests. It's good practice and it makes me more confident when I add a new functionnality.

</comment><comment><USER40> depends on the culture and on the goals of the company. Testing is an important best practice, but all "best practices" exist to enable the company to be successful. In your case it sounds like the work is focused on prototype projects, so "ship at all costs" sort of makes sense.

</comment><comment><USER41> Quite common in early-stage startups, 2-5 people including founders. As soon as the MVP is ready (first 3-6 months usually), they start around organizing things and prioritize stability, robustness over speed of delivery.

If the early engineers were experienced guys, a basic test suite and deployment pipeline would have been the first priority at the onset. It makes releasing frequent commits a breeze. Or else, they learn from subsequent hires to organize code, write tests and add extra processes. If they fail to hire such talent, they learn the hard way, frequent downtimes leading to user frustration and failing to retain them. It's crucial they realize this early on though, otherwise, this could lead to things blowing up pretty quickly leading to the death of the product.

Although I'd say, it sounds unusual for an investment bank. Doesn't sound like a company anyone would stick around for long. Sounds like inexperienced engineering leadership. If you're early in your career, I'd suggest looking for better companies.

</comment><comment><USER42> Here's an in-the-spirit-what-they've-said quote from 6 of my former clients & a couple bosses:

\- "I'm not a fan of testing. I'll add tests if management asks me to and budgets time for adding them."

\- "We've got 100% test coverage."

\- "We test everything."

\- "Testing is too hard for this kind of work."

\- "We over-test everything, and the test suite is damn slow."

\- "We have two test suites, the OLD one and the old one. Neither of them can be run reliably, and trying to get them to work is gonna take more work than just coding up an untested solution."

So in my own personal experience, I've 50% pro-testing and 50% without much testing. Personally I'm pro testing. That being said, I'm not such a zealot that I'll impose my views on others. When I'm in charge, if there weren't tests before, we'll start adding them for sure.

</comment><comment><USER43> What do you care if it is common for? Just start improving the situation. Set up Continuous Integration, add high-level smoke checks to catch the simple silly things, then make sure to always create a reasonable set of automated tests for whatever new you build. Does not have to be TDD to give benefits.

</comment><comment><USER44> Pretty common, though it depends a lot on the company, industry, how tech focused they are, etc.

A company who doesn't care much about tech won't build tests or have code reviews. And if their team is small enough, you probably can't blame them for that, it'd be difficult enough to keep up with client/company demands.

There are also an awful lot of programmers whose skillsets haven't really changed for a decade or so, and companies with this sort of team probably don't use much in the way of automated tests. Then again, there are quite a few of them that don't even use version control, or a staging site.

And yes, there are places where that hustle mentality is in play too. Often startups whose team falls in the above two categories.

But as said, it depends on the industry and company.

</comment><comment><USER45> My project (that I'm currently trying to get away from) is a large project that has been cobbled together over many years from many different teams both internal and external.

In the beginning everything was done to get something shippable and now that the project has shipped it is a monolithic monstrosity. Several devs have made an effort to infuse unit testing into the project but they always fizzled out because estimated dev time never included testing and so if a crunch happens now then the first thing that is dropped is the testing effort. I have learned a lot from my project however it's a lesson in how not to do things.

I will say that code reviews are heavily enforced. So we at least have that.

</comment><comment><USER46> Automated testing is just the question of your own style. What do you like to do more: debugging the problems or try to write a lot of testing code upfront and before the actual code.

Long hours are about work and pay. Never let the sense of guilt into it. It is not related to the 'quality'. You've got certain value of throughput (how much stuff useful for the client you can make per hour), and that's it, that's your value per hour. You don't increase it by working for more hours. Divide the pay by your de-facto hours (if you want to take more of them), see if it's a good deal for you.

</comment><comment><USER47> Unfortunately, that's the case in most small IT shops. It might be a large bank but I bet the programming team is small relative to other depts. It is just expensive to hire someone to test code. Most general managers don't understand that programmers need help testing code. From their point of view, programmers need to produce error-free code. It takes a strong IT manager to make the case of why new code needs to be tested after a programmer delivers it.

So yes it's common but you could make the case for unit testing and that will make your life a lot easier.

</comment><comment><USER48> It's more common in enterprises than you would think. Remember, automated testing is a fairly new concept. Some of these applications and developers have been doing it the same way for 15 years.

</comment><comment><USER49> > _the engineers frequently work from 9am-9pm and then some weekends._

Marginally related:

* Chinese Devs Using GitHub to Protest 996 Workweek (9am – 9pm, 6 days/week)

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

* 996, GitHub, and China's digital workers rights awakening

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

</comment><comment><USER50> We've open sourced our integration tests for our API: [https://github.com/serpapi](https://github.com/serpapi)

However we've really little unit tests.

There is balance between what tests are useful and which are not. Testing for sake of testing can be counterproductive. However in your case, it seems there is no reason to skip some form of testing or code reviews. Some companies have just bad practices.

<comment><USER51> One problem I've found with integration tests exclusively is that you end up having very little incentive to write modular code.

</comment></comment><comment><USER52> an effective alternative to writing coding tests is to automate the comparison of output data between old code -vs- new code using same set of input data ... this is valid when the initial few prod deployments had people manually confirm the output data was as expected

I worked in a global investment bank for many years on very large teams building systems responsible for processing hundreds of billions of $ in real time trading transactions where this approach not only worked it facilitates extremely productive use of software engineering talent

We also published prod data tapped and published from various points in our data processing pipeline which was subscribed to by QA prod-parallel which did the burn in of all new code ... it was fed live prod data and output of QA was compared to prod output in real time

I created a fuzzy match process which gracefully handled gradations of data match when faults where encountered when comparing data feeds from prod -vs- QA ... this allowed people to focus on chasing down the data diffs and not wasting their time writing coding tests which would have been very quickly obsolete

</comment><comment><USER53> I've worked in banking projects with no automated tests. You end up manually testing only what you think might break with new code. The stakeholders expectation is that things might break once in a while as long as you can fix it.

For me testing at its most basic level is kinda like insurance, you might live without it but it helps a lot when problems arise

</comment><comment><USER54> It is very common. But it depends upon who leads the team and how many resources they have.

When I hire a new developer, I always have them read TDD and Clean Code. Even if they don't get it right away, I aim to get them to pause and think about it.

Some quick software that was written in haste could be running over a decade. And they might be stuck maintaining it

</comment><comment><USER55> In 20 years I've never been in a project where tests were written rigorously. In fact, in the majority of projects there were no tests at all.

I don't think this is completely wrong though. The technological landscape moves so quickly it may not make sense to build some types of projects as if those were going to last 20 years.

</comment><comment><USER56> best situation I was in, we had a conference/group communications tool. Had a 'bot army' where each bot jumped around in the group space, turning mic on and off and texting. Wouldn't release until 100 bots could go all night and neither the client, server nor media node had problems.

That was a solid product!

</comment><comment><USER57> Quite common in consulting. There's no hard requirement for automated test coverage but typically we have dedicated resources for integration and UAT testing throughout the build phase of a project.

Code reviews are rare too. Often times you'll be the sole developer working on a particular component of a solution.

</comment><comment><USER58> I think the hustle mentality is a different issue, and I would be very hesitant to conflate the two or to entangle them in some way. It is unfortunately common, in my experience, however I hope you are looking for something else.

In my experience (20+ years of writing software professionally) I've never built an automated test. I've never used an automated test.

My preference is to write code and push it straight to production without even debugging it. tested afterwards, certainly, but if you're in such severe doubt that you're going to ruin the system, you need some serious code review.

My strong belief is that you cannot test your code into goodness, that is something that only a person can evaluate. By making myself better at coding, by not relying upon something else to make my code good for me, I am way more efficient than I could be otherwise. Given, this may limit the types of projects that I engage in, and certainly changes the project flow. However, when I look at my productivity as compared to others, I don't find any problems in my method.

Only human eyeballs can find some problems, despite how many cases you throw at something with automated testing.

<comment><USER59> > In my experience (20+ years of writing software professionally) I've never > built an automated test. I've never used an automated test.

That has to be quite an outlier. How do you find teams and managers that accept working like that? What's the failure rate of bugs found in production, and how much value at risk are we talking here?

I've written plenty of systems where automated testing was infeasible or useless .. but we always did manual testing before shipping.

(At the other end I've done IC design where if a mistake isn't found it's another £25k at least plus staff time to do a re-spin, so _obviously_ we had automated tests with near 100% coverage)

</comment></comment><comment><USER60> As a consultant who often comes in to fix broken projects after the team who built them has moved on? Pretty much universally true. I'll often start a test suite that covers the parts I'm fixing, but I have yet to come across a client project where I said "Wow! This has a great test suite!"

</comment><comment><USER61> This is very common in the web agency world, where budgets and hourly rates intersect at a place where there's hardly enough time to build out features. Testing is seen as eating up time that could be better used getting through the backlog.

</comment><comment><USER62> Tests are not terribly common in the games industry (at least in the traditional AAA space). Code is still reviewed, but it's brisk.

This is probably because the product involves shipping a box and then never looking at the code ever again.

</comment><comment><USER63> Personally, I don't do tests on my projects, it's a weak guarantee in my opinion. I prefer formal proofs... Working on a language for automatically managing the same.. Gothub.com/onchere/whack

</comment><comment><USER64> Engineer? Huh. In Mechanical Engineering, they use stress-strain curves to determine if components can handle the load. ie, they test.

Software engineering is often a lie. Sorry, but it's not engineering.

</comment><comment><USER65> It is very common. But the money is good, isn't it? :) If it isn't then you are missing out on the only real benefit of working in the finance industry.

</comment><comment><USER66> I've been programming professionally for 19 years.

I've been given permission and time to write tests for 9 of those years, at only 2 out of 6 total companies.

</comment><comment><USER67> > the engineers frequently work from 9am-9pm and then some weekends

Ironically, this could be because they have no tests...

</comment><comment><USER68> Yep from my experiences so far it's very common, and can be an uphill struggle to inspire change.

</comment><comment><USER69> How old is this company? How old is the department?

</comment><comment><USER70> Developers who don't write tests are lying to themselves about the quality of their work.

Without tests - automated, UI, unit or otherwise - you really can't evaluate your quality metric.

</comment><comment><USER71> 0 lines of my company's code has tests

</comment><comment><USER72> Depressingly.

</comment><comment><USER73> DevOps? Fix it on the production line mentality.

</comment><comment><USER74> I have been in some, with disastrous results. I think it happen in startups so often than I mostly blame the downfall of them to _not testing_ culture.

<comment><USER75> This is a very developer-y thing to say.

I read a book written by a brand marketer a couple years ago. He dissected about two dozen big companies that failed and, guess what, every one was due to poor brand marketing.

<comment><USER76> People tend to see flaws within their area of expertise, for better or worse. A developer is likely to say the problem is due to how software is made, while a brand marketer is likely going to mention poor brand marketing.

<comment><USER75> Indeed, we're paid to be experts in our area of expertise (by definition), so we _should_ see more flaws there. The key is not to go overboard by declaring that our area of focus is all that matters.</comment></comment></comment></comment>


Ask HN: What programming languages to teach kids under 12 years old? - <AUTHOR> What programming languages would be beneficial for kids under 12 years old?<p>Links to resources would be greatly appreciated. <comment><USER2> Kids(and anyone without the preexisting motivation to try the harder problems of programming, which would include most adults too) will want something with a lot of immediate responsiveness and simple failure modes. This rules out languages needing "build systems" of any kind, languages that require hooking up a "foobar library" to do anything but console output, and languages with obscure error messages and ample means of shooting oneself in the foot.

HTML/CSS mixed with a little bit of JS is roughly equivalent to learning BASIC these days - you can throw something on the screen quickly, and add bits of functionality from there. Since errors throw exceptions, they're pretty easy to understand, and with the newer HTML features there's tons of room to grow into different domains. Plus there's a zillion resources for JS coding out there.

A good alternative, if the kids in question are not old enough to care about the prestige factor of "real" languages yet(an issue as you get near the teen years), is Scratch: <http://scratch.mit.edu/> It reduces syntax to drag-and- drop while retaining some key concepts that bridge the gap into more powerful languages(conditional branches, named variables, and list manipulation)

<comment><USER3> I totally agree that html/css with js and maybe even some basic php if they are up for it is the way to go.

Sure html and css aren't languages, but couple them with javascript and a complete novice can make quite a few dynamic pages (read programs) in an afternoon.

I think one of the most important elements for introducing young children, or really anyone, to programming is providing the ability to build a complete interactive program almost immediately. This can definitely be accomplished with a few html tags and a few lines of js.

Alternatively, if you have access to a licenses for it I would recommend initially starting them out in Visual Basic Studio. It strikes me as a good balance between immediate buildableness and a easy environment to learn the basics of loops, strings, if/then, for/do, etc. Maybe a week or two in vbs and then switch them over to js.

While I have no qualms with languages like ruby or python, the call for them to be used as introductory languages seem misleading. While you can learn to build a stand alone program in them in a week or less, I get the feeling that a static box program is not going to be that exciting for most 10-12 year olds today (obviously this same problem exists for vbs)

My feeling is that to most children computers are two things, the internet and video games. Building your own video games immediately (outside of flash which isn't a terrible suggestion) is somewhat out of reach for most beginners. But building web pages, and pretty interesting ones at that, is very accessible for anyone once they get the syntax down. In truth you have to get relatively far into ruby or python before you can understand how to display a page you've build or get to very much interactivity.

</comment></comment><comment><USER4> At 9 I learned Basic.

At 10 or so I learned Pascal.

My programming finally took off around 12 when I learned C and Assembler.

I think it's important to point out that no programming language is "too hardcore" (well, maybe assembler) for a generic 12-year-old. They can learn anything.

With that, I would suggest a combination of HTML/CSS/Javascript for the quick results and Ruby for the fun and elegance. Then let them learn whatever they feel like. If they don't feel an impulse to go learn this stuff by themselves after learning 1 or 2 languages, they're probably not interested anyway.

<comment><USER5> I have to agree, probably the only kid who cut grass to buy a C compiler (Turbo C FTW!). I think I was 14 when I started writing C.

I was pissed later that summer when I installed FreeBSD only to find out these things were free.

Most of learning to program is motivation and patience in my estimation.

<comment><USER6> Nah, I remember saving to buy Microsoft QuickC for Windows when I was 12 or 13. Good times, those.

</comment></comment></comment><comment><USER7> Scheme. Here's a good article on this very subject, and the benefits of Scheme as a learning language:

<http://www.trollope.org/scheme.html>

Linked from Paul Graham's essay _Beating the Averages_ :

<http://www.paulgraham.com/avg.html>

In a nutshell, the advantage to Scheme is that there is almost no syntax for kids to get hung up on, they can jump straight into learning computing and solving problems.

And depending on how far they go with it, they'll learn some of the more powerful programming techniques like recursion and continuations.

The book referenced in the article is The Schemer's Guide:

<http://www.schemers.com/tsg.html>

Two other good learning books for children are probably _The Little Schemer_ and _The Seasoned Schemer_.

Racket is an easy, free, open source environment to get started in:

<http://racket-lang.org>

or install the package 'plt-scheme' from whatever Linux distro you're using.

<comment><USER8> Seconded. Writing the card game 'war' might be a fun challenge: <http://docs.racket-lang.org/cards/index.html>

</comment></comment><comment><USER9> If I were 25 years younger I'd like to be introduced to Processing (<http://processing.org/>). I say that because my interest in programming developed because I wanted to know how how to draw interesting patterns on a screen; and I liked the mathematical aspects of that sort of program.

I think the answer in your case will similarly depend on the interest of the kids. Is the question for a general school class or for a few kids with particular interests?

<comment><USER10> I totally agree. This is what processing is for. Even though I program as a job, a few hours with processing put a smile on my face; this is really what it used to be like. It's fun.

</comment></comment><comment><USER11> Hackety Hack is trying to accomplish this: <http://en.wikipedia.org/wiki/Hackety_Hack>

<comment><USER12> Thanks for mentioning it. (I'm the maintainer)

I have to mention that there are still some bugs, since we're pre 1.0. These should be fixed in the coming weeks, though, 1.0 should be out for Whyday!

</comment></comment><comment><USER13> Scratch[1], because its very easy, provides immediate feedback, is fun, educational and at the end of it they will understand fundamental programming concepts like variables, conditional statements and loops. Its also a visual language, so it will be immediately more appealing to kids than text, which is, lets face it, extremely boring.

[1] <http://scratch.mit.edu/>

</comment><comment><USER14> [from the other thread] There's LOGO if you want to go old school with turtle graphics:

<http://www.cs.berkeley.edu/~bh/logo.html>

<comment><USER15> <http://edu.kde.org/kturtle/> \- KDE4's version of LOGO. One of the advantages is that you can select language of commands - English, German, Polish and so on, so if your kid doesn't speak english it doean't mean it can't program easily.

</comment></comment><comment><USER16> Something like a C64 would be nice. That's how I learned but I'm quite much a visual and spatial person. YMMV.

The C64 had a BASIC that is easy to learn, immediate evaluation for trying things out and failing fast, and direct control of various graphics (text mode, bitmap mode, sprites). And you could do all kinds of

Someone suggested HTML+JS but I think that a simple raster display is much easier to grasp than CSS layout or vector graphics. Pling: a pixel goes bright. Plong: a pixel goes dark.

First you want to have something on the screen and then you want it moving. Coordinates conveniently introduce you to numbers and basic algebra. If you want to do crazy things, you can POKE the hardware directly.

I can't think of anything this simple in 2010.

</comment><comment><USER17> Well, if you want to get a kid hooked on programming, or at least grab his/her attention quickly, you should also keep the coolness factor in mind: how easy is to create something impressive and how you can promote some algorithmic and/or analytic thinking with it. With that considered, I'd suggest:

\- Python or Ruby: Their syntax is intuitive (don't mention significant whitespace though ;), they have lots of libraries to quickly deal with graphics, games or the web, they're well documented without idioms that would be encountered early on and could confuse a kid.

\- BASIC. I started out with it on an Amstrad CPC when I was 6 or 7. Interpreted, interactive procedural languages just feel natural to kids that age. I also learned that GOTO isn't necessarily bad (really, it isn't), and I also understood why functions are better than GOTO at a glance (spaghetti code didn't look neat or cool).

\- If he/she's playing a game with a scripting language involved (like WoW with Lua scripts), try going that way. Most such languages are pretty simple, user friendly, plus results are directly visible. Exciting!

\- Lego Mindstorms. One word: awesome. No, two: perfect.

\- C is a little advanced, but if (s)he's interested in the inner working of a PC or a high-level data structure, it's probably one of the best ways to get down to it. Not recommended for absolute starters.

Basically, avoid high levels of abstraction and abstract concepts. A kid under 12 will probably have a hard time contemplating functional languages (although learning recursion at that age is a must). Also, if you're considering shell languages, I'd recommend Windows Powershell over bash/tcsh/etc. at least for a starter.

</comment><comment><USER18> I think it depends on the age.

If he/she is 9-10-11 I think a fun combination could be a Lego Mindstorm robot that is controlled in C. You don't have to learn them pointers from the start, just let him mess around with the basic stuff such as data types and functions.

I think you should focus on results; getting a robot to do stuff could spike his/her interest because its 'cool'! A command line window might look dull.

</comment><comment><USER19> SmallBasic by Microsoft. It is intended to provide a foundational understanding of programming. Comes with a nice kid friendly IDE

<http://smallbasic.com/> <http://msdn.microsoft.com/en- us/beginner/ff384126.aspx>

</comment><comment><USER20> I really don't think it matters what langauge, as long as they can compile and run code.

Most of us probably started with BASIC interpreters, so easy and readable code is obviously not a prerequisite. What BASIC interpreters did tend to do well was allow you to write a few lines, then run it and have it do what you said.

To answer the question then - I think any non-compiled language would be fine. I think things like Python is probably the best, as you're not required to program in an OO style, or in a functional style - just write lines, and they'll work.

Once the kids are interested and know a bit about how programming, sure, then teach them proper style. The important part is getting them to realise how to formulate thoughts in a structured manner - once you've done that, forming them in a different structure doesn't seem too hard.

</comment><comment><USER21> The most important thing is to help the kids stay motivated. This happens if they have little successes. Now is the question: What is a succes to a 10 years old? Is it number printed out in command line or is it something colorful, maybe in a web browser? Personally I wouldn't recommend things like C, Assembler - the need month to leave the command line. My recommendation would be HTM/CSS - for a 10 years old this like programming - and then moving Javascript (obvious for the browser) or Python (Pygame and other fun stuff).

Remember, the most important ingredient to learning something is fun. If you got you kid started and it like what it is doing, it will choose the right programming language on it's own.

</comment><comment><USER22> It really depends on the kid's interest level. If the kid is highly interested in learning how to program, most languages should be fine as long as you are there to help guide them.

If the kid doesn't really care, you might be able to spark interest with some sort of novelty, but they would probably get more out of it if you waited until they were older.

I was about 8 when I asked my dad to teach me how to program. Since I was interested and motivated, all he had to do was show me how to get started, and give me his old college textbooks. If I had lacked motivation, I imagine some more prodding on his part would have been effective, but if I had lacked interest, I don't think I would have learned much at all.

</comment><comment><USER23> Have a look at [http://news.squeak.org/2008/10/28/squeak-learn- programming-w...](http://news.squeak.org/2008/10/28/squeak-learn-programming- with-robots-now-free/)

</comment><comment><USER24> I asked a similar question a while ago, for a 13 year old: <http://news.ycombinator.com/item?id=428095>

Got a lot of great answers.

<comment><USER25> Can you report on what works and what does not?

Specifically, I'm interested to know whether Javascript in the browser is good enough, or too difficult to use in practice.

<comment><USER24> Actually, my brother gave up before even trying (at this age "passions" are sometimes a very passing phenomenon).

I'd recommend pygame over web development. Making a video game is much more fulfilling at that age in my opinion. Ask any 12 year old "do you want to make a video game or a website?"

For an older kid (~16), web development with APIs such as Facebook can be interesting too, because (s)he'll want to brag about it to his/her friends.

<comment><USER25> Thanks!

I really like the Facebook app/games idea, since current video games set the bar way too high for any individual working alone. Making "Pong"-type of games will probably not impress anyone these days :)

</comment></comment></comment></comment><comment><USER26> "Guido van Robot, or GvR for short, is a programming language and free software application designed to introduce beginners to the fundamentals of programming. GvR runs on Windows, Macintosh, and GNU/Linux, in a variety of languages. It's great in both the classroom and the home as a way of introducing people to the basic concepts of programming."

<http://gvr.sourceforge.net/>

Then on to python.

</comment><comment><USER27> Teach them HTML and CSS. Once they've mastered that move on to CFML (using either open source distro) which are just by now just more powerful tags. Once they've mastered that move on to JQuery and pretty soon they will be quickly building useful stuff that keeps them motivated.

</comment><comment><USER28> Alice[1] may interest them. It teaches the very basics of programming without having to put them through the boring initial "Hello world!" experience right off the bat.

[1] <http://www.alice.org/>

</comment><comment><USER29> Google App Engine is not a language, but it is an environment where you can make a "hello world" web-page from scratch without much code... and it hosted and ready to show his/her grandparents out of the box.

</comment><comment><USER30> @chipsy Agreed completely as far as HTML/CSS. That's what I started with when I was 9. It's a great, easy, and extremely useful foundation to build on later when they want to write more involved scripts.

</comment><comment><USER31> <http://teachingkidsprogramming.com/>

<comment><USER32> The useful content appears to be links to <http://wiki.smallbasic.com/> and <http://extendsmallbasic.codeplex.com/> ; though I didn't watch the video.

They use a sucky framing policy where they frame the smallbasic wiki whilst displaying their own ads. This makes me instantly distrust the domain holder - however the apparent writers are working with kids doing programming (and appear to have married since they started the site) as [http://blogs.msdn.com/b/socaldevgal/archive/2010/06/17/teach...](http://blogs.msdn.com/b/socaldevgal/archive/2010/06/17/teaching- kids-programming-after-school-class-lessons-learned.aspx) attests.

</comment></comment><comment><AUTHOR> Thank you all. Please keep 'em coming.

</comment><comment><USER33> Lego NXT

</comment><comment><USER34> Logo?

</comment><comment><USER5> I'd recommend Microsoft Small Basic <http://msdn.microsoft.com/en- ca/beginner/ff384126.aspx>

It has a GUI which children will expect, runs out of the box on Windows which most kids will have, and allows them to easily interact with the GUI.

The other really nice thing is that as they progress they can use the full .NET runtime library so there is a lot of room to grow with out having to switch languages.

The only real downside is having a kid grow up like this: [http://www.dailymotion.com/video/xdwn4e_java-4ever- microsoft...](http://www.dailymotion.com/video/xdwn4e_java-4ever-microsoft- net-vs-java_shortfilms) [.NET vs. Java trailer] youtube took it down :(

<comment><USER35> If you're not afraid of Microsoft I recommend Kodu <http://research.microsoft.com/en-us/projects/kodu/> My kids literally beg me to be allowed to program with Kodu. It's very visual and very X-Box friendly.</comment></comment>


India authorises sale of electric vehicles without batteries - <AUTHOR> https://www.electricmotorengineering.com/india-sale-of-electric-vehicles-without-batteries/ <comment><USER2> From [https://www.indiatoday.in/auto/latest-auto- news/story/morth-...](https://www.indiatoday.in/auto/latest-auto- news/story/morth-allows-the-sale-of-electric-vehicles-without-batteries- everything-you-need-to-know-1710727-2020-08-13)

> The amendment will allow OEMs to sell batteries separately or with > subscription models, and will also encourage private players to join in as > well, boosting the grass-roots of the electric ecosystem.

So it's about allowing competition in battery providers and allowing battery leasing. This is a good move because not only does it open up the industry and hopefully drive overall prices down, but it decouples the prices of vehicle and "fuel", making it easier to compare directly with petrol-powered vehicles.

Also, by incentivizing vehicle designs with removable (and thus swappable) batteries, it makes taxis and other high demand use cases more practical without needing widespread fast charging infrastructure.

<comment><USER3> Better place, An Israeli startup tried electric cars with battery swapping and failed miserably.

So, decoupling battery from the car and allowing better competition in the battery space might fly. Car makers need not be bothered by the battery tech and can just focus on making good electric motors, since most of the car parts are from other vendors anyways.

However, the decoupling might not be all that rosy as Musk has demonstrated that safety is best achieved with total vertical integration. Even Tesla tried battery swapping but gave up.

This might work really well in 2 wheelers though. The existing bike manufacturers won't have to retool their factories by much to replace the engine with a motor and the batteries can be probably swapped in and out of the under seat space or something like that.

<comment><USER4> I am inclined to agree with you.

Removable batteries for cars has a LOT of bulk and weight to deal with. More a "service interval" like action rather than a daily event. Still handy to have but not nearly so much incentive in the market.

But for motorbikes and scooters, maybe it could work. Especially small city scooter(125cc equivalent) work.

Mind you, I am picturing a dystopian future whereby all the UberEats-like delivery scooter people keep getting their batteries stolen...

edit: streamline

<comment><USER3> Theft is a major issue and all anti-theft measures will result in increased cost. One possible option is for the battery manufacturers to make the stolen batteries useless by short circuiting them or something like that. So there is total deterrence against theft.

<comment><USER5> I wonder how much it'd cost for them to license a tiny part of the low- frequency radio spectrum? The one for BBC Radio 4 covers most of the country with a single transmitter for example, using this old-school technology you could report your battery's serial number as stolen (with the appropriate authentication) and the company would broadcast a signal to short it out. This would be much harder to defeat than an internet-based solution I think.

<comment><USER6> It's trivial to defeat with a faraday cage.

<comment><USER5> Not if you want it to actually fit in the socket of a car or bike.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> This is actually a really great direction.

Imagine - a software and hardware standard developed for batteries that allows generic installation/communication between the vehicle and the battery pack.

And the realization that EV's may be multi-decade investments (and need to be high quality to last) if the batteries are replaced each decade. Electric motors don't wear down with kms like petrol motors do - how often have you seen luxury cars wrecked where the interiors lasted a lot longer than the driveline (pretty often i.e. BMW Audi)?

Why shouldn't people be able to buy high quality interiors and put new batteries in them.

</comment><comment><USER8> Why was there a regulation in place preventing this in the first place? I don't get it.

<comment><USER9> How does it pass safety regulations without an integral part of the vehicle? How do they publish performance data if it can't move on itself?

Not that those are insurmountable obstacles, but a law that says "You can't claim your vehicle does 200 miles on a charge if it doesn't include a battery" or "You can't claim your vehicle is safe in a frontal crash because the battery absorbs some of the energy except you're not including the battery" don't seem unreasonable.

<comment><USER10> Can't you just design/test it with OEM batteries, but allow the end user to buy it without the OEM batteries?

<comment><USER11> That's pretty much what this law allows now

</comment></comment></comment></comment><comment><USER12> This is nice, if the battery spec is standardised and 3rd party battery makers can directly supply to the end users; not just to the OEMs. Barriers to entry for power delivery systems should be brought down as well incl. Smart Power Grids so that startups can enter the space in order to improve power delivery to the end users, at the end of the day economics of owning an EV in India should be favourable for the consumer to invest in it.

</comment><comment><USER13> India currently has a law forcing the scrapping of all petrol and diesel vehicles after 15 years of manufacture. [https://www.financialexpress.com/auto/car-news/cars-older- th...](https://www.financialexpress.com/auto/car-news/cars-older- than-10-years-to-be-scrapped-govts-new-scrappage-policy-how-it-will-affect- you/1294836/)

This is unnecessary as it will force perfectly usable vehicles to be scrapped and it would come at a huge cost to the environment.

Ideally it would have been good to allow this change for internal combustion engines as well so as to allow ICE cars to swap out their engines for more fuel efficient engines.

<comment><USER14> 15 year old cars in India are tinboxes, with very little margin for safety. No airbags for eg. Maybe once we actually start manufacturing cars that are safe, we can turn this off after a decade.

<comment><USER13> You can still buy new cars off the lot right now without airbags or any safety features. And of course, trucks and commercial vehicles rarely come with these safety features in any case.

Also, this scrapping law applies even for vehicles with all safety features.. including from companies such as Mercedes, BMW, VW etc.

I would think that it makes perfect sense to scrap vehicles - no matter how young/old, if it seriously fails an inspection or if the pollution levels from the vehicle is too bad - and there are existing "fitness" tests for this, and so why scrap vehicles which are well maintained?

<comment><USER15> I feel like in practice people will just find ways to skirt around the law. Who's gonna scrap a perfectly good BMW.

<comment><USER13> The new law that is being put into motion requires that all petrol and diesel vehicles be scrapped in 15 years no matter their condition. So if you have BMW in mint condition and serviced regularly - but it is 15 years old? well, tough luck, it won't be allowed to ply on the roads.

[https://timesofindia.indiatimes.com/auto/miscellaneous/govt-...](https://timesofindia.indiatimes.com/auto/miscellaneous/govt- proposes-scrapping-of-vehicles-older-than-15-years/articleshow/70401198.cms)

</comment></comment></comment></comment></comment><comment><USER16> Can someone help me understand how this will help the adoption when they still have to buy the expensive batteries

<comment><USER17> It will allow companies to compete above their scale if they don't own huge battery operations, and probably force standard battery interfaces / easy customer install. That could make swapping batteries practical depending on the design.

<comment><USER18> Considering that the ruling party is BJP (equivalent to US Republicans), this move will directly help Ambani & Adani.

There won't be any tight competition or open interface, it'll be a monopoly by the two business groups who support him the most.

<comment><USER19> > Considering that the ruling party is BJP (equivalent to US Republicans)

There are many things wrong with the BJP, but they are not really equivalent to the Republican Party. This is a lazy comparison at best, disingenuous at worst. Their economic, environmental policies and even social issues are completely different than the Republicans.

<comment><USER20> Yeah. The Modi government/BJP is equivalent to right wing authoritarian governments around the world. Tories in the UK, Netanyahu's government in Israel, etc.

The Republican Party is on its own little island far far away from any other normal political party in the world. For example, the Republican Party is the only major democratic political party in the entire world that denies the existence of anthropogenic climate change. There are major right wing political parties worldwide that may claim the costs of doing anything exceeds the benefits or that we need to wait for better solutions, etc but no major party denies the basic scientific fact of it happening the way the Republicans do.

There is also other stuff like the prevalence of young earth creationism, the overt religiosity, the lack of any economic principles (e.g. just see their rhetoric on deficits when there is a Democrat in charge vs what they do when they are in charge) etc that sets them apart from major right wing political parties worldwide.

<comment><USER18> > lack of any economic principles (e.g. just see their rhetoric on deficits > when there is a Democrat in charge vs what they do when they are in charge) > etc that sets them apart from major right wing political parties worldwide.

You literally described six mismanaged years of BJP in India

They did EVERYTHING which they opposed during Congress's time

They opposed FDI when in opposition And now they approved FDI in everything including defence manufacturing

There even was a site called modilies.com containing all such listing of things he opposed as CM which he is doing as PM

</comment></comment></comment></comment></comment></comment><comment><USER21> I got a chuckle out of the photo they used to illustrate the story.

</comment><comment><USER4> If they can do this for one highly complex, many moving parts, integrated product.... do it for phones.

And standardise recycling while you're at it.

</comment><comment><USER22> We need an open source, modular, convenient swappable battery + BMS design. Something that end users can pick up and drop in their vehicle of choice.

Something like the Gogoro battery, but with flexibility for larger vehicles.

</comment><comment><USER23> Sounds rational since existing car owners prefer to covert to EVs [https://www.bharatmobi.com/faqs/](https://www.bharatmobi.com/faqs/)

</comment><comment><USER24> Off topic, but why not a battery standard for all cars that will make charging almost instant by switching them just like we do with toys?

<comment><USER25> Swapping a battery is simply a lot more complex than charging it.

Renault tried it with the Fluence in Israel, it stopped. The Zoé has been designed to have easy battery swaps but it's not used.

Tesla did some demos in the past but they didn't explore more.

However Nio still believes in this solution, with proprietary batteries, so if they are very successful in China some others may try again.

<comment><USER26> Actually in Indian market the primary target audience i believe is 2 and 3 wheelers, which have smaller batteries and shorter ranges. China has already converted most of such fleet to electric. Due to lack of capability in producing batteries locally in India as well as geopolitical issues hampering China imports and dependency, this is one policy designed to make adoption cheaper.

Indian ICE manufacturers never had the vision to create an EV industry at home, they are very reactive in nature. Only Tata, Mahindra have some capability and most of the 2 wheeler manufacturers were importing almost all the important components from China.

</comment></comment></comment><comment> 867-5309 "excluding" may have been more appropriate than "without"

</comment><comment><USER27> Now I can drive my Tesla around with a hydrogen fuel and fuel cells.

<comment><USER25> Why would you do that though?

<comment><USER28> Why not?

<comment><USER25> Hydrogen is expensive and not convenient for cars.

<comment><USER27> Batteries are ~$3/KWH. The natural gas that hydrogen comes from is only $.50/KWH.

<comment><USER25> What about the hydrogen charging station?

<comment><USER27> Modify existing gas stations to supply hydrogen instead.

<comment><USER25> I was thinking about the cost of hydrogen fueling stations compared to electric fast chargers.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> How long before we have cars exploding because someone, somewhere, tried cutting corners and jerry-rigged a DIY battery in their car to save some money?</comment>


Halfway between a plant and animal. What is it? - <AUTHOR> http://en.wikipedia.org/wiki/Elysia_chlorotica

<comment><USER2> Taken right from the Wikipedia page: "Kingdom: Animalia." I'd say that pretty much clinches it!</comment>


Postel's Law in Development - <AUTHOR> https://flak.tedunangst.com/post/Postels-law-in-development <comment><USER2> This was a difficult parse, for being so short.

> Postel's law, also known as the robustness principle, states that we should > all be friends and try to get along.

No.

> It's also occasionally harmful.

No.

> Lain wants to add chat messages to activitypub in pleroma. I think this > could be cool, so I wrote some code for honk. Two implementations of the > same concept? We're gonna need some serious robustness, on principle.

What or who is Lain, what is activitypub, what is pleroma, what is honk, where did 2 implementations come from, what does serious robustness mean and what principle does it apply to? (if Postel, is the a redundant "principle" statement?).

> I could relax the parsing requirements slightly and accept it.

Then you pass on an empty mediaType when you know that's incorrect for the protocol? That's your problem, not his or an issue with the principle.

In that grueling "hour" you could have told your friend to fix their implementation, because you're going to make an assumption and it may have a mismatch in special cases. That's the story that could have been told. Instead it's "Postel's Law can hurt because I move fast and break things".

</comment><comment><USER3> Inherent in Postel's law is that you hold received messages to a lower standard than those you emit. Using your live receiver code to validate your output is incorrect, then, because you're testing against the wrong standard.

The usual workaround for this is to have a control flag for the receiver that specifies whether it should accept nonconforming messages. When testing a transmitter, run the receiver in strict mode. In live operation or when testing the receiver, run it in lenient mode.

</comment><comment><USER4> Reminds me of how we subverted Postel's Law to uphold Postel's Law [https://medium.com/pageup-tech/update-on-driving-client- resi...](https://medium.com/pageup-tech/update-on-driving-client-resiliency- how-we-enforced-postels-law-by-violating-postel-s-law-7cd51bf15baa)</comment>