I remember early in my career, a developer, a buddy for whom I have great respect, making fun of a peer for reading so many design pattern and programming books. As this peer learned, he constantly mentioned these design pattern names or programming concepts. My friend thought the person was doing it for show, to sound impressive or smarter than other people. I do not fault my buddy for that conclusion. I suppose sometimes it does happen. This younger peer very much lacked soft skills and often came off as a “know-it-all”. Even I questioned if this person was showing off due to insecurities or maybe pride.
After more observation and time working together, I concluded that although he did have a low self-esteem, he was sincerely trying to hone his skills. He challenged himself to be a better engineer by learning from others’ experiences. He was doing his best to improve his communication skills. Because he took great pride in his work, he truly desired greater expertise.
I am often reminded by similar situations in the work space that people are not always as they first seem. It takes time to really get to know someone. We should always give people the benefit of the doubt. The book smart person is not always the “no action and slow delivery” engineer. The “quick delivery” developer is not always just a coder who cannot design well while considering clean and long term concerns.
I know there are a lot of people that fit into these two extremes but not everyone does. There is a balance when creating a solution for a particular problem. It can be sometimes hard to find that balance. You have to weigh your options. Sometimes the solution requires more concern for the short term versus long term. I would rather have someone on my team that can judge this well. I would rather have someone who can knock a solution out quickly when needed but also one who is more learned to understand the long term consequences. I would rather have one that can better communicate and collaborate with team members to find the best solution.
I agree whole-heartedly with this young peer’s mind-set. It is one of the reasons that I believe being a Software Engineer can be fun. I love to learn. If you take pride in your job, then you realize in our field, we should always be learning.
Patterns are just a way to relate a concept to a particular word so that the concept can be communicated easily and quickly. Imagine having to explain the common solutions to common problems from start to finish every time you wanted to talk about one of them or suggest one of them. Isn’t it much easier for a person in our field to learn those terms? If we take pride in what we do, shouldn’t we learn the words that are used in our field of expertise? Can you imagine if a doctor had to describe in detail the common procedure for fixing a common problem versus just saying one word and someone in their expertise getting it?
"Nurse, this patient is scheduled to have blood vessels removed from part of his body so we can use them to repair the coronary artery. Their artery has become blocked and we must repair it... first we will blah blah blah"
Isn’t it much better for the doctor to say the following?
"Nurse this patient should be scheduled for a Coronary Artery Bypass"
Whether you are an engineer, or working in a warehouse, I believe you are getting paid to do a good job and should do that job to the best of your ability. Knowing common solutions for common problems and what those solutions are called is part of the job. That said everyone has their strengths and weaknesses. It is up to a good self-managed team or manager to organize those different strengths and weaknesses correctly within a team so that the members’ talents complement each other. We have to use the right tool for the right job.