We just got through a full company retreat. Thinking back over my career, this might be the first company that I worked at that actually did one of those. I have done team things before, and had all company meetings, but not a full on retreat. It was great to see the entire company come together to work on a common theme, and stop our day to day work to take a step back and look at our upcoming focus from a higher level.
There were some great talks by my fellow employees (the employees were in charge of the programming for one of the days), and one that stuck with me, discussed effective vs. efficient and how one should work first on the effective and then try for it to be efficient. I see this all the time pop up with processes that occur around requesting code changes, deployment strategies or how the business works with IT. It also made me think back to my first software engineer position, I was an associate at a transaction processing software company. For my first code review I actually printed off my code. Literally onto paper, handed out copies to my product group and they made suggestions, in pen, for the code. Was it efficient? Not on your life, but for some reason that was how it was done and that was how I was supposed to do it. This might have been somewhat effective, as a learning experience and sharing what people were working on, but was not at all efficient.
When you just focus on your day to day, and getting work done these type of problems just seem to pop up. They usually start because it was the easiest or quickest way of fixing something. If we don’t take a step back and look at the why, and our long term goals, it is easy to get bogged down in the weeds.
Oldest comments (0)