See the big picture

2 minute read

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.

My profile picture on DEV and 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?




Here is the original uncropped photo. You probably now know why my feet were in the state they were that day.

Me on my deck in high heel shoes after doing the Walk a Mile in Her Shoes fundraiser

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.