*But they definitely can be
The sentiment "I'm an engineer, and meetings just hamper my productivity" is pervasive. Many engineers you talk to (including myself) will likely say something similar to this when prompted on their opinions about meetings. My opinion on this has changed, but what's critical is to make sure your meetings are effective. You need to focus on three major facets when deciding if you need to have that meeting or if it's wasting everyone's time. They are scheduling, content, and takeaways...
Scheduling: Who? Where? and When? are the most important questions to ask here. Keep the invite list small but allow others to join if they want additional context. I have found that often if people aren't required to be there, they will sometimes join because they want to learn or feel they have something to contribute. Your mileage may vary depending on the team's culture, so find what works for you.
Nowadays, the "where" is usually online, but I often enjoy the in-person brainstorming or explanation meeting when wrapping my head around more complex topics. In-person, meetings are also less exhausting to me than video calls, but this also varies from person to person.
When? I have acted the least strategically in this area, but I want to get more deliberate about it. My hunch is that timing doesn't matter as much, but avoid lunch breaks, be conscious of time zones, and respect people's focus time. The most important thing here is to keep the meetings as short as possible without being pointless. If you dive deeply into specific topics, most meetings only need a full hour.
Content: "What are we actually talking about?" Every meeting should have an agenda. This is rarely a shared agenda, but that is a valuable tool I want to introduce into my arsenal. I usually have a list of talking points on a piece of paper on my desk that keeps me focused.
For example, suppose I have a meeting where I am trying to glean more information about an existing metrics service owned by another team. In that case, I might have the following on my agenda (granted, this is a contrived example):
I will work through the list, noting any notes and crossing off items as they are covered. If you cover everything on your list, end the meeting. Try to spin up side conversations only if the other meeting members are receptive or are pushing for it and everyone has time. This keeps you away from having meetings that drag on where most people aren't engaged.
Doing this, it's very common for me to have a meeting that could've easily dragged on to an hour and be done in 30 minutes or less.
Takeaways: If you can't come up with a few takeaways or "action items" for both parties in the meeting, you probably shouldn't have had the meeting in the first place. Take a moment at the end of every meeting to deliberately recap what you talked about and the action items. Usually, this will include a summary document, as well as a note to create Jira tickets or change a specific feature. For example:
This is the strategy I am trying to follow now, but I always want to take a look and revise my approach. If you agree or disagree with anything here, don't hesitate to get in touch with me. I'm always open to new ideas.