Morendil

> Of course developing software is a highly abstract, intellectually demanding activity

I don't mean to sound harsh, but "of course" and "it's absurd" aren't much of an argument.

My advice is to dig into this a bit deeper. What do you think makes software "a highly abstract, intellectually demanding activity"? What would the world look like if that were NOT the case, what would it look like if it WERE the case?

How does this claim coexist with that, which has been bandied about for decades, that software programming is on the brink of being automated away?

How does this claim square with sites like the Daily WTF, which provide evidence that many gainfully employed programmers do not, in fact, use their brains very much? With the more or less weekly announcements of "security breaches" caused by people ignoring basic best practice, for instance storing passwords in plain text?

How much mathematical(ish) ability is actually needed to put together a Web page, a bunch of CRUD fields, and some backend database template?

Why is it so easy to get a job writing software even if you have no formal credentials at all? How is it that some people can get these jobs even if all they can do is write a Web page, and that badly?

It's possible that our experiences differ: that for you software has been abstract and demanding. (I can see people who write kernels for a living getting the "of course" reaction.) Whereas I've often rubbed shoulders with the world of "IT programming", with self-taught games programmers and Web programmers and people who turned a half-baked idea and their gift for the gab into multimillion dollar businesses.

Whenever I did my homework and dug into the facts, I found that things that "of course" held true weren't all that obvious. I'm trying to encourage people in the profession to get into that habit.

> as absurd as claiming women are somehow incapable of doing exactly that

Yes, I too see that as a false claim. Do you deny that there are people out there who are in fact making that claim?

> dismantling the 10x claim (writing an entire book about it)

"Leprechauns" is by no means entirely about 10x developers.

In it I also tackle things like the "exponentially increasing cost of bugs" claim, the Cone of Uncertainty, the "software crisis", the successive mythical reconstructions of the Waterfall bogeyman, the limitations of the "empirically based software engineering" movement and specifically the problem of discipline envy.

If it had only been the 10x thing that turned out to be ill-supported I wouldn't have gotten my knickers all atwist. My beef is precisely that when you look closely most of software engineering looks awfully like pseudoscience.

This article is, in a way, Chapter 1 of the next book, in which I'd look beyond "academic" myths, and try to confront a broader picture of how the software community thinks about itself, and how that perpetuates some of the problems we've been bitching about for decades. (And some of these problems turned out to be non-existent; other very real ones barely rate a nod from academia. That is also part of the problem.)

"singling out some myths for critique rather than others gives a misleading impression"

Article author here. Agree with your first para, so the above has me puzzled, a bit.

Would you please expand: what impressions do you think the article gives, that are misleading? (And if possible: what do you see or hear that makes you think they are misleading?)

Where are you reading all that? The article says:

> at its best, labour offers us a chance to externalise what's good inside us (let's say, our creativity, our rigour, our logic), and to give it a stable, enduring form in some sort of object or service independent of us.

Note "object or service".

France here. down too.

Want to make your 10-minute drawing breaks more fun? Try Drawception: http://drawception.com/

Holy crap. An article with the words "cites research", with a hyperlink which actually goes to a PDF of the actual research being cited!

Would love to see HN rise to the occasion by discussing actual facts and data, rather than spouting opinion and speculation. (A popular pastime, to be sure, but it's always nice to do something different for a change.)

For what purpose? Employability, intellectual well-roundedness, zeitgeistiness? Each of these could pull you in a different direction.

My current hunch is that statistics/data science/machine learning will satisfy at least two of the above three, if not all.

I've been learning the basics of data analysis with R, much helped by the awesome RStudio. Initially this was for fun (and a tryout of MOOCs, specifically Coursera's data analysis class) but after only a few weeks I found occasion to use it at work (finding patterns in an application's response times in response to user load throughout the day).

Now I'm getting into stuff that's even more fun, specifically the reactive Web framework Shiny.

This is usually a sure sign of a good match between learner and subject matter: an iterative process where learning and applying, tightly interleaved, form a feedback loop.

No, Wikipedia, in the context of space missions a DTO is not a Data Transfer Object.

(Fixed, so see https://en.wikipedia.org/w/index.php?title=Quantum_vacuum_pl... for the lulz.)

But Y would I want to do a thing like this? http://weblog.raganwald.com/2007/02/but-y-would-i-want-to-do...

I'll just leave this here.

https://plus.google.com/+LaurentBossavit/posts/VBJTGru3PeW

Or this.

http://leanpub.com/leprechauns

The original paper is clearly a joke, but the LA Times article falls afoul of Poe's Law - at first glance it looks like the reporter just got trolled, though if you squint a little bit it could look as if the LA Times is trying to in turn troll its readership.

She's talking about paraconsistent logics.

http://en.wikipedia.org/wiki/Paraconsistent_logic

Feel better now?

> How did you go around to finding him?

If you're going to shop around for a change agent, I recommend reading Jerry Weinberg's "Secrets of Consulting"; although this is targeted at consultants rather than their clients, it can provide useful insight into how to create an effective working partnership with one.

Technical know-how doesn't by itself qualify someone to help you implement changes towards becoming more effective. It can be detrimental, in fact.

But someone with a solid grasp of the fundamentals AND a productive attitude to coaching/mentoring/consulting can be a great asset. One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him).

> the behavior of adults in the workforce

Not the same as "the men in the workforce", agreed?

> I am more infuriated by the idea that if women are underrepresented in technical fields, it must be the fault of the men in those technical fields.

Who's saying that?

> If we want to actually solve this problem, we need to go all the way to the beginning: middle school, where girls mysteriously start losing interest in technical fields.

What do you mean by "go to middle school" - who do you suggest should take what action in that particular venue?

> mysteriously

What's mysterious about it? What expectations do you have that this observation runs counter to? What needs to be changed in our mental model of this system, so that instead of this being a mystery it becomes a predictable of the system's properties? (At which point we can start asking "how to change the system so that we get different outcomes".)

(This is me being curious, not Socratic, BTW.)

Forty-something programmer (diversified into various forms of consulting). Self-taught from printed matter before the Internet existed. Started coding on a ZX81, moved up to Apple ][, then to Macs. Dropped out of college to start working as a coder at 20. I started out as a freelance games programmer but that was a bit beyond my business (not coding) skills of the time, I took a job at a startup(ish) instead.

Nearly all of my learning happened on the job, as a result of taking on projects involving technologies that I had no clue about when I started and mostly mastered by the time I finished. Pretty much what is now called a "full stack" developer as a result.

And that doesn't happen elsewhere?

Question seconded. The OP strongly implies that, and if it's not the case then the description of the process is oversimplified.

Citation needed.

This. If the only thing keeping you from bailing is an attachment to past decisions... don't let it keep you.

Except, of course, when a traffic spike brings it down. :(

I've been using Commafeed for a while now to replace Reader, and it's working like a charm.

For my needs it's an excellent fit - I don't have a huge list of RSS feeds, perhaps a dozen that update with any regularity, and a completely run of the mill workflow - check RSS once or twice a day, from my desktop. It completely replicates what I'd come to rely on from Reader.

Not quite ready for prime time? Reader import fails for me too.

Read the article carefully, and quote me the part where she agrees there is a problem.

The balance of evidence is that she is dismissive of the problem. She says she disagrees with Debra Mastaler, she uses scare-quotes around the word "bias", all but one of her "solutions" are aimed at female speakers individually, of the "do more to get noticed" variety. (The one standout is her accusation against Forbes Woman.)

Nowhere does she acknowledge that a) a number conferences have managed to get much, much closer to parity, without resorting to quotas, and b) a conference that still ends up with 95% males therefore very much has a problem.

This is known as "not doing your homework".

Fallacy of the excluded middle. Just because quotas are a wrong solution doesn't mean the problem doesn't exist.

A tech conference that ends up with 95% male speakers is Doing Something Wrong. They have no right to be "happy with their process".

One of the "correct" solutions has already been discussed in many places - use a name-blinded review process, and make sure your CFP outreach activities include women-intensive groups.

This, a million times. (Which is how many I feel like I've said it so far.)

Conversely, this particular dysfunction of standups is a useful index of how much the corporate culture leads people to feel like they must justify their existence.

Useless blog post: "X is a dumb idea, when we tried it Y happened which is bad."

Useful blog post: "We tried X expecting Z, but instead Y happened. I wonder what's going on, please chime in."

The mistake here isn't "negativity", it's Z-blindness. It's missing out on an opportunity to revise your model of how the world works, by noting that there is a discrepancy between your expectations and how things actually turned out.

(Of course, the "useful" approach results in less sensational titles, which may be why we see fewer of those.)

See this: http://www.slideshare.net/danmil30/how-to-run-a-5-whys-with-...

Guilt is a moral concept; when it comes to a run-of-the-mill operations mistake like yours, it does not belong in analysis of its consequences to the business. You are not a robot. You have made and will make mistakes this bad and worse.

Only consequentialist thinking should be the order of the day here; "what do we know that can prevent a similar mistake from hurting our bottom line". In this case backups are the standard, reasonable, well-known practice. Nothing will be improved by a firing or a resignation, by blaming or by shaming.

Insofar as the real root cause of the problem was not addressed, it's a reasonable prediction that any such company eventually joins the deadpool due to similar oversights.

So the person who made a split-second mistake while doing his all for the business was pressured into resigning - basically, got fired.

What I want to know is what happened to whoever decided that backups were a dispensable luxury? In 2010?

There's a rule that appears in Jerry Weinberg's writings - the person responsible for a X million dollar mistake (and who should be fired over such a mistake) is whoever has controlling authority over X million dollars' worth of the company's activities.

A company-killing mistake should result in the firing of the CEO, not in that of the low-level employee who committed the mistake. That's what C-level responsibility means.

(I had the same thing happen to me in the late 1990's, got fired over it. Sued my employer, who opted to settle out of court for a good sum of money to me. They knew full well they had no leg to stand on.)