Following up on my last
post, I'll give some instruction for those testers who want to become
programmers. As I said, last time, don't expect to learn everything you
need to at work. The forces in play will almost certainly conspire to
keep you from being able to. If you desire to expand your horizons and
become a programmer (either staying in test or moving to dev), here are
some ideas that can aid you in your journey.
Look for opportunities to program. Take advantage of them when they appear. There's always an extra tool that needs to be written. There's always a feature that would be really nice to have added to an existing tool. If you want to get support for your learning, this is your best chance. If you can do it and show the benefit to the team, you'll often be rewarded by more opportunities. The only way to get good at programming is to program. Practice every chance you get. I've seen plenty of aspiring developers ignore chances to develop tools at work. The ones that do rarely--if ever--make the leap.
Start small. When you are starting out, it is usually easier to add functionality to an existing program than to write something from scratch. This is because you have a structure to work with. When you are learning to program, you don't know how to put all the pieces together. You'll learn that, but starting out it can be hard. Working on something similar to an already-existing feature can be a good place to start.
Learn the language of your application. While Ruby, Python, or Visual Basic may be appealing and even easier to learn, unless they are the language the application you are testing is written in, you'd be best not to spend your time learning them--yet. Eventually, yes, but they won't really help you get where you want to go. There are two reasons for this. First, the most effective test automation is done in the native language of the application. Anything else doesn't align quite right and will make reaching the corners hard. Second, the people you can learn the most from--the application's developers--can only help you if you speak their language.
Ask a lot of questions. Potential candidates often ask what working at Microsoft is like. I invariably tell them that it is a very supportive environment. When you ask a question, you always get a detailed answer and usually a history lesson about why it is that way. I suspect that we're not alone in that respect. Most developers enjoy what they are doing and want to share that joy. If you ask them a question about how their program works or even about some project you are doing (that test tool you are writing) and the problem you are stuck on, they'll often be happy to help. Be careful not to take too much of a person's time and be especially careful not to ask the same question twice, but don't be afraid to ask. Part of learning on your own is asking questions of those more skilled than you. My rule of thumb is to spend a few hours trying to solve any problem. If you still don't have an answer, go ask someone.
Be prepared to put in the work. The job you were doing before you decided to go down this route didn't go away. You'll still need to do it. Learning to program isn't simple. It will take time. The combination is going to take a lot of time. Be prepared to show up early or stay late to work on your project.
Don't quit. There will be times when you get too busy to learn. There will be bugs that stump you for a long time. Don't lose track of what you are doing. Don't get out of the habit. Don't take on projects and then let them languish for months. You have to keep going.
Put in time outside of work. Read. Either online or on dead trees. A lot. Practice. A lot. Pick up a side project and work on that. Open source make a good place to start. Just working on something of your own does too. Work on programming a game or writing a tool. It's not even important that you finish so long as you are working. If you want to become a developer, it should be because you enjoy programming. Use this joy to your advantage. What you learn on the side will help make the stuff you do at work make more sense and go faster.
http://blogs.msdn.com/b/steverowe/archive/2007/04/26/teaching-yourself-to-program.aspx
Look for opportunities to program. Take advantage of them when they appear. There's always an extra tool that needs to be written. There's always a feature that would be really nice to have added to an existing tool. If you want to get support for your learning, this is your best chance. If you can do it and show the benefit to the team, you'll often be rewarded by more opportunities. The only way to get good at programming is to program. Practice every chance you get. I've seen plenty of aspiring developers ignore chances to develop tools at work. The ones that do rarely--if ever--make the leap.
Start small. When you are starting out, it is usually easier to add functionality to an existing program than to write something from scratch. This is because you have a structure to work with. When you are learning to program, you don't know how to put all the pieces together. You'll learn that, but starting out it can be hard. Working on something similar to an already-existing feature can be a good place to start.
Learn the language of your application. While Ruby, Python, or Visual Basic may be appealing and even easier to learn, unless they are the language the application you are testing is written in, you'd be best not to spend your time learning them--yet. Eventually, yes, but they won't really help you get where you want to go. There are two reasons for this. First, the most effective test automation is done in the native language of the application. Anything else doesn't align quite right and will make reaching the corners hard. Second, the people you can learn the most from--the application's developers--can only help you if you speak their language.
Ask a lot of questions. Potential candidates often ask what working at Microsoft is like. I invariably tell them that it is a very supportive environment. When you ask a question, you always get a detailed answer and usually a history lesson about why it is that way. I suspect that we're not alone in that respect. Most developers enjoy what they are doing and want to share that joy. If you ask them a question about how their program works or even about some project you are doing (that test tool you are writing) and the problem you are stuck on, they'll often be happy to help. Be careful not to take too much of a person's time and be especially careful not to ask the same question twice, but don't be afraid to ask. Part of learning on your own is asking questions of those more skilled than you. My rule of thumb is to spend a few hours trying to solve any problem. If you still don't have an answer, go ask someone.
Be prepared to put in the work. The job you were doing before you decided to go down this route didn't go away. You'll still need to do it. Learning to program isn't simple. It will take time. The combination is going to take a lot of time. Be prepared to show up early or stay late to work on your project.
Don't quit. There will be times when you get too busy to learn. There will be bugs that stump you for a long time. Don't lose track of what you are doing. Don't get out of the habit. Don't take on projects and then let them languish for months. You have to keep going.
Put in time outside of work. Read. Either online or on dead trees. A lot. Practice. A lot. Pick up a side project and work on that. Open source make a good place to start. Just working on something of your own does too. Work on programming a game or writing a tool. It's not even important that you finish so long as you are working. If you want to become a developer, it should be because you enjoy programming. Use this joy to your advantage. What you learn on the side will help make the stuff you do at work make more sense and go faster.
http://blogs.msdn.com/b/steverowe/archive/2007/04/26/teaching-yourself-to-program.aspx
No hay comentarios.:
Publicar un comentario