Ed Weissman's Blog, page 2
January 19, 2012
January 3, 2012
How to Participate in Hacker News
I recently received an inquiry from a Hacker News newcomer on how to best participate in the community. I was ready to reply, "Just follow the guidelines and be yourself." Then I realized that it was actually a very good question that deserved a much better answer.
So here is my more detailed answer, based upon many years of hard knocks.
First of all, follow the guidelines! This is a necessary, but not sufficient condition.
http://ycombinator.com/newsguidelines.html
There are literally hundreds of discussions about Hacker News participation just a search away, with much to learn. Hopefully, I can add something new here:
1. Be yourself.
I know that sounds lame, but think about it for a moment. Who else are you going to be? I see no need for "personas". Just be yourself. Talk to others just as if you were in the room with them. Let others see you as your genuine self, full of strengths and areas primed for learning. We can all grow together. Many of us will meet our future in this community.
2. Participate!
I never understood why people lurked so long. No need to be shy here. If you have something to say, say it. If not, then just lurk and learn. But everybody has something of value to share. This is one of the best places to do it.
3. Be positive.
This can really be hard when smart people debate, but try it anyway. Notice the difference between:
Person A: Water is dry.
Person B: No it's not. You're full of shit.
and
Person C: Water is dry.
Person D: Not in my experience. What data have you encountered to cause you to arrive at that conclusion?
I realize that this is an extreme trivial example, but try to be more like Person D than Person B.
4. Make friends.
Harness the power of the internet! You are not restricted by geography, circumstances, or time period (to some degree). There are many incredible people here who you would likely never meet most other places. Take advantage to the opportunity to meet them, in Hacker News discussion threads, off-line via email, and even in person. Put your contact info in the "about" section of your profile (the "email" is private). Organize and participate in local Hacker News get-togethers. Who knows, your next co-founder, investor, or friend for life may be one or two clicks away.
5. Have something to add.
Again, this may sound obvious and lame, but think about it for a minute. Which comments do you like the most? The ones that add data (which very oftens translate into value). The key words are "add", "data", and "value". If you have something interesting to add, the please add it. It's not just your right, it's your responsibility! Everyone wins when you do this: the community gets richer, someone gets value, and you get a bit of a following as an expert in something.
6. Know when to talk and when to listen.
If you have experience doing something being discussed, then by all means, share it! If not then read, listen, and learn. If you have a theory about something but aren't too sure, fine. Just say so. Shocking, but just because you read something on the internets doesn't necessarily mean it's true. And most of all, please never start a sentence with, "It seems to me...". Many of us already get too much of that from our PHBs.
7. The articles may be valuable, but the real gold is in the comments.
If an interesting article posted on Hacker News fell in the forest and no one commented, did it make an impact? Sometimes I post something interesting just to see what you guys will say about it.
Remember:
Good umpire: I call 'em as I see 'em.
Better umpire: I call 'em as they are.
Best umpire: They aren't anything until I call 'em.
Similarly:
Good article: I write 'em as I see 'em.
Better article: I write 'em as they are.
Best article: I'm nothing until until the Hacker News community comments on me.
8. Try to focus on your work.
I know this is controversial, but our work is what makes this community what it is. There are debates about all kinds of things here and elsewhere, but remember, our work is our common thread. Frankly, I'm much more interested in what you built, what you encountered when you built it, and what you learned than your opinion about SOPA.
Another old story:
Husband: I am the head of the household! I make all of our family's critical policy decisions on the world's major economic, political, and industrial issues!
Wife: I decide the little things like where we'll live, what we'll eat, and where the kids go to school.
Similarly:
Commenter 1: This major issue can have profound impact on our technological future.
Commenter 2: I don't know much about that, but here's how it took me 9 tries to get my app just right for my audience.
Notice that everyone is right, but I still prefer reading the comments of the second person in each example.
9. Be nice.
Life's too short for anything less. There are many other places any of us could be, but we're here. When people aren't nice to me, I just close my browser and come back another day. I know that sounds silly, but it dealing with not nice people is just a big waste of time and everybody loses. Please don't be that person.
Patrick Swayze's character in "Roadhouse" says it much better than me:
http://news.ycombinator.com/item?id=3354139
10. No list is ever exhaustive, on Hacker News or anywhere else. Anyone have any other suggestions?
Follow @edw519
December 20, 2011
Stupid Bosses I've Had (Part 2 of 2)
This is a follow-up to "Famous Last Words by Bosses I've Had" here: http://edweissman.com/famous-last-words-by-bosses-ive-had
Stupid Bosses I've Had (Part 2 of 3)
This is a follow-up to "Famous Last Words by Bosses I've Had" here: http://edweissman.com/famous-last-words-by-bosses-ive-had
December 16, 2011
Famous Last Words by Bosses I've Had
Sorry to say, none of these were made up...
Me, 124 Monday lunches in a row: We need an adequate disaster recovery plan.
Boss: We do. We back up every day.
Me: What happens when we try to restore one of those backups?
Boss: I don't know. Why?
Me: Where's the test plan?
Boss: Jerry will make sure Fred's program works.
Me: Where's the "Expected Results" section on the test plan?
Boss: What?
Me: I don't have access to the production server.
Boss: I already emailed you your password.
Me: I know, but I don't know my login.
Boss: What's a login?
Me: That doesn't make any sense. Have the auditors approved it?
Boss: No, but we can't have everything.
Boss: I'm really upset that no one has updated me on Project 127.
Me: I cc'd you on all 9 Project 127 emails I sent this week.
Boss: I haven't had time to get caught up on my email.
Me: You've been invited to a meeting with 3 department heads to hash out their differences on Project 249.
Boss: I hate meetings.
Boss: Why haven't you started the Accounts Receivable project yet?
Me: Because management has not yet decided whether customer credit limits should be per division or companywide.
Boss: What difference does that make?
Boss: We have hundreds of past due orders.
Me: No, we have 22 past due orders.
Boss: I'm not going to argue with you.
Me: Good, because you'd lose.
Me: We're meeting with the customer at 8:00 a.m. tomorrow.
Boss: I hate mornings.
Me: The server crashed. IT Services is working to bring it back up.
Boss: Don't confuse me with all these technical details.
Me: The customer didn't receive that information because that product is not on our computer.
Boss: Give me a list of all products not on our computer.
Boss: Why haven't you started Project 193 yet?
Me: Because the customer has not yet committed to the specs.
Boss: What difference does that make?
Me: The program was written with 3 SQL selects inside a loop. It ran OK when we had 500 parts. Now that we have 10,000 parts, it runs real slow.
Boss: I don't understand.
Boss: What are you working on?
Me: Project 432, which you said was my top priority. Remember?
Boss: No.
Boss: Why aren't you working on Project 387?
Me: Because you said not to work on anything else until Project 432 was complete. Remember?
Boss: No.
Boss: I'm giving you only enhancements. I'm outsourcing all of the bug fixes.
Me: But this is a bug fix. It says so right here on the ticket.
Boss: Oh, I didn't have time to read the ticket.
Boss: Amazon is threatening to shut us down because we ship too many orders late. How do we fix this?
Me: Ship every order on time.
Boss: No, I meant, "How do we fix this with software?"
Boss, on December 31: Write a program to close every work order so we make our year end numbers.
Boss, on January 3: Why is the database so screwed up?
Boss: You did great this year. I'm giving you a 2% increase.
Me: I hate you. I quit.
Boss: Then I'll give you a 4% increase.
Me: I still hate you. I still quit.
December 15, 2011
Insidious Bug or Comedy of Errors?
A client presented me with an obvious and significant problem that required immediate attention. I worked on the problem and helped them solve it. Along the way, I discovered a whole bunch of things that merit further examination by software developers.
The names and facts are changed and I will present the code as pseudo-code. I never compromise client confidences and the technology doesn't matter: this could have happened anywhere.
This is pretty much bread-and-butter backroom application software for a large enterprise that processes lots of orders for lots of dollars...
I was presented of a pdf of a Purchase Order that had been emailed to a Vendor. The problem? No prices. Yikes. This could be a huge problem. The company emails thousands of Purchase Orders to Vendors every day, full of data supporting critical legal and mission critical transactions. The fundamental data elements are Part Number, Quantity, and Price. How could the price be missing? And how could it only be missing from one (or a few) out of thousands of Purchase Orders?
I started by doing what any digital sleuth would do: I tried to recreate the problem. Fortunately, this worked on the first try. I reprinted the Purchase Order and sure enough, no prices. I reprinted several others and there were prices.
The next step was to isolate the problem, debugging backwards. Output Record? Blank price. Variable feeding Output Record? Null value. Price on Purchase Order data base record. Fine. Hmmm. Next I examined the logic pulling the data from the data base and placing it in the output variable. It was looking for the Price in Column 22, the column for Foreign Currency Price. On an order to a California Vendor? OK, I was onto something.
I zeroed in on these two lines in the print program:
CurrencyCode = PORec[45]
if CurrencyCode = "USD" then PriceCol = 21 else PriceCol = 22
What was in Column 45 of this PO Record for this California Vendor? "USD" and a bunch of delimitters. Hmmm. That would cause PriceCol to be 22 when we obviously want it to be 21. The Price was in Column 21 but we are pulling a null out of Column 22. Bingo.
The customers are screaming. The business is suffering. Now what?
Stupid way out: Get the Currency Code from the Vendor record, not the PO Record
Lazy way out: Strip the delmitters from PORec[45].
Right way out: Find out what's putting delimitters into Column 45 of the PO Record.
Long term solution: See below.
The right way out can be very difficult with a large code base. First I isolated the 614 programs that had been promoted into production in the last 90 days. (I figured that the problem was new so the culprit program must be fresh.) I searched for the string "45". 42 hits. Nothing suspicious. Next I looked at data dictionaries and canned functions that provided potential synonyms for Column 45 of the PO Record. I found four possibilities. Then I searched the 614 programs for each of these. Nothing. Hmmm. Standards that no one follows. OK.
Then I simply scoured the list of 614 programs. One name caught my eye: "PoSplitter". Brand new. Written by a contractor who didn't know the whole application. Promoted 3 weeks ago. I read the whole program. No reference to "45", "Foreign Currency", or anything seemingly related. But one variable looked suspicious: DatasetCols. What was this? A list of columns in the PO Record that had matching multiple values, one for each Part on the PO. DatasetCols was a global variable passed down by a master routine. I read that routine and (bingo!) found 45 in the list of DatasetCols. I traced the mods back to 2005 when it was added to the list.
I double-checked the data dictionaries and the common functions. All said that Column 45 of the PO Record must be a single Foreign Currency Code defaulted from the Vendor Record and joined to a preset table. On the other hand, the master PO routine had it in a dataset list. A dataset list that had never been referenced by any other program until that contractor used it in PoSplitter. So, as soon as his program went into production, for every Purchase Order that was "split", Column 45 kept its original Foreign Currency Code along with a delimitter for each Part on the PO. Which in turn caused the PO Print program to fail to secure "USD" and automatically default to Foreign Currency (note that this bug would never affect foreign orders).
The immediate (right) solution:
1. Remove Column 45 from the variable "DatasetCols" in the master routine. Recompile all affected programs.
2. Clean up the data base.
The long term solution:
1. The data dictionary must be the Bible. Have no other code, variables, or function that can possibly say something else. Variables like "DatasetCols" must never be hardcoded, but must be populated from the data dictionary. All synonyms must also be defined in the data dictionary, not in many other routines.
2. Don't use datasets. Normalize your data. (Enough said).
3. Don't have hanging conditionals. Will If...then cover all possibilites? No? Then make a Case, catching any errors. ("USD***" is NOT a valid Foreign Currency Code!)
4. If something breaks, break it! The first time an error was encountered (see #3 above), the PO Print program should have stopped and demanded a help desk intervention. But since errors weren't being captured at the point of failure, 3500 Purchase Orders were printed without prices for three weeks before anybody who cared noticed.
5. Learn the app before you change it. I realize that this is easier said than done, but I'd like to think that the contractor should have understood what all the columns in the PO Record that he was changing. He simply trusted the variable "DatasetCols". Do you imagine that a senior developer would have caught that Column 45 was inconsistently documented in the existing code base? I don't know, but it's an interesting question.
6. Parallel test. The Split Line enhancement was big enough to run an automated parallel test. Column 45 of the POs from the test data base would not have matched those from the Control data base. This would have stuck out like a sore thumb if anyone had bothered to check.
7. Regression test. Just because the stuff that should have changed did change as expected, did everything that should not have changed stay the same? (I know, I know, how do we test for "everything else".) There's no easy answer for this, but doing nothing is the worst possible alternative.
What else would you add to my Long Term Solution list?
October 18, 2011
Programmer Classifieds
Brilliant startup with fantastic performance in high growth sector seeks backend engineer. We are enlightened, open to new ideas, think outside the box, and actively support diversity. No Java programmers, please.
September 21, 2011
Betty Weissman (1930 - 2011)
When others said, "You can't", she said, "You can."
When others said, "You can," she said, "You better."
When others said, "You won't," she said, "You will. And I'll help you."
When others said, "You may be able to," she said, "You have to."
When others pushed you down, she picked you up. When others hurt you, she put on the band-aid, and unwrapped the Klondike.
When others said, "We don't have room on our team for you," she said, "That's all right honey. We'll make our own team."
The first time one of us said, "Ma! He's looking at me," she said, "Don't look at him." The next time one of us said, "Ma! He's looking at me," she said, "Go wash the dishes. He won't look so much."
When you played a song on the piano and she recognized it, she said, "Beautiful!" When you played a song on the piano and she didn't recognize it, she said, "For this we need lessons? Go practice some more!"
When others said, "Eat the salad; you'll feel better," she said, "Screw the salad; eat the corned beef."
When others said, "Given the choice, go have fun," she said, "Given the choice, go to work. We'll have fun together later. You're buying."
Whenever you went somewhere, others asked, "How was it?" She asked, "So nu? What'd they serve?"
When others said, "I'll be ready in a minute," she said, "Let's go." When others said, "Let's pray," she said, "Let's eat."
When others put on a schmutie to go to Giant Eagle, she put on her best outfit to go to the mailbox.
When others did things halfway, she did them all the way, and made us do them that way too.
When asked, "What should you do with a problem child?" others said, "You fix them." She said, "You love them."
When others said, "We need a time-out," or "This is a teaching moment," she just looked at you in such a way that you knew that there would never be a worse feeling than disappointing her.
When others picked up the phone and heard your voice, they said, "Hello." When she picked up the phone and heard your voice, she just laughed, as if to say, "No better thing could have just happened."
When others finished a phone call, they said, "Bye." When she finished a phone call, she said, "I love you. I'll talk to you tomorrow."
When others did something, it was "to impress the boys" or "to get the girl" or "to earn some money" or "to win the game". When we did something, it was to make her smile. Until she smiled, everything was a work in progress. After she smiled, nothing else mattered.
When it came her time to say goodbye, she did it just like she did everything else: for her children. She did it slowly, taking years. She may have made it harder for herself, but she made it easier for us, so that we could get used to the idea of her being gone. It sorta worked, but not really.
I will never be able to say goodbye. The only thing I'll ever be able to say is the only thing I've ever wanted to say, "Hey Ma, look at me! I love you. I'll talk to you tomorrow."
April 13, 2011
53. How fast do you work?
Very fast. Let me explain.
April 11, 2011
I Turned my Hacker News Comments into an ebook
Over the years, I've received lots of favorable feedback about my comments on Hacker News. Some have suggested that I blog or even write a book. I always resisted because I thought that more writing would take time away from my software, which I've always considered more important.
Ed Weissman's Blog
- Ed Weissman's profile
- 5 followers
Ed Weissman isn't a Goodreads Author
(yet),
but they
do have a blog,
so here are some recent posts imported from
their feed.
