![\"quilt\"](\"https:\/\/www.zackgrossbart.com\/blog\/wp-content\/uploads\/2010\/02\/quilt1.jpg\" "\\"quilt\\"")
<\/p>\n<\/p>\n
The editorial calendar project has gone on for a couple of weeks now. We’ve had meetings and made sure everyone is on the same page, but now it’s time to get real. We’re ready for the first patch.<\/p>\n
Computer programs are made up of a very large number of very small pieces. The business of writing computer software is figuring out how to organize and manage all of those little pieces. When a developer says, “it worked on my machine,” they’re probably right, but that doesn’t mean it’s ready for anyone else.<\/p>\n
So far my wife and I have have written all the code. Not it’s time Bob to make the first code contribution and submit it as a patch<\/a>. This is a little scary because up till now I’ve never seen his code. I know he’s a chef, but I haven’t tasted his cooking. This first taste makes a large impression.<\/p>\n Bob’s first patch is more an appetizer than a three course dinner. He’d worked on one of the small pieces I’d suggested as a good way for new programmers to get started with the project. When the patch came in it had some good signs and some bad. <\/p>\n He did it quickly<\/b>. The tasks were all easy and small so a quick response was perfect.<\/p>\n He made a real patch<\/b>. Unix defines a diff and patch<\/a> process for submitting code and he used it well.<\/p>\n He wrote a very short email<\/b>. The first patch is crucial and you expect even more documentation than usual. His email was terse to say the least. <\/p>\n Bob didn’t test it<\/b>. Developers call this throwing shit over the wall. <\/p>\n Let’s remember that nobody on the team has met Bob face-to-face. We don’t really know what to expect from him, first impressions matter and this is a good time for Bob to <\/a> make it easy for us to give him an A<\/a>. In this case the easy A is showing us his work and making sure it works. <\/p>\n Someone submitting a bad patch on a typical open source project would receive a small rebuke and be given a second chance. Maybe even two or three second chances. But this wasn’t a typical project. <\/p>\n Bob was getting paid by Justin and Colin. That makes this a human problem. They were using this project to test him out. I called Colin and explained the problem to him. He called Bob. Colin put it well, “no bad news over email.”<\/p>\n This is the trickiest part of the relationship. We can’t ignore Bob’s bad patch, but we can’t villify him for it either. In person we’d have a talk, but remotely the system can break down with bad actors. It’s too easy to ignore problems. <\/p>\n So was Bob a bad guy, just a little careless, or the victim or a misunderstanding? We didn’t know. Bob gets a second chance. If the next patch is good we’ll forget the first one. If it’s bad we have a real problem. We’ll just wait and see.<\/p>\n The picture in this article was created by californiaAmy<\/a> and is used in accordance with the Creative Commons license<\/a><\/p>\n http:\/\/credit-n.ru\/electronica.html<\/a> http:\/\/credit-n.ru\/offers-zaim\/moneza-online-zaym.html<\/a> Good signs<\/h2>\n
Bad signs<\/h2>\n
Human problems are complex problems<\/h2>\n