I'm a tester and I want to be a tester. But I also want to be a product entrepreneur. I want to be a business analyst. I want to be a programmer. And most of all, I want to have fun learning stuff that I feel drawn to. This post is inspired by Cem Kaner's words_
I find that when people take up learning programming, they usually appear to have a common path. They read something, a book or online articles.They take a course in programming. They try stuff out and create new programs. I haven't been drawn to that. I find that by accident, I've found other ways of learning that inspire me. Perhaps some of those would inspire you too?
Pairing and mobbing
After I got over my discomfort of pairing on something that I did not already know how to do (hint: strong-style pairing & the idea that you can bring different things to pairing), this is now a way I want to learn in. Pairing still drains my energy, as it is very intensive learning. Mobbing gives me more of ability to control the intensity as I share the work with a group over having one person rely on me.
I tried reading a book on programming and fell asleep. But instead, I sat with my team and programmed in a mob. I sat with nicest ones of my developers and fixed bugs with them. I organized Tech Excellence -themes meetups to program in other languages with developers I don't work with.
I learned a lot already. I keep learning a lot. And I'm addicted. Learning in bite-sized chunks. The joy of getting things done while learning. I recommend this!
Clean up, don't create
I'm noticing that while the courses and books direct you to start from a greenfield project, I make choices that lead me to start with legacy code. I see a lot of samples on how people have done it. I find joy in increasing my ability to understand what the code does by cleaning it up. I might ask questions that lead to cleaning it up. Or I might just take it upon myself to go and rename methods, to do automatic refactorings and in general, go through the existing "prose" to make it more easy to read.
I feel this approach is closer to deep proofreading with understanding, than to creating. I feel I enjoy taking the role of someone who keeps the style consistent and readable.
Reading code
You don't have to write anything or change anything. You could just read what is there. I did this for a few decades without giving myself credit on it. Don't belittle yourself, reading is a skill just as writing.
Push for seams for smart tests
Now that I program, I have something against keeping me constraint to programming on tests. First of all, I still consider the interesting problems to be in the application's domain - that's why I love being a tester in the first place. Second, programming tests is programming, and why should one limit themselves in just doing that if other options exist.
I rather share all the work with my team. And sharing has some very nice benefits. When testing something is hard, I seem to be one with creativity on saying that we could test these things this way, and these other things this other way, if only we could split these two. And when the focus is on solving the problem (getting the stuff tested with and without programming test artifacts) we fix the problems instead of playing around them. Instead of generating tons of selenium on top, we can find ways of pushing testing down to a smaller scope.
I find my learning programming is with focus on communicating this, over work on programming test scripts on where they are possible now.
Find your *thing*
This shouldn't come as a surprise, but programming or being a programmer isn't thing. I speak of this with 20 years of experience of monitoring several individuals in detail, and analyzing the stuff they produce in detail as a tester.
Some people do a bit of everything, but programmers also start from some corner. You can choose your corner in any way that suits you and (helps your company forward).
There's at least:
"Note to people who want to stay in testing: temporary role shift is worth the investment."My thinking is that I'm not in middle of a temporary role shift, but instead I do extensive job crafting. I take my work and craft it to be better for me, better for my company and I look critically what that might be. I'm still a tester, but it does not stop me from doing stuff.
I find that when people take up learning programming, they usually appear to have a common path. They read something, a book or online articles.They take a course in programming. They try stuff out and create new programs. I haven't been drawn to that. I find that by accident, I've found other ways of learning that inspire me. Perhaps some of those would inspire you too?
Pairing and mobbing
After I got over my discomfort of pairing on something that I did not already know how to do (hint: strong-style pairing & the idea that you can bring different things to pairing), this is now a way I want to learn in. Pairing still drains my energy, as it is very intensive learning. Mobbing gives me more of ability to control the intensity as I share the work with a group over having one person rely on me.
I tried reading a book on programming and fell asleep. But instead, I sat with my team and programmed in a mob. I sat with nicest ones of my developers and fixed bugs with them. I organized Tech Excellence -themes meetups to program in other languages with developers I don't work with.
I learned a lot already. I keep learning a lot. And I'm addicted. Learning in bite-sized chunks. The joy of getting things done while learning. I recommend this!
Clean up, don't create
I'm noticing that while the courses and books direct you to start from a greenfield project, I make choices that lead me to start with legacy code. I see a lot of samples on how people have done it. I find joy in increasing my ability to understand what the code does by cleaning it up. I might ask questions that lead to cleaning it up. Or I might just take it upon myself to go and rename methods, to do automatic refactorings and in general, go through the existing "prose" to make it more easy to read.
I feel this approach is closer to deep proofreading with understanding, than to creating. I feel I enjoy taking the role of someone who keeps the style consistent and readable.
Reading code
You don't have to write anything or change anything. You could just read what is there. I did this for a few decades without giving myself credit on it. Don't belittle yourself, reading is a skill just as writing.
Push for seams for smart tests
Now that I program, I have something against keeping me constraint to programming on tests. First of all, I still consider the interesting problems to be in the application's domain - that's why I love being a tester in the first place. Second, programming tests is programming, and why should one limit themselves in just doing that if other options exist.
I rather share all the work with my team. And sharing has some very nice benefits. When testing something is hard, I seem to be one with creativity on saying that we could test these things this way, and these other things this other way, if only we could split these two. And when the focus is on solving the problem (getting the stuff tested with and without programming test artifacts) we fix the problems instead of playing around them. Instead of generating tons of selenium on top, we can find ways of pushing testing down to a smaller scope.
I find my learning programming is with focus on communicating this, over work on programming test scripts on where they are possible now.
Find your *thing*
This shouldn't come as a surprise, but programming or being a programmer isn't thing. I speak of this with 20 years of experience of monitoring several individuals in detail, and analyzing the stuff they produce in detail as a tester.
Some people do a bit of everything, but programmers also start from some corner. You can choose your corner in any way that suits you and (helps your company forward).
There's at least:
- Types of activities with different skills needed
- Creating something new, prototyping - some programmers would only want to do this
- Debugging & fixing - some programmers are really bad at this
- Configuring the platform - some programmers do wonders on fixing behaviors without writing a single line of code
- Cleaning up & extending legacy code - some programmers have extraordinary skills in working with code they don't understand
- Selecting technologies and libraries - some programmers have great overall understanding of purposes and availability of solutions
- Architecting structures and enforcing patters - some programmers can apply a great deal of information of good learning that came before them
- Creating maintainable and purposeful test artifacts - some programmers have a great idea what kind of programmed test artifact would be helpful in the long run
- Portraying good habits - some programmers are disciplined in working the way they know is good and not taking shortcuts
- Recognizing programmable solutions - some programmers notice things that should be automated to make the flow of work better
- Understanding user and domain - some programmers are able to talk with end users and find the right small next bit of value to implement
- Working efficiently - using other programmers and non-programmers to get the work done-done, instead of going where one's own limits reach.
- Languages and libraries
- From single language specialist to a polyglot programmer, there's a lot of variety. And more to know comes in every day, so instead of knowing, the focus is on discovering and fast learning.
