tag:blogger.com,1999:blog-25922407.post5546585298377328379..comments2024-03-17T01:25:27.910-07:00Comments on Gerald Weinberg's Secrets of Writing and Consulting: How We Used to Do Unit TestingGerald M. Weinberghttp://www.blogger.com/profile/05902673055244863609noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-25922407.post-88542475889805712882009-02-04T23:06:00.000-08:002009-02-04T23:06:00.000-08:00"I hate to be embarrassed, look stupid, whatever. ...<I>"I hate to be embarrassed, look stupid, whatever. It killed me (still does) when someone finds a mistake in my work."</I><BR/><BR/>I know that feeling myself, but gave it up when I managed to truly internalize Carol Dweck's research on mindset. These days, any thinking I do about my programming process starts with the premise that I make mistakes, I always did, and I always will. Really dumb mistakes.<BR/><BR/>I have somewhere a highlighted quote from Stroustrup about assertions, something along the lines that, of course you would use them only sparingly, not use them on trivial things like checking for NULL pointers. I used to think that way, until I realized the darnedest thing: NULL pointer errors still crop up in my code. So now, I don't try to pretend I don't make mistakes, and you'll find assert(ptr != NULL) is not an uncommon occurrence in my code.<BR/><BR/>I assume Stroustrup just doesn't get NULL pointer errors in his code. And now, neither do I! I get assertion errors instead, which usually help me quickly locate the bug (and more importantly, help me convince myself my code is correct when I read it).<BR/><BR/>In the words of philosopher Andy Clark, my brain seems to be <B>bad at logic, good at Frisbee</B>, so instead of imagining that such a talented fellow as myself should not be making simple errors, I try to push my intelligence outside of my skull, into the outside world, with practices such as "excessive" assertions so I can (stealing from Clark's words again) <B>make the world smart so I can be dumb in peace.</B>Ron Burkhttps://www.blogger.com/profile/01502981410880210349noreply@blogger.comtag:blogger.com,1999:blog-25922407.post-52531044480142609082008-12-26T10:31:00.000-08:002008-12-26T10:31:00.000-08:00Seeker wrote: "What's your thoughts? Is relation b...Seeker wrote: "What's your thoughts? Is relation between tech leads/dev managers and their execs similar to relation of developers to tech leads or not?"<BR/><BR/>They are certainly similar in the dangers of micromanaging. A manager should be first concerned about WHAT employees are doing, NOT HOW they are doing it.<BR/><BR/>The only time the manager should become concerned with HOW is when and employee's WHAT is not up to a desired level. At that point, the manager's job is to see that the underperforming employee (or team) gets what they need to come up to snuff.<BR/><BR/>What they need might be resources, training, or motivation. What they seldom need is the manager stepping in and micromanaging the task. That generally makes things worse, at any level.<BR/><BR/>BTW, if the lower-level employee is always running to his/her manager for approval of ever aspect of their job, then there's another problem.Gerald M. Weinberghttps://www.blogger.com/profile/05902673055244863609noreply@blogger.comtag:blogger.com,1999:blog-25922407.post-69353777986572216512008-12-26T03:30:00.000-08:002008-12-26T03:30:00.000-08:00Hi Jerry and Searcher,what about that question con...Hi Jerry and Searcher,<BR/>what about that question considered on the lower level, a developer wants to do unit testing as his own initiative, should he "sell" it to his supervisor/tech lead when he expects resistance (like 'we don't have time')? doing tests he're going to increase time of performing single tasks but finally increase quality (and save bug fixing time).<BR/>I think it may be reasonable to follow your opinion also on that level. That's developer responsibility to do a good job so he does not need to sell it, just do it.<BR/>What's your thoughts? Is relation between tech leads/dev managers and their execs similar to ralation of developers to tech leads or not?Seekerhttps://www.blogger.com/profile/18372024881281158191noreply@blogger.comtag:blogger.com,1999:blog-25922407.post-36750043245687206992008-12-24T12:38:00.000-08:002008-12-24T12:38:00.000-08:00Searcher wrote:"Jerry, what's your advice on how t...Searcher wrote:<BR/>"Jerry, what's your advice on how to sell quality more effectively? How do I show quick results to executives once new culture is sold."<BR/><BR/>Great question, though sometimes exactly the wrong question. In the case of unit testing, for example, I would avoid trying to sell executives until you have some real experience to show for it. If you look at the principles, yoiu'll notice that there's no real reason to involve execs in any of it. They simply don't have to know that you're doing unit testing differently, or doing it at all.<BR/><BR/>Do it first, document results, THEN if you wish, go to execs and show them the improvements in their terms, like fewer bugs going forward and shorter, more reliable delivery time.<BR/><BR/>And, as with all improvements, start the exec involment by asking them what they would consider improvements, then framing your presentations in those terms. For instance, if they don't care about bug counts, leave them out, but translate them into $$ saved or earned.Gerald M. Weinberghttps://www.blogger.com/profile/05902673055244863609noreply@blogger.comtag:blogger.com,1999:blog-25922407.post-51837396943715635502008-12-24T06:34:00.000-08:002008-12-24T06:34:00.000-08:00I believe it is fair to write that I came a genera...I believe it is fair to write that I came a generation after Jerry Weinberg. Still, I always tested my code units as best I could before giving them to someone or something else. <BR/><BR/>I think for me, it is because I hate to be embarrassed, look stupid, whatever. It killed me (still does) when someone finds a mistake in my work.<BR/><BR/>I guess this is some sort of insecurity that drives me to do good all the time. That insecurity can be destructive in many instances, but perhaps it is good in writing and testing code.Unknownhttps://www.blogger.com/profile/02305697664289102933noreply@blogger.comtag:blogger.com,1999:blog-25922407.post-88260683869111717592008-12-24T03:45:00.000-08:002008-12-24T03:45:00.000-08:00My favorite is "Test Before Code, or perhaps Test ...My favorite is "Test Before Code, or perhaps Test Before Design."<BR/>I preach it with my customers but often it is hard to sell since what you sell is culture change.<BR/>Not only it is hard to change culture, it is also hard to show quick results. That is why many executives do not buy into such apporach.<BR/><BR/>Both software vendors and customers like to sell/buy tools/products.... selling/buying services is harder i think....<BR/><BR/>Jerry, what's your advice on how to sell quality more effectively? How do I show quick results to executives once new culture is sold.<BR/>Thankssearcherhttps://www.blogger.com/profile/05126031171905500747noreply@blogger.comtag:blogger.com,1999:blog-25922407.post-7646302770702556612008-12-24T02:47:00.000-08:002008-12-24T02:47:00.000-08:00Beautiful prose and insight.A rose by any other na...Beautiful prose and insight.<BR/><BR/>A rose by any other name, still stinks just as sweet.<BR/><BR/>At the end of the day, it always circles back to why do you do what you do.J.D. Meierhttps://www.blogger.com/profile/02678290889994566788noreply@blogger.com