Calling All Hackers | Hacker News Reader

Calling All Hackers

braythwayt.com

92 pointsraganwald43 comments

I will turn this into a longer post, but there are projects like DocumentCloud which are run by a non-profit, produce 100% open source code, and which could absolutely benefit from hackers, who are interested in doing good.

Besides Backbone.js, Underscore.js, Jammit & Docsplit, DocumentCloud also has several Open Source products (such as the documentcloud platform, and our document viewer, which is even used by the FBI). These projects serve a civic mission through making journalism more open and more efficient.

We see relatively little traffic on our product repos vs our FOSS tooling repos, which makes me a little sad.

https://github.com/documentcloud/

If you're interested in making the world a better place, come find us.

This is actually kind of horrifying to me. The fact that there are multiple software design processes is really per se evidence that they're all broken? You can't really think that the fact that some people like TDD and some people hate it is evidence that we're not doing it right?

N.B. I'm not saying we are doing it right, but if we're not it's not because people hate/love TDD

Even in the stultifyingly stodgy confines of the DoD we don't believe that there is one and only one optimal way of doing things.

Or to put it another way, unlike the vast majority of Americans I hate and despise mashed potatoes. I can't eat them without gagging. But I don't take this as evidence that I'm wrong and mashed-potato-eaters are right, or that they are wrong and I'm right. I take it as nothing more than that different people like different things.

Instead of finding The One True Methodology, why don't we instead explore how to identify the best methodology for a given developer and a given team?

You can't really think that the fact that some people like TDD and some people hate it is evidence that we're not doing it right?

I think it's evidence that we don't understand it. Compare this to medicine. I think we're Witch Doctors. I don't think that the problem here is sorting out when to use leeches and when to submerge the patient in water,.

I think we need to understand actual physiology and medicine. That leads to understanding blood clotting and the role of bacteria. Which may lead us back to leeches in some cases, and may get us to wash our hands and wash the patients. But it will also lead us to entirely new ways of treating patients and the wholesale rejection of many of the old ways.

So I agree that neither TDD nor Pair Programming are OneTrueMethodologies.

I don't think that's quite an apt analogy. The different software development methodologies would be more like different medicine school programs or individual medical students' learning styles, not the end production of the doctors (which would be akin to the shipped software product).

I don't think that programming is where medicine is, so I find it difficult to emotionally buy into the idea that Pair Programming is like a Medical School program.

But I accept that if you think we're further along, you'll make that point.

I'm lucky enough to be healthy enough not to need a lot of direct contact with the medical establishment, but I know many people who have had illnesses that were misdiagnosed repeatedly by many different doctors, and a few people who had problems for which medicine's answer was "sorry, we ain't got shit for you, go die plz".

I wouldn't say software development is "ahead" of medicine, though, the two fields are simply not at all comparable. I have yet to hear an analogy between software and another field (architectural engineering comes up a lot and that one is also pretty stupid) that actually makes any sense.

I fully agree that we don't really understand why TDD or Pair work (when they do work) or don't work (when they don't).

Solving that is important in its own right though, not because people do or do not like them.

I don't like doing push-ups, even though I understand at a basic level how they improve my upper body strength. I'm pretty sure that even if we should someday understand why TDD works (or doesn't) that there will still be good software developers that don't (or do) like it.

I was thinking that people championing and rejecting these practices was more a telltale sign that we don't understand them than anything inherently wrong with disliking things.

So wrt pushups, it's as if millions of people were saying, "pushups don't work" and millions of others were saying, "pushups made me strong."

I think if we solve the problem of understanding why these things sometimes work, we will discover some deeper, more important thing. Maybe pair programming isn't about pairing at all, maybe it's really that we suck so bad at code review, and "soling" pair programming will actually make it obsolete.

I don't know, but as they say, "The best way to predict the future is to invent it."

OK, I see what you're saying. Something to the effect of "they can't all be right", so let's figure out what we're missing?

What you're assuming here is that everyone is doing pushups in the same way. Some of the difference between people liking/disliking certain approaches has to be related to not understanding it and applying it in the same way, surely? I myself couldn't get my head around TDD for ages and then it suddenly clicked and I became a complete convert.

>Solving that is important in its own right though, not because people do or do not like them.

Is it? I tend to think of writing software as something like writing literature. Or composing music, perhaps. I don't see people up in arms saying, "Our understanding of writing is broken because some people like to write structured outlines before they write, whereas others just start free-writing and come back to edit." We don't say, "Our understanding of music composition is broken because some songwriters write the lyrics first but others write the melody first." Why is it so important to understand why different programmers employ different techniques?

If you view eating as a nutrient-delivery process, then yes, you are wrong to despise mashed potatoes. On the other hand, if we view eating as a recreational activity, then you should eat whatever you want. On the gripping hand, tastes can be changed fairly easily - if you eat mashed potatoes a couple of dozen times, you'll learn to tolerate them.

So is programming about pleasure? About delivering business value? Are we artists, engineers, factory workers, craftsmen? How much weight do we give to the programmer's preferences, versus practices that seem to produce better results on average?

But those are not the important questions. The problem is that we can't even begin to answer those questions, because we don't know what is effective "on average", or how to measure those results.

> On the gripping hand, tastes can be changed fairly easily - if you eat mashed potatoes a couple of dozen times, you'll learn to tolerate them.

My parents used to be proponents of that idea as well, until they encountered me.

They did at least get a cool story out of it which they relate everything Thanksgiving, about the time 10-year-old me grew a pair and simply tossed the mashed potatoes in the trash instead of sitting at the table for 2 hours.

It's true, with the one caveat that you actually have to want to learn to like it, you can't be forced into it by your parents once you're older than 2 or 3. The social difficulty of not eating potatoes is what set me down that path initially :)

> You can't really think that the fact that some people like TDD and some people hate it is evidence that we're not doing it right?

There is no right. There is only works for us and doesn't work for us, and different people may have better success with different methods.

That is true given what we know today, but it feels like saying the gods bless some farmers and curse others. There may not be a right, but I feel there's more to it than just doing what feels good and seeing what happens.

It's more like programming is still an art, not an established engineering field, and there isn't a right or wrong to art and we haven't gotten to the established engineering point yet. We will eventually.

"We understand pair brainstorming. We understand pair bicycle repair. We understand pair driving in rally racing. But we don’t understand pair programming?"

We understand pair painting. We understand pair music composition. We understand pair writing. We understand pair knitting. But we don't understand pair programming?

There is a time to pair up, and there is a time to isolate oneself and think and meditate and explore the problem space and be creative. Beware of those who espouse a one-size-fits-all solution.

I 100% agree with you, to compare programming to 'bicycle repair' is a new kind of stupid, unless you both pair programming a hello world application.

This is my favourite comment by far.

If the program is broken, bicycle repair might be a closer analogy than painting. Bug-hunting certainly works in pairs.

Even his other examples don't make sense. I don't know if he's actually talked to musicians or writers, but I would be willing to bet that many of them actually don't work in pairs. Musicians may play as a group, but composition, as far as I can tell, is a fairly solitary activity. In the same manner, writing is fairly solitary, even though editing and review are social. To translate this into programming, I'd say that programming should be solitary while code reviews should be done in pairs.

EDIT: Even the rally driving example doesn't make sense. In rally driving, there is a driver and there is a navigator. The roles are different and very clearly defined from one another. This is nothing like pair-programming, where the distinction in roles between the person at the keyboard and the person watching is much looser and the two people are expected to take turns at the helm.

I may be wrong, but I think some of the current commenters are missing the point (re: everyone should program, gender doesn't have anything to do with it). I think the question posed here is that if we care so much about fixing things; why aren't we fixing the most fundamental problem of making it easier for people to build things, as having that extra brainpower can only exponentially help us short- and long-term? That is not the same as everyone learning to program or learning to think in ways that don't come naturally to them, but rather creating a much more well-rounded methodology for completing these tasks that makes it easier for all of us.

That's what I took from it, anyway.

Thank you.

No, thank you! I really liked this post and I think it's something we should be looking into more considerably. I've found it very interesting that many new programmers - many of them women, at least from what I've witnessed - create another language as one of their first projects (which is not surprising, since that'd probably be high on my list, too). While they're intended to be friendlier, they are generally under the guise of being made for children; complete with silly shapes and colors and storylines. But why just kids? Why do we feel like it isn't acceptable for adult tools to be just as fun and easy to use in their own ways? It's a lot like why we aren't doing more to utilize our collective physical exertion to answer problems in the same way computers can contribute to efforts like Folding@Home and Bitcoin mining or our eyes/knowledge for things like Snapshot Serengeti and reCAPTCHA.

What drives me in working in UX is just my own confusion and frustration with the way things are. Something does not need to be complicated to do complex things. I should not feel stupid looking at immense lines of code when I know that there are better ways to accomplish the same goal (in the same, if not shorter amount of time). Something that doesn't make sense right away probably has a problem, even though the person next to me may have the experience or luck to not have the same issue. If that disadvantage can be avoided, it should be.

Naturally, I've had a lot of ideas on how to make things better, but I can't wrap my head around building those things and I would rather find someone else equally as passionate about the issue to work with than just anyone off the street.

I think why people get so uppity by the "everyone should program/build/create/do" idea is because they are concerned about their job security. They believe that educating the masses is going to lead to oversaturation. Some are concerned because they are doers, not thinkers, and thinkers with these tools would threaten their ability to get by on the bare minimum. It's limiting them more than they think.

In reality, like any knowledge discipline, it can only create better tools, which create more/new jobs and thus create a better future.

Interesting post. But is it really strange that it is hard to find people who are interested in programming, or who are willing to invest in learning it? No matter how we improve it, in the end, programming is just instructing a machine how to conduct itself. Which is an activity that attracts only a few people who are intrinsically fascinated by that, and some others that learn the craft because it is good for its money. We can improve the state of programming to make it more fun or easier to learn or understand, but whether you are writing a process scheduler or programming LEGO Mindstorms, the activity in itself doesn't change. You are still interacting with machines, not humans, you are mastering a creative process, which doesn't always sit well with working as a team, and the end result of your work is machine behaviour. These constraints are bound to scare off a lot of people. Improving the state of programming won't change that.

I'm at a loss as to what this is about. I'm confused. I think it might be another thing about how everyone needs to be a programmer, which I totally disagree with. As well, it would be nice if us programmers used less world changing hyperbole all the time; it makes our little culture seems very odd to reasonable people. Just being honest.

Not everyone needs to be a systems programmer, but everyone that need a computer for their work would probably benefit in knowing how to automating whatever task they do on an every day basis. Perhaps I do believe that everyone needs to be a programmer; just that the domains in which we apply programming methodology also should be widened. Programming, taken from its particular domain is a very generic skill applicable to many fields.

"..One of the big issues recently is women. Or people of colour."

Seriously?

He's using it as an example of 'problems in the system'. I don't believe he meant those words as his own.

Is "women" the wrong term these days?

Agreed. Happy to see this caused an eye roll in some one else.

Doing good, but misrepresenting the 'big issues' is not helpful. Too often good intentions substitute for good work.

One should care about the race or gender of someone, the goal should be to attract the most talent. Also, saying 'everyone can learn' may give a warm fuzzy feeling and make people think you are a good person, but it is most likely not true.

Pushing a round peg into a square hole is destructive both for the peg and the hole.

The exact quote is hacking the system so that more people program, not "everyone can learn." The article suggests that there are barriers in place that prevent some people from learning and prevent some people from programming.

The contention is that hacking a way around, under, or through those barriers is a good thing for everyone, but it makes no suggestion that every woman, or every poor person, or everyone who doesn't grok pointers should somehow be a programmer.

Maybe they actually would prefer to paint.

I have no idea what this article is about. I do know that p2p decentralized work is going on worldwide to free us all from the evils of corporate centralized censorship and control. Plenty of "hackers" are working on these projects, like GNUnet, and Secure Share.

Coursera.org, Khanacademy, MIT open courseware and Stanford free online courses are helping to eliminate the financial hurdles of getting a computer science education. Last time I checked there were millions of lectures and courses/bootcamps uploaded to youtube to just teach programming and algorithms as well. Anybody can program if they want to now, though they could before anyways just by reading K&R and using free software.

I see one hurdle left: people can learn how to program with any of these great projects if they know English.

One can argue that English is the new Latin, a language that anyone with a minimum of education is supposed to know, but to go on a tangent and into a completely unrelated field, I wonder if geniuses like Messi and Ronaldo would have reached the top of their profession if they had to have a working knowledge of English even before they could join their first soccer match.

Raganwald's entire post begs the question:

Begging the question (Latin petitio principii, "assuming the initial point") is a type of informal fallacy in which an implicit premise would directly entail the conclusion

Moreover, in the poisoned atmosphere that surrounds this question, it seems "dangerous" to even raise the notion that the premise deserves a good challenge.

It seems all too often that pointing out the assumptions, the bad measurements, the poisoned atmosphere, or heavens, a disagreement over the validity of the premise or the reasonableness or fairness of the conclusion leads to name calling and bullying.

Reminds me to the best motion picture I've ever seen: "The Network" from 1976.

https://www.youtube.com/watch?v=WINDtlPXmmE

I want you to get mad!

And I love how this movie naively predicts the madness in concentrated power. Naively because attractors such as powers will always be existing generators of fractions of people going into similar directions generating new ideas and innovation replacing control with choice.

I really like this, because he states my thoughts, and I didn't have to do the work of putting them into words eloquently.

I'm completely on board since a year and a half ago. This [1] is what I have so far. More to come.

[1] https://github.com/shurcooL/Conception#conception

Could you use the same argument for accountancy? Or playing the guitar?

less talking, more doing

Am I the only one annoyed by blatant overuse of the word 'hacker' in this article?

I'm starting to group this word with catastrophes such as 'rockstar' and 'ninja' now.

"Hacker" is a specific term, and I hope this article uses it correctly. It is not a synonym for programmer or problem solver or digital vandal. It refers to someone with a deep curiosity about the mechanisms behind things and a desire to find new ways to use them, amongst other things.

Hackers are not necessarily smarter or more gifted than other programmers in any sense. Hackers might be disorganized or lazy or write clever code for its own sake.

So I hope nobody thinks it is synonymous with ninja or rock star.

Pair programming is like treating the other mind as an extension of yours. You have to force each mind to be on the same thought and same problem. If one side wanders off, they have to be brought back.

When one decides to go in a wild new direction, the other has to follow or pull in the other direction. When one makes a mistake, the other has to correct it.

When it starts to flow, it's a form of intimacy that can be extremely gratifying as it begins to feel like 1 or 2 additional programmers are in the room. You learn each others strengths and weaknesses, and the combined power of 2 minds can do things that the individuals were incapable of doing.

I understand pair programming. I've done it, the hard part is finding a compatible human to whom you can experience it with. When it really flows and you feel the additional ghost programmers helping out, it's like sex. A cosmic melding of two minds. When you are apart, it's like 75% of you is missing, and that is kind of sad.

Reply on news.ycombinator.com