Earlier we discussed the issue of “attitude.” I believe everyone has the attitude to do “better,” or otherwise we would not be working together. Sometimes you might still wonder why “wanting to do better” does not turn out to be the case.
This is when we should calm down and ask ourselves whether we really tried. While it may sound strange, you may surprisingly find no signs of trying. Although I do not practice such reflection on a daily basis, I always ask myself this question whenever I feel frustrated and upset. Through this process of “introspective reflection,” it is possible to determine whether I really proceeded with “implementation.”
Perhaps you would tell me that there are no opportunities to try at work, and there are various concerns about allocating your own time after work. I certainly understand most of the time. Especially when I notice my inability to withstand limitless stress and fully commit my life to work. I understand that everyone feels fixed in place by their work, and has the needs to relieve work stress after a shift.
However, is it really true that we do not have the opportunity to “do better”? Or is this an “excuse?” It is not a shame to look for excuses as I also find my words and deeds in the past to be full of excuses. After all, we are afraid to do things wrong and finding excuses can reduce some of the stress.
Nevertheless, we still need to think about potential room for improvement at work. Most people have read books on refactoring and design models and we know there are some signs to look for. Then why don’t we think about re-encapsulation when seeing redundant codes? Why don’t we think about whether or not to refactor the codes when modifying or adding functions? Or why do we trust answers from Google or suggestions from other people when we design a function for the first time? Why not make a decision based on our judgement after multi-party verification?
Time may be a restraint and customer requirement may be another. But are these unsolvable issues? In terms of project timelines, we try to give junior engineers a sufficient amount of time as much as possible. Although you may be unfamiliar in the first few tries, did you try to refine the technique after becoming more familiarized with it, or did you just keep the status quo?
If customers develop more functional expectations during the implementation process and thereby exceeding the original timeline, should we be silent about it? Definitely not. To the management and supervisors, this is our responsibility to communicate and coordinate. Other than development, we should let customers know that software development is not only about function delivery. Instead, the software should be perceived as an organism that needs healthy codes to sustain long-term usage and growth. Our attitude toward such requests is to mediate with customers and obtain more resources for comprehensive designs, refactoring, and testing.
There are many practice opportunities in reality. In other words, there are opportunities during the coding process that you must seize before you miss. This is why I always “proceed before discussion.” In my past experience, it is easy to miss opportunities that could have been earned by being satisfied with the status quo. Hence I learned the importance of getting myself ready for opportunities at all times, especially for things that can be predicted (wage increase, promotion to a supervisory position, etc.)
We try to strive for opportunities in response to time and customer requests. Hence the critical keys lie in whether we make the commitment to practice and grow.
At 5×RUBY, we aspire for continuous improvement and implementation until we finally become the best practice. This is our pride.
On the path of technology, what matters is not how fast we walk but rather if we can walk further taking one step at a time. We hope that everyone can remain committed until the end. I will always be here to march forward with you and become better together.
Have a nice day.
蒼時 Cang Shi