- Joined
- 5/2/06
- Messages
- 12,166
- Points
- 273
This article on FEN is very interesting and beneficial for all of us to read. Please read and share your thoughts and comments.
http://www.fenews.com/fen47/risk-reward/risk-reward.html
FEN is closing down for sale so their contents are no longer available but here is the article from some online cache
In this column I would like to discuss one of the "big" questions that sometimes comes up in classroom discussions about financial engineering, but is rarely written about: How do you become a good financial engineer? Since many FEN readers will have asked themselves this question at some time, I thought it might be helpful to devote a column to it. (Readers might rightfully ask: What would an academic economist know of the real world? The answer is some teaching experience and plenty of mistakes.)
I will first address this question at a very general level, and then address it at a more concrete and detailed level, i.e., in terms of how one might proceed with a project such as a master's dissertation.
General advice
Learn what the subject is about
The first thing you need to do is understand the nature of the subject, and not be fooled by the glamour image of financial engineers as backroom quants who do the financial equivalent of nuclear physics. Essentially, the subject involves repackaging financial products to produce new products with desirable characteristics. Much of this is risk management and requires qualitative as well as quantitative skills: judgement, an understanding of how organizations and markets work, an awareness of the "things that can go wrong," etc. Thus, the subject uses sophisticated tools, but context and judgement are extremely important. We should also keep in mind that financial engineers deal with other people's money, and this has ethical and legal implications.
Cultivate the right personal qualities
As a student, the key to success is to be diligent and self-reliant, to strive for excellence and avoid shortcuts. This is a tough subject and if you want to succeed you have to put in a lot of sustained hard work. You should learn to work things out for yourself, and it is no accident that some of the best financial engineers are self-taught. To be a financial engineer requires a way of thinking: every problem is different and you have to be able to think each problem through from first principles. You also need to be self-reflective and learn from your mistakes. And you can never stop learning.
Develop basic skills
The time when you are studying the subject is also probably the best time to get on top of basic life skills: how to use a computer properly (including how to word-process quickly and how to become competent with spreadsheets), how to manage your time, how to write properly and how to manage stress. These skills take a lot of time and effort to acquire, but if you want to be good at your work then you need to develop them - and you will have even less time to acquire them after you graduate.
Tool up
Much of your work as a financial engineer will involve using computers to solve technical problems. It is therefore essential that you become competent at technical computing. You need to become competent using Excel to solve financial problems. I usually recommend that my students buy a good book such as Simon Benninga's Financial Modelling and read it systematically three or four times until they feel that they have absorbed it. After this, you need to master a high-level computing language. The choice is a matter of taste, but I prefer MATLAB myself: it is easy to learn, is very powerful, has lots of purpose-built special functions and produces really nice graphics.
Don't put this off: the quicker you "take the plunge" the better. I always emphasize this point to my students and the results have always been striking. Most students ignore the advice and in so doing condemn themselves to struggle on. However, there are always a few who get the message. They soon realize that being able to do technical computing opens up a completely new world, and they literally race ahead. Because they have strong technical skills, they go on to do outstanding dissertations and get very good jobs as well.
Handling projects
Choose a suitable topic
When dealing with projects, the first task is to choose a suitable topic. My advice is to decide what interests you, and within that area try to form a sense of what the cutting edge topics are. You should aim to do more than just replicate what someone else has done, but at the same time be careful not to be too ambitious. Whilst using high-level tools, you should also bear in mind that much of the value-added lies in the ways in which these tools are applied to specific problems.
In choosing a topic, it often helps enormously if you can identify one or more papers that you can take as your role models. Having concrete examples helps to clarify your thinking and give you a much better idea of what the project is likely to involve (e.g., likely problems, etc.).
Building your model
Your main task will then be building up your calculation engine. My advice here is to begin by building a spreadsheet prototype. The advantage of working with a spreadsheet is transparency: it is much easier to see what is going on (which helps to establish the key mechanics of the problem) and you have a much better chance of detecting mistakes. It is also important to start simple: take a straightforward (possibly over-simplified) task and build a little model to do it. You then gradually build the other parts, relax any over-simplifications, and connect the various bits. After a lot of trial and error you should eventually have a prototype that works.
As you assemble these building blocks, keep checking your programming. You can often do this by identifying special cases where the correct answer is clear, and then see if this matches the answer your model gives. It is also important that you take the time and effort to ensure that variables are labelled, explanatory notes are clear and inputs and outputs are clearly distinguished. (This is important because you will forget later why you did what you did, and I know from my own experience that it is all too easy to destroy a model by blundering around with it later when you have forgotten these details.) Above all, resist the pressure to hurry: if you try to hurry the model-building process, you are much more likely to set yourself back with a major error. (I know what I am talking about here!) The old saying "The more hurry, the less speed" was never more apt.
Having built a spreadsheet prototype and satisfied yourself that it seems to be correct, the next task is to build a "replica" software function in your chosen computing language. This software function will be our real model, and we resort to programming to obtain the full benefits of the programming language. (Excel is good for transparency, but has many limitations as a computing tool.) Again, it is important to annotate the program properly. My advice is to always assume that you will have forgotten everything the next time you look at it: explain everything.
When writing software code, computer specialists often advise that we should aim to write code that is computer-efficient. An example would be to use vectorized code (which is efficient) rather than resort to do-loops (which are not). Such considerations can be important, but financial engineers should be careful about this advice. It can take a lot of time to optimize code, and the calculation times saved might not be worth the time taken to improve the coding. More importantly, there is a trade-off between transparency and efficiency. A do-loop might be slow, but gives a clear sense of what is happening, and this clarity is vital if we are to be able to follow our own coding properly.
Having built the software model, make sure the two models produce the same answers when given the same inputs. If you find any cases where they give different answers, sort out the discrepancies before proceeding.
Once the software model is complete, you might explore the possibility of automating routine tasks. For example, instead of producing a table of results using the model function 50 times yourself, it is generally better to write a function that calls the model function 50 times and produces the table in one go. The benefits of this become very apparent the next time you have to redo all your results.
The whole process is very much groping in the dark. You start off with a vague sense of what you are trying to do, and the model gradually evolves as you try different things out, spot things you hadn't notice before and so on. You are likely to make a large number of errors in the process. (We all do!) As the model takes shape, you might also find that it throws up unexpected findings. Occasionally - too occasionally, in my experience - these turn out to be significant and you can get a breakthrough. Be this as it may, both the project and the model gradually evolve in a random manner, and you are making genuine discoveries in the process. You then end up with something that "looks right" but isn't something you could have anticipated ab initio. You then feel a little stupid when you look back after all that work and it all seems pretty obvious in retrospect. But research projects are always like that. They are like life itself: nothing ever works out the way it "should" on paper.
Dr. Kevin Dowd is professor of financial risk management at Nottingham University Business School in England and director of research in Black Swan Risk Advisors LLC, based in Berkeley, California. He can be contacted at kdowd@fenews.com
http://www.fenews.com/fen47/risk-reward/risk-reward.html
FEN is closing down for sale so their contents are no longer available but here is the article from some online cache
In this column I would like to discuss one of the "big" questions that sometimes comes up in classroom discussions about financial engineering, but is rarely written about: How do you become a good financial engineer? Since many FEN readers will have asked themselves this question at some time, I thought it might be helpful to devote a column to it. (Readers might rightfully ask: What would an academic economist know of the real world? The answer is some teaching experience and plenty of mistakes.)
I will first address this question at a very general level, and then address it at a more concrete and detailed level, i.e., in terms of how one might proceed with a project such as a master's dissertation.
General advice
Learn what the subject is about
The first thing you need to do is understand the nature of the subject, and not be fooled by the glamour image of financial engineers as backroom quants who do the financial equivalent of nuclear physics. Essentially, the subject involves repackaging financial products to produce new products with desirable characteristics. Much of this is risk management and requires qualitative as well as quantitative skills: judgement, an understanding of how organizations and markets work, an awareness of the "things that can go wrong," etc. Thus, the subject uses sophisticated tools, but context and judgement are extremely important. We should also keep in mind that financial engineers deal with other people's money, and this has ethical and legal implications.
Cultivate the right personal qualities
As a student, the key to success is to be diligent and self-reliant, to strive for excellence and avoid shortcuts. This is a tough subject and if you want to succeed you have to put in a lot of sustained hard work. You should learn to work things out for yourself, and it is no accident that some of the best financial engineers are self-taught. To be a financial engineer requires a way of thinking: every problem is different and you have to be able to think each problem through from first principles. You also need to be self-reflective and learn from your mistakes. And you can never stop learning.
Develop basic skills
The time when you are studying the subject is also probably the best time to get on top of basic life skills: how to use a computer properly (including how to word-process quickly and how to become competent with spreadsheets), how to manage your time, how to write properly and how to manage stress. These skills take a lot of time and effort to acquire, but if you want to be good at your work then you need to develop them - and you will have even less time to acquire them after you graduate.
Tool up
Much of your work as a financial engineer will involve using computers to solve technical problems. It is therefore essential that you become competent at technical computing. You need to become competent using Excel to solve financial problems. I usually recommend that my students buy a good book such as Simon Benninga's Financial Modelling and read it systematically three or four times until they feel that they have absorbed it. After this, you need to master a high-level computing language. The choice is a matter of taste, but I prefer MATLAB myself: it is easy to learn, is very powerful, has lots of purpose-built special functions and produces really nice graphics.
Don't put this off: the quicker you "take the plunge" the better. I always emphasize this point to my students and the results have always been striking. Most students ignore the advice and in so doing condemn themselves to struggle on. However, there are always a few who get the message. They soon realize that being able to do technical computing opens up a completely new world, and they literally race ahead. Because they have strong technical skills, they go on to do outstanding dissertations and get very good jobs as well.
Handling projects
Choose a suitable topic
When dealing with projects, the first task is to choose a suitable topic. My advice is to decide what interests you, and within that area try to form a sense of what the cutting edge topics are. You should aim to do more than just replicate what someone else has done, but at the same time be careful not to be too ambitious. Whilst using high-level tools, you should also bear in mind that much of the value-added lies in the ways in which these tools are applied to specific problems.
In choosing a topic, it often helps enormously if you can identify one or more papers that you can take as your role models. Having concrete examples helps to clarify your thinking and give you a much better idea of what the project is likely to involve (e.g., likely problems, etc.).
Building your model
Your main task will then be building up your calculation engine. My advice here is to begin by building a spreadsheet prototype. The advantage of working with a spreadsheet is transparency: it is much easier to see what is going on (which helps to establish the key mechanics of the problem) and you have a much better chance of detecting mistakes. It is also important to start simple: take a straightforward (possibly over-simplified) task and build a little model to do it. You then gradually build the other parts, relax any over-simplifications, and connect the various bits. After a lot of trial and error you should eventually have a prototype that works.
As you assemble these building blocks, keep checking your programming. You can often do this by identifying special cases where the correct answer is clear, and then see if this matches the answer your model gives. It is also important that you take the time and effort to ensure that variables are labelled, explanatory notes are clear and inputs and outputs are clearly distinguished. (This is important because you will forget later why you did what you did, and I know from my own experience that it is all too easy to destroy a model by blundering around with it later when you have forgotten these details.) Above all, resist the pressure to hurry: if you try to hurry the model-building process, you are much more likely to set yourself back with a major error. (I know what I am talking about here!) The old saying "The more hurry, the less speed" was never more apt.
Having built a spreadsheet prototype and satisfied yourself that it seems to be correct, the next task is to build a "replica" software function in your chosen computing language. This software function will be our real model, and we resort to programming to obtain the full benefits of the programming language. (Excel is good for transparency, but has many limitations as a computing tool.) Again, it is important to annotate the program properly. My advice is to always assume that you will have forgotten everything the next time you look at it: explain everything.
When writing software code, computer specialists often advise that we should aim to write code that is computer-efficient. An example would be to use vectorized code (which is efficient) rather than resort to do-loops (which are not). Such considerations can be important, but financial engineers should be careful about this advice. It can take a lot of time to optimize code, and the calculation times saved might not be worth the time taken to improve the coding. More importantly, there is a trade-off between transparency and efficiency. A do-loop might be slow, but gives a clear sense of what is happening, and this clarity is vital if we are to be able to follow our own coding properly.
Having built the software model, make sure the two models produce the same answers when given the same inputs. If you find any cases where they give different answers, sort out the discrepancies before proceeding.
Once the software model is complete, you might explore the possibility of automating routine tasks. For example, instead of producing a table of results using the model function 50 times yourself, it is generally better to write a function that calls the model function 50 times and produces the table in one go. The benefits of this become very apparent the next time you have to redo all your results.
The whole process is very much groping in the dark. You start off with a vague sense of what you are trying to do, and the model gradually evolves as you try different things out, spot things you hadn't notice before and so on. You are likely to make a large number of errors in the process. (We all do!) As the model takes shape, you might also find that it throws up unexpected findings. Occasionally - too occasionally, in my experience - these turn out to be significant and you can get a breakthrough. Be this as it may, both the project and the model gradually evolve in a random manner, and you are making genuine discoveries in the process. You then end up with something that "looks right" but isn't something you could have anticipated ab initio. You then feel a little stupid when you look back after all that work and it all seems pretty obvious in retrospect. But research projects are always like that. They are like life itself: nothing ever works out the way it "should" on paper.
Dr. Kevin Dowd is professor of financial risk management at Nottingham University Business School in England and director of research in Black Swan Risk Advisors LLC, based in Berkeley, California. He can be contacted at kdowd@fenews.com
