“What Should I Learn?”

 A friend who is in the QA/Automation space asked me the following question the other day:

Since we have nothing to work on at work right now, I’ve been looking at tutorials.  Looked at some C# a while back (which is confusing to me), Ruby today (still a little confusing syntactically), and brushed up against Watir for a few minutes, only to find that the main book on it isn’t even done.  Got passed over for a job opp recently because I don’t know Cucumber, so I’ll probably look at that, too.  From what I can tell, all of these are fairly dev-centric, and similar to one another.

So I pose to you the question — which ones are most worth learning?  What’s dominating out there?  What do you use?  Maybe for that blog of yours you could do a ELI5 overview of what each of the major technologies is and how they differ, their strengths and weaknesses.  I’m going thru now just figuring out what they are.  I don’t know enough to be dangerous with any of them.

This is a side effect of our company not using any of these tools, and seeing them in job descriptions everywhere else.  Are we morons for not using them?  Our people are falling behind the curve in the industry by NOT using them, it seems.

Great Question. Even Though You Asked, Like, Four, Dude.

At their core, these questions are asking about relevance. Specifically, self relevance and company relevance.

Relevance of either type has less to do with what you know, and more to do with what kinds of problems you solve–how you use what you know to accomplish that goal.

You use what you know in order to solve problems. But even if you’re a master at something, and that something doesn’t solve anyone’s problem, it’s not relevant.

So here’s a checklist to figure out what to learn. You can write this down on a sticky note and put it somewhere you’ll see it. Real short. Three things:

• Identify a problem,
• Learn how to use a tool that will solve that problem, and then,
• Solve the problem.

…that’s really it.

Might seem kinda smarmy but you’d be surprised how many people get hung up on the wrong solution by either ignoring or bypassing even one of these points.

• Learning a tool and solving a problem first, can lead to solving either the wrong problem, or a non-existent one.
• Identifying and then trying to solve a problem without seeing if there’s a correct tool for it, leads to a painful and probably rickety solution.
• Identifying a problem and then learning a tool to solve it is useless if you don’t execute on it, and actually solve the problem.

Very important points. So I’m going to go through each question and answer with these points in mind.

Which Ones are Most Worth Learning?

The ones most worth learning are the ones that will solve the problems that are in your face today, and also get you a little bit out of your comfort zone.

The technologies you mentioned are centered around Web UI automation. And it sounds like that stack will get you plenty out of your comfort zone.

And I mention comfort zone because, out of the wide array of similar-but-not-quite-accurate tools out there, the temptation may be to glom onto something close to what you’re already familiar with, and have that end up being the wrong tool in the longrun.

That poop-your-pants feeling is just your gut telling you that you’re getting ready to learn something cool. Follow it and don’t let it stop you from learning the correct thing to solve your problem.

What’s Dominating Out There?

Short answer: Nothing. It’s the Wild West, baby!

While it may seem like there are pockets of tech in certain places, there are actually a lot of factors that come into play when seeing what’s a pattern and what’s not. Things like:

• Location
• Field
• Skillset
• Budget

Location–I’m in St. Louis MO. This is primarily considered Java territory–a  lot of dev positions come up that are dingling around in that stack somewhere. But, the team I’m on, for this particular client, uses C#. For automating the tests, I use Ruby. So, we can’t really go by location to see what’s dominating.

Field–what field are you providing services for? If you’re doing a lot with medical, there’s a good chance you’ll be working a lot in databases. For the energy sector, there are lots of things communicating with other things. For any kind of application that messes with Big Data, you might find some Python or some R mixed in. The field itself guides what tools are the best fit.

Skillset–Company A might have a lot of Java Developers. Their competitor, Company B, may have a lot more C# developers. They both basically do the same thing, but with different tools. Does one work better than the other? Maybe. I mean if one company isn’t outrunning the other by miles, it may be safe to say that both skillsets are valid. Many skills can apply and solve similar problems. Many places will hire for particular skillsets simply because that’s what’s there. When the company first started, maybe the only dev there wrote everything in Python, and now that there’s a lot of legacy Python code around, that’s what they hire for, in order to maintain their current stuff.

Budget—the budget of the company also has a lot to do about what is used in a given location. Around here, a lot of the larger, richer, slower companies tend to use off-the-shelf tools for automating tests. For those companies, the tools work great. For smaller, quicker, frugal companies, it won’t be a good fit–either the tool doesn’t move fast enough or they can’t afford it. So just because a solution is being used somewhere, doesn’t mean it’s dominating in the field.

The reason I said all that is to say this: You’re free to choose whatever solution works the best, and not worry about using whatever is dominant.

Remember: it’s about solving the problem, so don’t get hung up on using what appears to be right, based on what others are using.

What Do You Use?

I actually use the same stack you talked about–Ruby, Watir and Cucumber. The reason for that is because the topology of this company, when I showed up, required a change so that the automation effort could continue.

So my problem set included:

• Original automation was written in C#,
• No automators were left at the company,
• Since no automators were here, manual QA became the target audience instead,
• Manual QA needed to be able to write automation without writing much code,
• Need to know what the tests are actually doing without looking at the code,
• Need to keep the automation low-maintenance.

I already knew Cucumber (or something similar) would be a boon for automation, because it prevents people from having to read the code itself to know what the test is doing. That by itself is huge.

The target application being tested was Web UI, so I’d need to be able to use some kind of webdriver tool for that. The Cucumber-esque toolset works with Java, C#, Python and Ruby at the very least.

The devs here use C# so that’s an option. But the target audience of Manual QA, doesn’t. It’s an incredibly hard sell to get non-devs functional in a dev-heavy language. C#’s out.

Java’s out–although similar in heft to C#, likely not even the devs would be able to help if we went that direction because it’d be a huge context switch for them.

Python could be used, but seemed a little academic, although being a scripting language gives us some tricks that we can’t (or can’t easily) do in a compiled language. So while it’s out, it’s a strong 2nd.

That left Ruby–a good balance of readability, and extendability. Plus it, along with just about any IDE you could get for it, was free.

So Ruby with Cucumber was a pretty good pairing.

Webdriving was handled with the Watir library, which research showed had pretty good support and good functionality for what I want to do. So I went with that.

On the framework side, I wanted to make sure that I didn’t have to write a ton of code. This meant using the dynamic programming that scripting languages bring, along with using regular expressions, letting me write single steps that handle all of one type of operation–clicking elements for example. So a lot of time was freed up and much of the automation code was reusable.

And I’ll admit, I kinda took a shortcut in this process, because I already knew about how Watir, Cucumber and Ruby play together. That knowledge came from having previously picked up the technologies (separately), kicking the tires and seeing how they act. Had there been some C# automators around still, it’d be a different conversation.

Are We Morons for Not Using (These Tools)?

Not morons, no. It’s just sometimes a company can’t adopt certain changes because reasons. It happens.

When a company cannot adapt to change and solve current problems, it’s usually due to one or more of the following:

• Lots of red tape and bureaucracy,
• People who are comfortable with the status quo,
• People who are spooked about change,
• Lack of foresight in what the market’s gonna do.

Solving a problem for a company is more than plunking down a solution.

Even if the solution works… even if it solves 100% of their problems… it’s not complete unless the company is free to act on, and to start using, that solution.

To prepare a change, it’s important to “till the soil” so that you can get new ideas to take root easier. Let’s take a look at each point and see what we can do to address each one.

Red tape. People generally want to do and have things that help them. Rules can fill that role. We can’t just have anarchy and chaos, and expect to get things done.

But, a lot of red tape–excessive rules–can be a hindrance. God bless the people who mean well but actually inadvertently create more problems then they solve.

People will either follow the rules because they actually work, because they’re told to, or because they don’t want to make waves.

But too many rules indicates a larger problem–not knowing what problems the rules are meant to solve.

To Fix: Some rules are kind of like those weird state laws that are still on the books, but largely take up space. Start asking the questions about why certain rules are the way they are. Pay attention particularly to ones that seem to eat up time or contradict each other. Maybe you can get them refactored or removed entirely. Every nonsense rule or policy that gets modified or removed frees up time for the company to try something they didn’t have time to try before.

Comfortable people. Some people don’t realize they’re in physical pain until it’s pointed out to them by a doctor. And usually they go to the doctor because something’s just not working quite right nor not as efficiently as it should.

Same thing for business pain. Employees sometimes get into this mode where, “if it ain’t broke don’t fix it”. Problem is, it actually is broke, but they’re either numb to the pain or the pain has increased so gradually they didn’t realize how much of an owie they have now.

But I would challenge that with another quote by Norman Schwarzkopf: The more you sweat in peace time the less you bleed in war.

To Fix: Throw up some demos and show people how they can improve, even if they feel like they don’t need to. It doesn’t have to be a formal meeting either, maybe you can just go up to someone’s desk and do a, “Hey you wanna see something cool?” Curiosity is a powerful drive. Demonstrate what it is that would help them, and they’ll realize they have some pain. They’ll probably want to learn more.

Fearfulness. People sometimes are fearful of trying something and failing, which can be exacerbated by the company environment if failure is punished.

If you make it easier and less painful to fail, people will be less fearful.

To fix: Have meetings showing examples of how the new things work, and how they can help these people. I say “meeting” but it’s really more like a “workshop”–it should be a safe place for people to try some new things, right there in the room. If we’re talking about automation, are they able to write some with a little bit of guidance? See if your company would be willing to host a Lunch and Learn to help draw people in.

Lack of Foresight. They say hindsight is always 20/20. How do we know ahead of time what new thing is going to make changes to our space? Answer: it’s usually some weird outlier.

To fix: Read, read, read. Whatever your space and discipline is, start signing up for things to get sent to your email and read whatever sounds interesting. I don’t expect you to snarf up every morsel of info, or spend all your time reading. That’s unrealistic. But start getting a feel of what’s going on in the market you’re involved in.

What you’ll start noticing is that there are some “fringe” thingies that seem way out there… but they’re mixed into the feed. Pay attention to these outliers. Sometimes they drive the market a whole different direction and you can start bringing these outliers up to managers.

How would they affect how the company does its job? How would they affect how you do YOUR job within the company, and how do they affect any changes to the stack you’re using? Then, if there’s anything you pick up tool-wise to learn how to adapt that stuff into your stuff, try it out and see what happens.

Learn Enough to be Dangerous

The final touch to this is actually about how to learn the stuff. In your question you’d mentioned not knowing enough to be dangerous.

I would say, you know what, that’s the goal. That right there. Learn enough to be dangerous.

Some people think that to be effective in any field, they have to have a brain full of knowledge that they can just call up on demand.

The longer I’m in this field the more I realize… thaaaaaat’s a buncha BS.

There is literally no way that you or I can retain that much info–info that will end up becoming obsolete eventually–and be able to stay sane. I don’t care how smart you are.

And here’s where I’m gonna plug for John Sonmez’s course on How to Learn Anything Quickly. Again, it’s less about how much you know, and more about how you apply what you already know.

It’s ok to learn just enough to be dangerous. Pick up a thing and slam out a Hello World. Then extend it. Then extend it a little more. You’ll quickly have something that’s usable. Something show-off-able. Something that solves a problem.

It may not be the most elegant solution. You may not have mastery of whatever it is you’re using to build the solution. That’s just fine. The more you learn later, that does make it elegant, can be applied after you learn that new thing.

Just because it’s not sleek and sexy right now doesn’t make it invalid.

So don’t feel bad about not mastering a certain technology. Instead strive to master learning what you need to know quickly and efficiently.

Remember, we’re talking about solving problems, and the thing we’re solving is: “I need to know enough to solve the problem I’m trying to solve,” right? Learning way more than you need, to solve the problem at hand, is not the right approach.

Conclusion

Hope this helps answer your questions. And a funny thing though–if you’re thinking about your job in terms of problem-solving instead of being a cog in the machine, you’re already thinking like a consultant.

LOL. Welcome to Anarchy 99 🙂