|
rnbergren wrote: Boss wants to be part of the meeting. Wants to be "in" the discussion. Thoughts on how I can keep the meeting moving along so we cover the items we need to cover?
Two people talking would not normally be a "meeting". You can't really get sidetracked or have conversations that are off topic because everyone in the meeting is in fact participating. Presumably because everyone (the two people) consider all of the discussions relevant.
Three people would be a meeting. And you have concerns about what contributions your boss would actually make.
Thus you do not have a meeting problem. You have a management problem. Might be specific to the manager in that they are not in fact contributing anything. Or in general because all meetings in the company tend to go this way.
In general businesses cannot solve process problems unless senior management actually supports and in fact demands that processes are defined and followed. If that is not the case where you are then you just deal with it. Let them babble on about their vacation plans and how their teams did. For yourself just accept it as team building. At larger companies you are perhaps more likely to be able to discuss and solve this because more managers means more of them are likely to see it as a problem. With senior level support one can have arbitrators in meetings whose role is to specifically keep the meeting on point.
But there could also be causes outside of what you described here. For example the other person in your meeting has told your boss that you are a bully. Or that your demands are non-specific and outside the normal business requirements. So your boss is in fact attempting to mediate.
|
|
|
|
|
I'm with the codewitch on this one - avoid them like the plague. I never had any compunction asking the meeting to "move on", same effect as "discuss this offline".
I also found asking if I was needed for this discussion and then leaving had a curtailing effect on senior management who liked to pontificate about irrelevant crap.
Eventually I did not get invited to non essential meetings which meant I missed out on a number of social events - thank the Great Ghu.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
1. Have an agenda and stick to it.
2. Be ready to say "let's take this off-line".
3. Document everything, and send around meeting notes.
a. If done right, this may have even stopped your boss from wanting to sit in in the first place.
4. Finally be open to listening what your boss wants, and don't forget that they are the boss.
Be prepared, that last point is probably going to be the hardest one for you to follow.
You made mention that the is more management than programming, the fact is the best programmers not only have good technical skills, they also have good soft skills such as managing people, and that goes both ways.
|
|
|
|
|
I also used: "We can talk about it or we can do it. Your choice.". I haven't been praised for my diplomacy but I have been praised for the efficiency.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Come up with some expectations of what you expect to achieve in the meeting and bring this up at the beginning of the meeting.
Such as "I have called this meeting so that we can come to a decision on x, I would like us to decide in the meeting what we will do with x by the end of our meeting time."
Then ask people if they agree or disagree with this - that way you are making it clear that they play a part in getting x agreed on.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I have a tendency to make jokes in meetings. On one such occasion for reasons I do not recall another programmer stated there is a shortage of Priests in the Catholic Faith as the conversation somehow became off topic. The meeting was with a client a big shot Chicago Board Options Exchange trader a very successful and aggressive capitalist worth millions. So I stated "Sounds like a business opportunity" It got a good laugh. I later regretted not also stating "Revs for Rent" "You Pay We Pray"
|
|
|
|
|
1) Have a goal for the meeting
2) Have an agenda for the meeting to achieve the goal and stick to it
3) Deviate from the agenda ONLY if there is a discovery that serves the goal more than the original agenda and everyone agrees
4) Schedule the meeting to end 10 to 20 minutes early so that you can table side discussions and detail problem solving that applies to a subset of the attendees. They can stay on whilst the rest can drop.
5) Invite ONLY people that can help achieve the goal
6) Document action items, decisions, and discoveries. Nobody has time for a transcript.
|
|
|
|
|
Hold the meeting standing up.
|
|
|
|
|
star couple (definition)
discard bin
constellation Aries
binaries
|
|
|
|
|
Should really be star couples - nut nice clue.
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
modified 8-Jul-21 4:33am.
|
|
|
|
|
Couple is more often treated as plural: the couple are getting married.
|
|
|
|
|
Well done! I was nowhere near!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I thought maybe you were near, or didn't want to take it, because of your previous comment. I was going to reply Batalix[^] but thought it would be too much of a hint.
|
|
|
|
|
Nor me
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
I haven't solved one in months. The CCC wasn't there when I looked this morning, so I looked after lunch and it was there, then. It took me about 4 mins, which I was very pleased about. But, before submitting I thought I'd better check whether the solution had arrived. It had, three minutes earlier, so it was too late to post. Never mind, maybe in a few more months, another one will come along that I can manage.
|
|
|
|
|
If you managed this one, I don't think it'll take you months to manage the next one!
|
|
|
|
|
|
Those aren't devs - those are script kiddies.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Indeed.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
The code is the urtext, and its documentation is a derivative work to help readers understand it. Cluttering and defiling it with tags to the point where it has to be exported by a tool is an abomination.
|
|
|
|
|
I have to agree with that. I really hate code where every function has a heckin' header on it. Just comment a description. If it takes more than one line to describe it, in most cases, write another function.
Real programmers use butterflies
|
|
|
|
|
I don't mind headers, as long as they are sensible - I use spacing comments a lot and a small header works just fine. i.e. something like this is fine for me (about the max size I can tolerate for a header)
They are just an embellishment of a comment though, documentation is another thing entirely.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Yeah, I don't care for that stuff, because to me it increases maintenance without (usually) adding much value beyond the description. I tend to lean on long, descriptive parameter names and hard typing everything I need to be as descriptive as possible, even if means using a bool instead of an int like a lot of people do. =)
Real programmers use butterflies
|
|
|
|
|
If all you do is write simple methods then of course what you state is true.
But often methods fulfill complex needs that are not clear from the code itself. And comments are necessary to explain what need the code is fulfilling. A maintenance programmer should not be required to understand and be familiar with the entire application just so they can make a change in one method.
And that is an ideal world. Methods, especially in legacy code, often grow due to convenience and work load rather than because it was optimal. And with multiple requirements being met that way it becomes very difficult for maintenance programmers to make required changes without impacting the application in unexpected ways.
|
|
|
|
|
Yeah, code rots. At some point it should be rewritten, and too often in the industry it gets punted until long after it's necessary to do it.
Fortunately I don't have to deal with that anymore.
I document my design and architecture down to the code level usually, so the functions are pretty clear, if you read them.
But then I don't have to work on teams anymore, so I've shed a lot of the baggage/overhead that comes with that.
Real programmers use butterflies
|
|
|
|