When you work, don't code like you have a shotgun. Pretend like you are a sharpshooter, preparing and waiting for the right moment.
It might be hunting season, but don't let yourself become a shotgun coder.
Shoot From the Hip
Ever notice how in first person shooter video games, you usually have two strategies to play? You either are the player that lines up every shot down the sight; usually implementing tactical approaches, strategy, and patience to accomplish your goal...
Then you have the people who play the games like me. I am loud, crazy, and shoot from the hip. I might not be as clean or as successful as most people who play these games, but my strategy is that if I attack from the hip faster, with less accuracy, I can accomplish more 😎
But it's weird, because I know this isn't the case. Having strategy, patience, and tactical knowledge will always win over the free-for-all firing of more novice players...and when we draw parallels to software design and programming, don't the same schools of thought exist?
The Shotgun Coder
Try to understand and solve problems before you even touch a line of code.
My video game style is similar to my coding habits...I tend to shoot from the hip. It's a very, "build first, design later" attitude. I assume that as I go along with the project, the solution will just magically become more clear to me, and I'll have the epiphany that solves everything!
The Shotgun Coder is one who assumes that by trying every strategy, they will eventually get what they want, instead of sitting back and really solving the problem first. In other words, Shotgun Coders don't want to think for themselves, they would just rather have the computer figure out the solution after they've tried x number of attempts.
Back when I was in high school, I was a member of a FIRST Robotics team. My team's mentor nicknamed me The Shotgun because whenever a problem would come up, or something had to be fixed/added, I would always rush to the code to try different strategies, instead of sitting back and thinking up the best solution first. This approach had a low success rate, led to a lot of mishaps and failed attempts, including an instance where the robot destroyed itself due to some untested code...(Always test, folks)
I see the Shotgun Coder mentality come out a lot when [mock] interviewing people. I ask a technical question, and more than half of the candidates jump to code without even clarifying the question!
It helps so much, and looks a lot better, if they take a breath, step back, and try to solve the problem without using code. Try to understand and solve problems before you even touch a line of code. This goes for algorithms and project design.
Is There a Way Out of the Woods
Ha! Shotgun → Hunting → Woods...oh the titles are great when you explain them...
So how do we avoid being a Shotgun Coder? Well, think back to the video game argument at the beginning of this post. There's two different types of people...we want to emulate the ones who are smooth, precise, patient, and tactical. They are usually the ones that end up winning the game. Instead of firing from the hip, we should be slow, careful, and have a clear sight to aim for our goals, to ensure we hit the bullseye.
So what does this mean for coding and designing?
It means take your time!
It is better to take more time planning and preparing a detailed solution, so that you (and your team) don't have to spend so much time shooting from the hip and hacking mini-solutions together for problems that weren't thought of in advance.
Would you rather take two weeks designing something, and a week to build it, OR would you want to immediately start building it, only to realize you didn't understand the big picture, all the features, or exactly what the end goal was?...Yea, now what could have been a three week project is now three months in, you've lost your hair, and your significant other has left you because you have nightmares screaming project management terms in your sleep...CONFLUENCE!!
This advice goes for interviews, school projects, tests, work, starting a company....anything you can think of! Don't be a shotgun thinker! It's good to get ideas out quickly, but its even better to then take those ideas and figure out the next steps before jumping into them.
Take what you have now, take where you want to be, and although its okay to take a few unguided steps along the journey, plan everything out before you start shooting from the hip.
Top comments (6)
I agree with most of the points, but here I need some clarification.
Are you advocating for waterfall? (Which has its own merits and use-cases by the way)
While the big picture is important, it's rarely possible to understand up-front everything, all the features and the end goal exactly, when even the customers don't know what exactly they want.
I'm not really a purist for either Waterfall vs Scrum/Agile, and I wasn't actually thinking of project management when writing this post. I approach this mentality when it comes to solving problems, where people jump in with coding a solution before they even understand the problem.
Thanks for pointing out that it draws some heavy similarities though!
I like to use the Cynefin framework, to categorise issues being investigated by my customer(s) and the problem solving team. Once there are some categorised issues, work can start to find solutions using the different techniques appropriate to each category, including doing some exploratory coding to reduce the risk of unknowns (proof of concept work) if appropriate - don't keep all the fun bits for later :)
Both approaches have merit, choosing the wrong one is painful in either direction.
Understanding the big picture is very important. But that's not a programming activity, that's learning what your stakeholders care about. It's not even requirements gathering, requirements are implementation details that exist because someone thinks it will achieve a goal. Knowing the goal is important, creating a plan to achieve the goal can be useful, but can also be counterproductive.
I've seen many many times that planning takes overwhelmingly longer than jumping in because you don't know what's best until you get there. In its most malignant form, you don't solve the problem, but you commit to a bunch of decisions. Then, when you get there, the pieces aren't fitting, your understanding of the problem has changed. And as you look at the plan you made for the future, it's going full tilt into the problems instead of adjusting course.
It's generally better to invest in low coupling, low commitment, fast iteration time. Write your code so it's easy to change and so you can delete with as much ease as you can add. Hell, you could even spend that first week implementing shitty prototypes and then spend that second week planning based on what you learned in the first week. I'd expect that to be much more effective.
Anyway, planning is right for some problems, so it's good to have that in your tool chest, but it's an absolute mistake to apply that tool to every problem you have. Especially within the domain of programming where planning and its cronies have such a consistently bad track record that manifestos are written to defang it.
100% with you. This is great advice. <3
Great advice.
I used to do this most the time but now I take extra care before starting any project & tasks.