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.
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!