|
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
|
|
|
|
|
Indeed. Good names and taking advantage of C++'s strong typing is good enough a documentation for 90% of all functions. I've often seen hard to read code that could be improved just by using appropriate names and the correct data types. int is overused - I've seen too many cases where bool or enum s would be a much better fit, and increase readability too.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|