If one cannot create his own algorithm for programs, does that make him a bad programmer?

Question

I am used to looking up at a lot of algorithms and combining the good and bad points of each and come up with something. I was always weak at formulating my own algorithms for certain problems. Don't get me wrong here, it's not some sort of a complex mathematical algorithm like pythagorean triplets or anything like that. I always look up codes for creating Validation or payment libraries and, like I said, combine things from each file into a single file. I was used to doing it that way that I am really bothered that if a time comes that I have to formulate my own solution, I would just be staring at the problem.

They say you must not reinvent the wheel, I think the concept got to me a little too heavily, that I forgot to once in a while be creative and invent my own wheel.

If I cannot even create my own algorithms for even simple tasks such as accessing web services or creating a custom search engine, does that make me a bad programmer?

Answer 1

In the bad old days, programmers wrote programs. Analysts figured out algorithms and told the programmers what to write. In that sense, no—you're not a bad programmer.

As long as you can select the appropriate algorithm, you are a good engineer. If part of the algorithm doesn't work somehow, and you fix it, you're a very good engineer.

Anyway, just because you think you can't do it now, doesn't mean you won't be able to do it next month...

Answer 2

It does not necessarily make one a “bad programmer”, but could (depending on context) be indicative of an “inexperienced programmer”.

it should also be noted that all modern programmers piecemeal the best of different existing source codes to arrive at the desired position. There is NOTHING wrong with borrowing code, or pieces of it – with one exception: You should attempt to understand the code you borrow - it will enhance your technical skills.

Answer 3

No, a bad programmer is one who insists on trying to figure out everything for themselves. I would much rather not be paying someone by the hour for that attitude.

Programmers are not a group unto themselves. They generally work for a business that has real-world needs like return on investment and maximum bang-per-buck. Don't steal code but definitely 'steal' algorithms (unless they're patented of course).

You'll be far more productive that way.

Answer 4

I agree with NTDLS,

"You should attempt to understand the code you borrow - it will enhance your technical skills."

I can relate to this.

Answer 5

Yes, if you don't have the capacity to come up with algorithms for simple tasks then I think it is inescapable that you are a bad programmer. If you don't know what an algorithm should look like then how are you even evaluating the algorithms you do incorporate into your code, they might be written by someone who has even less of an idea.

If you can come up with algorithms but you don't have time to, or know that theres already a piece of software that does exactly what you want, then that's just effective time management.

Answer 6

Being able to produce/create algorithms for solving specific problems is certainly a valuable skill. If one has a problem (let’s say sorting of data) and has absolutely no clue how to write code to implement an algorithm to do that, then I think maybe that person might not be best suited for a programming career. The best programmers I have worked with always have an idea for solving a particular problem. I believe it is part of a programmer’s nature to think about how to solve a problem. In fact, I love having a collection of problems in my head so that I can think about how to solve them when I am stuck in a boring situation.

On the other hand, I suspect that it is a rare situation where it is actually best to use an algorithm written from scratch (at least with well known problems such as the sorting example). I am quite sure that I would never have been able to “invent” or “create” the quick sort algorithm. It seems likely that any sorting algorithm that I would create from scratch (assuming I knew nothing about sorting) would end up being O(n^2) or worse. But being able to understand the quick sort algorithm has been invaluable. We had a situation where a class of data was turning out to be very costly to sort (close to n^2) by a quick sort implementation we were using. By understanding the algorithm, I was able to change the code to choose a much better partition element for that class of data and “fix” it so that it worked in O(n*log(n)).

So I think there is some middle ground. Having no interest or capability in writing an algorithm for a class of problems is possibly an indication that a different career path might be more rewarding. At the other extreme, someone who insists is on writing everything from scratch is, in my opinion, a much worse person to have on the payroll. I think the former person can probably have a good career even if not the most enjoyable for that person, while the latter may not succeed in the long run.

Answer 7

You don't have to be able to invent the most efficient possible algorithm for every possible scenario like a C.A.R. Hoare or an Edsgar Dijkstra. Most hardcore algorithm people, ironically, are more like mathematicians and can't actually code their way out of a paper bag. However, you should at least understand things like quick sort, Dijkstra's algorithm, etc. in hindsight if you end up needing them.

You should also be able to come up with simple, reasonably efficient (but not necessarily provably optimal) algorithms for things that don't fit into any "classic" computer science problem. Studying known algorithms that are tangentially relevant helps you "learn to think" here. Even more important, though, is to master reducing your problem to one for which an efficient algorithm already exists. For example, maybe if you think of your problem a certain way, it's just finding minimal cost path (Dijkstra), or just a few sorts (quick sort), or maybe it's reducible to the Traveling Salesman Problem (in which case it's NP-complete and you should usually start thinking about approximation instead).