Learning to identify and develop faster test cases sounds like something only a programmer would do. Automated unit tests are an example of an extremely fast test case and will help with efficient learning for programmers.
Running an app, logging in manually, navigating to a screen and tapping a button is a pretty slow test case. It should come as no surprise that the programmer writing the automated test case has more efficiently used their time than the run-rinse-repeat programmer.
Extrapolate that over a number of years, and the automated test programmer now has significantly more experience as a programmer than the run-rinse-repeat programmer. This is why ‘years experience’ on a resume is a low-quality metric to me; how many of those years were thrown away to inefficiency?
Related: How to Properly Mentor a Junior Developer
Identifying and developing fast test cases isn’t unique to programming, though. If I were practicing free throws with one basketball, each shot requires that I grab the rebound and then get back to the line and reset. Maybe I get one free throw every 10 seconds. If I have ten basketballs in a rack, I only have to collect the balls once every ten shots. Maybe that brings me down to 6 seconds a shot on average. If I get someone to constantly feed me basketballs, I get a shot off every two seconds. This allows for faster test cases.
Also in basketball, it is really hard to practice shooting a game-winning shot. Sure, you can take a shot from every position on the floor during practice hundreds of times. But a game-winning shot contains a lot of variables that can’t truly be reproduced in a practice environment. You’ll have to play every day for years to build up a resume of game-winning shot attempts.
Same goes for programming. It is easy to learn the syntax of a programming language; there is immediate feedback if you do something wrong. Learning to write well-architected code is hard. If you do something wrong, you won’t find out for a while – sometimes you won’t find out at all. You’ll have to write a lot of different software over a period of time to see those pieces fall into place.
If you have someone to help you, you’ll learn a lot quicker. Whether that is a mentor, a co-worker or a blog post that gives you a new perspective or tool – outside help can cut out the number of failures it takes to reach success. There’s a line to walk here though – you still have to write bad code on your own and you still have to do the work yourself. You can’t copy and paste the Stack Overflow answer for ‘How do I become a better programmer?’
Again, the same thing goes for basketball. Competing against people who are always just a little bit better than you is a great way to learn. Having a coach gives you a portal into more years of experience than one person could have on their own. Just like having to write your own bad code, you’re gonna have to miss a few crucial shots and there are no shortcuts.
Basketball and programming, as different as they are, are still both disciplines. And disciplines always require efficient learning. Find ways to optimize your test cases, a way to put a little something in each day and people who are working towards the same goal – not just in programming, but in everything that is important to you.
