I think as engineers we have to realize a few things:
1. Unless you are working alone and for yourself good communications are more important than most engineers will admit. The thing is: the quality of communication does not necessarily correlate with the quantity or the duration of it. And depending what role you play, you might not need a lot of communication in order to get a clear picture, while others might need more (for you: unnecessary) communiation to get on the same page. The drummer of my band always used to say there shouldn't be that much discussion about what we are playing, which is super easy to say if you don't need to harmonically integrate with other instrumentalists.
2. Every single one of us is in danger of dialing the degree of complexity too far, or not far enough. Every single one of us is in danger of doing things a certain way because we try to make them nice, while that makes them technically unmaintainable. Code is communication as well. Communication with your collegues or yourself in the future. Good code is efficient, reliable and communicates well. Sometimes we have to sacrifice a little bit of one for the other, but clear code and e.g. efficient code should not be seen as opposites, but as a multidimensional problem to which there are solutions that work better on both fronts and solutions that suck on both fronts.
3. Context. Many engineers I have met have a hard time explaining some concept or problem in a way that it is understandable. Either they dive in way to hard and assume everybody knows what they know or they will start explaining it and get side-tracked and end up talking about something entirely else. Giving someone a clear image of where we are and then zooming in on the detail in well-sized steps is a skill I wish more people had. This skill also helps when debugging, because you will check your zoomed-out-priors first and then bifurcate the problem space as you zoom in.
1. Unless you are working alone and for yourself good communications are more important than most engineers will admit. The thing is: the quality of communication does not necessarily correlate with the quantity or the duration of it. And depending what role you play, you might not need a lot of communication in order to get a clear picture, while others might need more (for you: unnecessary) communiation to get on the same page. The drummer of my band always used to say there shouldn't be that much discussion about what we are playing, which is super easy to say if you don't need to harmonically integrate with other instrumentalists.
2. Every single one of us is in danger of dialing the degree of complexity too far, or not far enough. Every single one of us is in danger of doing things a certain way because we try to make them nice, while that makes them technically unmaintainable. Code is communication as well. Communication with your collegues or yourself in the future. Good code is efficient, reliable and communicates well. Sometimes we have to sacrifice a little bit of one for the other, but clear code and e.g. efficient code should not be seen as opposites, but as a multidimensional problem to which there are solutions that work better on both fronts and solutions that suck on both fronts.
3. Context. Many engineers I have met have a hard time explaining some concept or problem in a way that it is understandable. Either they dive in way to hard and assume everybody knows what they know or they will start explaining it and get side-tracked and end up talking about something entirely else. Giving someone a clear image of where we are and then zooming in on the detail in well-sized steps is a skill I wish more people had. This skill also helps when debugging, because you will check your zoomed-out-priors first and then bifurcate the problem space as you zoom in.