Hacker News Reader

Comment by mamcx | Hacker News Reader

Why limit a "Stealth Incompetents" to one that is a "web developer"?

A person recently graduate from the U. Perfect scores in algorithms and that stuff.

Now, is in a company. That make web things. Don't know databases well (if any). Don't know JS. Don't know html5. Don't know CSS3. Don't know django, or ruby, or whatever.

But know BIg(O)! Know how do a Black tree!!

And that is almost useless in his job!

You know what is that? A incompetent.

Competence is the match of skills to the tasks.

You will say "A person that know algorithmic stuff can learn web development easy!" (I will say: Why think a web developer can't learn how build a algorithms?)

Real-life disagree. People are not equally good across the full spectrum of skills.

Thinking that "web development" is trivial in contrast with "real engineering" is wrong. Both are hard. Requiere different skills and mind-sets.

View on HN

I have been doing this a long time, and I have never met someone who knows computer science who has had any difficulty picking up a web development framework. This stuff isn't rocket science.

Anecdotal: just last week a CS graduate at my work produced Python code so horrible, that our tech lead refused to comment on it. Have you heard about storing an app's - no, an app part's - settings in a __builtin__ module? And that's a tip of an iceberg in this case :)

Well, being a programmer I am able to answer both simple and a bit more complicated CS questions, although I worked hard on my own to be able to as I have no CS degree. The reverse is not true - the CS graduates cannot produce maintainable code. At least that was the case in those few cases I witnessed, so of course it's not (probably) a rule, but it certainly happens.

This.

A "simple" thing like the kind of language you used to learn first have a huge impact in how you code or solve problems.

And if, for example, people learn first C, then try to workaround the limitations of it... in python.

I learn first foxpro. And my personal experience is that it give me a huge boost in database/data manipulation than the regular developer. To this day (I do integrations between several ERPs made with different languages and databases) the system that I have meet with people with strong C-like and algorithmic stuff are qualitative worse, by a LOT (take in account, is not normal to meet GREAT GREAT developers, so YMMV), that people that start with DBase languages (yes, DBase/Fox was HUGE in my country ;)).

Is like this. If a person that learn by the CS path have a problem, inside his C/C++/Java:= Amazing. But when the same problem is inside a database engine :=Not amazing.

Is weird! Some folks have tell me I'm a great developer (I know I'm not. I'm very average) because I know SQL! I could figure how solve stuff with Sql/Sql languages naturally, but then... I'm inside C/C++/Java and I lost if need to do a black tree...

FWIW, I was hired by Google in the depths of the 2009 recession because "You have both solid front-end skills and deep algorithmic knowledge, and that's not a combination we see very often." I work with a number of Ph.D's from top universities who are doing cutting-edge machine-learning and ranking algorithms. Many of them cannot code themselves a UI if their life depended upon it, let alone stay up-to-date with emerging web standards, stay away from browser quirks, debug obscure Javascript or CSS corner cases, or pay attention to client-side latency.

Good web development is harder than it looks. I've done some pretty impressive algorithmic stuff (eg. ported Arc to Javascript, wrote a Scheme interpreter in Haskell, built a JIT in LLVM, coded a conformant HTML5 parser in C), and I'd say that on a day-to-day basis, web development requires the largest body of knowledge and the greatest ability to make trade-offs in your head.

Where do you even look for these types of jobs? I started in algorithms and business logic, and over the years have been expanding through the front end, all the way to photoshop. I can't design worth much scratch, but once a designer gives me a few pictures I'm well skilled from there until we hit database optimization.

But most jobs I've worked at and see have two very seperate categories: 1) Front End Developer, 2) Application Tier Developer, and don't expect or really allow much cross between the two.

The best place to be if you want to learn both algorithms and frontend webdev is a startup, because they're so short on people that you'll basically have to do everything. All my jobs before Google were startups, and I suspect that if I ever left, all my jobs after would be too.

The other important thing I did was to never let people stop me from exploring other stuff on my own. Most of my algorithmic experience was actually on my own initiative, either nights-and-weekends side projects or 20% time, although I've had a couple projects at Google where I do backend stuff. Compilers are cool because they're largely self-checking: it's immediately apparent if you don't understand the concepts, because your programs will give wrong answers.

There's a very good reason why the job descriptions are separate: they really are separate skills, and it's fairly rare to be good at both. But not impossible, and there's certainly less of a difference between frontend & backend dev than there is between backend dev & leadership.

Wasn't really looking for a place to learn. And yes, that's why I've largely worked in startup companies. Was just wondering if there was anything else out there I was missing.

I believe the core of what you're saying: it's fairly rare to find someone who is algorithmically excellent, and who already knows all of the details of web dev. But I think that's largely a matter of interest and specialization, not capability.

But I stand by my larger point: I wouldn't hire a web dev who wasn't fluent enough in basic CS that they couldn't pass an algorithm interview. They don't need to be able to design machine learning algorithms, but things like basic algorithm analysis are essential.

I don't think we really disagree: I also wouldn't hire a web dev who wasn't fluent enough in basic CS that they couldn't pass an algorithm interview. Once you get past JQuery and need to do your own DOM manipulation, it becomes really important to have your tree traversals down. And webdevs who don't realize that NodeLists are actually lists (with O(N) .length calls) cause a world of pain with their for(var i = 0; i < element.children.length; ++i) quadratic loops.

But I thought what started this thread was mamcx's thought question about why we don't apply this the other way around: when hiring data scientists, why do we not require that they have a basic fluency with web UIs, at least enough to throw a table and a few images up onto a web page and show/hide some details? In my experience, what separates the best data scientists from the worst - and there's an order of magnitude difference in productivity between them, at least, enough that a poor data-scientist will never come up with a useful result - is the ability to quickly visualize their data set and understand its "shape". They need to know the distribution, and be able to drill into a few examples of raw data, and come up with the top X or so results by whatever signal they're studying. And the easiest way to do this is by generating a web page with a few charts, a few examples, a sortable table, etc. Nothing terribly fancy, but having the chops to do this on your own makes you much more effective than someone who knows the theory but can get their hands dirty with actual data.

Yeah, I think we're on the same page. Your traversal example is a good one.

I also agree with you that web engineers should be at least functionally competent at UI development. But where I depart from mamcx is that I'd still choose the algorithmically talented candidate over the one with UI skill and no algorithmic knowledge. I think that learning web UI development is easier than learning the fundamentals of computer science. But maybe I'm just a snob. :-)

Along with other responders to your post, I have dealt with plenty of really smart people that cannot program. I don't mean 'pick up a framework' - learning an API is right up a clever person's alley (I frequently carefully distinguish between clever and smart, and am doing so now). But, can they string together nested logic, design in a way to minimize dependencies, is their code readable, is it testable, and so on? So often, no. I think the ability to craft high quality code and to act as a empirically oriented engineer is a somewhat rare skill, and one that is quite orthogonal to proving the correctness of Prim's algorithm, or remembering how to implement Union Find efficiently.

Furthermore, it is not necessary. I have worked with plenty of people that I would work with any day, in any project, that had no real algorithmic chops. Oh, they may know that databases use something like B+ trees, but they'd be hard pressed to describe the data structure, let alone implement an operation on it. But they could, if they needed to. Half an hour with a book, a few experiments, and they'd be off to the races.

"I have dealt with plenty of really smart people that cannot program."

Straw man. You obviously have to make candidates prove that they can code, in addition to knowing algorithms.

That said, you can have the people who know how to use a database, but can't at least explain a B+ tree. That's a combination of laziness and incompetence that shouldn't be tolerated. You can't possibly understand how to build performant database systems if you don't know how they work.

Not only is possible, happens all the time.

Is because the abstraction level of a database engine is different of a core language.

Is possible to build a performant database systems without understand what is a BTree, or how is different from a Black tree or a hash. (I suspect, from my experience, that a lot of DBAs and database-focused developer have not much clue on that low-level stuff).

In fact, is not only possible, but build a good database is the job of the people that build good databases. But how archive that, is different from how build a performant algorithm (is more about how layout the data, how index it, how build the querys, analyzing the plans... but mainly, how layout the data)

In my life I have never ever ever think in the low-level implementation of a index as a key point in how build a database system.

(However, I will be glad in know a example in where this could provide a huge advantage)

I know it's possible to build a performant system without knowing how it works, it just isn't deterministically likely.

There's also a difference between "building a database", and "using a database". I'm not suggesting that people who write SQL should be able to write a DBMS (though that certainly helps) -- just that they should know, for example, how a B-tree index will most likely perform when joining two large tables. Or how storing a text column is different than a string. And so on.

I've spent a lot of time cleaning up the messes of people who can write SQL -- sometimes, on large, heavily-used systems -- but had absolutely no idea why their multi-way joins were slow, or why doing LIKE queries over a large text column is a performance hit. These are stupid problems that anyone with basic CS knowledge can understand how to avoid.

Aside: this is also the reason why fans of certain trendy technologies (...rhymes with bongo...) are routinely pilloried for making dumb technical decisions. Those who don't understand CS in theory are doomed to learn it in practice.

I once worked with an individual with a PhD in Mathematics who wrote some of the most god-awful code you could possibly imagine. In an algorithmic test, he would have bested anybody I can think of.

Intelligence and usefulness at tasks are incredibly complex topics for discussion. If you think you can reliably go from A to B, you're dead wrong. The only reliable metric is, if you want skills A, test for A. If you want skills B, test for B.

Indeed. You want people who can code, and who know algorithms. You must test for both.

Reply on news.ycombinator.com