|
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 enums 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)
|
|
|
|
|
a big Bronx Cheer if you are using Doxygen, just saying. 
~d~
|
|
|
|
|
I do not believe that function needs any documentation as the function name and argument names are self explanatory as they should be. In my own work I rarely document for that reason. Also I am lazy
|
|
|
|
|
I've been called out in meetings and *thanked* for writing comments. We have a fairly high turnover rate where I work, and knowing that, I comment pretty much everything I do, not so much as the "what", but more the "why" of code. I also comment as if the person coming in behind me is fairly new at being a programmer.
I've actually gotten letters of commendation for my "drive towards more maintainable code".
Good comments are worth the effort and the clutter that necessarily comes with them.
We don't use Doxygen,
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Perhaps, now you have some influence, you can convince your employer and team to use Doxygen -- take your code to the next level.  ![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
~d~
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Elephant | [mastadon]](https://codeproject.freetls.fastly.net/script/Forums/Images/elephant.gif)
![Sunshine | [little ray of sunshine]](https://codeproject.freetls.fastly.net/script/Forums/Images/sunshine.gif)
as documentation and call it a day. Now I know precisely what public members your library defines (reading the code is out of fashion) and nothing at all on how the 
