Labs are designed for learning. I learn by doing. While I can read, as they say in the local vernacular in my propinquity “Wicked Fast,” I don’t process read information to the depth that I need in order to retain it. I need to type in the code in order to learn. Here’s a technique I use to do that.Continue reading
I’m a nerdy male of Jewish, Eastern European Descent. I was born in 1971. My parents listened to John Denver, Simon and Garfunkle, Billy Joel, Mac Davis, Anne Murray and Carly Simon. My Uncle Ben started me on Saxophone in second grade.Continue reading
I spent the past six work days in a courthouse as a juror. It was a civil case, involving a house repair after a burst pipe flooded it. Verdict went in at around 3 PM (Aug. 2)
There is so much you don’t know on a jury. You can only consider the evidence placed before you…and sometimes you have to forget something you learned before the witness reacts to the word “Objection.”
It was a construction case, and, despite having grown up as the son (and sometimes employee) of a construction contractor, they chose me anyway. I don’t think it colored my reasoning anyway.
Based on this incomplete information, we had to award money to one or the other; doing nothing was, in effect, awarding money to the client who had not paid.
While I did not agree with the other eleven people on the jury about all of the outcomes (there were several charges both ways) I was very thankful to have all of them share the burden of making the decision. I can only imaging the burden carried by a judge in arbitration.
On the other hand, in arbitration, the judge can do research. We couldn’t. We had to even forget things we know about construction (like you postpone work on the outside to get the people back inside) if it was not presented as evidence.
I was very thankful to have my dad to talk this over with afterwards as he has fifty plus years in the construction industry. He clarified some of my assumptions (based on the incomplete information I gave him) and I think I can let go of my doubts. I can sleep soundly tonight knowing I did the best I could, and that, most likely, justice was served.
The number one thing I took away from this experience is, with anything involving contracting, or money in general, is to get everything in writing, communicate as clearly as possible. Aside from covering you for a future lawsuit, it might help prevent that lawsuit by keeping the other person on track. Run your business such that someone else could step in and take over from you, and know exactly what you were doing…or you can hand over what you want to a brand new contractor and they could take over. Obviously, that is a high bar to clear, but the better you do, the better for all involved.
Jill Jubinski is a well known and respected community leader in OpenStack. When she says something, especially about recruiting, it is worth listening to her, and evaluating what she says. When she tweeted:
While I find the ‘show some code ur proud of’ stance, its like, what if someone doesnt want to code outside of work? That has to be ok too.
my response came off as a contradicting her. It was:
nothing to show would be suspect. If you hate to code, no paycheck would be high enough to make you do it well.
Which goes to show that terseness is a demanding constraint; I did not adequately state what I was trying to state in my attempt to limit it to a single tweet. And of course, that meant it became a discussion back and forth.
Let me try to be a little more nuanced and fair here. What Jill says is spot on: it should be 100% OK for a programmer, and a good one, to not have anything that they are capable of showing prior to an interview. I, myself, would have fallen into that category earlier in my career.
This post has been removed.
I had an interesting exchange last week. We had someone in the chatroom asking for help, morgan was doing his part, and I chimed in and proceeded to get attacked.
Principle #10 â€“ Build A Team
Principle #11 â€“ Employ Your Team In Accordance With Its Capabilities
Principle #7 â€“ Keep Your Team Informed
Communication is the key to any operation. In the Army, they taught that an Infantry Soldier needs to do three things in order to succeed: Shoot, move, and communicate. Well, there should be very little gun fire in open source development, so shooting is less essential. Movement to, since most things happen via network. But communication is paramount. Tell people what you are going to do. A great decision left not communicated is no decision. In the absence of information, people will make assumptions. It is easier to correct mistakes early, and to identify them requires review and correction.
Principle #6 â€“ Know Your Personnel and Look Out for Their Well Being
In an Open Source software project, who are “your people?” Your people are your community. Whether they are a fellow developer from your own company, the guy that pops in once every couple of months to make a typo fix, or someone that just reports bugs, they are all the people that lead to the success (or lack thereof) of your project.