Thursday, June 30, 2016

Strategies on learning programming

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_
"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.
A big realization: the best of programmers start to resemble the best of testers a lot. We just start out in different corners and use most of our energy on different things. After 20 years of testing and a few in programming, I hate the term "junior developer - senior tester". With what I know from testing, I already contribute more than I would have given myself credit for earlier.

1 comment:

  1. Great post Maaret.

    Even though you are way ahead on the programming part (well every part, really), I seem to follow the same kind of a path. Past year I have even been pondering in really taking a bigger step and diving explicitly into the programmer role.

    But as it comes to software development, I have seen and thought for a while now that the actual turning of instructions into code is rather small part of the programmers work. Understanding what needs to be done, in which order, taking into account backwards compatibility and future scalability, having good tests, reviews, releasing in a smart way, adding good logging and monitoring clues, taking performance, security and ux into account, coaching other team members, thinking and improving the work process of the team, helping customer support, etc etc takes a huge lump of the day of many programmers. And many of these things are something that a "tester" in the team do/can/should do as well.

    With this I do not want to say that the ability to create beautiful code is not a great skill. I've worked with developers I have huge respect for, who do such wonders with code that I could not do it in a million years.

    But still, I do feel that the testing/developing gap is not that big. And if it is not, why not hop on both sides? Why think what I can lose, but instead what can I win?

    You looking for new developers btw? ;)

    - Anssi

    ReplyDelete