Friday, June 23, 2017

Test Automation is the fastest way to get hired!

Another person hired as a Test Automation Engineer!  Seriously forget the things you hear about your first coding job should be as a junior developer.  Getting hired as a Test Automation Engineer is way easier and still allows you to write code :-)

I only personally coach 1 person at a time these days.  Please welcome Jae Shin to the tech field as a Test Automation Engineer.

Getting hired is simply, learn how to code, learn how to market yourself, and share that enthusiasm and passion during the interview.  Most people can get hired in 4 months once they set their mind to achieving the goal of getting hired.  Now is the perfect time to break into tech, there is more opportunity than ever in the tech scene.  Seriously go to any job board and search for "QA" or "Test Automation" and see all the jobs that are available.


Here is Jae's review from his coaching experience, by the way he got hired in 1 month:


"I can't thank Josh enough for coaching me through the steps in locking in my first tech job. Josh's guidance can only be surpassed by his sheer enthusiasm for watching people succeed. Not only did he walk me through what skills I needed, but also continuously challenged me to become a greater coder with his assignments. The skills I learned, in addition to the encouragements I received, gave me the confidence during my interview and landed me my first tech job."


- Jae Shin, 
Test Automation Engineer,
Accenture

Be encouraged, charge forward, never listen to the naysayers!  You can learn and you can get hired, and it doesn't have to take years!

Always keep learning :-)

Thursday, May 25, 2017

How to be an instant hero at work!

Let's face it when you work at a tech company, there is never enough good documentation to know how certain processes work.  Another issue is that you never have enough time to document the new workflow, or how a back end web service works.

Previously I have used a text editor and simply wrote my own very crude documentation, as I learned a new web application or back-end system.   I tried excel for a while, didn't really like it.   I also tried using Mac's built-in Notes app.  I even tried a mind mapping tool called Freemind, nothing worked well, looked good, or was easy to use.

That has all changed!  I finally stumbled upon  XMind the open source mind mapping tool.  I am here to tell you that even the free version of XMind is simply amazing!  I feel bad for myself these past 3.5 years of keeping track of notes and writing documentation without using XMind.  I personally have the paid version of XMind because it is that good.  I literally use it every single day at work for taking notes, documenting a new workflow or process, and when I am working on a user story.

I make test plans, test scenarios, and test idea sessions all with XMind.  I absolutely love the "brainstorming" feature for test scenario creation!  The app is super easy to use straight off of the shelf and super intuitive, it just makes sense.  I have over 30 XMind mind maps for work, I can't share those with you as they are strictly work mind maps.  However, I plan on making more mind maps for personal projects so that I can share them!


How does using XMind make you an instant work hero?

Whenever I work on something that is poorly documented, a team member or manager will ask:  "Did you document the new process that worked for you?   Can you put it up on a Confluence page?"
Normally that is a lot of extra work and extra formatting to make sure that my documentation all looks correct.  Also for Confluence ( and a lot of other intranet sites ) they only have an import feature for Word Docs.

This is what is so amazing about XMind, it will let you export your mind map to TONS of different formats and they all look amazing.  With 2 clicks I literally have a perfectly looking Word Doc that I can instantly upload to Confluence in 10 seconds.  Virtually everything that I touch at work is being improved, people have been thanking me for "taking the time" to document or clean up a process.

I don't tell them that thanks to XMind's built-in export tool it doesn't take me any extra time.  Xmind literally has 20 different formats that you can use.  It doesn't matter if you need the document in an Excel format, CSV, Word, or whatever.  XMind does it all!

I don't recommend things that I don't believe in as you all know.  I literally use this tool every day for at least 1 - 2 hours.  I highly recommend you try it out and see how much easier your life gets. Being a documentation "rock star" at work never hurts either.  Let's face it most people hate writing documentation, with XMind it's super easy!

Check out XMind

Keep on learning how to code peeps, you can do this!

Tuesday, April 4, 2017

WTW?

Announcing Work Together Wednesdays!  I am constantly asked questions like:
"What do I need to know to get hired?"
"What is basic coding mean?"
"What is QA / Testing?"
"How should I practice Test Automation?"

You really don't have to spend 3 years learning to code in your parents basement, most people can learn enough to get hired in 4 months for an entry level QA / testing job.  I have decided to open up my Wednesday evenings at 8pm EST to you.

There is no cost, I want to show people what you really need to know, and help people learn what is not important.  I am going to be paying for a Zoom account, so you will need to have a free account to access the Wednesday sessions.

Link to Zoom https://zoom.us/

Here's how it is going to work.  At 7:30pm EST ( 30 minutes before the start of the session ), I will send out an email with a link to the session.  If you want to attend send me your email address and I will make sure you are sent the conference email next Wednesday April 12th, 2017.

I will be having the WTW sessions weekly starting April 12th, 2017.  This will be very informal I can simply show you all some things I think are important.  If there are a bunch of questions I can answer them, whatever works for the group.  This session is not geared toward advanced programming, or exact application specific questions.

Topics will be mainly geared towards:
Test Automation basics
QA / Testing basics
Coding basics

If the above interests you, send me your email at: joshuakemp85@gmail.com

See you next Wednesday peeps!

Friday, March 24, 2017

I've been coding for 4 years... here's what I've learned

I am a Test Automation consultant, I write and read code most days.  Over the past 4 years I've done many different things with code:

I've written basic Rails applications - this is how I got hired at my first job as a junior developer
I wrote web scraper scripts and used Jenkins to automate them  - At my second job - this is where I really started to get better at coding, I learned the basics of automating things.
I worked as a mid level software engineer in testing using Javascript exclusively for 6 months - I really started focusing on test automation, learned the importance of writing cleaner code.  I also realized I didn't want to become a Javascript developer.
I helped create an API web service test automation framework in Ruby - I paired with a senior Ruby developer for 6 months straight creating the framework.  The code reviews and pairing took my coding skills to a higher level.

I don't know everything but I've learned a few things along the way that I would like to share with you:


Code reviews - be mean to the code, nice to the coder - alot of people still don't know this or use it.
I had a boss who would flip me off every morning and thought it was funny, after day 210 it starts to get very annoying.  I have had about 4 developers who really knew how to do a great job at code reviews.  Code doesn't have feelings, people do.  When you are a junior level developer you are going to be getting tons of comments on your code reviews, this is a good thing as you will get better.  Developers are notorious for lacking empathy, alot of code reviews suck because of it.  My advice is to remember the humiliation and frustration when you have a *%$* reviewing your code, and to not do that to someone else when you start doing code reviews.  Also try to not take anything the developer says personally ( even if they make it personal ).


Make it run, make it right, make it fast.
I used to want to make something or write a script and I would try to plot out the perfect path to make the code awesome before ever writing a single line of code.  Instead, think about what you want to make long enough for you to be able to write a "first draft" that works, albeit it's ugly.  Get your code working and then start making it pretty and start looking at how to really improve it.  Lastly you should look at ways to improve performance before pushing your code up for review.  For me this was a very freeing concept to start writing code and not just trying to have everything perfect in my head from the start.  I think as you gain more experience you will be able to write awesome code right off the bat, I have seen very senior developers do this.  I don't think most entry level tech people will be able to for several years.


The courses you take online are not really what you do in real life.
Courses are not geared to helping you land a job in the shortest amount of time, for the most part they want you to keep paying a monthly subscription fee.  The real world trenches look very little like the clean beautiful courses you took online, which is why I recommend getting your first job as quick as possible, getting your wet and figuring out what it actually means to be a professional in the field.  This may sound backwards, but I see far too many people who are waiting to get "good enough" coding in their parents basement's for 3+ years.  There are many jobs out their with less qualified people filling them, I think the key is your passion and willingness to learn.  If you have those you will grow your skills organically as needed, when "pain points" arise you will learn enough to get through them.  Someone with 1 year of real world experience is far more hirable and productive than a 3 year "basement coder".


Algorithms are hardly used in the real world.
I have almost never used an algorithm in my professional job, I have only ever needed to know algorithms for interviewing purposes and other mind games.  Real world coding is much more about these topics:
Knowing OOP
Writing methods that only do one thing
Creating separate classes to keep the code cleaner
Writing method names as verbs
Naming variable that make sense - tip: name it what the method is returning back, also make sure to name it singular or plural depending on what is being returned.
Reading code - this is the hardest thing that is almost never taught.  It's hard to read other people's code, but that is 80% of your job.  A good IDE helps.
Refactoring
Debugging - senior devs are amazing at this

NOTE:  This has been my experience with web development and test automation, I think the more senior level a developer becomes that changes some.


Refactor organically - slowly as you go.
The last senior developer that I wrote the API automation framework with taught me this.  Become aware of pain points in your code.  When you are writing your code and start getting annoyed or frustrated with it, ask yourself why and how can you remove that pain point?

Simple example:  Whenever you find yourself writing the same line fo code more than once - make a method.  When you have to change your code and it takes forever or is confusing, figure out how you can make it easier.  Don't be afraid to make another class to clean something up or break methods down further.


No one is truly TDD - bet yes, have tests - unit tests are amazing.
I hate writing unit tests and really don't like the whole TDD thing ( yes I know it is important ).  I also realize that one reason Rubyists are so caught up with TDD is because Ruby is an interpreted language, and doesn't show compile errors.  I have not worked with a single developer in real life ( not at conferences ) who actually wrote tests first.  What I did see in real life was developers who wrote tests and checked their unit test coverage before pushing their code up for review.

From the QA side of things, whenever I found a bug, a good developer would instantly write a unit test ( where applicable ) to cover that "missed test".  I will say from the QA / Test Automation side of things their is nothing better than seeing a ton of unit tests.  Why?  Unit tests are super fast and give a high level of confidence that the web app has been tested.  Also unit tests are awesome to run every time you pull down a new feature branch from a developer. Nothing beats unit tests  for regression testing.

Lastly unit tests will make QAs happier everywhere :-)  So the moral of the story is yes, please write unit tests, whether or not you write them first, make sure you have some written.


In a nutshell how to write better code - think of others.
You could spend your entire life on just this subject alone, but since you have a real job and must write code now what do you do?

Writing cleaner / better code really comes down to one thing:

Thinking of others.

Someone is going to have to change your code in the future, how hard or easy is it going to be?

Keeping that thought in your mind while you are writing code will help you the most.  When you are faced with the decision to write some code that will be easy to implement but hard to maintain, don't do it.  You can write code as a first "rough draft" but you should never push the code up for review knowing it will be hard to maintain.  Always take the approach that will be easier to maintain in the long run, even if it's harder for you to implement now.


Being okay with abstraction and not understanding how everything works
I used to freak out when I would be faced with a new code base or product if I didn't understand exactly how everything worked.  The truth is sometimes you are given an object and you need to take it for what it is an object and figure out what you can do with it.  Being comfortable with not understanding something is hard, I have gotten better with getting thrown into a new project or team and "rolling with the punches" until I figure out the lay of the land.


As a junior developer you need a really nice senior developer to take you under their wing.
You don't know what you don't know.  I am a very driven person and always try to improve my skills, whether it be writing code, testing, pen testing, or data science ( my latest passion ).  Finding a mentor will make you get better at a rate impossible on your own.  I have worked with lots of crappy developers and testers, don't be one of those.  You absolutely need a mentor, I can't tell you exactly how to get one, but you should always be on the lookout.  Always be the best student and do the work required to grow.  With my new endeavor ( Data Science ) I have several people who I can reach out to and ask questions whenever needed.  Find someone who will be that for you.  Pairing with the last senior developer for 6 months straight helped me grow more than I thought possible and gave me the confidence to learn my first compiled language C#.

All in all learning how to code is one of the most useful skills you can learn on the planet.  You don't ever have to be a full blown developer, but learn how to write loops, variables, how to navigate / read code, make methods and classes.  You will know how to code enough to get your feet wet in the tech field :-)  You can do this peeps!





























Saturday, March 18, 2017

Becoming a Data Scientist - Part 2

Wow, thanks for the out pouring of advice and help.  A special thank you to Ryan Herr who is a Data Scientist!  Follow him on Twitter at @rrherr, I really appreciate the help!!!  Whenever you are moving into a new field, one of the fastest ways to achieve your goal is to find a mentor.  I know several people from work and online who are currently Data Scientists or have been in the past.  Find people online who can be a mentor to you or who you can follow.  Here are some basic things I am doing and recommend so far:

Listen to podcasts on the way to work:
http://www.becomingadatascientist.com/category/podcast/  

My commute is 25 minutes each way so I should be able to get through all or most of these podcasts in a month without too much effort.

DataQuest:
https://www.dataquest.io/

I have started Data Quest and highly recommend it, it's like an online Data Science boot camp.  One thing I would like to note.  I used to be supportive of coding bootcamps back in 2012 - 2014, I am no longer supportive of coding bootcamps.  The reason being there is a glut of  "junior developers" on the market because of all the coding bootcamps who constantly "churn" them out.  In any new field which is in constant change, there is a huge opportunity for people who are less qualified to break into the field.  This is what it was like from 2012 - 2014 with coding bootcamps, if  you went to a bootcamp you could easily land a job afterwards.  That is not the case anymore, there are literally hundreds of people all applying for the same junior dev job. Most with virtually all have the same story: "I attended a coding bootcamp".  This is not a good way to stand out from the crowd anymore, in fact it almost makes you "unremarkable".

The reason I am doing DataQuest is that the data science field is still very new, and there are no clear paths on how to get hired as a Data Scientist.  Basically in my mind the data science field feels very much like trying to get a junior dev job back in 2011 - 2012.  It's hard because there is no clear path, but it's also very freeing because no one can tell who is truly "qualified" or not.  This is why I am trying DataQuest, I feel like they have a pretty good path ( so far ) that gently introduces you to data science topics.  I think 5 years from now there will be 100 data science bootcamps and everyone will be telling you to attend!

I have always thought and have done the following:

"Don't do what everyone else is doing.  If everyone is doing something then do the opposite"

Also I look at trends and which jobs are getting outsourced or are easier to outsource.  I also know that the reason brain surgeons make so much money is because they are hard to replace.  Not many people can do what a brain surgeon does, brain surgery is a real skill.  The tech field is the same way, the more people who have a certain skill the lower the income, and the easier to outsource the job.  I also believe in doing something that I am passionate about and enjoy doing, it's not only about which job makes the most money.  You need to enjoy what you are doing, this is the reason I am not interested in becoming a Javascript developer, I simply do not enjoy using Javascript.  I was a mid level software engineer in testing for 6 months and realized it wasn't for me.

The whole key it to learn the basics of programming, once you do there are so many different opportunities for jobs out there!  Spend at least an hour every day learning something new in the tech field, for me it is data science.  Get moving peeps, you can do this!!! :-)