Kent Beck: "I get paid for code that works, not for tests" (2013) - <AUTHOR> https://istacee.wordpress.com/2013/09/18/kent-beck-i-get-paid-for-code-that-works-not-for-tests/ <comment><USER3> But we don't write tests to check if our code works. We write tests to be able to change it in the future with certain degree of confidence that we don't break anything and - if so - what exactly.

There are other techniques which can give similar confidence, but tests are the easiest one.

<comment><USER4> I agree with your assessment that the primary reason we write unit tests is to be able to quickly make changes in the future without fear of breaking something: You do some extra work today so that you can save a tiny bit of work (and worry) tomorrow, and over time that accumulated future benefit outweighs the penalty paid today.

However, many in the industry forget that this is the underlying reasoning, as seen just two days ago here on this site. Read through the top-rated comments on this post: [https://news.ycombinator.com/item?id=13119138](https://news.ycombinator.com/item?id=13119138)

They describe an emergency situation where a single "3" needed to be changed to "4" ASAP or people would lose their jobs, and everyone's applauding the gatekeepers who insisted on significant refactoring and the creation of additional tests before the change could be approved.

I agree with those who say those improvements should maybe have been demanded immediately _after_ the fire was out, but those who would have delayed the firefighting out of blind allegiance to the rules seemed, to me, to have forgotten that the rules are there to serve the programmers (particularly, their ability to quickly ship working code), and not the other way around.

A rule that's failing to do that should be changed or ignored.

<comment><USER5> Everything in moderation.

<comment><USER6> That's rather extreme.

</comment></comment></comment></comment><comment><USER7> I'll put the question to the other readers:

How often do you find, despite having written tests, that there is some bug in your software? And how many of those times did you think that you should have considered it beforehand, rather than that it would be impossible to foresee?

In my experience the most useful tests are the ones that came from some unforeseen bug, which was then fixed and a test case built around it, so that it wouldn't get "unfixed".

The least useful tests are the ones for cases you know not to invoke, because they are obvious. Like how you know when you divide by a variable, you know it can't be zero. So you make sure it can't be zero, making the test case a bit moot.

<comment><USER8> Perhaps I'm just an outlier, but I think every time I've gone in to write tests for my code (usually post-testing rather than red/green testing), it's rather quickly invalidated some assumptions I made when writing the tests.

"Oh yeah, that's going to need to be thread safe."

"Oh yeah, that might be nil. Rather frequently."

In my experience, testing has been much more beneficial as an exercise of my mental model of the code and its interaction than for refactoring. But to that end, I can think of quite a few times that I've been _very_ grateful for a unit test suite while I did a large refactoring.

<comment><USER9> I agree, tread safety and race conditions I got hit a lot, other than that test coverage provided a lot I guess

<comment><USER10>
      > tread safety and race conditions

I feel like this comment wouldn't be out of place in an F1 thread.

</comment></comment></comment></comment><comment><USER11> People get too hung up on the question "to test or not to test" instead of asking the question "where and when should I test".

I started my career writing iOS clients, and the obsession with TDD was baffling. 80% of my code was usually either UI or simple Core Data manipulations, while the last 20% was mostly API parsing and a touch of business logic. I wrote a few tests for parsing corner cases or business logic, but they never really gave me any confidence or helped with refactoring, instead taking up time and adding overhead whenever I made changes. I supposed I didn't have enough coverage to get the benefits, but what tests would I write for my UI? What tests would I write for simple Core Data queries (which is assuredly unit tested already)? What tests would I write for my parsing libraries (which are already unit tested)?

Then I started working on the (Python + Flask) API backend, and tests were self-evidently necessary. Python is dynamically typed, which can result in lots of corner cases when doing simple data manipulations. Python is interpreted, which means the compiler/IDE won't warn you about syntax issues without running the code, and you can't catch even the simplest logic errors without running the function. Most importantly, the API's entire job is translating data, inputs are in the API parameters or database, and output is the JSON. It's a perfect function, and tests were obvious. I wrote something like 600 in a week, then used them to make some major refactors with confidence.

What I learned from those juxtapositions was that unit tests and automation are invaluable in certain circumstances. Specifically _any system that creates machine-readable output_ like JSON, populating a database, or even a non- trivial object factory should be unit tested like crazy. Any system that creates human-readable output, like views or changes in an unreachable database (something like an external API or a bank account) needs to be human- tested, there's just no way around it.

<comment><USER12> Mostly anything a human can test, a machine can test even if it requires end- to-end UI-automation integration testing. If there's a test that's part of the suite that is worth running every time something changes, it's simply a matter of cost: How much time will automation take, how long will the automation last, what is the cost of maintenance, is that less than the cost of a person doing it manually?

People tend to be bad at forecasting these kinds of costs, its easy for prejudice for or against test automation to cloud one's ability to be impartial in the forecast.

</comment></comment><comment><USER13> As someone who worked as dev (4yrs) later moved as tester (4yrs) and finally returned to dev again.

Here's my personal thoughts/experiences:

\- Testing job is underestimated.

\- In General, Developers considered superior to testers.

\- What makes Tester position difficult is 'repetitive tasks' . Yes you can automated tasks, but you still need to do some tasks that can't be automated. These are manual & repeated tasks, often boring.

\- Some developers are so lazy. for ex: while testing we found 'python syntax issue!'

\- Management thinks testers can be replaced once they automated everything. Obviously they push for this.

\- I know for sure, there are projects with passionate developers but no-one can really take care of their testing side.

\- Dev underestimate/avoid unit-tests & rely on testing team to find basic issues.

<comment><USER14> Don't blame the devs completely. Not many bosses give out raises or bonuses for good testing. Or even for not shipping bugs. Being a hero and fixing the bug you shipped gets much more visibility and accolades.

<comment><USER13> I'm not blaming all devs, but most devs :) But i guess there is wide-spread believe with Managers/bosses, testing is secondary to development.

I've seen testers, who find bugs and also fix them but they don't get credits they deserved.

</comment></comment></comment><comment><USER15> And that's a fantastic observation.

When you get out a bit of the IT world, you'll find that people who demand software want to receive something: software. They bought an app, they want the app. Simple as that.

If you are good enough to have your code working without tests, good. If you don't need documentation, good. If you paint your walls with use cases, good. All that doesn't matter, if you deliver the app you were hired for.

And if your app doesn't work... well, everything you've done doesn't matter either. Because you were hired to deliver an app.

Of course tests are good, documentation is good, self-documenting code is good. But only for the IT. For non-IT people who's contracting you (you can be your company, too), he just want the app. The software. Working.

<comment><USER16> Sure, but they also expect that the 'non-software' bits work OK/that you've thought of not only that the software works now, but at some point in the future as well.

If you tell people "You told me you wanted software, not MAINTAINABLE software :-)" they'll say "Aren't you a professional? Shouldn't you just be doing this stuff? Isn't it just implied?"

So yes, they're paying for 'the software', but the tests are part of it, maintainability, as well as things like security and scalability are things that should be considered as well as just whether the software 'works'.

<comment><USER15> Yes, I do agree that it's expected. But I also bet that very few non-IT people have the slightly idea on what it requires. So, let's say after 6 months that any contract ended, they'll need some update.

They'll go to the market and ask how much it costs for someone to include a new functionality. They'll get $100, $90... and your bid. You know you have all those tests and documentations properly done, then you can charge just $10 and win. And you can charge $70 and also win. It's up to you, because you know how hard/easy it'll be.

And if the software was made by someone else, who charged less in the beginning? You don't know how worky it'll be, so you have to charge a bit higher, like that $90.

So, from the client perspective, the difference from a well tested software and a barely-works one is just the initial price. After all contracts are over, they (remember, non-IT) can't know if the new functionality has a fair price or not. And who didn't developed it can't be sure about the maintainability, either.

Having tests (and everything else) was good for you, for your future. But, in general, the client didn't knew all this. He just paid for the software...

</comment></comment></comment><comment><USER17> > "If I don't typically make a kind of mistake (like setting the wrong > variables in a constructor), I don't test for it."

But for those of us who work on a team, it's far more complicated than that, and you have no idea who might be touching your code in the future.

<comment><USER18> "When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong."

I think addresses that point quite nicely?

<comment><USER19> Not necessarily. In many firms the turnover rate is significant enough that you have no idea who will be working on your code in six months or so. Unless you are on the sort of team that never changes, you can't really use your past experience as a guide for a future team's strengths/weaknesses.

<comment><USER20> If your goal is to test every possible scenario now or future I think you'll eventually find it's not realistic.

</comment></comment></comment></comment><comment><USER21> I asked one time to my teammates why we had test. They just didn't answer. For them it was just a dogmatic approach.

That doesn't means that you should not have them. But you at least should be able to answer that question to be able to evaluate the value that they bring and how much tests do you need and where.

</comment><comment><USER22> I like Beck's vision for the future, and I agree that we should keep experimenting in order to learn which tests tend to work and why. But we don't need to do it all manually -- we can use computers to automate and speed up such experiments. To that end, I've started a project to automatically generate unit tests from C++ source: [https://github.com/dekimir/RamFuzz](https://github.com/dekimir/RamFuzz)

Right now the generated tests are pretty superficial and silly, but the key is that they are randomized. Because of this, we can run millions of variations, some of which will prove to be good tests. Right now I'm hacking an AI that will pick those good instances from many random test runs. If it works, we'll be able to simply take source code and produce (after burning enough CPU cycles) good unit tests for it. This will be a huge help in letting the human programmer only do "enough" test writing -- the AI will take care of the rest. Additionally, the solution can be unleashed on cruft code that no-one dares touch because of a lack of tests and understanding.

(Yes, there will be a business built around this, but that's for next year. :)

</comment><comment><USER23> It doesn't make sense to write no tests at all but I _understand_ this sentiment based on problems with testing that I have seen before:

\- 1. Test infrastructure is too complex. If I have to create a bunch of config files, obey a questionable directory structure, etc. before I can even write my test case, there is a problem. There should be very little magic between you and your test front-end.

\- 2. Test infrastructure is too lacking. It is also a problem to have too _little_ support. There should be at least enough consistency between tests that you can take a look at another test and emulate it. There should be clearly-identified tools for common operations such as pattern-excluding "diff", a "diff" that ignores small numerical differences, etc. depending on the purpose.

\- 3. Existing tests should not be overly-brittle. Do NOT just "diff" a giant log file (or worse, several files), and call it a day; that means damn near _any_ code change will cause the test to "fail" and create more work. Similarly, make absolutely certain when you develop the test that it _can_ fail properly: temporarily force your failure condition so you know your error-detection logic is sound.

\- 4. Tests should not be overly-large. Do not just take some entire product and throw it at your test, creating a half hour of run time and 40,000 possible failure points just because it _happens_ to cover your function under test. It is vital to have a small, focused example.

If your test environment has problems like these, I fully understand the desire to balance time constraints against the hell of dealing with new or existing test cases, and wanting to avoid it completely.

And if you're in charge of such an environment, you owe it to yourself to devote serious time to fixing the test infrastructure itself.

</comment><comment><USER24> I think the biggest problem with TDD is that there are two types of code, trivial and non-trivial.

I think testing trivial code is a waste of time and does nothing but improve coverage numbers.

When you think about a non-trivial problem to write tests, you don't always know what the final code will look like. Maybe you forget an edge case or some small detail in the requirements that will cause you to restructure the code and approach the problem in a different way. In which case, you now need to re-write your tests. You might as well just write tests around the final version.

<comment><USER25> What happens where trivial code later needs to grow? What happens when trivial code is invoked by non-trivial code and you need to make a change?

If it's truly trivial code, you should be able to test it trivially, so I'm a little unsure of why this becomes a make-or-break issue for some people. Pretty sure more time and energy is wasted determining if code is trivial and needs to be tested versus just testing the damned thing ;-).

<comment><USER26> Trivial code does not grow, it gets replaced. If the replacement is non- trivial, test it. If it's trivial, don't. Anyway, you've saved some useless tests that would need to be rewrite on the first change.

Trivial tests may be trivial, but they are numerous: their need grows exponentially with code size. And they generate almost all the false positives you will get.

</comment></comment></comment><comment><USER27> I'm glad to read that. In my opinion, the problem starts when tests become a religion, e.g. forcing to put unit tests everywhere, no matter if it makes sense or not: just put tests, in order to justify that if whatever goes wrong, you can use the excuse of "it fails, but at least it is test covered".

In some case unit testing is necessary, e.g. for ensuring that a hash function works exactly as defined. However, there are other cases where unit testing is absurd, and black-box API tests or automated tests could do a better job on error coverage. As an example, imagine the Linux kernel filled with unit testing everywhere: plenty unit testing religion fun, but no guarantee of getting anything better, but a risk of new bugs because of the changes and increased code complexity.

<comment><USER28> You don't understand what for are tests. Tests don't give a shit if your code works today - you write them to freeze today's state of code (doesn't matter, if your code correct or not).

<comment><USER27> I do. My point is that not all code is of same kind. E.g. for the case you point, I do extensive unit testing for synchronous code with inputs and output/s that does significant stuff, in order to avoid breaking past things with new changes. You can check that I try to honor what I say, here: [https://github.com/faragon/libsrt/blob/master/examples/stest...](https://github.com/faragon/libsrt/blob/master/examples/stest.c)

However, there are cases where unit testing is not suitable, or it is not a guarantee, or it is an additional risk, e.g. event-driven or low level stuff, multithreaded code, etc.

<comment><USER28> Multithreaded and async code needs tests even more! It's much more difficult to test, but it doesn't mean such code shouldn't be tested. Where code is complicated, chances to create unintended changes are higher.

<comment><USER27> Sure. I was arguing against "religion" ("put unit tests everywhere, for every single thing"), not as "anti tests". There are many kind of tests.

</comment></comment></comment></comment></comment><comment><USER29> "I get paid for code that works, not for maintainable code."

Ah, I get it. _That_ explains the piece of s--- I'm looking at right now.

That said, the title might be sensationalist, but I agree with the holistic sentiment of the text.

<comment><USER30> [https://xkcd.com/1513/](https://xkcd.com/1513/)

</comment></comment><comment><USER31> There are so many unneeded tests being written I can't even begin to point them out. Here's an example: [http://entulho.fiatjaf.alhur.es/notes/the-unit- test-bubble/](http://entulho.fiatjaf.alhur.es/notes/the-unit-test-bubble/)

I've seen dozens of GitHub repos with a "tests/" directory that only contains tests for the constructor and ignores all the parts that should be tested. You don't need to test a constructor, this is stupid. If your constructor is not working none of the other tests will -- BUT HEY, your constructor is working, it is not hard to see it.

</comment><comment><USER32> One benefit of testing is that it can highlight whether your abstractions make sense. If you need to pull in the world to test a small module then probably your dependencies are not right and what you thought was a unit turns out to be more than that.

When I am writing a module/function, I tend to continuously think of how this can be tested, which helps me design better abstractions.

For example if you're writing a class that uses a socket read/write, when testing you probably need to mock them. If you weren't planning on writing tests then probably you'd have ended by having the methods embedded in the class itself as read/write/close when those methods don't belong to the class and should be in another module called Socket that inherits a Socket interface. Now that you have a socket interface it becomes easier to test your class by passing a mock Socket interface.

</comment><comment><USER33> The title quote is a bit out of context...

> I get paid for code that works, not for tests, so my philosophy is to test > as little as possible to reach a given level of confidence (I suspect this > level of confidence is high compared to industry standards, but that could > just be hubris). If I don't typically make a kind of mistake (like setting > the wrong variables in a constructor), I don't test for it. I do tend to > make sense of test errors, so I'm extra careful when I have logic with > complicated conditionals. When coding on a team, I modify my strategy to > carefully test code that we, collectively, tend to get wrong.

</comment><comment><USER34> Mixing up business and tech.

On the business side, you don't get paid for code at all. You get paid to make something people want. The fact that you're using programming to do that is inconsequential.

On the tech side, you're not delivering anything unless somebody, somewhere can test it, even if only one time.

So yes, you are getting paid for tests. In fact, that's the only thing you are getting paid for. The nub of the question is what the tests look like and how many you should have.

<comment><USER35> It's like a carpenter saying "I don't get paid for load testing table tops, I get paid for durable furniture."

<comment><USER34> Absolutely. There's some subtle wordplay going on here -- frankly it's probably done on purpose to draw out a lot of public discussion.

</comment></comment></comment><comment><USER36> The point is that there is a limit to testing. And some people go way overboard with it. You'll never get 100% coverage. It's simply not possible.

Now, that doesn't mean you should not test. It means you should understand the limits of unit testing and test what is important as best as you can. Most every software engineering class at universities will cover this in-depth.

<comment><USER37> Of course you get 100% coverage if that's your goal. SQLite for example is a big project with 100% coverage:

[https://www.sqlite.org/testing.html](https://www.sqlite.org/testing.html)

If you want rock solid software you need to spend the time to properly test it.

<comment><USER38> well, not at all times. [http://cve.mitre.org/cgi- bin/cvename.cgi?name=CVE-2015-3416](http://cve.mitre.org/cgi- bin/cvename.cgi?name=CVE-2015-3416)

<comment><USER37> Great, you've proved that 100% test coverage doesn't mean 0% bugs. The actual question is whether there is a significant difference in reliability in software with 80% test coverage compared to software with 100% coverage.

<comment><USER38> at which point we first need to talk about the type of coverage ... tree coverage or line coverage (or something else?)

<comment><USER39> In the case of SQLite, it's 100% branch coverage and 100% MC/DC coverage: [https://www.sqlite.org/th3.html](https://www.sqlite.org/th3.html)

</comment></comment></comment></comment></comment></comment><comment><USER40> For me, the takeaway from that article is this:

> Different people will have different testing strategies based on this > philosophy, but that seems reasonable to me given the immature state of > understanding of how tests can best fit into the inner loop of coding. Ten > or twenty years from now we'll likely have a more universal theory of which > tests to write, which tests not to write, and how to tell the difference. In > the meantime, experimentation seems in order.

Indeed, we still "don't know" how to test—more generally, and given the abundance of methodologies and their tendency to go through a hype and dump cycle, I would say we still "don't know" how to write code in the first place.

We'll get there eventually, but for now I would take whichever approach, methodology, tools, and language that I use as having a "best before" date, and invest in it accordingly.

</comment><comment><USER41> I don't write tests for all my code. But if I'm not writing an automated test (frequently when I'm writing a single-use script, which is something I do a lot, as I'm merely a hobbyist), I still "test" my code, function by function, at a REPL.

I've long since learned the hard way that if you don't test the functions as you write them, the bugs get buried in the system, and become very hard to find. When you test your code as you write it and modify it (formally on larger projects, informally on smaller ones) this doesn't happen.

That's the advantage of tests, so I can get Beck's point: If the function is so painfully simple that you already know if it's right, (say, an accessor) just by looking, then it's not worth writing a test for it.

</comment><comment><USER42> Seems pretty simple, honestly. I've written enough unit tests to throw in my 2 bits.

Put a sane, normal value test. This will pass unless shit's broken.

Then test edge cases. Test min, max.

Then test some impossible values. If they correctly fail, you pass.

<comment><USER43> Or, you know, write property-based tests instead, so you only need to worry about the logic and not the test values.

I've always found that if you let the author of a piece of code decide on what value that code should be tested with, he'll test for the edge cases that he's thought of (and dealt with), not the ones that actually crash production.

<comment><USER44> On the other hand, if you ask the author to think of the edge cases first, they're more likely to list them and then write code that handles them. Still no guarantee, but better than writing tests for code you just "finished".

<comment><USER43> But still, you end up with tests for what the author feels his code should handle, not necessarily what the real world is actually like.

Don't get me wrong, that's still valuable - if only for the non-regression aspect - but I feel property-based testing is a superior approach.

Write your code ("this is a function that sorts lists of ints"), write a property ("when given a list of ints, after sorting it, elements should be sorted and the list should have the same size"), let the framework generate test cases for you. Whenever something breaks ("lists of one element come back empty"), extract the test case and put it in a unit test to make sure the same issue doesn't crop up again in the future.

</comment></comment></comment></comment><comment><USER45> The key to success with that attitude:

>>I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris).

Is the humility in the parenthetical. There is a difference between arrogance and confidence.

<comment><USER46> Sounds like he'd be a team player and a great all-around guy to work with...

In reality, there's a considerable amount of respect given to people who are great at what they do, but are also humble and without the boated ego.

</comment></comment><comment><USER47> In other words "be smart, don't be stupid". Do you really need to write a test for that single expression setter?

But then again, it may be easier to just set a single round goal like 100% for test coverage. Writing that test for the single expression setter won't cost you a lot.

<comment><USER48> > Writing that test for the single expression setter won't cost you a lot.

Yeah, usually it won't cost anything to the guy who writes the test, but he is actually paid. What it costs to the business/customer/etc and whether the value added is worth of the cost is totally different matter.

I think there is clear incentive for writing unnecessary tests for certain developers - it is non-risky general work, where it is is difficult to fuck up anyway. If you are able to sell test-writing hours, what's the downside?

<comment><USER47> Difficult to even imagine a project that could fail business-wise because some developer wrote too many easy unit tests. Do you know of such cases?

<comment><USER49> probably won't fail business-wise, but will cost incrementally more for each test business-wise.

<comment><USER47> Significantly?

<comment><USER50> Depends on the business case. I don't think this answer can be generalized either way.

You can lose a business because of the heavy costs which add little value, however it is not easily arguable that a specific cost was the deal-breaker.

</comment></comment></comment></comment></comment></comment><comment><USER51> If someone posted that question on SO now it would be insta-downvoted and then removed for being vague.

</comment><comment><USER52> There are enough people in the industry who are actually paid for writing the tests and discovering the potential failures of the mission critical code, where the tests are fundamentally important.

I've had a small team nicely paid for months only to prove and document the that the product my company was to deliver won't fail in some specific scenarios, specified by the contract.

Those who don't produce the mission critical code (or believe what they produce is not on the critical path) unsurprisingly see the investment in the tests questionable. Of course, there is always a real danger of doing something "just because it is done" even if there's no real need.

<comment><USER53> I think possibly you are not quite understanding what Kent meant. Those people you mention are not getting paid for tests, they are being paid to give confidence that some software system works, they use tests to do this, just like Kent does. His point is about delivering working code with a certain level of confidence.

Meaning if tests don't increase your confidence, but simply put in to tick a box for having a test, you aren't getting paid for that (or if you are getting paid for that, someones lost sight of what they are trying to achieve)

<comment><USER52> In my specific case, that I've mentioned, the tests surely increased the confidence as they were the part of the whole process, where the results from the tests were used to modify the product in question until it was able to pass all the tests. The tests allowed to proactively "solve the bugs" which would otherwise produce much more problems if the product had been used in production without these tests.

</comment></comment></comment><comment><USER54> I happen to work in a team. So I get paid to write code that works, that other devolopers can make sense of and hack on as well. That's why I write lots of tests.

If Kent Beck is coding in a private bubble, he can do whatever he wants that makes code work.

</comment><comment><USER55> This is like saying "I'm paid for code that works, not proper syntax."

But proper syntax is what gets you code that works. You aren't paid directly for it, though. Tests are not a direct path to code that works, but they can be a big help.

</comment><comment><USER56> The full quote is a bit more nuanced and captures this, but the key to this mantra is properly defining what "works" means.

Code that "works" doesn't just mean it runs/compiles/passes CI/etc. It has to _continuously add value_. It can do this by running properly and efficiently across a wide variety of likely or infrequent conditions, as well as some exceptional scenarios. It can do this by being written clearly and not adding technical debt. It can do this by being as simple and/or as replaceable as possible. And ultimately, it can even add a final gasp of value by being easily deletable.

</comment><comment><USER57> And yet programmers wants to be held in the same regard as engineers.

[https://www.youtube.com/watch?v=0WMWUP5ZHSY](https://www.youtube.com/watch?v=0WMWUP5ZHSY)

</comment><comment><USER58> _I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it._

Which is unfortunately complete opposite of how TDD was interpreted, especially in its glory days (and in some corners, up until the present day).

</comment><comment><USER59> This is why I advocate for end to end testing of a whole system's expected behavior to augment a small set of unit tests (the unit tests are for edge cases).

Nobody needs division by zero tests if there are already guards in place so that can't happen, but it's quite helpful to have a "A goes in, B should come out" view from a client/user perspective. As long as behavior appears correct to the client and is not exploitable you're good to go.

</comment><comment><USER60> I contend that tests need cover functional and non-functional _requirements_. Everything else is to some degree optional.

Of course given no formal requirements, all that is possible are tests of the technical implementation. Regression errors will still be inevitable for customers and stakeholders, despite the "programmer" being able to claim his or her tests passed.

We need to find a way to stop kidding ourselves and find a way to test the _right_ thing.

</comment><comment><USER61> I'm not a big fan of this mentality. Writing enough tests to be bug free just isn't enough. Sure it's bug free today and that's great but will it be bug free tomorrow after a junior dev modifies it?

I'm not advocating testing getters/setters but not testing because "I don't write those kinds of bugs" can burn the next junior dev who might.

Testing is as much about finding bugs early as it is making your more agile in the future.

<comment><USER20> I submit that testing a bunch of trivial things isn't actually going to make it easier to catch bugs. I recommend this article: [http://rbcs- us.com/documents/Why-Most-Unit-Testing-is-Waste....](http://rbcs- us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf)

</comment></comment><comment><USER62> You get paid to make the best technical decision for the company/project/who ever it is that's paying you. You get paid to communicate and understand when test are needed and when they are not. Startups will probably have a lot less test than bigger companies ; unless your a security startup or something that needs a solid foundation that you can trust.

Its all a trade off that needs to be communicated to whoever is paying you.

</comment><comment><USER63> "Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. "

The problem with comments like this is that they're too ambiguous. Someone who doesn't want to spend the time to write unit tests, will use this ambiguity as a mechanism for justifying their laziness.

</comment><comment><USER64> You write tests to automate tests you would have to otherwise perform manually. That is the only reason tests exist, to automate the boring task of testing.

That's one problem with the TDD mindset. If you start by looking for things to test, you might come up with unlikely scenarios or cases that don't matter much for your user.

<comment><USER65> Or even worse you start writing code for "testability" and it becomes a bloated mess of one- or few-liner functions that are only called in one location by some other function.

</comment></comment><comment><USER66> "You get paid to write code, not tests" -My boss after telling me I should quit writing tests

I agree with Kent Beck mostly. I would add that tests can also be used to maintain invariants for future changes to increase maintainability. I just hope this quote isn't taken out of context.

</comment><comment><USER67> It is a stupid, broad statement without proper context.

It really depends on what your project is, what your goals for maintainability are and what programming language you use.

Two things about testing: \- test to confirm your spec \- if you have trouble writing tests, your design is probably flawed

</comment><comment><USER63> I first write good code. I then write unit tests to protect my code from:

a) Bad team mates. b) Future developers.

I've been burned one too many times with junior devs making cavalier changes in code they don't understand. Unit tests were THE solution for catching these changes.

</comment><comment><USER68> Just an fyi about some nuances of TDD that are overlooked based on the 60+ comments I see so far.

Most comments seem to equate:

      "regression tests"=="TDD"

... but it's really...

      "regression tests" is subset of "TDD"

I'm not a practitioner of TDD but I my understanding of its components are:

1) the _ergonomics & design_ of the API you're building by way of writing the tests first. In this sense, the buzzword acronym could have been EDD (Ergonomics Driven Development). Writing the _usage_ of the API first to see how the interface _feels_ to subsequent programmers. Arguably, a lot of incoherent/inconsistent APIs out there could have benefitted from a little TDD (e.g. func1(src, dst) doesn't match func2(dst, src))

2) a sort of _specification of behavior by usage examples_ ... again by writing the tests first. Consider the case of programmers trying to figure out how an unfamiliar function actually works. Let's say a newbie Javascript programmer wants to know how to use .IndexOf()[1] What do many programmers do? They skip all the intro paragraphs and just hit PageDown repeatedly until they get to the section subtitled as "EXAMPLES". With TDD, instead of examples being relegated to code comments _" sqrt(64) // should print 8"_ , it formally encodes the "should print 8" into real syntax that's understood by the automated test tools. (Test unit frameworks typically use the keyword _" Expect()"_ as the syntax.)

3) an IDE that's "TDD aware" because it creates a quick visual feedback loop (the code that's "red" turns to "green") during initial editing. The TDD "artifacts" can also act as a "dashboard" for subsequent automated builds alerting you that something broke.

So TDD is a "workflow" and from that, you address 3 areas: (1) design (2) documentation (3) quality assurance via regression tests. With that background, the original Stackoverflow question makes more sense: how many "test cases" do I write because it looks like I can get bogged down in the test case phase?!?

[1][https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/String/indexOf)

</comment><comment><USER69> O: my manager is the person who asked the StackOverflow question that prompted this.

</comment><comment><USER70> Funny thing is, the most frequent positive result of tests for me hasn't even been mentioned, I don't believe. The biggest benefit I got was an ongoing education about how the program I was writing ACTUALLY functioned - <USER2> me to correct my assumptions before the shit hit the fan. This isn't quite the same as catching errors, since often you still want the algorithm you wrote as you wrote it, but knowing more about what's really going on gives you a heads up to avoid future problems, conflicts, etc. Of course, you may program differently. I was always big on asserts back in the day, and two-thirds of my debugging (by instance not hours) was spent fixing asserts, and thereby learning that some assumption I was making about the program, was wrong at least some of the time. Always good to know.

</comment><comment><USER71> Tests might help you write better code.To the extent they do, you should use them.

That's like saying "I get paid for functioning software, not writing code."

Yes, you get paid for the output of the act, not the act itself.

</comment><comment><USER72> Beck elaborates on this point of view in the current issue of Java Magazine: [http://bit.ly/2g6YEo2](http://bit.ly/2g6YEo2) (loads slowly)

</comment><comment><USER73> >Indeed, since this answer, 5years ago, some big improvements have been made, but it's still a great view from a inspiring person

Such as?

</comment><comment><USER74> Writing test is like investing. You have to pick the tests that return the most reward. Simply firing shots is wasteful.

</comment><comment><USER75> I've referenced this stack post a few times too. I feel like it might be easy to take this out of context.

</comment><comment><USER76> you _will know_ when and why to write tests ... The same bug keeps coming up, you spend most of your time manually testing, you are not sure this change will break anything, or you are too scared to touch the code.

</comment><comment><USER20> Interesting comment although I don't feel like the article adds much to it.

</comment><comment><USER77> That's why you need to pay another guy to find code that breaks :)

<comment><USER78> And then, because the tester gets paid to write test, not to understand the product, you will operate with huge blindspots.

[Edit] I erased a cheap shot I took at Ken Beck. I still think the title of the article is stupid, but what the guy actually said is much more nuanced than that.

</comment></comment><comment><USER79> Why not get paid for both?

</comment><comment><USER80> The start of the comment is really out of context here. What he wrote about the team case (what most of us are payed for) is this:

When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

</comment><comment><USER81> It is a begging comment and not clear what is said beyond "create some automated tests until you feel good"

Allow me to explain:

Production use of code IS testing (manual, etc). Because it is an observation of the system state.

All of the world is testing. Every system is inherently a quantum mechanical one (ie: the observer is constantly testing the state of various systems to ascertain some level of confidence)

If you are going to test anything... then you should test the Use Cases (ie: Interactor objects). Don't have Use Case/Interactor objects that encapsulate intent? Well, you better understand it since the world, and therefore software, is all about intent.</comment>


Lulzsec Hack's PBS in Response to Frontline Documentary - <AUTHOR> http://www.nytimes.com/2011/05/31/technology/31pbs.html?_r=1&hp

<comment><USER2> I've supported anonymous like groups in their defence of wikileaks and other such causes. But I'm struggling to understand the rationale of this attack.

If you're a person who wants to defend wikileaks - don't you believe that one should be able to express one's views online without being harassed by thugs, whether they be government, corporate or hacker groups?

While I'm a big supporter of wikileaks and have donated money to them in the past, they are not, nor should not be immune to criticism or negative press.

These people are becoming exactly what they seem to hate. Leave PBS alone.

<comment><USER3> Meh. While I don't support this behavior without some sort of an understandable cause to compel them, I view the overall activities of "oh noes; posted something on your website!" and "oh noes; got yer emailz!" as an important part of boosting the immune system. Imagine what kind of shitty police department you would have if they never had any crime to pursue and just ate donuts all day? These small fries keep people on their toes just enough to almost justify security specialists and keep funding security efforts in corporations from being automatically crossed off the list to save a few bucks.

<comment><USER4> So, in your opinion, crime is a net positive because it reinforces the need for police?

<comment><USER3> No, in my opinion a system thrives when it is challenged. An immune system, a legal system, an enforcement system, or a security system. The challenges provoke adaptation. Evolution. I'm not a fan of illness, but some degree of exposure is necessary to build up the human immune system on both local and global scopes. Likewise, I'm not a fan of network penetration and security breaches, but they reinforce the re-focus that which they attack as a whole.

And note that we're talking about screwing with a couple articles on a web page and getting some passwords. Sure, that's bad, but it's not shutting down the power grid that feeds a hospital or stealing social security from elderly women. Likewise, I tolerate colds and cold season as part of reinforcing the immune system while I would probably not be so tolerant of small-pox unleashing itself across the population.

</comment></comment></comment></comment><comment><USER5> This, in and of itself, isn't particularly interesting. What is, and what doesn't bode well, on the other hand, is the possibility for groups like this to cause another flash crash or some sort of international incident.

<comment><USER3> I'm more shocked that John Markoff still has a career, when he hasn't had anything sensationalistic to tie his opportunistic bylines to since Mitnick.

</comment></comment><comment><USER6> The documentary appears to be "WikiSecrets", which the article neglected to mention. I would link to it, but cannot find an official one that works.

<comment><USER7> <http://www.pbs.org/wgbh/pages/frontline/wikileaks/></comment></comment>


Firefox 3.0 final available for download - <AUTHOR> http://blogs.zdnet.com/hardware/?p=2092

<comment><USER2> For those that jump straight to the downloads: "Downloads from FTP server will not count towards the Guinness World Record attempt for the most software downloads in a day. If participation in this event is important to you, wait for the official release."</comment>


Women Who Code (YC S16) helps female engineers level up in their careers - <AUTHOR> http://themacro.com/articles/2016/06/women-who-code/ <comment><USER3> _Women who are halfway into their careers in tech are leaving at a rate of 56%, which is more than double the quit rate of men. One reason for the high quit rate may be that women have a much lower chance of being promoted, even when they have the same amount of experience and tenure as their male peers, according to the National Bureau of Economic Research._

So around the time a lot of people have kids? They probably discover that you need to make a LOT of money to pay for daycare per kid, and at 2+ you might as well just stay home.

I'm going to go out and a limb here and say that solid support for working moms would be one of the more effective strategies for long-term careers for women. I also can't imagine that it's that easy getting back into a tech career after 8 years of being a state-at-home mom (which is about 2-3 kids, with the youngest finally in kindergarten), looking for to work for a specific 6 hours per day on school days.

Maybe SF is different, though. I'm not there.

<comment><USER4> > you might as well just stay home

But why does it have to be the woman who stays home? Why is this just the tacit assumption?

I'd love to see not just solid support for moms at work, but solid support / encouragement for dads at home: paternity leave up-to-par with maternity leave, a normalization and acceptance of stay-at-home dads where desired, etc. It's kind of amazing how prevalent the assumption is that children are mom's problem. As a guy I care about this not just from a supporting-women perspective but from a when-I-have-kids-I'll-want-to-spend-time-with-them-too perspective. This should be one of the easiest ways for men to be sold on feminism.

Somehow though, paternity leave is a second class citizen and people who talk about advancement of women mostly just talk about maternity leave benefits. Let me help! I'm happy to take care of kids while you build your career!

<comment><USER3> As someone who has taken the kids out and about during the day, I have to say that it's _awkward_. You end up being the only man in a group of dozens of women with their kids, or you are the guy at the playground sitting by himself while his kids play on it (which looks a ton like you don't have any kids to an outsider). Society, at least in most of the U.S. is frankly a bit hostile to males as the caregivers. I can't imagine what single dads have to go through.

<comment><USER5> And now you know how it feels to be the only woman engineer on a team of 20 engineers. It's awkward and sometimes hard for women engineers like me to focus on our jobs because of the awkwardness contributing to hostile work environments. And this is why it's awesome that YC is supporting Women Who Code.

<comment><USER6> Sure. Just so we are clear though, there is a huge difference between being regarded and treated as a potential pedophile/kidnapper (father at a playground) vs. simply an outsider.

[http://www.freerangekids.com/thanks-for-assuming-im-a- pedoph...](http://www.freerangekids.com/thanks-for-assuming-im-a-pedophile- just-because-i-was-out-with-my-grandson/)

<comment><USER7> I don't think "simply an outsider" covers many of the experiences described by some women in tech: Groping, sexual harassment, assumptions on getting the job on looks, over-scrutiny of their work, etc ...

This is not every woman's experience, but neither is the pedophile one. I have worked at an all girls school and everyone - parents, students, children was fine with it.

</comment></comment></comment></comment></comment></comment><comment><USER8> Is it just me or does anyone find these type of groups too career oriented? Don't get me wrong, I am a female dev and I'm all for equal opportunity and working towards supportive environment for any gender or non-gendered, sexual orientation or no orientation. I don't really find these organisations really that helpful in bringing everyone together. I'm a nerd by nature before I knew computers existed and becoming a coder just came naturally to me. Obviously it's not because I'm unique and amazing. I just grew up in an environment with a lot of freedom as a child so I wasn't limited to think or act in a certain way. Anyway I wouldn't be comfortable in a group like wwcode because looking at the blurbs on the site it's just too career oriented. I wouldn't fit in at all but that doesn't mean I don't have the same problems these women have. Just because my sex is female I get treated differently even though I don't necessarily feel either female or male inside and I'm a pure thoroughbred nerd. I don't feel like climbing the career ladder because I enjoy being the lowly dev as long as there's a bit of freedom in how I solve problems and problems are not too terribly boring. All this, yeah you're a woman, yeah you deserve to get promoted etc kinda puts me off a little bit. I'm sure it's all with good intentions but if I'm feeling like this (a woman) imagine all those males who feel threatened by us. That's why I think these type of organisations, even though they have good intentions sometimes fall short at bringing everybody together. Because in the end we all need to come to an understanding and accept our differences to have a truly harmonious society. Also a side point about people comparing computing jobs with nursing or bin lorry operators. You are comparing apples and oranges. There are factors such as money, status, education levels to consider and are different. No one is blocked from becoming a bin lorry man/woman and as a kid no one dreamt of becoming one. They add a lot of value to the society though maybe even more than some developers but that's another discussion. Ok rant's over. :)

<comment><USER9> Are you actually complaining about an increased societal focus and push for women's success at work? What exactly is "too career focused", and what would you rather see from assemblies of people who are trying to bolster women's place at work -- or would you simply rather not see such assemblies at all?

<comment><USER8> I am not saying that I would rather no see such assemblies at all. I know people have good intentions but I wish there is a bit more holistic approach to this rather than, it being just for a type of woman. It should include male, female, non-sex, people who wants kid and people who don't want kids, people with different aspirations in life, not necessary the traditional path set out such as school, work, marriage, kids etc.

beepboop2045 made a good point though about women working under female leadership. We do need role models. I just wish there are other paths being considered and talked about.

</comment></comment></comment><comment><USER10> This is likely going to be 100% ignored since I'm late to the party on this but my wife's experiences have been that true discrimination and difficulty doesn't rise until a female engineer tries to enter management. When she was "just an engineer" things were great and nothing went wrong.

When she tried to level up into management, she faced these difficulties:

\- competition from other female managers who had transitioned into the role from product management. They often times felt immensely threatened by her technical acumen and played politics to stop her.

\- Lots of pretending from engineers (never the ones she's led, oddly enough) that she "doesn't know anything"

\- Her current manager recently demoted her on his second day and told her "she should do engineering because he believes she'll do great at it and, if she can prove herself, she might be put in charge of a project and have a chance at leadership in the future."

The last one still has me pretty irked since it's recent.

<comment><USER11> isn't this a challenge for every software engineer?

it is practically a stereotype for other engineers to criticize someone else's code

it is practically a stereotype for senior software engineers to face a career plateau

and you think this was uniquely sexual discrimination? so lets give you the benefit of the doubt, of the things you described, these are issues all software engineers face.

<comment><USER12> The reality is that women face presumptions about their technical incompetence at a much higher rate than men. This is well documented and researched. [1]

Obviously male developers also get undermined by their coworkers and face career plateaus. That is reality, but it is not a binary action - <USER2> because some men face similar problems does not imply that it is an equal problem for both genders.

[1] [http://www.uchastings.edu/news/articles/2015/01/double- jeopa...](http://www.uchastings.edu/news/articles/2015/01/double-jeopardy- report.pdf)

<comment><USER11> Yeah I'm going to stick to what I said earlier, the way you phrased it almost tries to put a shield around any rebuttal.

He could have completely not mentioned the idea of gender being a crutch and it would have sounded like a gender neutral problem known to engineers.

<comment><USER10> You do have a point. I do have a male friend who is also facing a similar situation. When I commented I was emotional since it was more recent and while she was demoted without regards to performance the dude promoted 3 white guys he brought in. ಠ_ಠ

</comment></comment></comment></comment></comment><comment><USER13> It's an honor to be a part of YC S16! As an organization, we've been committed to making sure our members stay in tech and excel in the industry.

We are excited to work with our Partners at YC and further enhance the Women Who Code experience. :)

<comment><USER14> Do you agree with the recent diversity and inclusion effort at github which noted that _(6) some of the biggest barriers to progress are white women_?

[http://www.businessinsider.com/diversity-guru-discusses- whit...](http://www.businessinsider.com/diversity-guru-discusses-white- women-2016-2)

<comment><USER15> I'm not sure I agree with it, but there may be a point there that upper and middle class white women playing the victim card discredits it for those who have had more serious barriers to entry.

</comment></comment></comment><comment><USER16> I wonder how much of the balance difference is due to boys liking tech more than girls. I'd say that if you ask 10-15 year olds, who hardly think about their future, about what they do in their free time you will find equal balance on the reply "gaming/stuff on my PC". Most girls don't like it, that translates to later stages in life I guess. Never see the reports for other fields where females excel in acceptance rates. Teachers, daycare, psychology, there are plenty really.

Mind you, I'm not saying women are treated equally once they _have_ the job, I'm just not sold on this whole "only x% of tech is women!" Thing. We can probably learn a thing or two on how to treat our female colleagues, but please stop trying to fight for 50% should be women kind of causes. There are other fields where it is completely the other way around and I don't see people fighting there for equal rights.

<comment><USER17> > I don't see people fighting there for equal rights.

 _every_ time the gender imbalance comes up on HN someone makes the same comment you have.

Did you try Google? Because those programmes are trivially easy to find.

People will often make a similar comment about the lack of programmes to get women into construction or mining. But those programmes are really easy to find too.

<comment><USER16> I wasn't hinting at other programmes for women. I was hinting at programmes where men were at a disadvantage and fought for equal rights. Or even better, where women acknowledged the fact that only 20% of psychology, teachers, or whatever are men. There suddenly it isn't a problem to have the imbalance? Should we favor men in those categories over women? Just because we have fewer male teachers? So unfair! To think that women are better with children and thus hire them faster.. (Just to be sure: im exaggerating)

I do curse the fact that women who found a job in tech are handled differently but in return I would love to have front fighters for women equal rights drop the whole "we have so few women in tech" statement. I think most of that is due to the difference in what men or women have affinity with, not hiring process or disadvantages.

In other words, stop confusing amount of women in tech with equal women's rights. These are not casually related.

<comment><USER18> > I was hinting at programmes where men were at a disadvantage and fought for > equal rights.

That's exactly what DanBC was referring to. There are such programmes for nursing, teaching, and many other fields. (Although the situation with nursing is complex, as male nurses are not getting paid less than their female counterparts.)

[http://www.nytimes.com/2014/09/07/sunday-review/why-dont- mor...](http://www.nytimes.com/2014/09/07/sunday-review/why-dont-more-men-go- into-teaching.html?_r=0)

[http://www.nytimes.com/2010/11/07/education/edlife/07conted-...](http://www.nytimes.com/2010/11/07/education/edlife/07conted-t.html)

</comment></comment></comment></comment><comment><USER19> Hey @Alaina from Women Who Code here. We are thrilled to be joining the YC community and I'm happy to answer questions.

<comment><USER20> > Women Who Code is an international 501c3 non-profit organization that works > to empower career-aged women to excel in their technology careers.

Is there any relationship with the Girls Who Code organization? Because of the similarity of names it sounds as if it's a similar concept targeted at an older female audience.

<comment><USER13> Great question.

We focus on making sure our members stay in their engineering careers and excel in them!

Girls Who Code focuses on getting high school girls interested in STEM.

Our members often mentor Girls Who Code members.

</comment></comment></comment><comment><USER21> i have trouble accepting the idea that fewer women in tech is a problem. it's not that i want to discourage women -- or anyone -- from going into tech. i just don't believe in encouraging anyone to do _anything_ in particular, except what they enjoy. i'd appreciate it if someone can persuade me that the hype is true so i no longer need to feel like a black sheep. but..

for one, the fact that there are fewer women than men in any field, computing or otherwise, is neither good nor bad. the disproportionate number of women in nursing is not seen as a problem, but somehow it has become one in tech.

two, as we flood more people into professional computing, the good pay -- one of the reasons given on the wwcode website for encouraging women to enter the field -- will decrease, due to the increased supply of workers. tech is reduced to Yet Another Job, and Women Who Bgurp becomes the next YC startup.

three, the wwcode website argues that diverse teams perform better by increasing collective intelligence -- measured in what units? and when it claims that organizations with the largest representation of women leadership have a higher return on investment, how is that measured? this seems super hand-wavy to me.

lastly, the website's statement about women investing 90% of their income in their communities "when [they] make more" is not only unlikely, but is predicated on the long-term availability of good pay in professional computing, which, as i mentioned earlier, will decline at a rate proportional to the frequency with which we encourage people to enter the field.

<comment><USER22> > for one, the fact that there are fewer women than men in any field, > computing or otherwise, is neither good nor bad. the disproportionate number > of women in nursing is not seen as a problem, but somehow it has become one > in tech.

I don't agree. I think the gender disparity in nursing is just as much a problem. I think it's a significantly less tractable problem though, because I don't think the monetary incentives are there for men to enter nursing.

As for your economic arguments, I think they're oversimplified. We really don't know what the job market is going to look like long-term. We do know that the computing job market has quadrupled in size over the past 20 years, and it is a good bet that the job market can quadruple again over the next 20 years, without any loss in median salary.

Back to monetary incentives. The median salary for software engineers could be reduced by 25% and it would still be a good career choice. So there's no real reason not to encourage more people to enter the field. Nursing has a substantially lower median salary.

<comment><USER23> > The median salary for software engineers could be reduced by 25% and it > would still be a good career choice. So there's no real reason not to > encourage more people to enter the field. Nursing has a substantially lower > median salary.

That's not accurate, at least when controlling for location. Going by BLS data, the difference between RNs and software engineers is less than 25% in LA, NYC, Boston, Chicago, San Jose and probably many other places that I didn't check. In San Francisco, RNs actually get paid more on average.

<comment><USER22> It's not useful to control for location without controlling for number of jobs available. What I'm really trying to approximate is "How difficult is it to get a job making at least a six-figure salary as a nurse or a software developer?" In SF for example, there are at least twice as many software developer positions as nursing positions. So while the median may be higher for nurses, it's still harder to get a high-paid nursing job than a similarly paid software job.

[http://www.bls.gov/regions/west/news- release/occupationalemp...](http://www.bls.gov/regions/west/news- release/occupationalemploymentandwages_sanfrancisco.htm)

</comment></comment></comment></comment><comment><USER24> I spend a lot of my time and personal money to encourage high school students to pursue a field in STEM (specifically robotics), however, lately I've been having trouble convincing myself to continue due to the long term prospects of a career in STEM. As a professional software engineer at a well known software company, I can only see it as a dead end job with low status and a small shelf life due to age discrimination.

I'd be interested to hear from others who are interested in inclusion how they feel about potentially painting too rosey of a picture.

<comment><USER25> I share your feeling. I am actively seeking of moving away from the tech field. I am still trying to figure out how to do that (maybe PT MBA will help not sure). My wife who is a software engineer will also exit the tech field in few years, so will my sister.

</comment></comment><comment><USER26> I would be interested in the number of men or women who leave tech because the next promotion effectively is a promotion out of tech and into management.

What is the record like with tech companies with engineer tracks vs normal up or out? How big is the male female divide in those cases - and is the diff significant?

<comment><USER27> Half of the women who leave (so roughly 25%) leave tech fields altogether.

The numbers are fudged such that women in management are still considered as in tech. Most "women in tech" numbers that you see include PMs, POs, IT workers, Support Engineers, etc.

The male female divide is actually quite large in management. Women are promoted to management disproportionately (hypotheses include "better people skills" and a distrust of their technical ability).

"We find that senior technical women are significantly more likely to be in a manager position (36.9%) than are men (19%); conversely, men at the high level are significantly more likely to be in an individual contributor position (80.6%) than are women (63.1%)." [0]

"45 percent of women technologists felt like women were being "pushed" into execution roles, and 42 percent of women reported that women do not have equal access to technology creation roles." [0]

[0] [http://gender.stanford.edu/sites/default/files/Senior- Techni...](http://gender.stanford.edu/sites/default/files/Senior-Technical- Women-A-Profile-of-Success.pdf)

<comment><USER26> Thanks.

</comment></comment></comment><comment><USER28> If anyone from WWC is reading:

Is there a cutoff age (age > n) for participants or members?

<comment><USER19> The average age across our entire community is 30, but people of all age are welcome. We've had people from kids and teens to people with more than 30 years of experience join.

</comment></comment><comment> saiya-jin is it really true that women don't get promoted in engineering as much? that's a honest question, the only few I've met did not aspire for higher and higher positions intensively, rather enjoyed what they were doing (that could be said about most of the guys too).

I am all for equal situations for both genders, but my assumption was that we already +-have it in western societies, thus such a move would make guys actually in a disadvantage and thus be unfair.

IT is not a very cool job to non/tech people outside few top companies like facebook or google, somewhere along accountants maybe. naturally, more ambitious ones will go for jobs like lawyers (if they have no heart :)) or medicine as my fiancee did. IT is just not that sexi.

another point - if you are in your 40s, it's hard to be just developer. people move up to architecture or management, which I consider both boring as hell - endless conf calls, producing never-ending stream of powerpoints etc. not exactly why creative people came into IT in first place.

I admit other branches of engineering might look differently, no clue about it.

<comment><USER29> [http://i.imgur.com/reUNxYu.png](http://i.imgur.com/reUNxYu.png) Definitely something odd going on in computer science.

<comment><USER15> The inflection point is right about when consumer PCs (personal computers in general, not wintel specifically) became a thing. What are consumer PCs used for, when they aren't being used productively? Gaming, and kids who like games trying to learn how to make their own games (particularly in the pre-web 2.0 era... Web 2.0, remember that?). And ultimately, who was the main consumer of PC gaming? 12-25 year old boys and men.

Then you've got a decline in the wake of the Dot-Com bust. One has to wonder if the gains in the other fields of study cannibalized high-aptitude women who might have gone into CS.

</comment></comment></comment><comment><USER30> how exactly are they helping women? I am on their mailing list and it is not particularly useful. Once got interested in a "free" scholarship, contacted them, and the person tried to sell me a course for almost $10K.

It's impossible for a woman after 35 to get back in tech

</comment><comment><USER31> How does VC funding for a non-profit work? How does YC exit or recoup their investment?

<comment><USER32> It's a charitable donation - [https://www.ycombinator.com/nonprofits/](https://www.ycombinator.com/nonprofits/)

</comment></comment><comment><USER33> Congratulations Alaina!

</comment><comment><USER14> What would people think if the genders were reversed and this institution was discriminating against women and only helping men? Women have a far larger presence in other fields like biology and education, but you don't see new organizations popping up every other month to change that in favor of men.

Discrimination like this should be illegal.

<comment><USER34> The reason women dominate in certain fields is that those fields were generally seen as less important, so women were pushed into them. E.g., doctors were men, women were nurses, and there was an enormous pay and prestige difference between the two. (Hint: it did not favor the nurses.)

If you're interested in learning more, researching "pink ghetto" will get you started.

<comment><USER35> Its actually the other way around. Men face more pressure to earn a higher income than women, so more men enter higher paying careers.

1\. Women prefer to marry a guy who makes more money than her. So there is significant sexual pressure to become a high status ($) man.

2\. Men (statistically) can't marry up large income gaps. So they know that what ever lifestyle they want, they have to be solely responsible for it.

Women on the other hand have more freedom to do what they desire since men care far less about their partners income, and women have the economic security of being able to marry a higher income partner.

<comment><USER36> Men also end up working in far more dangerous jobs, which pay more. The gap in workplace accidents and deaths affecting men vs women is staggering. Over 90% of workplace deaths are men.

</comment></comment></comment></comment><comment><USER37> I don't understand this constant fight to have 50%.

There are capable women who climb ladders successfully. The other women who couldn't, simply couldn't, just like many men who couldn't.

Also, pregnancy and breastfeeding cannot be done by a man. A woman who aspires to be a mother will have to compromise on other things to be a mother, which probably will include a compromise in career.

A man who aspires to be a father will have to compromise on other things to be a father, which probably will include a compromise in EVERY OTHER FACET of his life ensuring he has a job to pay the bills for the woman and children.

Why is motherhood such a stigma? Why is career the all-important thing that EVERY woman has to pursue? Let the woman choose herself what she wants to do.

<comment><USER27> So you think that there are more incapable women than men in the world?

Women are capable of working in fields like tech through pregnancy. We have breast pumps and formula. If you're going to complain about maternity leave, why is the man not taking paternity leave to help his partner and bond with his child?

Why does it have to be the man making all of these decisions? Why can't both partners work together ot support a child?

Why is motherhood viewed in the ridiculous, rigid way that we see it today a given? The thing is, given attitudes like yours (which are emblematic of societies) you're presented a false dichotomy of "career-woman" or the martyrdom of modern motherhood.

<comment><USER37> >> So you think that there are more incapable women than men in the world?

Incapable of what? Never once did I say women are incapable of either career or motherhood. Women can efficiently do what they choose to. Juggling many roles on the other hand is hard for any human being (regardless of gender)

>> Women are capable of working in fields like tech through pregnancy. We have breast pumps and formula. If you're going to complain about maternity leave, why is the man not taking paternity leave to help his partner and bond with his child?

Who said that man doesn't want to take a paternity leave? Every single recent father I know wants to take time off to bond with the kid. Unfortunately, he can't without a cut in pay (in the US). Get this law in and you'll see so many fathers doing it.

>> Why does it have to be the man making all of these decisions? Why can't both partners work together ot support a child?

It is always a partnership. Only a partnership works. More often than not, partnership == compromise from all parties involved to WIN.

If you were a basketball watcher, you'd know that not everyone can play point guard even if they want to. Only one person plays that role and the remaining support that person. Why? So that the team wins.

In a baby-making situation, WIN = produce a healthy baby and have enough resources for its upbringing and the mother's safety.

With this definition of WIN, a man/woman who only wants selfish desires and doesn't care for the partner or the kid is a subhuman being. Sorry. You both need to be less selfish here for the sake of the kid.

>> Why is motherhood in the ridiculous, rigid way that we see it today a given? The thing is, given attitudes like yours (which are emblematic of societies) you're presented a false dichotomy of "career-woman" or the martyrdom of modern motherhood.

Fine. Do both jobs half-heartedly. Anybody who has been a successful mother knows that it is HARD. If you think it just "happens" you're badly mistaken.

<comment><USER27> >"There are capable women who climb ladders successfully. The other women who couldn't, simply couldn't, just like many men who couldn't." There are fewer women, proportionally, who "climb ladders" successfully. This implies that there are fewer capable women than men in the world.

>"Who said that man doesn't want to take a paternity leave? Every single recent father I know wants to take time off to bond with the kid. Unfortunately, he can't without a cut in pay (in the US). Get this law in and you'll see so many fathers doing it."

The mother being present is not required for a child to be exclusively breastfed anymore. Pumping is quite effective. The only argument for only the woman to be taking the time off and making these career compromises is one that views women as the only capable caregivers.

>"It is always a partnership. Only a partnership works. More often than not, partnership == compromise from all parties involved to WIN."

And this can't be done with both partners sharing in childcare responsibilities and working? The data is out there (see my other posts) to show that SAHM are significantly more angry, depressed, etc. than their working counterparts. Is this a win for the mother and the baby?

Do you think that women are incapable of "playing point guard", i.e. providing for their family?

>"Fine. Do both jobs half-heartedly. Anybody who has been a successful mother knows that it is HARD. If you think it just "happens" you're badly mistaken."

I've stayed at home with child. I know that it's hard. Being a successful PARENT is hard too, and the reason that motherhood is even harder for the majority of the people that I know is their sole responsibility as child- rearer.

<comment><USER37> >> There are fewer women, proportionally, who "climb ladders" successfully. This implies that there are fewer capable women than men in the world.

Or, they make different life choices.

>> The mother being present is not required for a child to be exclusively breastfed anymore. Pumping is quite effective. The only argument for only the woman to be taking the time off and making these career compromises is one that views women as the only capable caregivers.

Fine. Don't be a good parent. Women are not the only capable caregivers. Men can be equally good. Women can be equally shitty. Unfortunately, law treats women specially. Get this law to treat women the same as men.

>> And this can't be done with both partners sharing in childcare responsibilities and working? The data is out there (see my other posts) to show that SAHM are significantly more angry, depressed, etc. than their working counterparts. Is this a win for the mother and the baby?

Do you think that women are incapable of "playing point guard", i.e. providing for their family?

No. Women certainly can play point guard. But when was the last time you saw a woman date a deadbeat? No woman wants to date a man who sits at home....implicitly, men who are going to become a parent work (or have to work).

Women can play point guards when they start having families with deadbeats.

>> I've stayed at home with child. I know that it's hard. Being a successful PARENT is hard too, and the reason that motherhood is even harder for the majority of the people that I know is their sole responsibility as child- rearer.

It's not the mother's sole responsibility. But at least one partner has to take more care of the kid while the other partner sacrifices their social life for work. You can have men sitting at home taking care of the kid, but I don't see many women married to men like that. Care to set an example?

<comment><USER27> >>Don't be a good parent.

Nice to see where this is going.

>>Get this law to treat women the same as men.

Wrt to parental leave, that's what I've been advocating for throughout this thread. I think that the social and legal status quo sets up women as the caregiver defaults, which is harmful to women.

>>Women can play point guards when they start having families with deadbeats.

Or, men could leave their jobs and let women return to work at a more reasonable rate. You're again assuming that the male has to be the provider. Why can't a man sacrifice his current career path while his partner continues hers?

>>You can have men sitting at home taking care of the kid, but I don't see many women married to men like that. Care to set an example?

I think you've missed the point. This is exactly what I did. Both my partner and I have CS degrees from a top 10 university, and we decided that her career looked more promising.

<comment><USER38> > I think that the social and legal status quo sets up women > as the > caregiver defaults, which is harmful to women.

That's quite sexist claim.

<comment><USER37> Not really. Laws in the US default to women as caregivers.

\- Women get maternity, men don't \- Women get default custody of child in divorce, men don't \- Women get to adopt easier than men \- Domestic violence on men is ignored/laughed upon, presumably because men are not caregivers but violators by default \- Women don't have mandatory military conscription, men do (presumably because men have to be fighters and women have to be caregivers by default)

<comment><USER39> > Laws in the US default to women as caregivers.

Mostly, they don't.

> Women get maternity, men don't

Well, by definition, its only "maternity" when the mother gets it, but the federal requirement for unpaid, job-protected family leave in FMLA applies equally to parents of both genders, as does (for one example) the California state requirements for job-protected unpaid family (CFRA) and paid family leave (PFL)

> Women get default custody of child in divorce, men don't

There is no legally-specified default custody in divorce; women get custody in divorce more often because they are more likely to _request_ it. Men get custody more often when it is contested between the parties.

> Women get to adopt easier than men

AFAIK, that's true for single women vs. single men in practice, but not an example of a default in the law, since its a result of the practices of private adoption agencies, not a result of a difference in legal requirements.

> Domestic violence on men is ignored/laughed upon, presumably because men are > not caregivers but violators by default

Again, to the extent that's true, that's not an example of the law treating them differently; as a matter of law, domestic violence is equally prohibited when a male is the victim.

> Women don't have mandatory military conscription, men do

Well, no, since the draft ended and the all-volunteer force was established, _no one_ has had mandatory military conscription in the US. Men are required to register in preparation for any potential change in that policy, though, so while overstated, this seems to be the single valid example of a legal preference in the direction you suggest on your list.

<comment><USER37> > There is no legally-specified default custody in divorce; women get custody > in divorce more often because they are more likely to request it. Men get > custody more often when it is contested between the parties.

> Again, to the extent that's true, that's not an example of the law treating > them differently; as a matter of law, domestic violence is equally > prohibited when a male is the victim.

You are onto something. The laws seem to treat men and women the same.

So why is there a need for an organizations like "Women who code"? The law, on paper, treats both men and women the same right?

If your answer is that the laws are unfair towards a particular gender, then you yourself contradict the above mentioned points.

else if your answer is that "in practice" women get treated unfairly despite equal on-paper laws, that is exactly what I meant by "US laws default to women as caregivers". Men get treated unfairly in domestic and family issues.

Written law and law as it is enforced and practiced is very very different when it comes to gender issues.

<comment><USER39> > So why is there a need for an organizations like "Women who code"? The law, > on paper, treats both men and women the same right?

There are many social reasons that the situations women face in the programming might be different than those faced by men that have nothing to do with differences in law, either on their face or in practical application.

> If your answer is that the laws are unfair towards a particular gender

But its not, so that's okay.

> else if your answer is that "in practice" women get treated unfairly despite > equal on-paper laws

But my answer is not that they in practice get treated unfairly _in the execution of the law_ , either.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER40> The two sexes are not identical. Boy are you going to be surprised about what pants are hiding.

<comment><USER27> You know exactly what I mean. Arguing for the idea of "brain sex" is essentialist and ridiculous. There's nothing that makes my wife or the average woman a less capable programmer than anyone else in the field other than a consistent problem with socialization.

<comment><USER14> Men and women have been subject to different pressures throughout the evolution of our species. Its seems unlikely that this would not lead to some differences either on _average_ or across the populations.

<comment><USER27> If you can provide me with any well-done research showing that evopsych is anything besides the modern phrenology I'd be surprised.

<comment><USER14> Wow, that's a really good question. I'm fairly certain you've done a great deal more research on this than me. I had to start by finding the definition of two of the words you used. For the benefit of others who might not be as well versed...

 _evopsych - psychological traits are evolved adaptations_

 _phrenology - the detailed study of the shape and size of the cranium as a supposed indication of character and mental abilities_

My previous post was based on information from a recent study on Y-DNA which indicates a high differential in reproductive rate between men and women, with men reproducing at a much lower rate. This of course means that reproductive competition is much higher amongst men (at least in terms of successful reproduction) and might have lead to the aggressive pruning that we see in the y-chromosome. I'm also aware that competition has a heavy influence on evolution and that the sex chromosomes are not really isolated to gender specific anatomy.

Here's that study: [http://genome.cshlp.org/content/25/4/459.full](http://genome.cshlp.org/content/25/4/459.full)

I found another study (link below) on differences in personality traits across genders and culture. The authors found gender differences to be most pronounced in cultures that minimize traditional sex roles. Does this study fit your criteria?

[http://www.cin.ufpe.br/~ssj/Genderdifferences%20in%20persona...](http://www.cin.ufpe.br/~ssj/Genderdifferences%20in%20personality%20traits%20across%20cultures%20Robust%20andsurprising%20findings.pdf)

With respect to _phrenology_ , I'm aware of studies linking brain size to intelligence. The meta-analysis (linked below) confirms this and actually notes a higher correlation among women.

[http://www.govrel.vcu.edu//news/Releases/2005/june/McDaniel-...](http://www.govrel.vcu.edu//news/Releases/2005/june/McDaniel- Big%20Brain.pdf)

From your previous post, I'm guessing you might have reason to discard this type of study. Could you please elaborate and share your thoughts?</comment></comment></comment></comment></comment>


Show HN: Capsule – Simple Packaging and Deployment for JVM Apps - <AUTHOR> https://github.com/puniverse/capsule

<comment><USER2> This looks interesting. I've been looking at using getdown[0] for a desktop java app to push updates. It's unfortunate that launching java and updating apps is so terrible given the otherwise excellent cross-platform nature of the jvm.

[0] [https://github.com/threerings/getdown](https://github.com/threerings/getdown)

</comment><comment><USER3> > One-Jar does support native libraries, but uses class-loader hacks that may > interfere with the application in even subtler ways.

How does Capsule solve the issue? With the good ole "unpack to temp directory" trick?

<comment><AUTHOR> Yes. But the cool thing is that it lets you specify JVM arguments, system properties etc., and best of all, it downloads maven dependencies (listed in the manifest) at runtime (when the capsule is first launched).

<comment><USER4> I don't know Maven, where are the dependencies downloaded from? The Web? Isn't there a significant danger that the capsule will fail to launch due to some network glitch?

<comment><AUTHOR> By default, from the Web, but you can host a local Maven repository inside your organization, or, you can choose to embed all dependencies in the capsule.</comment></comment></comment></comment>


The Rackspace Cloud Powered By OpenStack - <AUTHOR> http://www.rackspace.com/blog/next-generation-rackspace-cloud-servers/

<comment><USER2> The OpenStack project is a collection of different applications that provide the ability to run an open-source Cloud provider. Rackspace's offerings generally map to OpenStack projects. Cloud Servers is Nova[1], Cloud Files is Swift[2], Cloud Networks is Quantum[3] and Cloud Databases is Red Dwarf [4]. I'm not sure the OpenStack codename for Cloud Block Storage yet, but I'll see if I can find it.

[1] <https://launchpad.net/nova/>

[2] <https://launchpad.net/swift/>

[3] <https://launchpad.net/quantum/>

[4] <https://launchpad.net/reddwarf/>

<comment><AUTHOR> The Cloud Block Storage service uses Nova Volume[5] where you can plug in a number of different storage engines.

[5] [http://docs.openstack.org/trunk/openstack- compute/admin/cont...](http://docs.openstack.org/trunk/openstack- compute/admin/content/managing-volumes.html)</comment></comment>


AWS: Scaling Up to 10M Users - <AUTHOR> https://www.slideshare.net/AmazonWebServices/ent309-scaling-up-to-your-first-10-million-users-78927643 <comment><USER3> Great resource.

Now let's talk to the 0 user startups with trivial data with their SOA/microservices, NoSQL databases or sharded data bases...

</comment><comment><USER4> AWS Scaling beyond 1 Million would mean that you have a global audience - <USER2> does not have any Global LoadBalancer for customers who do not want to use Route53 - has anyone worked on Global Loadbalancer on AWS infrastructure without Route53 ?

<comment><USER5> What do you mean by global load balancer? You can use AWS loadbalancer without Route53.

<comment><USER6> I think he means Anycast routing. Technically, one could run their own nameservers which direct to their own load balancers.

Or you could use one of the other DNS providers who provide Anycast support. I think DynDNS does it.

<comment><USER7> Anycast is easy to setup. Scaling it is another story: [https://www.linkedin.com/pulse/build-your-own-anycast- networ...](https://www.linkedin.com/pulse/build-your-own-anycast- network-9-steps-samir-jafferali)

Though most people that are convinced they need anycast would be better served with 53's GeoDNS

</comment></comment></comment></comment><comment><USER8> Great slides. The only thing I disagree with is that I think you should put your instances into an autoscaling group from day one. You don't even need to autoscale, but just by having your instance(s) in an autoscaling group, you'll be able to deal with instances dying without having to take manual action. Just an autoscaling group with a desired capacity of 2 will take you a long, long way without significant complexity.

</comment><comment><USER9> Is there a similar resource / slide deck for scaling on GCP?

<comment><USER10> Same concepts apply, you just have to map the AWS services to the GCP alternatives. Autoscaling Groups = Managed Instance Groups, ELB/ALB = Cloud Load Balancing, RDS = Cloud SQL, etc.

<comment><USER9> For sure, makes sense! I'm not familiar with the GCP alternatives, and you seem to be on a roll: care to keep the equivalency mapping going? :) (We may end up crowdsourcing generation of a GCP version of these slides...)

<comment><USER10> Off the top of my head, what I remember mentioned in the slides:

* Elasticache = Managed Redis and Memcache isn't available on GCP. (I really wish it was.)

* S3 = Cloud Storage

* CloudFront = Cloud CDN

* SQS = Cloud PubSub

* Elastic Beanstalk/CodeDeploy — No GCP alternative.

* Lambda = Cloud Functions (Beta)

Nice thing about GCP is that they don't get creative with naming, so it's pretty easy to infer what their services do.

</comment></comment></comment></comment><comment><USER11> Which is the point when you decide to go server less?

<comment><USER12> As early as possible. Things like AWS Lambda require you to really architecture for them in order to get the full benefit of it.

Lambda is also nearly costless if you have little traffic so it's not like you would pay extra for it. But serverless architecture isn't always the right decision.

Serverless shines when you have an unpredictable amount of async tasks to run, and those tasks can take a long time to run. Thumbnailing images for example.

<comment><USER13> Lambda has a 5 minute execution limit. It's not that great for background tasks unless you can divide them up to keep them comfortably under that limit. It shouldn't be that hard, but it's not effortless either.</comment></comment></comment>