This is going to be blunt. I don't know a not-blunt way to say this.
First, learn to code. Working with Selenium, no matter what your toolkit happens to be, is writing code. If you don't understand the code or the principles behind the code, you will be constantly frustrated, and worse, you will irritate your peers with what will seem to experienced coders to be "foolish newbie questions" - that is, the kind of question that a typical junior developer would be able to solve for themselves.
Once you are able to write, read, and understand moderately complex code, then you can start considering adding Webdriver into the mix.
At this point, I'd start with the following:
- Start simple - make your first Webdriver test really simple. One method, which handles all the setup, the test actions, and the assertions. Your goal here is to develop a feel for working with the Webdriver API, to sort out the dependencies you need to make sure your browser driver is somewhere the API can access and your code has the right executable permissions.
- Refactor as you build - Any time you find yourself rewriting or copy/pasting large chunks of code that's almost the same, that's code you can extract into its own method. Whether it lands in a separate library object or namespace will depend on what you need.
- YAGNI - resist the temptation to add things "for later". "You Ain't Gunna Need It" - or more likely, when you eventually do need "it", what you originally wrote isn't going to do the job the way you want, because you've improved a lot since then.
- KISS - Keep It Super Simple. As Michael Durrant has already said, you want to minimize testing through the UI. UI work is complicated and involves a lot of moving parts, which means a lot of ways your tests can fail that aren't bugs in the application in test.
After that, you can start looking at CI, data-driving your tests, and other more complex scenarios, but your best option is to get the basics as solidly as you can before you try to do anything more complex.
