Honest question: how does that article contradict that statement? Everyone is bouncing off the walls about this but I honestly can't see where the story is. Microsoft + others enable NSA to access customer data when presented with court order. You can agree or not agree but is it really a shock?
I'm probably overly sensitive to this, being a "non-US person", but I'm constantly reading "with a court order" as "either with a court order, or with a 51% suspicion that one of the two parties to the communication is not a US citizen - in which case we can do what we like"
"I’m your typical “balls to the wall” founder that will sacrifice all for the sake of the startup" ... "I founded and ran GooseChase, which makes running scavenger hunts incredibly easy via iPhone & Android apps".
Your comment is unnecessary and I'm shocked that's sitting high on the comments page.
Trivializing the amount of effort and energy this fellow put in to producing/developing this cross-platform mobile app because you disagree with...well, I still don't know what your issue is with the quotes you pulled, care to share?
You might have felt better after posting your comment but you also gave up your chance to add something constructive to the discussion. To paraphrase pg's reaction, it makes me embarrassed for HN when people include projects in their blog profile and this is the sort of response they get.
Partially, the problem is that "designer" is such an elastic word. You could argue that an interaction designer should be able to code, at least enough to make a realistic prototype - if a design isn't interactive then how can it be an "interaction" design?
Coding is less critical for visual designers though. It's better if the visual designer can render his design in html/css (or whatever), but you probably don't want to turn down an otherwise brilliant visual designer if they can't.
The "should designers code" question seems to come up again and again because interaction and visual design gets rolled into one discipline (and often one person).
But affordances (such as bevelled buttons) are not the same as skeuomorphic design. Bevelling an area of the screen implies that something is pressable and hence aids the user. Covering iCal in a fake leather bitmap does not help the user. WP7/Metro seems to have taken a lot of tried and tested affordances away, but hasn't really replaced them with anything.
You're right of course, but if you take that to the extreme, styling a clickable action with a coloured square is skeumorphism too (it's still a button). The way I see it, the concept of a button has long since tracended into a metaphor in the visual language of UI. Where it used to mimic the physical world, it has since been reduced to a symbol. I think that most people would say that the beveling effect is part of this symbol. If that is the case, then Metro tries to redefine an established symbol. This isn't unique per se - languages evolve all the time, but it does explain why a lot of people might be confused of it.
They all have something to do with software development in specific situations. But the assertion is that this set of "exam papers" represent the canonical body of development knowledge and if you don't know the majority of answers off the top of your head you shouldn't be a developer, or at least should be grateful your ignorance has gone unnoticed. I find that assertion ... questionable.
:) This is surely just degenerating into parody now. I can't wait for part 4: "Build a Turing Machine from scratch using paper-clips and sticky tape and send it to me for grading. Remember to show your working and no looking it up on Google."
It is irrelevant because the real world is composed of CRUD apps in [Java, C#, PHP], and you don't need to know most of the subjects the OP talks in his "tests." It is a parody, because the OP seems to not have worked a common software position, where most time is spent building new UIs for marketing or management, making complex and awkward joins, and making sure changes don't break the spaghetti. It all sounds like academia talk, which is fine (and valuable), but not a real sign of real world programming.
I will say that the tests have been fun to complete, and have helped me fill in the gaps here and there. But as someone who is hiring programmers at this very moment, I would not hire someone with such an approach to programming. This person would (I assume from experience) write complex code all day to show off his/her knowledge of advanced CS topics. Then not document it because the code is just obvious to read. And finally quit after a month because the job is not up to his/her standards or challenging. They would then write a blog post ranting about how programming has turned into a circus or produce a series of "tests" to show off their superior knowledge.
Real world? As opposed to the OP's world which would be called what? The Matrix?
> It is a parody, because the OP seems to not have worked a common software position,
And for some reason, only the people who have worked for common software positions can have opinions about software?
A good majority is making CRUD apps, yes, but the spam classification for GMail needs to be written, the binary data packing has to be done for Dropbox, Facebook has to detect faces, that small startup doing a storage engine for MySql has to understand B-tree, automated translation has to understand n-gram modelling, tarsnap has to make sure the data is secure, and so on and on.
> But as someone who is hiring programmers at this very moment, I would not hire someone with such an approach to programming.
Well, if all you are doing is writing CRUD apps, I don't see how someone like OP is going to be even remotely a good fit. You need a mechanic, you hire a mechanic; you don't go looking for someone who can design a V engine.
Well, if all you are doing is writing CRUD apps, I don't see how someone like OP is going to be even remotely a good fit. You need a mechanic, you hire a mechanic; you don't go looking for someone who can design a V engine.
Funny that you wrote that. I used to be a mechanic, and have modified my share of Porsche 911s. Have a couple that put out above 600 horsepower when measured at the wheels. Almost doubling their factory output. Designed turbocharger systems, intake manifolds (which was difficult due to me not previously knowing much about fluid dynamics , and such), intercoolers, stand alone fuel injection systems, and aerodynamics with composite materials (mostly fiberglass and carbon fiber). If you ask me right now about any of the subjects I would draw a blank. Why? Because I learned how to do something back then for a couple of projects, and then moved on. I did not need to know fluid dynamics for my day job fixing cars. Neither did I need to know much math. Just needed to know how to do the basics that the work required. Which were mostly things learned in the field.
Same with programming. I started out writing programs that solved a problem. Then continued with such an approach until hitting a wall due to lack of mathmatical knowledge. Learned whatever needed and moved on. Do I remmeber most of the math I've had to learn? Not really. I don't use it everyday. If I have to use it again, I'll just go to my reference material and refresh my memory.
Well, if all you are doing is writing CRUD apps, I don't see how someone like OP is going to be even remotely a good fit. You need a mechanic, you hire a mechanic; you don't go looking for someone who can design a V engine.
Problem is that all these tests do is promote the idea that real-world programming inside the matrix is about CS. Its not. Not knowing the answers to the tests created by the OP does not make anyone a bad programmer. Hell, the most productive programmer I know used to work with Visual Basic and Excell/Access all day long. His code served thousands of users and he shipped something out every week. When I asked him about big O notation his face drew a blank. But boy could he knock out software in a couple of days.
No. They can be interesting things to read about, and knowing a little about the themes each question comes from (i.e. how does a processor cache work) will make you a better programmer, but don't worry about cramming your head with trivia such as "what does MESI stand for?"
Hear, hear. Obsession with trivia and a supercilious tone are sure signals of a B-player in my experience. "Name and describe the four states in MESI cache coherence"? Sorry, memorising an algorithm for determining if a graph is bipartite pushed that knowledge clean out of my head...no doubt I'm very stupid.
For what it's worth, I'd never (so far as I can remember) known the four states in MESI cache coherence, but worked out roughly what they had to be; when I checked after submitting my answers, it turned out I was right. And I've no idea whether anyone's ever told me an algorithm for checking whether a graph is bipartite, but I worked one out.
On the other hand, I know nothing about pthreads, made a handwavy guess about that question, and got it very wrong. The underlying failure was a bad guess about the semantics of condition variables. I could whinge about that, but I bet that if I spent more of my life writing multithreaded software -- which is, make no mistake about it, an important skill -- then I wouldn't have made that wrong guess even if I'd still never used pthreads. My answer might still have begun "I've never used pthreads, but ..." but that would have been followed by a better guess than it actually was.
Something may look like a trivia question but give much more information than just "does this person have the information stored in their brain right now?". In this particular case, Colin could (if he chose; he probably has better things to do than go into such detail on the hundreds of responses he's getting) guess that I haven't written much multithreaded software, don't spend a lot of time optimizing things for the memory subsystem but have a good grasp of principles, and am good with algorithms. Not so bad for three trivia questions.
And, whatever cperciva's failings (which may for all I know be many and serious) one thing he certainly isn't is a "B-player". (But then, in my experience talking about "B-players" is itself a bad sign.)
He's definitely not a B-player, but that makes it all the more mysterious why this project is missing the target so badly.
I don't think the questions are awful, though they do tend to have a trivia component to them.
What I think has really happened is that the whole thing is completely mispackaged. By calling it a "software development final exam" and saying it's things every programmer should know, he's set up an idea that it would be fairly broad and comprehensive, when in reality it's fairly narrow.
Plus that terminology is a bit socially off-key since it sets people up to be defensive rather engaging in meaningful discussion.
Indeed, presenting this more 'guide to interesting things you should know' rather than 'here's an exam I've condescended to set for everyone dumber than me' would have worked out much better.
Maybe B-player is harsh but in my career I've worked with some very good programmers and some real stars. When I talk to the very good programmers I always feel dumber, but whenever I talk to the real stars I always feel smarter myself (though heaven knows that's not actually true). This seems to fall firmly in the "very good programmer" category.
I thought that the bipartite graph algorithm question was the best so far. It was a question that, in addition to remembering what a bipartite graph is, required a little bit of thinking instead of just rote memorization (if you know what a bipartite graph is you can come up with the algorithm on your own -- no need to memorize that). Question #2 in this set is also pretty good.
Remembering the relation of a bipartite graph to graph coloring helped me coming up with an algorithm fairly quickly. Although that might in fact require a little familiarity with graphs and the associated terms. I guess most of my former fellow students who didn't hear a graph theory lecture won't really remember that.
"Name and describe the four states in MESI cache coherence" is mostly about having at least basic idea of how multiprocessor systems work that is pretty crucial to any seriously meant multi-threaded programming. It's something that anyone who wants to call himself a programmer has to know (or at least have some idea that something like that is happening, which is almost equivalent to knowing how it works, because it's really straightforward).
I don't think the question as phrased is about having a basic idea of how multiprocessor systems work. It's a question about naming(!) of the component parts of a specific protocol. That's trivia. It's as if the question about the TLB was about the acronym rather than the function.
(So what's a good question to see if somebody understands cache coherency? Maybe describing a problem caused by cache-line contention, and asking for an explanation and fix to it?)
I'm a big fan of The Verge but this seems melodramatic and a little hollow. The HP machine doesn't just share a few design features with the iMac, it's lifted the design wholesale. Way more than any Samsung phone did w.r.t iPhone. Not mentioning this in the article was weird.
And Joshua is being "bullied"? Really? Sensitive types, these bloggers.
Oh god, an OSNews article from Thom Holwerda about how "obvious" the iPhone was is now top of Hacker News? How long do I need to switch the internet off for to restore sanity?
