Comment by nadam | Hacker News Reader

Comment by nadam | Hacker News Reader

Parent Full thread

"If you can build large scale systems, you can code complex algorithms."

Not sure I agree. Architecting/Maintaining huge systems and inventing very smart algorithms are very different skills. Both can be learned to some extent, and a programmer should learn both to some level, but it is totally possible that one person is very stong in one but not that strong in the other.

Look at the source of the splay tree:

http://www.link.cs.cmu.edu/link/ftp-site/splaying/

It is short, a programmer usually writes this amount of code in a day. Coming up with this made its creator famous.

Algorithmization is like short distance running. You prepare a lot (think a lot) but probably write little code, and you have to be quite math-focused.

Building huge systems is long distance running: you have to be strategical, you write lots of code, (and put together lots of third party components), you have to be 'wise'...

In essence good progammers are usually good enough in both (I am sure this is true for the poster), but he/she can be particularly strong in one or the other.

Speaking of very different skills, I used to have a developer working for me who was an absolute genius at fixing bugs - he would dive into complex code he had never seen before and be able to pinpoint and fix problems that had eluded other people.

However, when confronted with a "clean sheet of paper" for the design of a new module he literally couldn't do it - even with a lot of coaching.

Wow, glad I'm not the only one who's seen this.

My problem is convincing managers that good bug fixers don't always make good clean-sheet coders. Nearly everyone has things their good at. The trick is figuring out how to utilize strengths while mitigating weaknesses.

To make matters even more complicated, the good bug fixers aren't necessarily "just" maintenance developers with some savant-like bug fixing talent.

Many of them are perfectly capable of building completely new features on top of an existing architecture, and they will get frustrated if they get stuck with just the maintenance jobs.

Also, many, if not most, programmers don't handle the "clean sheet of paper" very well, no matter how much everyone else claims to love a greenfield project. Actual good clean-sheet coders are rare.

>Also, many, if not most, programmers don't handle the "clean sheet of paper" very well, no matter how much everyone else claims to love a greenfield project. Actual good clean-sheet coders are rare.

I think I get it right on my 2nd or 3rd clean sheet.

extra soft, or extra strong?

right, i'm one of those "puzzle hackers". I consider myself more of a problem solver rather than an Academic who architects an application from scratch and knows exactly what data structures and design patterns to implement without doing some extra research.

My math is terrible. My math teachers were horrible, and my attention spam limited. Complex equations make my eyes spin. I have a great visual and linguistic memory which helps me overcome these limitations. I'm also good at envisioning somewhat complex patterns and logic problems. When i code I usually start cowboy, and optimize later. I'm not at all a great abstract thinker, and therefor not consider myself a great programmer. I'm also from a hobby PHP background for 12 years now. Maybe that says something :)

tl;dr: different people think differently, and that doesn't mean they're stupid.

I'm exactly like the person you describe, arethuza.

I've been a sysadmin for 15 years, and am fantastic at what I do and am highly sought after by recruiters and so on and so forth. I started as a programmer, and I've never stopped programming, mostly for fun but my job regularly requires scripting, of course, and I'm great at it. I also really enjoy writing test automation and release automation, and I'm fantastic at those, too.

I can't design a program from scratch to save my life. I've never been able to. When I try, what comes out is absolute garbage, and usually extremely hostile to being actually used by actual people.

If I stick with a piece of non-trivial from-scratch code, I can usually get it to the point of being useful, but it takes 5+ iterations of near-total rewrites.

The basic issue, which is much like the original article, is that I just can't see the end result in my head, at all. If I have a system I need to change, seeing the end result of the system + my one change is easy. But when I try to imagine a complete system in my head (or on paper or whatever) it just ... fails. What I have in my head is much simpler than reality requires, and frequently wrong in major respects. I don't know why and I've never been able to fix it. At this point I've basically given up; when I need a high level design, I get someone else to write it, and then I fill it in.

If you give me a program where all the functions definitions and what they're supposed to do is written out, but nothing else, what I give back to you will be amazing. But if you tell me to write a program that does X, what I give back to you will be crap. This potentially has impact on my career advancement, but so far I've been able to do well by simply stating clearly that these are my limits, and I can be most effectively used in role X that doesn't cause trouble with these limits.

I used to be the bug fixer guy. There was nothing worse to me than a blank file. There's something simple and focused and comfortable about fixing bugs for a lot of people. It does take creative, critical thinking to fix bugs it's different than creating something from square one.

With a bunch of practice I got to the point where I'm more or less equally comfortable in either role. I learned to apply principles and defined a process that works for me. I watched other people create. I had two really good mentors that showed a lot of patience coaching me through those moments of profound uncertainty that come with creating new things.

Very different skills but both are learnable.

Chasing a nasty bug is fun!

I'm mostly a software design person. Despite that, nothing is more pleasing and fun than to trace problems in a system with which I am unfamiliar. And I'm either extremely lucky or extremely good at it. When asked to help with a sticky problem I can usually steer co-workers to a solution fairly quickly. In a surprising number of instances the "problem" vanishes, never to return (unlike a Heisenbug).

My peers have somewhat ungratefully termed this the "Asshole Effect"!

I'm sort of the same way and I think I've narrowed down the cause to be either choice fatigue and/or perfectionism. With a bug, the problem is "it's broke", the solution is "fix it". I don't have to think about languages, frameworks, APIs, code style/structure/efficiency/maintainability, etc. It's already in place and it's just not doing exactly what is expected, usually in some relatively minor way. With a new feature, or worse, project, the options are endless. From "Should I use a stack I'm comfortable with or use this opportunity to learn a new technology?" to "Should I completely rethink how a user enters information into a computer or just use a text box?".

Crazy to say I love fixing bugs! It does get tiring at some point to fix very similar bugs over and over again. I realized bug fixing is in essence binary search. Keep cutting the code size in half and write down the important values. Soon enough you'll find where the problem is.

I thin bug fixing builds a skill most people simply don't have, reading code. Reading other people's code is incredibly difficult and most people don't put the time and effort into it.

It does suck to get boxed into that kind of role. Where you are simply just reading code and changing a few characters per day. It is exciting get a clean sheet of paper and creating something new.

You're actually a little mislead. Proving that splay trees don't suck and inventing amortized analysis made Danny Sleator famous. Coming up with and coding it took him less than an hour (from his own mouth which might be embellished). If you look at the full proof of its log(n) running time, you'll realize that splay trees are incredibly complex.

Sleator is also an amazing problem solver. He can outcome most of the people commenting on this thread but isn't necessarily the best architect.

I believe algo is about problem solving. If you don't understand it, you don't know when to use which tool. Its unecessary if you're writing boilerplate and solved problems with frameworks but when you get to the google/amazon level, you can't just write good code. You need to understand algo to create dynamo and write dremel and mapreduce.

I agree with everything you say I just don't understand why you say that I am mislead.

Of course he could code it in one hour. Probably he came up with it in a bright moment. But a researcher has to think for years to come up with something so successful, and most of their ideas suck.

"Sleator is also an amazing problem solver. He can outcome most of the people commenting on this thread but isn't necessarily the best architect." Which is what I think exactly.

"I believe algo is about problem solving." Not just problem solving, but a kind of problem solving. algo is some kind of mathematical thinking. To be a extremely good at algorithmization you have to be extremely good in a kind of mathematical thinking. Of course those people who are extremely good at it like Sleator (or Von Neumann etc...) are extremely smart, so they are probably very good at other things also, but algorithmization is not a general purpose intelligence, it is a kind of 'mathematical intelligence'.

Friendly correction for both of you; it's "misled" not "mislead" (the latter is a verb that rhymes with "misdeed", not an adjective).

Reply on news.ycombinator.com