Evolution of a programmer
Programmers can be categorized into the below:
1. Those who have no idea about what they are doing.
2. Those who just manage to do the job.
3. Those who can do the job if you tell them how exactly to do something.
4. Those who write code for years and learn by experience doing things differently each time.
5. Those who write code for years and gain experience but always do stuff the same way.
6. Those who have a degree in CS but who have little hands on coding experience.
7. Those who have a degree in CS who can get around decently.
8. Those who have a degree in CS and can talk very well, but do little in the real world.
During interviews, choosing a candidate can be a big problem because sometimes we select the guy who can talk really well, but who cannot do any practical work on a day to day basis. The guys who can code really well, may not do well in the interview at all. Sometimes the candidate with the worst feel in the interview, might be the exact fit for the job.
This post is for all those guys who are confused about why the guy who does not know about data structures or solve puzzles may be the best programmer around...
See... learning CS is good, but the problem is that often the guys who learn something in college, take it for granted, and never actually apply any of it. So they may know a lot of stuff in theory but in the real world, faced with a real problem, they will sweat profusely. If they manage to start the work, they will write the worst code ever, where the code is not what solves the problem, but basically a mad bull attack from every angle using every technique they learnt in college. If they are lucky one of their solutions will hit the solution, otherwise, they will struggle on.
A real programmer, is one who has learnt programming by years of writing code, differently each time, improving every time, even if all the projects they have ever done are in the same domain. They never believe any hearsay, they will always try something out before deciding whether it is good or not, their code is simple, but elegant. Their code is maintainable, and every technique they use will have a reason for usage, and not there just because they know how to use X and Y.
Knowing the latest API or framework, does not mean the guy is a master programmer. You can know all the latest technologies and still code like a neanderthal. A master programmer will write masterful astonishing code, even if the work to be done is the most mundane task ever. You never become a master programmer by reading something - you become one by hard work, by writing code, by loving to write code, by always striving to improve what you have written in the past, and by knowing high level details of what it is possible to do.
The master programmer may not know all the Design Patterns. He can invent his own. Then he will compare with the existing design patterns, and most often, he will find his solution better than the design pattern in the books because these proscribed patterns always have caveats - his solution won't. Comparison is something the programmer likes to do, because he knows that he does not know everything.
The master programmer can solve 95% of the technical challenges in a project, and for the remaining 5%, this person will know the direction of the solution. Knowledge of Data Structures are not need to create elegant solutions in 95% of the cases. In fact, if you know nothing about data structures, you can reach the summit of the mountain you need to scale. It is after you reach the summit, you will need data structures sometimes to scale the remaining 5%. As the master programmer already solved 95% of the problem, which nobody else could, the remaining 5% is easily resolved by a quick study of the data structure to be used.
I have been interviewed by people who asked questions only on data structures and afterwards on the job, no data structures ever came in any of the work they did in the subsequent 2 years. Nor was it there in the existing work. I was one of the best programmers they ever had, all my projects were done in time, while the data structure guys were often producing late or buggy code. So, I have to speak up for all those programmers like me, who are master programmers, but cannot elucidate exactly what it is they have over the data structure guys.
A good programmer might be the less talkative, shy guy in the interview. Remember that you are not interviewing for the best person who can speak up eloquently. The job is for the best programmer who can be found.
I have worked on projects with some guys who really were pretty good programmers and also data structure guys. The problem with most of the code written by such people is that, it will contain lots of stuffing which is not needed and actually hinders the real work, and makes it more difficult to get around, just so that they can say they used this or that technique. This is the ugliest characteristic of the data structure programmer.
Imagine, they would use interfaces all over the code, except in the exact scenario where Interfaces were actually supposed to be used, and can provide the maximum value. And you will see many, many examples of this philosophy as you go through their code. They think that the best code is which uses their latest fad technique in the most number of places.
The truth is that the best code is that which uses techniques where they are supposed to be used, and does not use unwanted techniques just for the sake of using them.
You have one class library, which will never be changed, and 2 adjoining classes, which will never be modified, still one will use the other via interfaces or the better technique according to these programmers is to use the Unity application block. Make it really convoluted to do something which should be easy to do, and then by the time you really reach the complex parts you need to do, you are running around circles where you should be going in a straight line.
Still the world respects these pompous data structure guys. I remember an interview where they were looking for an architect, and they guy on the line is asking me for the definition of a framework, from a book he is reading. A real architect can architect the best solution, and write the best framework better than those who have read about frameworks in books.
Fads come and go. XML, MVC, Cloud, Razor, Silverlight, etc, etc. Each time they try to use a fad to solve all the problems, they stumble, they fumble, they curse, and eventually they move on. The master programmer looks at this and silently smiles, they do their work, and they move on...
1. Those who have no idea about what they are doing.
2. Those who just manage to do the job.
3. Those who can do the job if you tell them how exactly to do something.
4. Those who write code for years and learn by experience doing things differently each time.
5. Those who write code for years and gain experience but always do stuff the same way.
6. Those who have a degree in CS but who have little hands on coding experience.
7. Those who have a degree in CS who can get around decently.
8. Those who have a degree in CS and can talk very well, but do little in the real world.
During interviews, choosing a candidate can be a big problem because sometimes we select the guy who can talk really well, but who cannot do any practical work on a day to day basis. The guys who can code really well, may not do well in the interview at all. Sometimes the candidate with the worst feel in the interview, might be the exact fit for the job.
This post is for all those guys who are confused about why the guy who does not know about data structures or solve puzzles may be the best programmer around...
See... learning CS is good, but the problem is that often the guys who learn something in college, take it for granted, and never actually apply any of it. So they may know a lot of stuff in theory but in the real world, faced with a real problem, they will sweat profusely. If they manage to start the work, they will write the worst code ever, where the code is not what solves the problem, but basically a mad bull attack from every angle using every technique they learnt in college. If they are lucky one of their solutions will hit the solution, otherwise, they will struggle on.
A real programmer, is one who has learnt programming by years of writing code, differently each time, improving every time, even if all the projects they have ever done are in the same domain. They never believe any hearsay, they will always try something out before deciding whether it is good or not, their code is simple, but elegant. Their code is maintainable, and every technique they use will have a reason for usage, and not there just because they know how to use X and Y.
Knowing the latest API or framework, does not mean the guy is a master programmer. You can know all the latest technologies and still code like a neanderthal. A master programmer will write masterful astonishing code, even if the work to be done is the most mundane task ever. You never become a master programmer by reading something - you become one by hard work, by writing code, by loving to write code, by always striving to improve what you have written in the past, and by knowing high level details of what it is possible to do.
The master programmer may not know all the Design Patterns. He can invent his own. Then he will compare with the existing design patterns, and most often, he will find his solution better than the design pattern in the books because these proscribed patterns always have caveats - his solution won't. Comparison is something the programmer likes to do, because he knows that he does not know everything.
The master programmer can solve 95% of the technical challenges in a project, and for the remaining 5%, this person will know the direction of the solution. Knowledge of Data Structures are not need to create elegant solutions in 95% of the cases. In fact, if you know nothing about data structures, you can reach the summit of the mountain you need to scale. It is after you reach the summit, you will need data structures sometimes to scale the remaining 5%. As the master programmer already solved 95% of the problem, which nobody else could, the remaining 5% is easily resolved by a quick study of the data structure to be used.
I have been interviewed by people who asked questions only on data structures and afterwards on the job, no data structures ever came in any of the work they did in the subsequent 2 years. Nor was it there in the existing work. I was one of the best programmers they ever had, all my projects were done in time, while the data structure guys were often producing late or buggy code. So, I have to speak up for all those programmers like me, who are master programmers, but cannot elucidate exactly what it is they have over the data structure guys.
A good programmer might be the less talkative, shy guy in the interview. Remember that you are not interviewing for the best person who can speak up eloquently. The job is for the best programmer who can be found.
I have worked on projects with some guys who really were pretty good programmers and also data structure guys. The problem with most of the code written by such people is that, it will contain lots of stuffing which is not needed and actually hinders the real work, and makes it more difficult to get around, just so that they can say they used this or that technique. This is the ugliest characteristic of the data structure programmer.
Imagine, they would use interfaces all over the code, except in the exact scenario where Interfaces were actually supposed to be used, and can provide the maximum value. And you will see many, many examples of this philosophy as you go through their code. They think that the best code is which uses their latest fad technique in the most number of places.
The truth is that the best code is that which uses techniques where they are supposed to be used, and does not use unwanted techniques just for the sake of using them.
You have one class library, which will never be changed, and 2 adjoining classes, which will never be modified, still one will use the other via interfaces or the better technique according to these programmers is to use the Unity application block. Make it really convoluted to do something which should be easy to do, and then by the time you really reach the complex parts you need to do, you are running around circles where you should be going in a straight line.
Still the world respects these pompous data structure guys. I remember an interview where they were looking for an architect, and they guy on the line is asking me for the definition of a framework, from a book he is reading. A real architect can architect the best solution, and write the best framework better than those who have read about frameworks in books.
Fads come and go. XML, MVC, Cloud, Razor, Silverlight, etc, etc. Each time they try to use a fad to solve all the problems, they stumble, they fumble, they curse, and eventually they move on. The master programmer looks at this and silently smiles, they do their work, and they move on...
Comments
Post a Comment