Hi, I'm Gregory Brown.
My goal is to help software developers get better at what they do, whether they've been at it for five weeks or fifty years.
(he/him)
Early in my career, I treated every decision I needed to make in every project (no matter the size) as if it were Very Important and Very Urgent.
I thought this is what it meant to be conscientious and to pay attention to detail, but it really was a combination of perfectionism and a lack of experience that lead me to treat everything with equal weight.
All decisions in software projects involve trade-offs. But sometimes the difference between one option and another leads to a 100x difference in end results, sometimes it leads to a 0.001% difference. Most bike shed arguments fall into the latter category, and not only do they waste time, they burn relationships.
Over time I eventually also learned that things that are low priority concerns at one stage in a software project's lifecycle can become very high priority later on (and vice versa), and so having the "right argument at the wrong time" can be a big net loss as well.
This only became clear to me after seeing how things play out in practice on many different projects, over long time scales. But I sort of wish that I had learned earlier to always put the micro-scale decisions I made day to day into perspective by remembering the big picture end goals I was trying to achieve, and then figuring out from there what a proportional response looks like in any given situation.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Early in my career, I treated every decision I needed to make in every project (no matter the size) as if it were Very Important and Very Urgent.
I thought this is what it meant to be conscientious and to pay attention to detail, but it really was a combination of perfectionism and a lack of experience that lead me to treat everything with equal weight.
All decisions in software projects involve trade-offs. But sometimes the difference between one option and another leads to a 100x difference in end results, sometimes it leads to a 0.001% difference. Most bike shed arguments fall into the latter category, and not only do they waste time, they burn relationships.
Over time I eventually also learned that things that are low priority concerns at one stage in a software project's lifecycle can become very high priority later on (and vice versa), and so having the "right argument at the wrong time" can be a big net loss as well.
This only became clear to me after seeing how things play out in practice on many different projects, over long time scales. But I sort of wish that I had learned earlier to always put the micro-scale decisions I made day to day into perspective by remembering the big picture end goals I was trying to achieve, and then figuring out from there what a proportional response looks like in any given situation.