I'm simultaneously reminded of two different quotes:
Let's argue about whether Haskell or Clojure is better while somebody else ships products using PHP and duct tape. --@agentdero [0]
And the other:
<dm> I discovered that you'd never get an answer to a problem from Linux Gurus by asking. You have to troll in order for someone to help you with a Linux problem.
-- Bash.org [1]
You should always try to do SOMETHING over being frozen in indecision. Additionally, we really should do a better job of explaining things to people, so they don't have to stoop to trolling for answers :)
This is one of my Jedi-level secrets of technical management.
I am quick to say I have a huge ego, because anyone who knew me would fight to say it first. The fact that I know what I know and have a good feel for where I'm weak lends me confidence in those situations where I'm mostly out of my depth.
I've managed ultra-introverted developers for about makesmesoundold years. Numerous are the times I've asked a question and gotten no answer. "How would we go about accomplishing x?" "How long would it take us to do y?" "What letter comes after z?"
Crickets
Throw a proposal just plausible enough that people think you're serious, but so "insane" that it almost defies logic ("what if we put, say, hmm...log base two of 2097152 is 21...jQuery callbacks in an HTML file full of id'd divs..."), then it's as if a tiny rock starts rolling down a hill. First one person offers a criticism, and then we get more people engaged, throwing out the alternatives that they would have suggested in the first place.
Eventually, they recognize the game, and then it's a fun brainstorming activity. Or you fire three as a message to the others.
This got my upvote. ;-)
I'm from Middle America. In Middle America, when you ask a farmer what he feeds his pigs, he tells you what he feeds his pigs, what he doesn't feed his pigs, why he feeds his pigs what he feeds his pigs, how he feeds his pigs, and what sunscreen he applies to their skin.
So it was very weird to me that a lot of programmers didn't like to share their knowledge of programming (except, it seems, when they are trying to impress other programmers).
For programmers, everyone is trying constantly to braindump to everyone else; that's half of what the blog posts on HN consist of. And everyone wants their braindumps analyzed, and, more importantly, debugged. "I'm feeding my pigs horse meat--did I make the right decision?"
When you're exposed to it so often, it's hard not to get tired of telling people about the benefits of grain over horse meat.
You wanted to do a thing. You made the computer do that thing. Programmer.
It's not about proving you're the smartest person before you even touch a keyboard. It's about being persistent, doing experiments, and always learning.
And I expect that your friend has forgotten the sort of things he did when he started.
"Slow down when you get to the old Willoughby place, you'll know it by the brick shed they built in back, because the statey likes to sit behind the hill and catch speeders, and after five minutes, you'll want to go left..."
I grew up on the extreme western frontier of Flyoveria, in Eastern Washington State. We had a culture of the same sort of accreted experience that results in journeymen in their various careers. There's a reason a lot of phrases such as "college boy," "doesn't know sh8t from Shinola," etc. tend to be more common, and it's not just because they're "folksy." On the other hand, they really want to save people from themselves if they're willing to learn, and they'll tell you all you need to start farming pigs. You'd better be ready to help him with his computers, though, even if he's running his farm on a Kaypro II.
In programming, there's not as much of a long-term investment in the apprentice-journeyman-master guild-style system, although you can find pockets here and there. I have lamented it and pondered the reasons for its erosion over the past 20 years, but I can't say with real authority why we don't have it any longer, other than an expected lack of tenure at any organization.
It's not like big law or finance, where your first firm is there to grind you out of the business before your second firm decides if you're up or out.
Young farmer: I got some pigs, but I don't know what to feed them. What do you feed your pigs?
Old farmer: I had some pigs once, I fed them one of my cows that had died of consumption.
Young farmer: Really?
Old farmer: Yup.
<2 weeks later>
Young farmer: One of my cows died, so I fed it to my pigs. They all died. Your pigs really thrived on meat of a diseased cow?
Old farmer: Nope, my pigs died.
In fact, I think that's probably a part of the reason why some programmers don't have patience for beginners with a lot of questions. It's because beginners actually have Google and StackOverflow these days, so it might seem like laziness to someone who had to learn using books and man pages. It's not that they don't like to share their knowledge, it's that they think the answer is already there if you'd bothered to look. I'm not saying that they're right to have that attitude, by the way. I'm just trying to present things from their perspective.
Of course, the information might also be a bit biased: everyone has their own preferences and opinions, and usually present them fairly strongly. Some people hedge about other options half-heartedly, but I doubt anyone would give you an even spiel on more than a couple of different options. Which is entirely natural: chances are, nobody has much experience with more than a couple of different options.
This might also vary a bit by community. I haven't spent much time recently talking to web developers. But the general programming languages/functional programming community is certainly fairly talkative.
That's not too hard to explain. Some programmers see themselves as part of a clique. Their code and ways are what keeps them superior, experts in the field that they work in. The sunscreen that coats their javascript perhaps took them a hard couple hours of debugging to discover, and many programmers are the type of people who feel and rationalize "If it took me this long, this newb should go through the same process".
Of course, there are many exceptions- all the online communities, forums, etc. But there's always some part that does work as I described. Hell, even I get annoyed sometimes and tell someone who's starting out "go google why you don't want a GOTO statement in code"...
I think the farmer can reasonably expect a layman to understand most of the things related to feeding pigs.
I, on the other hand, have no expectation that a layman would understand pointers, lambdas or any of the other lovely complicated things that even answering simple questions COULD entail if we went into details or expanded around the question.
[EDIT: Apologies it this comes off as arrogant or elitist or something, not intended.]
The fact that she went through with it and got it to work, despite how it ended up looking, is commendable.
And I really like the result. Anyway, this article was neat and put a smile on my face.
function animate_opacity_to(opacity) {
var elems = $('[id^=row]').get();
(function x(){
var el;
if(el = elems.pop())
$(el).animate({opacity:opacity},100,x);
})();
} function animate_opacity_to(opacity) {
$('[id^=row]').forEach(function(el) {
$(el).animate({opacity: opacity}, {duration: 100, queue: true});
});
}
In any case, great article - I definitely remember many similar scenarios that came up while I was learning to code. Sometimes you just gotta go with the crappy implementation you know will work rather than the efficient implementation that is beyond your current understanding :)
What will work is adding `delay` e.g.
$(el).delay(i*100).animate(...
$('[id^=row]').toArray().reduce(function(l,r){
return l.pipe(function(){
return $(r).animate({opacity:opacity}, 100);
});
}, $.Deferred().resolve());
Impressive is a slight understatement.
And judging by her github profile, she's a good programmer by any reasonable definition.
Amusingly, I've noticed the same thing: I do claim that a surprising amount of things are simple. And you know why? Because they are. A whole bunch of things (most recently F-algebras and F-coalgebras) really are simple: you start with a very simple concept (say sets and functions) and build up to them, taking very simple steps along the way. Maybe you have to bring in a couple of other concepts that are similarly simple.
EDIT: I should have made this clearer: I say something is simple before trying to explain it rather than instead of. I mainly do it to avoid scaring people without reason, and everyone gets far too scared of words like "F-coalgebra" or even "monoid".
Every single step along the way? Virtually trivial. But put them together and you get something genuinely difficult to follow.
It turns out that enough trivial steps all building upon each other becomes difficult to follow for anyone. Yet, once you've finally understood it, you can't see why it was difficult any more: after all, all the components are so simple, and it all makes sense! (Now.)
I realized this in a pretty direct way: I was trying to explain the aforementioned algebras to some of the smartest people I know--people with much more mathematical experience and aptitude than me--and they all found it a bit hard to follow. Not because they couldn't follow any particular step, but because putting it all together in your head is difficult.
So really, the ultimate conclusion is: just because something is simple does not mean it is easy. Having some trouble with simple concepts like this is not an issue at all; everybody does. But that doesn't mean they aren't simple!
Another, more surprising, conclusion is just how shallow the stack of concepts has to be to cause people trouble. It's not like there are hundreds of parts in these definitions: there are maybe 10. (Say: set, function, algebra, identity, category, morphism, functor, dual.) And yet this is more than enough to confuse.
"I gathered from these exchanges that programmers have a perpetual competition to see who can claim the most things as 'simple.'"
My particular favourite is the Lamina library in clojure which takes the event-driven approach https://github.com/ztellman/lamina/wiki/Introduction
http://msdn.microsoft.com/en-us/library/vstudio/hh156513.asp...
Just a rebuttal to one point that irked me.
That helped a lot, and I don't resent them for that type of help at all. I'm sorry if it came across that way in the writing.
This is very true. Especially early on, while learning basic concepts, I found it very difficult to Google things because I did not know the terms or concepts involved. When I was attempting to self-teach my first programming language (Python), I could not understand the difference between parameters and arguments - but I didn't know that that was how to characterize my problem either. I just thought "why doesn't 'x' mean what I said it means over there?"
Nobody hits my brother but me.
Programmers are persistently frustrated in our tools-- when you can see how things work, you start to see just how broken it all is. Things that should be easy are hard, things that should be hard are nearly impossible. And for every thing gotten right, there's something a little subtler that's completely and opaquely wrong, wasting days of your life. We hate our tools, and we love to complain about them.
But if you complain about our tools... Sorry, who are you? This is basic stuff.
In other professions, blaming your tools is essentially a "There's nothing I can do about it -- the tools just suck."
In programming, we can go "These tools suck, but I can fix them". Of course, then you never accomplish what you initially set out to...
You have entire and complex projects on github available for free , so no Programming is not hard , it takes time to become a good programmer yes but like everything else in life. You want to try something hard ? try to be a doctor instead.
My brother and I learned to program in BASIC on an Apple IIe when we were kids. At the time, we were also into making little movies with our family's VHS camcorder. You could draw graphics in BASIC, so we thought it would be radical to write a program that would draw a cool logo animation for our movies.
We got a big sheet of graph paper and hand-drew the intended pixel art for our logo. Then started writing code to draw it one line at a time. We put a delay between each line so that it would do an animated wipe. We knew how to pause by doing a busy loop:
10 FOR I = 1 to 100
20 NEXT I
Now I just lament having the much free time and focus to be able to do that...
Would you have been better off 'doing things right' from day one, versus experimenting and muddling through?
Sorry world. It's getting better. But slowly.
To my genuine amazement, the company I worked for immediately after leaving college is still using a program I wrote for them seven years after I wrote it. When I left, they said that every company operation was going to be covered by SAP- weird how that didn't work out...
But still, it was written in VB.NET (!) and was a horrible, horrible mess. I would love to take a look at that code now, but I'm afraid that if I contact them they'll hold me responsible for updating it.
For a while, I was even hesitant to simply show some of my projects to other developers I looked up to..I figured the code was so bad, and the project so trivial, that why bother?
Reading sites like HN, you read about these tremendously talented people.... doing exits, building absurdly cool projects that you think you'll never be able to build... and it's easy to benchmark yourself against that sort of ideal and think that your stuff isn't cool enough. When I finally was confident enough to share some projects with a few people I respected, I was blown away by how much I learned just listening to their feedback.
Even if you think you're code sucks, you'll improve rapidly by learning WHY it sucks, and using that in new projects.
I was so eager to get the graphical part out there that I didn't think about the problems of modeling, or having multiple objects on the screen at once. The whole thing was a single-file, thousand-line, hard-coded mess. And I still think it was awesome.
The important thing is to remember that there aren't (m)any super geniuses for which this stuff spews out first try. It's just that some people had the benefit of working through their ridiculously terrible code at the age of 8, writing BASIC, or whatever. And while they may have to learn jQuery the same as you did, they have a massive class of "intuitive" knowledge, which is really just experience, to help them through most of it.
It just goes to show that if you really have a passion for something and you really work hard at it, you can become awesome at it (or at least good enough to know you can be awesome without that much work) in no time. I find that this usually holds for most things in life, but it lends itself to web design especially.
Just goes to show that talent is as much inate as it is countless hours bashing against the wall. I had a lot of patience when I was 9.
And it's always funny to go back to our beginnings and see the difference in code and level after only some years :)
It isn't very uncommon to have code that would cause most to projectile-vomit in products that are massively successful, reliable and, yes, very profitable.
For design, there's always Craigslist.