Depending on where you are at in your career, you may have heard of the term get the big picture or see the full picture.
Typically (not always) folks with less experience do not grasp this. This is not a bad thing. It is something that comes with experience and having a deeper understanding of the system you are working in. This is why more experienced co-workers are there to help and guide you.
I'll tell you a funny story that relates to my profile picture. I use this as my profile picture on DEV, GitHub and all social media.
I'm sporting my DEV shirt looking up slightly into the sky as if I'm trying to look tough or looking at some imaginary DEV flag that I should be saluting to. What you don't see in this picture is that I am in extreme pain. My feet are killing me and I have blisters on several toes on each foot.
I can't remember why I decided that day to take this photo and make it my profile photo, but I did.
At this point you might start asking questions like why is he in so much pain? Where did the blisters come from? Was it from a long run? An accident?
WAIT FOR IT...
WAIT FOR IT...
WAIT FOR IT...
Here is the original uncropped photo. You probably now know why my feet were in the state they were that day.
I participated in a great local fundraiser for a women's shelter called "Walk a Mile in Her Shoes" in which you literally walk a mile in high heel shoes. So what does this all have to do with software?
If you are given a feature and asked to implement it, don't just jump in and start coding that feature. Ask questions! Spend some time really thinking about the feature outside the specs that were given to you.
- Does this feature affect other features or other parts of the codebase? If so, is this a big deal? A welcomed change? Is it destructive?
- This feature is the basis for some very near future feature work (Not YAGNI, "You Ain't Gonna Need It"). We should take that into account instead of doing the quick and dirty way to ship this.
- This feature needs to make database changes. Will this cause downtime?
All hypothetical questions and thoughts about some imaginary feature, but the point is to think outside the bubble of a feature or bug fix. Think about the system as a whole and how your changes will affect it.
That's all for now folks, but I'll leave you with a fun action shot at the end of a very painful one mile walk.
Top comments (9)
this post is awesome. so funny, and so to the point. this concept of the big picture and about making questions is so important and so difficult to transmit to junior ( and not only) junior devs! thanx
hahaha. Great tip Nick. Looking at the big picture it's really important to spend effort on what really matters.
Nick, my brother, you look FIIEERRRCCCEEEEE in those heels! 🔥 🔥 🔥
Brilliant
Love, love, love this! Such a good reminder and message!
Mostly 90% of our Job is to figure out, why, how etc and only 10% we Code. 😄
Great insight nick, this is what i needed to hear. Thank you for kindling hope. 🙂
Grat post! Now if only my team would understand "think more code less"... Anyhow I'll share this to them. Thanks!