Check out this month's Hacker Monthly.
One of my Stackoverflow answers was reswizzled into a short article on class design.
That was gratifying.
Rants on the daily grind of building software. This has been moved to https://slott56.github.io. Fix your bookmarks.
Moved
Moved. See https://slott56.github.io. All new content goes to the new site. This is a legacy, and will likely be dropped five years after the last post in Jan 2023.
Showing posts with label stackoverflow. Show all posts
Showing posts with label stackoverflow. Show all posts
Thursday, February 6, 2014
Wednesday, May 25, 2011
Meetup Tonight
Tonight (May 25th). Red Dog. Colley Ave. Ghent. I'll be wearing my Stack Overflow shirt. I'll be there about 7. I know that at least one other person won't be there until 8.
The Meetup link.
I like this meetup idea a lot. Probably because the WFH life-style is a little isolating.
There's the small "Hampton Stack Overflow Community". We have a common interest in Stack Overflow.
Also, there's the 757 Python Users Group. We have a common interest in Python. I've decided to become the "official" organizer for this. I'm going to join the 757 Labs Hackerspace, also.
Tuesday, April 5, 2011
Performance Discussions and Software Design
Read this first: "There is something I find interesting about online discussions around performance issues..." It's about Stack Overflow, specifically. Apparently, someone didn't get their question answered and decided it was better to gripe than to rewrite the question.
Let's look at their response in pieces.
"people try to gang up". Since there's almost no social networking capability, this is a bit much to attribute to people responding to a poorly-worded question. But, if you've worked all day on a bad solution to a poorly-conceived problem, it can feel like being ganged up on. When reality leaks in, it can feel unpleasant.
Hint 1. There are no gangs. It's possible that the question really is poorly written.
"cookie-cutter, patronizing, zero-information responses". I'm guessing these are comments suggesting the approach is bad and asking for clarification. I run afoul of this often because I feel compelled to post comments asking for clarification. Some folks just don't like to clarify. More than once I've been told that their question was very clear. Since I'm asking for clarification, it seems odd to insist the question is perfect. Worse, of course, is asking for help on Stack Overflow, but refusing to clarify the help required.
Hint 2. Clarify. Please. Don't insist that the question is perfect.
"they assume, without any basis, that the person has not (a) benchmarked the code," When the question has no bench mark data, this isn't an assumption. It's a response to the lack of benchmark data.
Hint 3. Provide the facts. Don't complain when folks ask for facts.
"(b) is obviously running an inferior algorithm". Again, this isn't an assumption. It's the response to an incomplete question where the algorithm isn't provided. Also, it's a common response to questions where the algorithm really is inferior.
Hint 4. Consider that -- even after spending days banging your head against the wall -- your question might be poorly-written and require both benchmark data and an algorithm.
"advice about premature optimization... is a well assimilated folklore by now and I dont see how repeating that adds value". Without measurements, profiler results and benchmark data, this is our only possible response. After the profiler results are posted, this advice really is useless. Before profiler results are posted, this advice often turns out to be essential.
Hint 5. Whatever you might know is not well-assimilated folklore on Stack Overflow as a whole. We don't know you, sadly. We don't know how much you know. To avoid useless advice, provide evidence -- in the question -- that the advice has already been followed.
"better served if the discussion shifted to ... Pointed out possible bottlenecks ahead of time," Wouldn't that be nice? What's a "possible bottleneck"? It's a badly-design algorithm. So, the responses to performance questions has to be focused on algorithm choice right away. That means details on the code being used, and profiling information.
Hint 6. There is no hint 6. This would simply repeat hints 3 and 5.
"regardless of the fact whether the code construct is actually a bottleneck in the application or not, it is always good to know what the more efficient alternatives are... there is something called intellectual curiosity."
Reducing a question to a hand-waving hypothetical doesn't improve the question. It doesn't rationalize a poor question. The question still needs to be clarified.
Hint 7. If the question raises a lot of comments and useless advice, please rewrite the question.
Thursday, March 31, 2011
StackOverflow Meetup
See http://www.meetup.com/stackoverflow/Hampton-VA/ for information on next week's Stack Exchange meetup.
For other events near you, see the Meetup page.
I'll be wearing my "official" Stack Overflow shirt. I'll try to grab a seat by the door, also, to be easy to find.
#SOMeetup
Subscribe to:
Posts (Atom)
