Posted by: jsonmez | August 12, 2012

The Myth of the Super Programmer

I received an email this past week that disturbed me.

Basically the author of the email inferred that most of the topics I talk about in my blog posts and Pluralsight videos are relatively easy topics, but that I had hypocritically suggested that interviews should be hard and should be designed for “real programmers” or super programmers.

Essentially the point of the email was that application developers are not “real programmers” and “real programmers” do hard stuff with difficult math.

Searching for the super programmer


I don’t think this attitude or understanding about programming and software development is unique or irregular.  Even Scott Hanselman has called himself and thought of himself as a phony.

His post on the subject resonated with me, because I think the same thing about myself sometimes.

Sometimes, I wonder if I could really tackle the really hard problems.

I would venture to say that most software developers have some sort of belief that they are just a regular programmer, but there exists out there some super programmers who actually do the difficult algorithms that control caches on hard drives and index search results for Google.

Now, of course there are programmers writing code that does all kinds of complex things that you and I don’t understand, but how different are those programmers from the rest of us?

Is there really a difference between an enterprise application developer and a programmer who writes search algorithms for Google and firmware which controls the mechanical operation of the head of a hard drive as it reads data from the platter?

Before I give you my answer…

Let’s talk about problems for a minute.

What is the most difficult problem you have ever been asked to solve?

How did you go about solving it?

In the end, when you actually solved the problem, did the solution seem easy?

When you go back and look at the problem, does it seem much simpler now?

Lots of questions, I know—but I want you to really take the time to think about those questions before reading on.

It is important to understand the difference between perception and reality and many software developers, myself included often have trouble distinguishing between the two.

You see, our perception of a problem is often much different than the reality of that problem.  When we don’t understand a thing, it seems much much more complex than it is.  But, once we come to understand a problem, we see how simple it actually was to begin with.

Let me give you a real example.  Take a look at this mathematical equation below.


Now there are two kinds of people who will look at this equation.

  1. Those who have a decent understanding of mid to advanced mathematics and immediately recognize it and understand it instantly.
  2. Those who have never seen these symbols used together and immediately think this is some kind of complex thing that would take them years to learn.

I may not be exactly correct, but my point is there is a clear division between those who understand and those who don’t.

I can very simply explain this set of symbols to you in terms you already understand.


That equation is the same as this code:

var total = 0;
for(int i = n; i <= m; i++)
   total +=  f(i)

So what is my point?

My point is that there are very few actual hard problems in math, programming, heck life in general, and usually those few hard problems can be decomposed into smaller problems (sometimes more than once), until you end up with a simple problem.

The point of this blog, the point of my Pluralsight videos, the point of my life, basically, is taking complex things and making them simple.

If you want to succeed as a programmer, you have to learn how to do this for yourself, because this is the single most important skill you can possess.

So, to answer the original question—No, I don’t believe there are super programmers.  I don’t believe that there is a difference between an enterprise application developer and programmers working on problems that most other programmers would perceive as really hard problems or “real programming.”

Now, don’t get me wrong and think that I am saying that I don’t think some programmers are orders of magnitude better than others.  I would venture to say that really good programmers are about 10 to 20 times as effective as just average ones.

What I am saying though is that we have a tendency to forget how simple all problems really are when they are decomposed to smaller problems and that ALL problems can be decomposed in that way.

What I am saying is the thing that might be stopping you from growing to become a really good programmer is your own false belief that you can’t possibly understand something that you currently perceive to be complex.

What I am saying is that when you write what appears to you to be a simple enterprise application, you might be forgetting just how difficult and damn near impossible it seems to all your friends and family that know nothing about programming.

Still think I am wrong?

Fine, you are entitled to think so.

But I do have a challenge for you.  Surely you know a “super programmer.”  You might even be one.  If so, let’s hear from you or them.  Tell us that complex problem that is too difficult for the rest of us to possibly understand.

I don’t even mean that sarcastically at all.  Seriously, if you can prove me wrong, do so.  I’ve just never seen a problem that couldn’t be broken down into simple to understand components, yet.



  1. I just love your blog posts! It is about programming, but you have a different angel to it, compared to so many other bloggers. You write about how to become a better programmer, inspiring people and how to think and you leave the specific problems and solutions and examples to others.

    I really like your blog posts.

    Sorry for off-topic

    And for the blog post, i know a few very good programmers, but yeah when i think about it, it is mostly, that they just have a “know-how” and maybe dont necessarily have a higher IQ or is a super programmer, but without a doubt, it required a big knowledge and cleverness to programming the big complex things and algorithms, that not every programmer can learn to handle.

    • Thanks Matias, appreciate the compliment!

    • There is no such thing as a super programmer you are a programmer or you not a programmer. Then we have intelligent people who manage to programm because they are not programmers it will work but the code is bad and complicated.

  2. As one of the “super productive” programmers, I have no idea whether I agree or not. I’ll have to think about this. 🙂

    You have a very good point regarding domain knowledge: that problems can appear complex to the uninitiated. But I’m not sure that *every* problem can be broken down. I used to work a lot developing heuristic algorithms for specific NP-Complete problems, big enough to be unfeasible to solve directly (factory automation). Even looking back on it, I wouldn’t call it “easy”.

    Also, some problems don’t allow easy decomposition. I’m currently a firmware architect building a distributed monitoring system. In this world, I don’t have nice tools like a thread pool or garbage collection. I also can’t have the same amount of abstraction that I would put into a .NET app. So more things need to be integrated rather than decomposed, for performance reasons. This, in turn, requires more from the programmer: I have to keep both the architecture and low-level details in mind at the same time while working on it.

    And *someone* has to write code like that. I would disagree, though, with the implication that only math-related programming is “real” programming. If there was a “real” programming, it would be centered around algorithm and data structure selection and design.

    Also, you don’t *want* to learn *all* domain knowledge. I work with programmers who do super-accurate GPS mapping. Like they adjust for the various “bulges” in the earth’s shape, and account for the dilation from relativity theory during their satellite communications. Not stuff I really *want* to know.

    Then again, I’ve never even used FFT. Don’t even know how it works. So maybe I’m just missing out on what the math programmers know. 🙂

    • And that problem sounds terrible, until you have the right tools. When you hav thge right tools, be they software tools,or just concepts, then that too can be made simple.

  3. I always liked a quote from Einstein – “If you can not explain the theory of relativity to your grandmother then you proberbly don’t understand it your self”.
    I would argue that super programmers are the ones who can explain things in simple terms and ways.

    • Your premise assumes that grandmother has sufficient education to understand the basic building blocks of the theory of relativity. Don’t believe it? Try explaining object oriented programming to a 5 year old 🙂

      • Actually the 5 year old is not a good reference point.

        The true test of your understanding of a topic is whether you can explain it to one of either:

        * Your Grandmother

        * A 11/12 year old

        There are differences in the needs of explaining a topic to your grandmother vs a 11-12 year old.

        Your grandmother will probably be polite and just let her eye’s glaze over, while the 11-12 year old will say “boring” and just walk away.

        Finding the interesting part of a topic is one essential part of understanding the topic.

  4. Sorry, but there is Sum in your equation, but your code doesn’t have it.

    • Heh, good catch. Fixed now. Thanks 🙂 Easy to make mistakes on even simple things.

  5. As an application programmer, I find a paradoxical relationship between the user\’s request and the solution. The ultimate solution is to produce a result that is fully functional, simple to understand and use, and reduces the user interface elements so they barely exist. It takes an experienced and talented developer to achieve this, generally to have the user respond with – ”that looks pretty simple, and you want me to pay HOW much?”

    • It is a paradoxical thing in programming that the simplest thing to do – is often the hardest thing to code – leading to exclamations of ‘That looks easy’ soon followed by ‘You want to be paid how much!’

    • The hardest thing is often to “find the essential simplicity”. When I start to design something, and the design starts to become horrid, I tear it up and tell myself that somewhere in this there is an essential simplicity lurking; all I have to do is find it. Finding it is sometimes quite hard.

  6. Maybe it goes back to the IBM days, when Harlan Mills wrote about “chief programmer teams” headed up by super programmers.

    • I suspect the distinction is not between programmers and super-programmers or chief programmers, but the distinction between programmers and algorithm developers. To define a new algorithm requires a deeper mathematical understanding of the problem, but does not require any ability to write code. Implementation of that algorithm in code in an efficient way is the job of the programmer who only needs to understand the algorithm not the mathematics.
      Two distinct processes, two distinct people. Of cours if you can do both so much the better, but think about which of the two tasks you are actually being paid to do.

  7. I think you may have ‘n’ and ‘i’ reversed in the for statement. You say:

    for(int n = i; n <= m; n++)

    But it should be

    for(int i = n; i <= m; i++)

    since the body of the for loop sums f(i).

    Otherwise, great article!

    • Thanks steven, I was trying to use n as the loop variable, but then reversed the idea when writing the code, so it was half and half.

  8. Fantastic. Here is my attempt at breaking down and explaining some math (Euler’s formula) that is supposedly hard to understand:

    • Excellent explanation!

      • Thanks, very glad you found it effective!

  9. Perhaps the difficulty of a problem isn’t that it can’t be broken up into simpler problems, but simply a consequence of the number of simple problems required to represent it.

    I work on problems that I consider hard simply because they are extremely conceptually difficult for me to solve and I have spent many years developing various approaches to them. As you observed, this is never because of some inherently complex component, but rather the increasing complexity of hundreds of smaller little problems that must all be solved at the same time through just one solution.

    What’s particularly interesting is that my solutions are almost always made up of multiple answers that already exist for unrelated problems combined in a particular way.

  10. As (formerly) one of the “super programmers” I both agree and disagree with you.

    I agree with you that almost all problems in software (and elsewhere)—to the tune of the Chambers Constant (that’s 99.44%)—can be decomposed into simpler and simpler problems until you’ve got trivial problems to solve (albeit sometimes a huge mass of those).

    I disagree with you that all people can become “super programmers”, however, because it takes something that not all people have to go down that route of decomposition: a sense of play and an overriding curiosity that makes you start down the path.

    Most programmers and programmer-wannabes lack that spark, that urge to know how and where and when and why to solve a problem. These people, no matter how much you blog your excellent thoughts, will never be “super programmers”.

    • Good point, I agree with you.

  11. You don’t know what you don’t know. There are super programmers in all fields of programming. Application development is only one of them. It doesn’t make you an expert in video encodings or operating systems. There are open problems in computer science too. If you solve any of them with elegance, you are super.

    The myth is that super programmers were born that way. But there really are super programmers. I have seen them.

    • I think the point is closer to “while you definitely don’t know what you don’t know, you *can* know what you don’t know if you break it into approachable pieces.” which I’ve found to be absolutely correct.

  12. What about mathematical proofs?

    What about all of the Millennium prize problems or other unsolved proofs in mathematics? They are still problems, just like these ones are, yet they have never been solved in history as of yet.

    • Good question. I have two thoughts on this.
      1. They will eventually be solved and then the solution will seem simple. (Or rather it will be able to be simply explained– Perceptions vs reality.)
      2. And also there are of course very hard problems, but they are very rare and rarely are required to be solved to solve a programming problem that any of us might face. (There are of course exceptions to this as well.)

      I think my post was misunderstood a bit. I am not trying to define an absolute. I am just saying that the perception many of us have about super programmers and the kinds of problems they solve is wrong, in general.

  13. What will you call a programmer who does this as

    ans = (m*(m+1)-n*(n+1))/2;

    • Gaussian-programmer

      • Wrong-programmer

        total = (m + n) * (m – n + 1) / 2;

    • Nice one idextrous. I wish I’d spotted that — now I know I’m not a super programmer.

      Actually, now I’m commenting I’ll put in my 2 cents.
      I have actually come to the conclusion that what makes a really good programmer is that they can write code that is easy for others (and themselves) to understand, because it’s easier to get it right, and easier to maintain. So your solution to the above is only a good one if you provide a really detailed comment (explaining, for a start, that sum of i from 1 to n = n*(n+1)/2 ).

      I have always approached programming problems like they are a puzzle to be solved, and more complex and elegant solutions are better. This is why I will never be a really good programmer, because I write code that even I can’t understand 6 weeks later, and I rarely write as many comments as I should.
      So jsonmez I think an important distinction is that the ’super programmer’ you are talking about can solve these really hard problems, but that doesn’t necessarily make them a ’really good programmer’ for most purposes.

    • A programmer that didn’t use unit tests:).

      I thought of that same apocryphal story about Gauss (adding the integers from 1 to 100 and seeing the pattern) when I saw the summation. However, I think you made a little mistake. This isn’t the summation of the integers from m to n… It’s the summation of values of the function f(I) for i=m to n… For example, what if the function is x^2?

    • You are supposed to sum F(i) not i. i is the one who is varying from n to m not F(i).

      Let’s suppose that F(i) = 0 for every i. Your formula would never give the correct result.

      Sorry man, but try again 🙂

      • f(i) is being summed. In that case it would just keep adding 0 to the total so it would be 0.
        Perhaps you can show what the correct code should be?

      • jsonmez, I was replying to the formula presented by idextrous, not the one that in the article, which I think is correct.

        • Ah, my mistake 🙂 My interface on wordpress doesn’t show the threading.

  14. I would make a little addendum: since the problems you have solved and know yourself able to solve are within your understanding, they will always seem simpler than those other people are dealing with.

    • Exactly, and that is part of my point. Because that is true, you can know that someone has solved your problem and for them it is easy and that some day you can also have the perspective about the same problem.

  15. This doesn’t make sense. If you are a programmer you MUST understand the equation since you study a brutal amount of maths at uni. If you don’t tha means that you aren’t an engineer and therefora you are not a programmer, you are an amateur.

    • Plenty of developers do not know or have forgotten most math past algebra.

      • forgotten is the keyword here, john. great programmers might be able to gain the math know-how somehow, if given another chance. but those who doesn’t know math at all, will never be a super programmer. btw, i follow all your topics at pluralsight, great stuff!

        • Thanks! I agree, also though anyone can learn math, even complex math.

  16. nicely written – lovely the way the formula looks so complicated in mathematical notation and so simple in code….but that’s probably just because I’m used to code

  17. But simplification is the hard part… Being able to understand a solution and being able to come up with a solution are two very different things.

    • Usually though, I find that actually understanding the problem completely leads directly to the solution. The hardest part if understanding the problem fully.

  18. I agree with the gist of your post. I’d state it as “Most people overestimate the complexity of problems in domains they don’t understand”. For example, I’m sure most programmers think they couldn’t write a Linux kernel driver or write their own (toy) OS from scratch. But I’d wager that most programmers can do them with a little guidance.

    But I don’t like the logical conclusion of your argument, which is “any Java (or PHP) programmer could become a Linux kernel hacker, except maybe they’d be 20 times slower”. I don’t buy it.

    I don’t think all programmers are capable of fully understanding complex software like the Linux memory management system. It’s not a simple matter of understanding one aspect of the problem: all the aspects must be understood at once (CPUs, page tables, DRAM, cache lines, NUMA, transcendental memory, RCU locks, power management, etc). As Paul Graham says, “you have to unpack the whole problem and walk around it in your head”. The vast majority of programmers will never even bother trying to understand how memory actually works. (Try getting your co-workers to read this paper: )

    People pick the level of complexity they are comfortable with and stay there. Sure, they could easily move up a few rungs on the complexity ladder. But I don’t think everyone is fully capable of climbing it. I’m not trying to sound elitist, but what you are saying is equivalent to “every doctor is capable of being a neurosurgeon.” I think at the cutting edge of programming, higher skill is actually required.

    • Agreed. That goes for all fields.

    • Agreed, especially with your last sentence.

      I have this class made many years ago that basically implements an LRU disk based cache with in memory tables. I feel quite confident that I know how it works. But if you asked me to design it back when I first started to use it, I’d have no idea. And even now, I’m quite certain that I could develop something like it, but it just would be as elegant as the original. Thats because the person that designed it, my mentor, was one of these super programmers. Sure, I could break it down into pieces and eventually figure it out, but the sum of my parts still wouldn’t be as good. I think that, the sum the problems, is something the author hasn’t fully fleshed out.

  19. I think that one of the things that I have noticed sets the good programmers apart is simply a good memory. As you say a complex problem can be broken down into simpler smaller problems. However, those smaller problems may be steps that you have taken over the past 5 years to bring you to that point. Being able to remember all of those small steps can be difficult.

    As a programmer you have to be able to keep track of a hundred different tasks in order to: Not make the same mistake twice, implement a feature based on past experiences with similar features, implement a feature keeping in mind past mistakes on similar features, remember that gotcha that happened last time you worked with a certain technology, and on and on.

    I think that a good memory is one of those things that can really set a programmer apart and make them appear “Super”. Rather they are able to take full advantage of their past programming experiences, especially those small steps that lead to the solution of the complex problem.

  20. I kind of agree. Joel on Software always goes on about superstar programmers and seems to think an understanding of pointers and recursion is the way of telling the good from the bad.

    Here is my experience. Give me an interesting project and a good tools (e.g the Django framework), and I have been way more productive than in my previous job where I was given all the crap / boring data related tasks to do as I was the “database guy” in the group.

  21. As a software project manager who was a highly sought after software architect and programmer (avionics) for many years, I more often think of a super programmer as a level of productivity. For me a super programmer is someone measured to be a sigma more productive (sloc) than the average and at equivalent or lower defect rate. There are programmers who have domain knowledge (problem space) of complex systems, but it is rare for programmers (implementers) to drive requirements and have a wide understanding of the system. This is the unfortunate reality for sw professionals. Even software engineering degrees don’t usually teach a lot of real engineering ( don’t teach how to trade design against lifecycle cost). Real programming is actually pretty boring because everything is already decided and all that is left is to code it up. If you enjoy the creativity and freedom of understanding and driving the big picture and full life cycle development, then real programming is likely not for you. Even though my Degree is compSci only, I’ve been able, through gaining many years of experience and demonstrating wider skills, to work into a rare position where I am driving a complex system from all the engineering angles, from invention through test and field support. These opportunities are more often reserved for engineers rather than sw geeks.

  22. I’ve done both… Highly mathematical heavy applications designed to find faults in structural engineering before things are built (you know.. such as predicting at what points and under what conditions trusses on a bridge may decide to sheer)

    And I’ve done things that are basically work-flow related (typical) data processing type things and automating business processes.

    In reality, I’d say the data processing/work-flow types of things are usually harder to do. With math-heavy applications, its a whole lot easier to anticipate and test for failure. Because there is generally only one right or wrong answer and it lends well to automation. Your end users are typically scientists or engineers themselves who understand the concept of a step-by-step formula or recipe to solve a particular problem.

    Automating business processes are often not nearly as predictable. And require engaging those that may not quite understand their workflow beyond the very typical “successful” use case. The avenues and requirements for creatively solving the problem here are a bit more important here too, as you don’t have decades of proven mathematical laws to fall back on.

    And while I would pass all of Joel Spolsky’s criteria for superstar programmers, and normally I agree with a lot of things he says, I’d say he’s off the mark on this one. Ultimately, a programmer’s worth is related to how useful his app is to those that use it. They could care less if you’re using pointers or following the published Fowler design patterns.

    In my opinion, a better means of measuring a developer is how well they solve their problem within the restraints they have. FogBugs’s own Trello is an example. It’s a great single page web app, and to be able to get the functionality they have in it by merely using coffee script on both the client and server is simply amazing.

    • Great points!

  23. Everything is simple, once you understand it 🙂

    What I’ve noticed is that decomposition is a great skill and will get most programming done. But abstraction is considerably more powerful, although many programmers have trouble coping with it (they prefer the code to be very specific). And of course complexity is also a killer and everyone has a different limit on how much of it they can handle all at once. Like any profession, some people are naturally more talented, but lots of learning, practice and hard work can sometimes level the playing field.


  24. You say that the author of the email “inferred” that most of your topics are easy topics.

    No, the author of the email *implied* that. You inferred. You have the two words backwards.

  25. You are not wrong sir. To change the subject a little…

    It’s extremely troublesome how non-programmers christen one “super”, or “poor”. They judge the programmer by their own values. Salespeople think that a programmer that thinks like a salesperson is a super programmer.. Aaaargh!

    I would add a few of strategies for those that are stuck on a plateau. They are identical in how they both require uninterrupted work.

    Most “aha” moments come during a period of rest. You try to solve the problem, run into a series of brick walls, and then do something else– eat, sleep, shoot pool– that’s when you get the clue that leads to the solution. You can’t cheat this though, if you rest too early, you get diddly.

    Do your thing for three hours straight, with no interruptions, every single day. Stephen King? Writes three hours a day. Olympic medalists? Do their sport three hours per day. It’s the same with programmers. This all falls apart in the office environment, because others distract us, and that kills good work, If someone asks a two second question, but the task switch takes 15 minutes (in other words 15 minutes to get completely back “in the zone”), then you aren’t going to get the truly great work done. Those that think that they can, are simply too used to working below potential.

    You need time to unlearn your mistakes. This part is easier to understand for mechanical skills like playing an instrument, or doing a sport, but it holds true for solving problems too. Most of what we do during practice is probably right, but there is a percentage that is wrong. You need breaks in order to forget the wrong parts. This is why athletes limit their time doing their sport. They need to forget the 5% that make them miss the target, in order to make the 95% be all that they retain.

    Me? I’m screwed. CFS has crippled my ability to continue programming well.

  26. Hardest thing I did: write a program to digitise time series data recorded on ancient circular charts, where the pivot point for the pen-arm was such that the “lines of same time” did not pass through the center of the circle. The geometry was j-u-s-t within my grasp.

  27. I don’t understand much, but to use my commonsense, their is always the best way to solve the problem. When I program impossible or dream big, I break it down into simple and doable task.

  28. Great post and angle.

    Problems that can’t be decomposed into simpler problems do exist.

    As an example try writing code on-top of awful middleware or writing code on a platform that should be threadsafe – but isn’t.
    These are really awful problems that requires testing-patching cycles… and you don’t know when you are done. When your product is considered done you just hope that you patched all the holes.

  29. The superprogrammer is not a myth, it’s propaganda. Every time you need to get a job you have to send your CV that details where you have worked, yet, when you get to the actual interview, you are asked about algorithms and logical problems with eggs and billiard balls. And if you get them right you feel like you cheated, because you have never used them in real life and , oh boy, you get to use them now. But the tasks you will be required to solve are HTML and Javascript interfaces because mobile phones are on the rise.

    Bottom line: the big development factories, the software corporations, they need to have you think there is a superprogrammer type out there that you can’t ever be like. That’s why they ask you all those silly questions about bubble sort and act all disappointed when you tell them to Google it and that’s why they have “career paths” that have several levels, yet there are 5 people in total that are above your level in a company of thousands.

    I’ve met people that I can’t ever be like, whether because they were just *that* smart or because they had access to learning something I considered interesting and never had the time to study. Yet, in the end, it all came down to if we could work well together or not.

    • Excellent post

    • The superprogrammer is not a myth, and it’s not propaganda, either: it’s reality. I know this because I am one. There’s nothing I can’t write, and nothing I can’t learn. In my time, I’ve written operating systems, compilers, database engines, firmware for tape drives and hard disks, device drivers, enterprise-level database applications, games and so on, using so many different languages and environments that I’ve basically lost count. Whether every programmer can learn to do this is debatable: my answer to the question, however, is “no”. They either burn out or lose interest at some point, but most of them aren’t smart enough to make the conceptual leaps one needs.

      Here’s what’s missing for most people: the superprogrammer needs to know everything. Not just about programming – I mean everything. If you’re going to write a system to formalize something, you need to know how that system works. If you’re capable of writing anything at all, then that means you have to know how everything works, or at least be capable of learning how anything works. Most people just aren’t smart enough.

      If this sounds arrogant, then so be it, but that’s the way it is, and you can call me deluded if you like, but I’m used to that: mediocrity always views intelligence as insanity.

      • Well to truly know everything would require some sense of humility. Don’t you agree? 🙂

        I’ve had the pleasure of working with some truly brilliant people in my life. But the most brilliant ones always seem to get past the elitism and see people for their strengths and know how to relate to a “mediocre” individual on a level that doesn’t socially alienate anyone involved.

        More to the point of Siderite, those tests given during interviews are not pragmatic. If someone has the drive and desire to be one the “super programmers”, then that’s a fantastic personal goal. But as far as the cares and daily operations of the real world, it’s largely an irrelevant one.

      • Agreed 100%. The humility doesn’t come across in what I wrote, but it has to be there for one still to be able to learn things. Once you think you know everything, you can’t learn anything any more. It’s a goal – not necessarily achievable – but the growth is in the journey… and so on.

  30. Of course there exists “hard problems”. But the programmer who is repeatedly claiming to solving hard problems is probably not solving on computer terms and is probably not producing clean code.
    A super programmer is the one who consistently takes “hard problems” and produces code that reads “oh-duh!” like the puzzle solution in the back of a magazine. Producing clean code with clear unambiguous terminology because it is based on common computer domain mechanics.
    The paradox is that a super programmer to the uninitiated only appear to solve simple problems.
    Also, the problem solving skills are only part of the skill set. Programming is also about problem decomposition, implementing, closing and shipping.

    • Great point.

  31. If you wanted to make a point, you could have chosen a seemingly harder math problem. Presuming that any programmer who reads other people’s blogs, or even an undergraduate student for that matter, doesn’t know what a sum is? “Ready?” That’s nonsense. That’s exactly what the mail you received was all about: you have a trivial problem, and then act like it takes super powers to solve it. Not to mention the solution had errors initially.

  32. On Genius and hard and simple …

    I once worked in a team of my Peers.

    Sounds like a throwaway statement, but there’s rather more in those words than I suspect many would see.

    We each (as singleton “fixers”) turned failing projects around and “did the impossible” on a daily basis.

    We produced and delivered things that did what was needed rather than what somebody else mistakenly said was required. We all did exceptional things and wondered why they had not been done that way in the first place.

    I spent many an afternoon in a Pub with inner-circle colleagues, drinking beer and mulling over what made us so great when the things we did were so obvious to us.

    I came to understand the answer was in those last three words – “obvious to us”.

    I truly believe most things are “simple” – it’s the view from individual points that can make things seem difficult.

    I would say that many (if not most) folk would describe Relativity as “hard”. Darrin attributes Einstein with “If you can not explain the theory of relativity to your grandmother, then you probably don’t understand it yourself”. I interpret this as if you don’t see it as “simple”, you can’t lay it out in a simple way.

    I would extend this notion with “You don’t really understand something until you understand it in more than one way”. I used to think these words were mine until it occurred to me to Google the last 7 of them. Frequently it seems, the words are attributed to the scientist Marvin Minsky; perhaps I read them at some point and the essential beauty immediately became obvious to me – the minor detail of the source being forgotten in the ecstatic moment of enlightenment.

    No matter – with some things, I have also come to believe it is more important that they be known than what they mean. However … I digress.

    Imagine you are in the woods with a bunch of friends. It’s not important why at this point, but you are convinced there’s a bear in the woods too – but no-one can see it right now (“hard”).

    You all move about until first one of you, then all of you, spot the bear.

    You are now all viewing the same bear from different points, each with an apparently different ancillary (ie non-bear) view of the rest of the universe – let’s call this “Context”.

    You all now see a bear in a number of different contexts (more than one way) but it’s the same bear. Collectively, you see the same thing in a number of ways, and if you each communicate your view to each other … well, I’m sure you see where I’m going. Suddenly, mere belief is superseded by understanding – the notion of “there is a bear in the woods with us” is “simple”.

    To bring the threads together, the bear is the topic, each line of sight is a way of seeing the bear and the set of views taken together offer more information about the topic than in each individual context.

    Now for the really important bit. It wasn’t important back then, but it is now. This whole scenario started off with “ .. you are convinced there’s a bear in the woods ..”. This was how the team achieved great things – we believed there was something to look for that would make the hard stuff seem simple. We then moved around mentally until we saw it in a number of ways, if only to confirm that this was the right thing – it had been found and we understood it.

    And so to my final point; the second word of the title – “Genius”.

    In my view we weren’t Geniuses (I SO wanted it to be Genii), it was the bootstrap-like thing we did that was genius. The fact that it was blindingly obvious to us, and that it became obvious to anyone else too but only after we explained it.

    Just my two cents-worth.


    • Nearly forgot the most important bit – I LOVED this article.

      Serious Kudos to you John, wise words – many thanks for sharing them.


      • Thank you sir!

    • Good example. Took me a bit to see what you are saying, but I get it. Also very true about understanding something more than one way. I find that I don’t really learn something until I do and that the easiest way to solve a problem is to gain a very deep and multi-dimensional understanding of the problem. Often the first glance of what we think a problem is, is not the real problem at all. It requires a deeper exploration to see what the actual problem is and understand it.

      • “Often the first glance of what we think a problem is, is not the real problem at all”


        Ahem. I mean precisely – another of my favourite sayings is:

        “OK – you may be coding the solution right, but are you coding the right solution”

        This is clearly what happens when you don’t understand in enough ways.

        We are of one mind I suspect, John. Thanks again for sharing.


  33. I am number 2. In my scool these mathematic algebra (If it is even called that) were not tought. Espeacly about the first symbol. I am cluless about that. If there is any reading material i would love to read it.

    I am hobbiest programmer.

    I did come to a problem where i thought i could never solve this. Then i decidet to try to write it. I Did reach a problem and couldn’t solve it. DId a research on a google, MSDN and forums. Managed to solve it.

    Before going to bed the code was in my head and thinking if I did that what could come out. Next day i comment out my code and try alghoritem that was stuck in my head. And i manneg to make it work and the new code was about 30% shorter (Just a few line less) and cleaner. Tested it out and it worked. Removed old code.

    I was happy with the result.

    Some code are too much for me like hash alghoritems and I know there are plenty alghoritems there so I awoid re-enventing the weel, and use either build-in or find already solved 3rd party code (Open Source or sample).

  34. From your post: “I’ve just never seen a problem that couldn’t be broken down into simple to understand components, yet.”

    … and this is indeed the hardest part.

    This is what “real” programmers or engineers in general do, and you need to have your mind set to it, and what wannabees will never understand or master.

  35. I totally agree that everything is simpler when you break it down into small chunks. But often times the hard part is figuring out what small chunks you need! That’s what sets the superstar developers apart – they are able to quickly see the solution to larger problems, effectively break them down into small tasks, and do it all much faster than the average developer can do it.

  36. There’s a big difference between writing difficult software and writing straightforward software that deals with some difficult math (or other domain knowledge). I would contend that unless hardware or performance limitations necessitate otherwise, a programmer should always aim for straightforward software because it’s more maintainable and compilers will probably optimise the heck out of it anyway.

    I’ve always been surprised that a coder might think it was really cool to compress 3 lines of code into one terse statement whose intent was not at all clear. But I’ve met so may of them.

    The hardest bit of programming I ever had to do was hard because I had limited knowledge and tools. It was fast, small and only I could ever have done anything with it. A few years later I re-engineered it from scratch in another very simple way and created something that was a bit bigger, a bit slower, and was used and maintained by others for maybe 15 years thereafter. Which was the cleverest bit of programming ?

  37. Perhaps we should really be distinguishing between ‘programmers’ and ‘developers’; the first can make a good engine, the second can make the machine drivable by ordinary mortals or even (in paradise) enjoyable to drive!

    The second can even help the driver to explore and drive to their full potential . . .

    I think the hardest thing of the lot is trying to relate to a myriad forms and facets of user intuition, and the real art lies with those who are able to marry the science and craft of writing really good, intelligible code that translates easily into interfaces that work well with human perceptions and dirty-hands needs.

    Perhaps their approach then is diametrically opposite; programmers tackle the problem first, developers begin with the solution?

  38. For me, the process of decomposition is where the difficulty can manifest itself. For one, there are often several different ways one might decompose the complex item into simplified steps. Seeing the “best” way in advance can be challenging. This does appear to be something which one can improve with practice, though.

    For another, which combination of simple steps to use (in other words, the definition of “best” for the particular problem domain) can often require some compromises related to architecture or user needs. A system which must only perform in isolation may have very different design parameters than one which must interface with external systems, thereby requiring a different set of steps. While modern design and architecture principles have helped to minimize this, it is still part of the equation.

  39. I completely agree. No problem is more difficult than another, except that some problems request more steps to be solved. and the difficulty to see the connection between the first and the last step is what makes things seem complex. but once the first step is taken, the second becomes obvius… the n-th step is taken, and n + 1 step is obvious. problem solved.

  40. As a humble amateur-coder who has a background in science, I think the problem is that programmers are somehow supposed to be whizzes with a computer, period. It would be like saying a good scientist is a whiz at science. It makes no sense, because within each area there are specialisms. A competent programmer can code and comprehend basic algorithms, but each also has some sort of specialism. This may be a frequently-encountered specialism popular in the commercial sector, such as ASP.NET, hacking networks, using a proprietary mobile IDE, or database-interfaces or data structures, or something more esoteric like numerical methods for solving differential equations, designing novel data-structures, or advanced-graphics algorithms. In my humble opinion, the IT sector needs to mature and realise that a good programmer is not someone who can do anything and everything with a computer, as that’s impossible. Rather, a good programmer is someone who has good basics and good competency in one or more specialisms.

  41. Anything is easy when you know the answer. 🙂

  42. If you do any system-architecture work (or even the framework for a medium-complexity desktop app), you’ll find that you can’t always break everything down into simple problems. The entire system has to be understood; a collection of well-designed components are useless if they don’t work well together.

    Code is only as good as the client system it’s used in. I’ve seen beautiful code tied together in haphazard, inefficient systems that had to be ripped out and re-done using ‘dirty’ C code.

    And the choice may not be yours at all, if you have to work with someone else’s over-designed library or API.

    There’s also ‘business’ logic that tends to change to strange and convoluted ways, reducing your beautiful codebase into a labyrinth that only an ace developer could unravel!

    As for actual math problems, I rarely encounter anything that can’t be solved with a little trig, basic algebra or geometry math (cross products and such). But if you do anything in physics simulation, rendering or AI, the maths gets insane. Even if it can be broken down, the papers and research assume a math-rich vocabulary from the get go.

    If you have the pleasure of meeting programmers who are math aces, then I think the ‘super programmer’ label does indeed apply.

  43. The super-programmer is the one who is lucky enough to work in a area he’s comfortable with.

    The Google programmer may have to work with low-level C code and master algorithms, while the enterprise-solution one will certainly have to work with C++ templates, know design patterns inside-out, and, above all, master politics.

    Move one of them in the other’s area, and all of a sudden the super-programmer becomes a (sub-)mediocre one.

  44. In the end, just like in life, it is all 1s and 0s, yes or no.

  45. Here is a an example of hard programing

    Try doing it

    Although it’s only seems hard if you don’t know how to solve and create programmes that make use of linear equations.

  46. When I was in college, I was able to master my programming classes, but struggled and barely got through Calculus. I have been able to have a career as a developer of over 22 years despite the difficulty with Calculus. No one in college seemed to be able to understand why I had no problem with software development, but huge problems in math.

  47. Nice article. For me a super programmer is someone who understands the code he has written in such a way that it is flexible and can be easily adapted when needed.
    And also the algorithm is more important then the code. So document the algorithm.

  48. My favorite Einstein Quote: “Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.”

    I consider my self to be a “Natural born coder” I love it. I’d do it even if I didn’t get paid for it. I know what I want to be when I grow up. Am I a “Super Programmer”? Nope. There are people out there who are better than me and there are people out there who are worse. Even for the people who are better, they are probably focused on one or two aspects and are sadly lacking in other areas. They may be capable of hacking into the most secure computers in the world but have no idea how to build a usable interface that anyone could use. Or they may make beautiful interfaces that besides looking good don’t work. Who knows. I just love what I do.

  49. Maybe most problems can be broken up into smaller problems, but some are just plain difficult no matter how you want to try and subdivide them. This is even more true when you add in the constraints on solving the problem in a piece of hardware such as processing power and/or memory available.

    I would say the hardest problem I ever worked on involved about three pages of simultaneous equations that had no direct solution. You had to ‘estimate’ several variables and then solve for the remaining variable to find a minimum value (from several localized minimums). All this on an imbedded processor with limited processing power and no floating point unit. No way that I’m aware of to subdivide it, just a lot of code to make ‘smart’ guesses on the ‘estimated’ values and optimized code to evaluate the equations as efficiently as possible. Maybe there was a better way, but I don’t know what it would be.

  50. One simple answer :

    Some problems are not just about divide and conquer. Some tasks require work , other require ingeniosity, thinking.It does not mean geniuses are needed. Sometime they are, but most of the time not. It means that some problems are really difficult to solve, and need the attention of definitively skilled people.

    In the end it’s only a question of the right man and the right place

  51. I’ve had many developers tell me they wish they could crank out code like I do. And then I go to my office and sit in puzzlement as to just what do they mean. But I realized over time that the reason I may seem “super” is because I take the big problems and break them into small tasks.

    I had a tools development team once and had the job of bringing in college graduates. The senior developers all thought that was wrong, they are being thrown into too difficult an environment, but I accepted them with open arms.

    One planned implementation had one of these developers working on the problem for almost a week without talking to me. Then he and his helper came and said ‘it cannot be done’. I asked if he could PROVE the technology isn’t there to solve the problem and he hemmed and hawed. I said to break it down and gave him a starting point. I asked him to prove to me the first step could not be done.

    A week and a half later he stopped me as I passed his desk and with a huge smile showed me the working prototype. I was happy but he was happier. He performed a ‘super programmer’ task without any programming help from me.

  52. I bought a game called Hi-Q, a greek cross with 33 holes, 32 pegs, and an empty hole in the middle. Not wanting to waste time manually solving it, I wrote a routine in assembler on my Univac AN/USQ-20 (think microsecond instruction speed) to solve it for me. There are 31 levels, some number of moves at each level, make one and continue to the next level. Each level offers a pop-up, push down opportunity. Simple! My routine was making 100 moves/sec and I expected an answer after lunch.

    The answer wasn’t there, in fact, it never got beyond the 25th level. Analysis (something I didn’t do at the outset) showed that given the number of available moves at each level, taken exponentially, would consume several billion years to play all possible games. I didn’t have that much time available so I did my analysis and showed that the game was bilaterally symetrical both horizontally and vertically meaning I didn’t have four moves at the start, only one. I put in a routine to remove half of all symetrical moves. It played slower but got a couple of levels higher. Finally, I put in a routine to save patterns at the halfway level going up and played the game backward (coming down) to that level, matching patterns (taking advantage of the crossing of exponential curves at a relatively low level). I got an answer in just a few hours.

    All this just proves that great programmers don’t just solve complex problems in measured steps, they thoroughly analyse their approach first. Early in my career, I missed that first step.

  53. Good point. I’m not sure if I complete agre with you. Let me express my doubts

    I believe something similar to what you say, but with some points

    The thing is, the example you have written about is quite simple. The level of Math required to understand it isn’t very hard.

    In my last project I had to use Kinect for Windows SDK 1.0, which provides a collection of joint positions for each body in front of it (well, just for the first 2 bodies). I had to take those positions and get the orientations (Quaternions) to apply to the bones of a 3D model to animate it with the same movements as the users.

    I managed to do it. And I believe it is quite hard (or extremely hard if you prefer) if you are not used to Quaternion algebra. Or if you’re not a game developer.

    After managing it, it all has some sense, and I don’t find it all THAT hard (it’s really hard. But I have done it before). the difficulty of the task was really the difficulty of acquiring the knowledge

    So there are 2 kind of tasks:

    1.- tasks we know how to develop, and we can tell that are simple, or hard
    2.- tasks that we don’t know how to handle. With those tasks, you have to investigate first just to be able to say if the task itself is possible. It might be impossible. Only after we have the slightest idea we can begin to think to solve it

    Then I don’t believe in superdevelopers. I believe in people who after years of working have some experience in a certain amount of things. Which is the same as saying that I believe in experience.

    • I agree with what you said, but I think I probably failed to realize one of the reasons why difficult problems can become simple.
      For your example with the Quaternion algebra, once you have solved the problem, you could have made a library that others could use so they wouldn’t have to know Quaternion algebra.
      In many cases problems are broken up by not just one person, but buy a whole succession of developers or mathematicians.

      The whole idea of Calculus for example, is just a simplification of many very complex problems. It is an abstraction which allows us to work at a higher level.

      • Agree. However, to a certain degree and with certain tasks, I believe you MUST know the tools you are using.

        It’s not like a car. You can use a car and not know how inner explosion engines really work

        But the thing with 3d engines or 3d models is that most things aren’t really standards. but tailor made to suit your needs (at least in my experience. And I don’t know a thing about games. I’m a enterprise app developer). Maybe it’s that this field isn’t as mature as others. Maybe is that game studios have the knowledge and they don’t share it eagerly. However if you google about it, you won’t find almost anything usable. At least not when I did it

        With any application you try to do, you must have knowledge about developing in itself (the API, the platform, patterns…), but also about the domain (and doing an accountancy app isn’t at all like developing a music writing app, or an architecture app, or a game, or a maths library). However, people tend to underestimate it. I am bored to discuss with marketing managers that some things are near to impossible to the developer profiles we have. I bet you know what I’m talking about 😛

  54. I guess I am one of those ‘super programmers’ I ‘know’ this because A number of people in the industry tell me “I’ll bet there are only a hand full of poeple in minnesota that can do what you do” – I used to think they where just saying that, but I keep hearing it from different people. Like the artical says – I never thought of my self as some ‘mega-programmer’, Very good, yes, but a ‘mega-programmer’ – no. What i do is basically just what the author said. I look for reoccurring patterns and break problems down to smaller simple ones that can be handed off to others 🙂
    I suppose 30+ years of experience doesn’t hurt either.

    If you want to visit a good site that tells more about doing that look at Hamilton Technology.
    Hamilton was the lead programmer on the Apollo project and knows a thing or 6 about high reliability software

  55. jsonmez

    i am a programmer, and i dont consider my self a SUPER DUPPER because i can solve complex problems by making them smaller and fewer.

    i consider my self good, because i can do that without trying, my mind does that automatically somehow, and i can code it fast, even debug most of it in my brain!

    not mayny so called “programmers” can do that! they simply copy paste stuff arround!

    now what you are tlaking about is LOGIC! and i defenetly agree with you, it may basic reason why my Fiance who is into finance and economics, so she is pretty good at math etc, everytime she is trying to solve a mathimatical problem, she uses the equation she knows…i dont for 2 main reasons!

    1)i dont know them that good

    2) i dont need to know them, i slpit the problem with my mind into smaller simplier problems,

    and 9/10 is just a bunch of + or – or * or / that you have to do nothing more nothing less! and with simple logic i always give her the exact same resault she found with the equations, and sometimes i do it faster!

    that drives her nuts! she cant understand how i do that, so she is the kind of people that Cant be a good programmer!

    simple as that.

    good programmers think like a regular CPU, knows only 1 or 0, every complicated equation ends up been just 2 mathimatic processes Add or Remove! thats all!

    the CPU thought can do this in milliseconds when we cant.

    thanks for your time jsonmez

  56. Excellent blog entry. As someone who is new to programming it intrinsically feels correct and that makes me even more inspired to code every minute I can.

  57. Thank you for this. Whenever anyone is enchanted by the idea that I can write a program I tell them that 50 percent of problem solving time is spent “googling” it. I often feel like a fake because I can’t recall every useful function without looking them up. This is very insightful, I am glad to see that other people feel the same some times.

  58. One of my Engineering firm clients has a favorite saying, “You can teach an Engineer to program (even if poorly) BUT you can’t teach a Programmer to engineer!” And they are 100% correct…

    As a result of multiple terrible experiences with computer science trained personnel they now hire Engineers exclusively and just assume they will acquire the programming skills to get the job done… and they do!

    And yes, the code may be terrible BUT it works.

  59. Hard problems ? What about fixing the multi-threading issues in an extremely complex and poorly designed 2.5 millions line of code product ? Or implementing an efficient massive exotic pricer ? Or an aggregation engine that have to be so fast that you end up counting cycles and learning about cpu stride access when doing the high-level arch ?

    One one hand, I agree that one don’t need to be a super-programmer to solve problems, and the world would be a better place without people thinking they are super-programmer and using their skills to over-complicate mundane problems. A lot of simple solutions to simple problem often give a good solution to the complicated whole. That’s 99% of the programming world.

    But, on the other hand, I have seen many problems which are not even worth giving to a “normal” programmer.

  60. “What is the most difficult problem you have ever been asked to solve?”

    I would guess that a great many of us have to deal with business or product people who “just want it to work.” You know the napkin design, or rather an email chain with bits of information and wishful thinking that passes as a specification. Hell even written specs, are rife with incomplete concepts.

    I’ll argue that for most engineers their most difficult task will be putting vague ideas and perceptions into reality, that eclipse the algorithmic details of their problems.

  61. Math problems aren’t the difficult ones. I once had to write a contract system (for the developers of the PlayStation 1) — here’s what the spec for the system said: “We want it to be as flexible as using a piece of paper, in terms of what we can agree to, but it still has to enforce the terms.” This was in 1993, and I had to write it in FoxPro. IMHO, that trumps any math problem. (It worked, too!!)

  62. I am an applications specific programmer. My field of expertise is Electronics Test or Automatic Test Equipment for electronic components. I use various languages, which have been tailored to help map the complexities of electronics test equipment and the connections to a component into a form that is somewhat more managable than writing lines of code to drive instruments to have an output, then searching for a way to map that output to a device pin.

    Because modern components are so complex, in most cases, no one person has a global concept of the overall design. A team of engineers constructed the device, used software to simulate it, and to simulate the connections between parts.

    They likely do not understand the simulation software nor the underlying algorithms which converge on the solution points in the simulation. The device has test paths which are mapped out by the software (JPEG is one standard if you are interested) and the software will also generate the data streams used to drive the part and check its output.

    Mixed signal and RF demands more software and hardware to evaluate linear results, including FFT’s, Smith charts, eye diagrams, and other somewhat unusual software (at least unusual to the average software enthusiest.)

    These complex devices must be tested quickly to keep the cost of test down. This is accomplished by performing multiple actions in parallel. A good design will be downloading the next set of test data to the instruments, the instruments will be running some number of concurrent tests, the data from a previous set of tests will be processing in the background sometimes on additional processors, prior test results will be verified against test limits while the test before that one will be datalogged somewhere in the system. All of this may be occuring on several devices in parallel if the tester has sufficient resources. Much of this is managed by system software, more is managed by the construction of the test sequences in the running software, and other bits are managed by hardware division.

    Designing one of these programs takes some time, but since the device life time today is about 18 months from first production until the next generation, the delivery time for each program is measured in weeks. Each program will have thousands of tests, and the program is expected to run 24/7 in places all over the world. This implies taking into account the various power line intereferences, and the measurement requirements in different countries.

    I have taught the classes to engineers on 10 different test systems.

    One of the main tenants I teach is that ones view of the problem is the driving vision of their solution. i.e. you solve the problem as you see it.

    One of the recurring themes of bad software in this environment is what I call the probability loop, where when a test fails, it is rerun in the hopes that it will pass the next time. Nothing is changed in the code, the test is just rerun. What drives this is that there is some feature (bug?) of the device that is not being properly driven, such that it is not consistant in its response to the stimulus. These loops exist because the programmer was typically rushed to get the code into production, and did not get sufficient time to resolve the conflict in the device/hardware/software that caused the anomolous action.

    One could argue that a “super programmer” would not let that bug into production. Or one could see that the necessity of releasing the code overcame the capability of the engineer to find and resolve the issue. In any case would you call the engineer a super programmer? After all, in thousands of tests on the device he probably only has one or two of these bits in his code. This is a hard decision, and the side of it you come down on will depend quite a bit on your own experience in programming. I say he did his best. Could I help him find the issue? Maybe, or maybe I could give him a better solution, but either way, maybe I wasn’t in that particular forest and so my view of the trees was a bit different.

    Les H

  63. I’ve worked with a few people who thought that math problems were all that and a bag of chips in terms of complexity/difficulty. As for myself, I don’t know if I’m a “super programmer” or not but here are my bonafides: I’ve designed and implemented a couple AI systems. (One of them was part of the CRAFT project mentioned in Bill Gates’ book, “Business at the Speed of Thought.”) I’ve also done applications and rather complex manufacturing process control (vacuum deposition in situ measurement and control). I’ve also done quite a bit of other work ranging from telephony engineering to order management to accounts receivable to, yea verily, even reports.

    My experience is that it’s not so much the math or the decision tree or identifying and describing all possible states in the finite state machine et al. In any case regardless of the target solution set, you best have an SME that can define the requirement and test your work for your target or you’re pretty much hosed out of the gate. The rare exception to this is when you also happen to be the SME…then you better find a good tester or community thereof.

    Math, even complex math, isn’t that much. Consider that whether it’s the formula in the blog post above or calculating real time utilization for features in a telephony environment (i.e. How much does call waiting your processor on an Asterisk server?), these should be solved problems when they’re handed to the programmer. (If you’re switching hats as the SME, see above.) If the math guy can’t explain this UNAMBIGUOUSLY in about 5 minutes to the programmer, he better go back to work until he can.

    What’s painful is when someone hands you something like the real time question and then adds, “And we need to be able to update this daily. And we need the updating to be done by the math guy who only does a little programming. And we need it to be cheap. And we need it to be on the network. And we need it to be available 24/7 because people all over the world are using it.” Then you have a “super programmer” class problem.

  64. Agree with your blog post completely. Our jobs essentially are taking big problems, breaking them down into smaller problems, and solving them while simultaneously linking it all together. First time here at your blog but I enjoyed the visit! Thanks for the post!

  65. I loved the explanation of Euler’s formula given by guscost.

    The only thing I have even marginally related is an explanation of a simple software FIFO. This process works well – even in a multi processor system – as long as . . .
    1) One processor writing and a second one reading will give the second processor either the prior content or the new content and not some h/w race condition mix-up.
    2) Assume that processor one writes two words A & B in that order and about the same time processor two reads B & A in that order. If processor two gets the new B it must also get the new A. (Possible caching issues here.)
    3) There is only one source and only one sink for the FIFO data.
    4) The compiler does not reorder the stores and fetches.

    Actually the hardest thing I ever wrote was the software for

    It was the constraints I was given that made the task hard.

    Constraint one: I had to replace the existing semi-functional code with NO hardware changes.

    The stove uses a PIC 16C57 – later changed to a 16F57 because they cost less. That processor has 72 bytes of RAM, inconveniently arranged in 4 pages. It has only 2 levels of subroutine call and no interrupt capability.

    Constraint two: Limited test bed. The factory was a 6-hour drive from the San Francisco Bay Area into the Los Angles area. I was sent the PCB and motors but could not test with an actual fire. Rheostats replacing the LM35s could only do so much.

    The 16C57 has an 8-bit timer that I set to increment at the 1 MHz instruction rate / 256. From that I made a series of timers. Reading internal temperatures with a pair of LM35s and an external ADC was not so bad. But this was the first time I ever did a control loop. First try I had WAY to much gain. The second try took longer to go out of control. Third time I got it under control.

    Later I actually got one of the stoves and noticed the fire oscillating between low and high. I asked the Sierra Products owner about this. His reply: “Don’t fix it. When the fire is low ash blows out of the burn pot. That’s good.” That was nice to hear because with one byte left I could hardly do any kind of PID control.

    Much later I learned the reason for the fire going low and high. It was due to my simplistic control loop. (Think equations for simple harmonic motion. Or the “I” part of PID.)

  66. I think a super programmer is defined based on an her average performance for an activity in which she consistently scores in the top 10%. By saying the “super person” is a myth, you imply that everyone can score in the top 10% on average and that is not possible according to the definition of average. 90% will never be in the top 10% no matter how you break a problem into simpler ones. On average, the super programmer finishes the same tasks sooner with a better solution and there is no aspect of myth to the outcome.

    There is a ROI to producing that outcome which is much higher for the super programmer. She is paid X for Y hours of work. If the average person has to put in 10Y hours to get the same outcome, it doesn’t matter if you define the super programmer as a myth. The fact is that she has a dramatically larger ROI is why we call her “super”. “A rose by any other name …”

    Furthermore, problems are broken into simpler ones at some cost. Hard problems are defined by their very high cost. If the super programmer converts a hard problem into simpler one and solves it, then the average programmer can’t be said to be equal the super programmer because he can solve the simpler problem too. That is like saying we all should get a metal for crossing the finish line even though we didn’t run the race.

    This is article should be taken down. It is like saying that the world being round is a myth because if you look at a small enough area it looks flat.

  67. Interesting post. I am a relatively mediocre programmer with only high school math experience, but my most challenging problems have been implementing a path finding algorithm and also a mandelbrot set explorer. Looking back, they were both easily decomposed into smaller problems, and not that hard to do. When I was just starting I was baffled by notation and big words and complex numbers, and it took me a while to work up the motivation to tackle the problems.

  68. For me, the hardest problems are always where I can’t leverage my previous experience. Inside my domains of expertise(programming language, programming paradigm, or industry) I can figure out a solution. It’s when I am working in contexts with which I am unfamiliar that problems see to be incredibly hard. Most problems would be easy to solve if I had known at the beginning what I know at the end

  69. The superprogrammers are the ones who work for NASA and major investment banks doing algo-trading algorithms and such, they all have 180+ IQ’s and yes they are elite, the best of the best. That is why they get paid 500k+ a year. Writing those low level drivers is not massively difficult, it just involves a lot of tedious assembly work.

    Your point about not understanding symbols being a barrier is very true I think.

  70. I started programming in the late 60’s on NC machines. I currently manage several programmers that design and program industrial CNC machinery. Over the years I’ve had the privilege of learning from some very strong programmers, contracted and permanent hires. I honestly believe anyone can write code if given reasonable instructions. However, the real difference comes from the individual’s ability to see through the fog.
    A good programmer must have a strong imagination.
    A super programmer has to be good, lives and loves it.
    They do exist.

  71. Mathematical programming is just another form of applications programming. Just dealing with the problem before you and that is all. Wait until you get into systems programming. It requires a greater degree of hardware awareness and user (other programmer’s) needs. In an application, you need to think only of the local problems before you. When making libraries that many other programmers use, you need to be able to service all of their needs. Not as easy as application or mathematical programming.

  72. As a super programmer, I think it is more a matter of attitude. The really best will look at something they have never seen before and say, “I can do that”. Ability is important, but willingness to use it is more so. I also think that when faced with a truly difficuklt problem, and little time to solve it, many ordinary programmers will show their super side!

  73. You are missing one point: Understanding a solution that is explained to you is easy (or should be if it is well explained). Finding that solution given the problem is not necessarily easy. Admittedly this does get easier if you have solved lots of similar problems, but if you are facing a new problem then you are in the same position as the people who think what you do is hard. Could they solve it? Probably, if they took the time to work on it. That is what you do when you face a challenge at work – you take the time to understand it and solve it as best you can.

  74. Good post.
    I have two comments

    1) Back in the day I started out as what was known as a Systems Programmer (the super duper of the time) and wrote lots of stuff that interacted with or changed the behaviour of the operating system including channel programs that retrieved data from disks. In the end I found it a repetetive and boring task and changed to applications programming, a much more satisfying experience.

    2) Recently I decided to use CSS in a more creative (for me) way and at first found it quite challenging but now (after two weeks) it too is quite easy. So the difficulty is usually in the newness of the task and not in the task per se

    So my point is that every task seems complex at first but with time becomes much easier. Every programmer who solves a real problem is a super programmer. The trick is to find where you find the most satisfaction and become competant in that area and above all DELIVER, which we all know is not as common as we would like to believe.

  75. I just want to say… I wholeheartedly agree with this. there are many people that think I (the author of this comment) completely have it together, and for SharePoint 2010, sometimes I do. but there are a select group of people that have seen me come completely undone about a problem I couldn’t fix. And for the vast majority of you, you have no freakin’ clue who I am… don’t worry, that’s intentional, as you will see… I do not consider myself to be a super programmer/coder/developer or “what have you”… In the end… there are people who are great in a problem domain that flounder in others, and there are people that can drop into any problem domain and they can figure it out and be successful quickly (as mentioned above). We all strive to be the best we can be… but ultimately, we still put our pants on one leg at a time, just like every other human being (that wears pants). To some I may be a rockstar, to others, I am a big fish in a small pond, and I wouldn’t be able to swim in theirs. what I would like to comment on primarily is the spirit of this thread.

    for those of you that proudly classify yourselves as gurus… you don’t own microsoft or facebook yet… so shut up and don’t get too big for your own britches… if you were “all that” … you would (own microsoft, in case you missed the reference while checking yourself in the mirror)… as it is… most likely 50 people in a small goegraphic area know who you are (and yes, you are better than them “whoop dee doo”), and if you are lucky, maybe a couple hundred in a few states/territories…

    for those of you who think that you are a nobody (i.e. the rest of the human race that are not narcissists [in case the folks identified in the above paragraph didn’t realize that’s what I was calling them])… there is always someone out there that will be more adept in something than you (yes, that even happens to the big shots), so stop comparing yourself to other people. I can’t dunk a basketball like lebron, and will never win an NBA championship (outside of a video game), but he can’t provision a sharepoint 2010 multi-tenant farm with two-way domain trusts and kerberos delegation. I doubt he’s concerned about it. why should i be? Now you say, well it doesn’t make sense to compare yourself to lebron, he’s a pro basketball player, your in “IT”. right… now you just got John’s point… to continue the thought … “and I don’t write operating systems”… but I could … honestly, any of you could too. it’s just another language, and pattern, and best practices… the point is you don’t, and most likely wont’… because the world only needs so many operating system device driver and process schedule writing programmers. What if I did want to play basketball? well, if I had enough time and money, I could potentially learn to play well enough to compete with lebron (minus a 10 inch height advantage … I will let you guess who has that), but even then, I would be a point guard at best, because there is not much call for 5’11” power forwards. and that’s a different role… so even though I am playing the same stat line as lebron, I am not pushing for the same stats…I want more assists, because the more I get, the more points he gets… and that’s my role. got it? good! because that horse is dead, and I am tired of beating it (darnit, I think I just pissed of PETA)

    Still not satisfied with that answer? here’s some advice I give all the time:

    1. Baseline your own skills (stop comparing to others) …

    2. make a plan for where you want to be technically over a 1-3 year period. (techical depth, promotions, etc)

    3. establish milestones … (certifications usually)

    4. Measure against the milestones (have I scheduled the cert exam, am I ready for the test)

    5. utilize role models and resources that you want to be like (but not ones that are narcissistic and treat you like trash, because you actually don’t want to be like that, at least I hope not)

    sound familiar? Yes… turn your own career development into a project that you will use to create a better product out of yourself (there are books about that, I could recommend one, but this is not about marketing). everybody that is successful at anything had to do that at some point, and everyone that is successful at anything was one time not successful (at that very thing they are currently successful). oddly enough… simply doing that (formulating a career path) creates the right attitude to succeed, and that will be perceptible to the people around you…. not to psychobabble or anything, but if you act confident, you are more likely to approach a problem from a positive attitude, and thus you are more likley to come to a positive conclusion. It’s forumalaic to some extent, if applied within the constraints of the boundaries in which you find yourself.

    take my word for it… I am the most normal, average, boring (yes this is redundant on purpose) guy in the world … and at this very moment I am sitting in a hotel in Redmond, WA… attending Certified Master Training for SharePoint 2010 … but I am no different from you (still talking to the not-narcissistic people that didn’t stop reading after the second paragraph, those guys are already down in the comments section preparing a scatching response) … I took the opportunities provided to me, I developed my skills to the appropriate level, and now here I am. Ultimately, I am merely living the American Dream… take yourself, devoid of anything out of your control, and make something out of that. everyone has a talent. use it. if you are not good at IT… why are you still doing it? you might make a great manager, or salesperson, or marketing, or whatever. if you need some inspiration, crack open that old history book about colonial america… something happened where a whole bunch of normal, average nobodies, did something really cool (sorry HRH), and that’s why I am sitting here typing this overly long response

    oh…and for the record I am terrible at math (getting back on topic for a sec)… only ever had College Alg II (and just barely passed)… never Calculus or trig, and it’s not stopped me from solving problems [and for the record, I am not stupid, last check, I have a fairly OK I.Q., but my wife’s is higher than me, and she stays home and takes care of the house, so … just read into that]. Some people would say I am an incomplete programmer, but I would tell them that sometimes, the more you try to classify a problem based on known theoretical principles, the less likely you are to provide the best solution (notice I didn’t say a viable solution) … they call that “thinking outside the box”. Math is simply too abstract and boring for me, you can sit all day long trying to figure out if a chicken or egg came first (i do feel that i have the answer for that if you like but this is not the right forum), but in the end, you will never achieve a mathematical answer to that problem … so many theorems, too few proofs… I don’t think being good at math makes you good at anything except being good at math (oh… I know I just pissed off a whole bunch of people but … oh well, this is United States of America and I am entitled to free speech of my own opinion, if you can’t get over that, you probably should have spent less time worrying about math and more time learning how to get along with other human beings, and accepting other points of view [which is impossible in math, because there are only formulaic ways of achieving things, hence the whole “thinking outside the box” conundrum, or maybe I didn’t get far enough in my mathematical disciplines to achieve the proper state of zen where thinking outside the box is achievable … but I guess I just don’t care]) … for instance, in the same way that being good at reading recipes doesn’t make you a world class chef. some things just take time and practice… and while reading recipes is fun . Creating recipes is a whole lot more interesting … (insert other trite analogy here), I’d rather spend my time solving real world problems in a way that is practical to the needs of business, than figure out how to implement a SOLID architecture every time with full separation between layers utilizing a 5th normal form Database. Theoretically it would work, and it would be the most well-designed system on the planet … but … who would pay for that, and how long would it take? (ie. ref above about “viable” versus “best” solution)

    Ok, now for those of you that want to spend time analyzing this response and debunking what I just said… that’s fine… but you MISSED THE POINT. Life is a journey, you are in your own lane, and I am in mine. we all get where we are going at our own speed, and the end destination is the same. the faster you get there, the more you miss. If you want to try to keep up with me, thats your business, but don’t feel bad if I you spend time looking at my bumper (not insinuating I am guru) … you might pass me by some day… that’s great, we can have drinks and slap each other on the back and talk about how you got there, and how I am now useless, and I can hand you the invisible baton that does not exist so that you can feel all warm and fuzzy on the inside. Being a guru or not is not the point, feeling like, on a day-to-day basis, that you are living a full life, regardless of external perception, is perfectly fine (i.e. normal). If you can’t get past not being a guru, then you are in for a long journey fighting against people you know right now, and people that are yet to come, and people you will never meet, just to stay on top of a pile that you will eventually retire from, fade into lost memory (and poorly documented code, because a guru’s code is self documenting) and be completely forgotten by 99.999% of the world (yes… 5 9’s), the other .0001% being those that think they are gurus and are “fixing” your crappy design. I’d rather sit back and watch. because I would rather be happy living in the middle than be sitting alone at the top.

    apologies to John Sonmez for microblogging in his comments section… just kind of annoys me when people think they are God’s personal gift to programming. Next time you take a dump, remind yourself who has to wipe your butt (please pardon my terseness) … for those of you that don’t understand … just remember “this” (sorry VB guys, if you don’t get that, you can’t be gurus… it’s impossible):

    protected async void ToiletUsed (object sender, BathroomEventArgs e) {
    Human personThatUsedToilet = HomoErectus.ConvertToHuman(sender);

    if (personThatUsedToilet.tookdump) {

    while (personThatUsedToilet.dirty) {


    for those of you that need an explanation of this method, well… you’re just not a guru [sigh] but you can be one someday too (JUST LIKE ME!!????) … and if you are really curious, ping me and we will learn together … because there was a time I didn’t know what this meant either, and I would love to share the sum of our experiences together. Narcissists need not apply.

    • Thanks Cory. I am glad that you get my point so well. Don’t worry about the long comment. 🙂

  76. The Super programmer thinks outside of the box.
    He or she is the person that can be given for example, a problem that has stumped a company for over a decaded – and come back with a solution the next day.

    A solution that everyone thinks is crazy, because it just should not work.

    But it does….

    A super programmer realises that .net and it’s spin offs like the model view model approach etc are both the future AND a hindrance.
    They realise that much of what is out there is not from ‘super programmers’ but from people with a vested interest in other developers doing as bad a job as possible.

    Rivals dont want programmers developing fast – so they complicate things.
    Microsoft wants developers to be tied forever into MS code – so they abstract everything to a ludicrous degree – things are no longer intuitive, but done the microsoft way.

    Real super programmers code because there heart is in it, they realise the impact their code has on people – and they bear that in mind.
    They realise that writing X function could put 100’s out of a job, or writing Y function could keep people in a job, or even increase jobs.

    Real super programmers HATE office politics and often dont last long in large corporations as they are HATED by many others who work their as they embarass them with the speed and efficiency with which they code.

    Real super programmers prefer to code than party – something Microsoft, Sage, and many other large firms still have not learned.

    Fact – if you have developers partying – then unless they were forced to be there, they are NOT super developers.

    Real super developers are usually underpaid, as they do not lie, bullpoo, manipulate or stab people in the back to get higher positions and wages.

    Real super programmers do not need analysts, team leaders, architects etc as they themselves fulfil the whole set of jobs – they are crippled when they are forced to work in enviroments like those.

    • Best reply so far. Just truth.

    • I agree with a lot that you say but Super Programmers DO party. They do it the same way they work, hard and completely and when it’s done, it’s done.

    • Yes. That’s right. That’s exactly the point I was trying to make.

      • That is why I am not an epic programmer. I do not see a box to think outside of.

  77. Some more or less random comments from me. And forgive if they overlap the comments; I didn’t have the time to read them all, though I did eyeball a few.

    1. In any profession or activity, some people are better than others, due to a combination of talent and training/learning/practice. We’ve seen ample proof of this (in fields totally unrelatede to programming) during the previous two weeks in London. If you want to call those who are exceptionally good at programming “super programmers” – fine with me. Just remember that they are still able to make errors and that they, too, have off days. Just as top athletes will not always win their matches.
    And also never forget that being exceptionally good at something doesn’t make you a better person. Just better at that specific thing, but not better in general. Others will be better than you at other terrains.

    2. Can every complicated problem be broken down in smaller, simpler problems? Probably – I never have encountered a situation where this was not the case. That being said, it is not always smart to do; when dealing with database queries, it is often more efficient to put all logic in a single query rather than breaking it down in many small steps. But one can always break down, solve, then combine again. Or accept a performance hit if the alternative is not being able to write the code at all.

    3. One thing that the blog post doesn’t mention is that there is a huge difference between (a) the realization that this complex problem I need to solve can be broken down, and (b) knowing exactly HOW to break it down. Maybe the true merit of the “super programmer” is that (s)he is the one who quickly finds an efficient way to break down complex problems, whereas “normal” programmers need much more time for that – or maybe never find a way to break down the problem.

    4. The most difficult problem I had to solve? There are three that come to my mind. In chronological order:

    4a: Not a real programming problem, as the program already existed – and was a true maiintenance nightmare!
    In the ’90s, I worked in maintenance of mainframe programs at a bank. One program was considered evil – so every time something had to be changed, they bolted on an extra module before or after the main program, making it even more complicated than it already was. But at one time, it became too much, and something had to be done. I then got the task of deciphering and documenting this program. It used meaningless, three- and four-letter field names, no comments, GOTO statements with a label variable as the target (yes, PL/I allows label variables, which is very close to actual self-modifying code), etc etc etc. A huge mess. My main technique in finding out how this monster worked was a very huge sheet of paper to track the values of all variables and then following the code line by line, until it finally started to make sense.
    Solving this problem definitely involved breaking it down, as I had to start at the submodules that were at the bottom of the calling chain, describing their functionality, before I could tackle the modules that called them.

    4b: Several years ago, I tried to answer a question in a SQL Server Forum on a problem that was basically a bin packing problem. I ended up finding a very nice algorithm that I describe in a lot of detail on my blog. And yes, this algorithm can at a very high level be described as breaking the problem down into a few smaller and easier problems and then tying the solutions together. I won’t include a full description here; whoever is interested can read it on my blog.

    4c: Also several years ago, I had to solve a complex ordering problem. It involved processes that consume data collections and modify (other) data collections. The goal is to execute the processes in the most efficient order – that is, all process that may modify data collection X have to be executed before processes that consume that data collection are started. To complicate this, there were also “loops” – in other words, there were situations where a process Y modifies data that is used in a chain of other processes that, eventually modify data that is consumed by that same process Y. This would result in loops that were iterated until no more data was changed. And the existence of those loops made it very hard to find a good solution for this problem.
    I won’t explain the solution here, but I’ll elave it as an exercise for the reader (yes, I am evil like that). It did involve breaking down the problem, but it took me a very long time, and at least two promissing but eventually totally failed attempts, before I finally found out HOW I had to break down this problem.

    • Funny. Superprogrammers don’t think about how to break down problems into smaller units. They don’t think about how to construct algorithms, or consider what would be the best way to design data structures. They just do it.

      • Hmmm, I don’t think that’s true. It may look that way for the innocent bystander, but they still think about it. Just faster than others.
        I compare it to watching Judd Trump play snooker, or Tiger Woods play golf. They are so good that it looks as if all strokes hit almost by themselves, without taking any effort of the player. In reality, the player does put in a lot of effort.
        (Though experience comes in at some point as well. Just as Woods and Trump have situations similar to previous matches and practice situations, programmers encounter problems similar to previous problems, so they can easily and quickly adapt their previous solution).

        • It’s not about speed; it’s about the fact that the brain works the right way; follows the correct paths in lateral thinking. The correct way simply appears as obvious, all the time. I speak from personal experience.

  78. There are no super programmers of the type that Holywood likes to confront us with (i. e. the type that takes all of 2 minutes from grabbing a console to an ultra-high-security network until taking control and shutting out everyone else).

    There are however highly skilled programmers that would deserve the title, even though they may be thinking little of their own ability.

    The problem here is that you can’t measure programming skills in the way you measure how long it takes Usain Bolt to run 100m. Those *not* at the appropriate level of understanding are not qualified to accurately judge the actual skill of a potential ‘super programmer’, and those at that level wouldn’t think to name themselves so unless someone even better tells them so. That said, programmers – especially the very good ones – are rarely known for their social skills…

    In short; Yes there are Super Programmers. We just lack the people qualified to name them.

  79. There’s a funny German saying: “Kunst ist etwas was man nicht kann. Wenn man’s kann, ist es keine Kunst mehr.” Pretty badly translatable, it essentially says that “difficult” is something you don’t yet know how to do.

    IMO, there’s an isue here: difficulty of the solution vs. difficulty of the problem. A programming problem may be hard. However, once you have devised a solution, you can decompose the single complex solution into smaller, simple solutions to small problems – and this is what makes implementation simple and easy. You use domain knowledge, potentially borrowed/leased from experts, to devise the solution, and use programming knowledge to create an apparently simple implementation of the solution. IMO, this is the only thing that makes one a super-programmer.

  80. […] 【英文原文链接:The Myth of the Super Programmer 译文出处:外刊IT】 […]

  81. […] 英文原文:The Myth of the Super Programmer […]

  82. sorry. there’s i am not quite agree. things around math will be tough sometimes, i agree that many problems can be desolve by cutting them up. However, we humman beings are not quite celver to solve everything, the tip is that sometimes we really don’t know how to get start with the problem. we always learn things from people not by ourselves,we know we can handle it cause that someone else did it successfully. we take the wit of these though leader and that’s the point. There are people who are thougt leader made there achievements so that following there steps can we handle the problems. when talking about them suppose turing , which get deep into the problem and pay much effort deal with them. differently many afraid to take adventure where is not reached before by man. in conclusion there are people or Hero leading us. they really did things we cannot.
    ps. we can be one of them if … withmany true conditions.
    sorry for my poor english as it is my second languge.
    thanks for your reading.

    typed by mobile phone 3.7inch

  83. indeed. From my opinion, “super-programmer” is just like average people. The reason of being called by average people is because of they can solve tough problems. From me, “super-programmer” is just a programmar that has a lot of experience in solving different type of problems regularly.

    • So you’re saying ‘super-programmer’ is a relative title? I. e. when talking to a programmer with less skill, he’ll consider you one, but one with a higher skill will not? I mean, a higher skilled programmer will not consider the problems you solve as difficult …

      That is an interesting notion, especially in conjuntion with my statement above (that only better qualified persons are even able to tell that you are a super-programmer): In effect it means that no one will ever be able to tell you that you are a super programmer: the better programmers won’t appreciate your efforts, and the lesser skilled ones will consider you a magician (by the conjecture that any sufficiently advanced technology cannot be distinguished from magic). 😉

  84. […] 英文原文:The Myth of the Super Programmer  编译:外刊IT评论 […]

  85. […] I realize this might not apply to you.  You might be a super programmer who spends all 8 hours of his or her work day writing perfect code and never getting stuck, and […]

  86. Super Programmers do exist! So do good, average and poor programmers. So whats the difference? Is it development environment, experience, talent, culture or something else? Is it the ability to focus intently and really listen to what needs to be done or perhaps the creativity to break free and create new things in the sand box? Is it the A+ student in computer science or the hacker that broke down the walls? Is it a brain child after a long career in an industry finally being implemented or a high profile intense project….

    Super programmers answer Yes and No to all of the above questions. Having worked in telecommunication as the lead developer I have come face to face with breaking new ground or face the unemployment line along with my team.

    Super programmers exceed expectations on a consistent basic. The make tools that out scope their tasks. They always are highly inspired and channel that into their work. They are the Rembrandt’s, Beethoven’s, Einstein’s, Edison’s of software development.

  87. […] 英文原文:The Myth of the Super Programmer  编译:外刊IT评论 […]

  88. Reblogged this on Software & Hardware for Geeks.

  89. I partly with you.
    I know nothing about kernel programming, or 3d graphics, etc. But I think I made some nice OO stuff, and I can design a good relational db. Most kernel-gurus and videogame-makers don’t know how to face db problems, which are part of my work – and those issues can be complex.
    Others, can do wonderful bash scripts or write regexp’s that are impossible for me – of for Linux Torvalds. Even if they can’t do anything else, I call them real programmers.
    Also, I work on real projects, and need to see the results. Years ago, I worked with a great mathematician. Seriously, I think he was a genius. He knew everything about trees and other complex data structures, and his university thesis was a new algorythm to navigate a graph. But he wrote horrible code. He used all the worst practices I’ve ever seen, and we had to rewrite many functions he wrote. Was he a great programmer just because he was an excellent mathematician? No, he wasn’t.

  90. I’m really inspired with your writing skills and also with the structure to your blog. Is this a paid topic or did you customize it yourself? Anyway keep up the excellent high quality writing, it’s
    rare to peer a great blog like this one nowadays.

    • Thank you, it is not a paid topic, just my personal blog. 🙂

  91. […] This great article was originally posted by John Sonmez at his blog. […]

  92. […] article was originally posted by Amber at Coding Killed the […]

  93. […] article was originally posted by Amber at Coding Killed the […]

  94. […] within the development community, there seems to be a distinction between “real programmers,” and “not real programmers,” based on language or technology […]

  95. […] within the development community, there seems to be a distinction between “real programmers,” and “not real programmers,” based on language or technology […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: