When a developer approaches a problem, they usually have a clear objective.
Fix this bug, create that component, refactor this implementation.
Were very goal oriented by nature.
But heres the funny part…I rarely noticed when I was switching between them.
Afterwards, well examine the two programmer mindsets more closely.
My recent journey
Right now, my team is at an interesting point in our long journey.
We first started by building the menu & checkout pages of the website.
It’s free, every week, in your inbox.
Our main challenge for this page was implementing the various filters and sorting mechanisms.
Each team was responsible for building pages from the ground up.
During this period I was mostly in what I started calling thearchitectmindset.
Instead, we were following what was already in place.
We deliberated and agreed to follow the coding conventions that wed established together.
you’ve got the option to think of it as buildingon top ofwhat was already there.
This is the other mindset, what I call theadaptermindset.
Neither mindset is better than the other.
The two work together as yin and yang.
Both mindsets are utilized by developers of all experience levels.
The trick is to be mindful of when its best to be in one mindset over the other.
Lets get into it.
This is when we start whipping out the dry erase markers and get to the whiteboard.
Youll be weighing the decisions of one possible implementation with another.
This allows us to keep conventions for certain patterns in mind.
They can be as small as preferringBoolean(foo)over!
!fooor naming your redux action creators in the past tense likeorderSubmitted,preferenceSaved, etc.
Were following patterns that have been laid out by previous developers.
Good architectural decisions have been made to allow your software to extend and scale.
Imagine joining a big project thats been active for 2+ years.
These various functions will be depended upon and utilized throughout the system.
This places you in the adapter mindset.
Is one mindset better than the other?
Switching between the two mindsets
One approach is not better than the other.
In fact, as software developers we need a proper handle on both approaches.
But senior developers can greatly benefit from mastering this mindset.
Assume that you have little knowledge about this topic and that the program is decently matured.
A smart developer will first research which mechanisms already exist and can be reused.
These are steps that we take while were in the adapter mindset.
Then, lets assume another scenario where you you better request certain user data from a separate API.
This is the moment when we switch to the architect mindset.
Have I checked in the codebase for a similar implementation that can be reused?
Or am I just coding away on autopilot?
I kept looking for an existing way to solve my problem.
went on in my head.
I was trying to extend what currently existed in the codebase.
I needed to approach the problem from the architect mindset.
I had done my research and testing, and determined that the solution did not exist in the codebase.
I would have to build it myself.
This late realization happens more often than you would think.
Dont beat yourself up if it took you a bit of time to make the connection like I did.
This is all part of growing as a developer.
The important thing is that you note these moments in your career and learn from them.
I appreciate how these concepts are reflected in scrum.
Conclusion
Sometimes it feels as if youre expected to know all the answers about your codebase.
Working this way will build stress and can lead to burnout.
Thats why its important tothink about how you think.
Which approach will most likely lead me to a high quality solution?
Software development is all about trial and error.
Its always cognitively demanding.
This article was originally published on theJust Eat Takeaway-Tech medium blog.
you could read ithere.
