I was reading this article on TheDailyWTF.
http://thedailywtf.com/Articles/Get-to-da-COPPA!.aspx
Like many TheDailyWTF articles, it's a nice humorous story, but I love the last part of the story.
The short story is engineer Derek could not come to a reasonable compromise with engineer Steve on a solution to a problem. After many internal frustrations, Derek bypassed Steve's engineering team entirely, went to the software install team, and changed the install process for the software. The result? Derek implements his solution without ever involving the team that writes the software. The end of the article states, "Steve's team got to keep their constraint, and the customers didn't."
I love that last sentence.
"Steve's team got to keep their constraint, and the customers didn't."
The core engineering team will never see a setup (and will never know the setup for awhile) that the customers will always have. Long term, that can't be good.
While this is an extreme example, it got me thinking. How often do internal managers/staff not come to an agreement or get on the same page? As a consequence, staff begin doing whatever it takes to get the job done, bypassing teams, roles, procedures, etc. I think tiny versions of it happen all the time. Some amount of it we accept b/c we work with a lot of people, but how much of it can be made better?
Friday, September 30, 2011
Friday, September 16, 2011
Albert Pujols the Great
(Following up my post from earlier in the year.)
On May 29th, Albert Pujols saw his line for the year sit at
.257 BA, .326 OBP, .395 SLG, .722 OPS
Epicly awful for a man with a career line of
.330 BA, .424 OBP, .621 SLG, 1.045 OPS
at the time. Now it's September 16th. Albert Pujols just went 4 for 4 against the Phillies. His line for the year is now:
.301 BA, .372 OBP, .549 SLG, .921 OPS
This is simply stunning. After an brutally awful April & May (which likely included a hidden injury) Albert Pujols has performed well enough to get his batting average back up above .300 and have an OPS over .900. It's an incredible year by normal human standards, definitely subpar for Albert Pujols standards, but Albert Pujols' legend continues to grow.
On May 29th, Albert Pujols saw his line for the year sit at
.257 BA, .326 OBP, .395 SLG, .722 OPS
Epicly awful for a man with a career line of
.330 BA, .424 OBP, .621 SLG, 1.045 OPS
at the time. Now it's September 16th. Albert Pujols just went 4 for 4 against the Phillies. His line for the year is now:
.301 BA, .372 OBP, .549 SLG, .921 OPS
This is simply stunning. After an brutally awful April & May (which likely included a hidden injury) Albert Pujols has performed well enough to get his batting average back up above .300 and have an OPS over .900. It's an incredible year by normal human standards, definitely subpar for Albert Pujols standards, but Albert Pujols' legend continues to grow.
Friday, August 19, 2011
In twenty years, will I be the old timer that still programs in C?
I was speaking to someone at a party that told me COBOL programmers make a lot of money nowadays. Somewhat shocked, I asked how this was possible. His answer was simple. There's a ton of COBOL legacy software out there and very few out there who can work on it. Companies are paying up the wazoo to grab those few out there still remaining.
I recently participated in some interviewing events for recent college grads/soon to be college grad
s. It blew me away how few of the candidates had worked in C or C++. In fact, some barely even touched C/C++.
So I started wondering, will I be that rare C programmer in 20 years? I'll be the rare programmer who knows the ancient art of working with pointers?
I recently participated in some interviewing events for recent college grads/soon to be college grad
s. It blew me away how few of the candidates had worked in C or C++. In fact, some barely even touched C/C++.
So I started wondering, will I be that rare C programmer in 20 years? I'll be the rare programmer who knows the ancient art of working with pointers?
Tuesday, July 5, 2011
How It Should Have Ended
Sometime ago I came upon this series of hilarious clips on YouTube. The series is called "How it should have ended". Basically, it's how movies should have ended if the characters in the movies acted like smart human beings. Or if you the viewer stopped suspending disbelief. The following are my favorites:
Saturday, July 2, 2011
Paul Simon and George Harrison
Sometime ago I came upon these performances from Paul Simon and George Harrison on SNL. They're absolutely incredible.
Sunday, May 29, 2011
Puzzle/Brain-Teaser Interview Questions
I came upon an article (here) on Techcrunch about CS recruiting. There's this quote in it:
I remember reading a similar comment/article on theDailyWTF (here).
Although I personally don't like to give these kinds of questions in interviews, I personally do not think the brain-teaser questions are as bad as most people think they are. What they are is bad if executed improperly. I think most interviewers, at Microsoft or otherwise, do not know how to execute the question, the interview and judge the answers from candidates. Some examples:
A) Many interviewers want the right answer from the candidate, and will reject a candidate if they can't solve it. This is the wrong attitude. The question is trying to judge how a candidate thinks through a problem to solve it. Even arriving at the wrong answer is acceptable if the plan of attack was acceptable.
B) The question is also meant to judge your communication ability. Can you talk about how you model the problem, or want to plan to attack the problem, etc. Compared to normal programming questions, you have to speak out of your element.
C) The question also judges your ability to work under pressure and/or show your willingness to not give up. Some candidates may (do?) break down in interviews. Is this the type of employee that will break down in front of a client, partner, or co-workers if presented something difficult or stressful?
D) The brain-teaser/puzzle questions should be given along with other normal technical questions and behavioral questions. It's shouldn't only be brain-teaser/puzzle questions. I interviewed with a company straight out of college that gave me around 10 C programming "puzzle" questions. I probably got 6-7 right, which was enough for them to understand that I really knew C well and got to the next round of interviews. I've known of other people that have been given ONE C puzzle question, and that one question determined if they knew C well enough or not for the job. It's a good example of how not to balance the interview.
Update (12/6/11)
One additional thought. There are also good puzzle/brain-teaser questions and bad ones. Some, such as "Why is a manhole cover round?", are terrible questions. There is little ability to get the candidate to think through the problem and reason it out. A question such as, "How many golfballs can you fit inside a school bus?" isn't that bad.
Like many of the hangovers that haunt modern software engineering, this is ultimately mostly Microsoft’s fault.2 Back when they were the evil empire where everyone secretly wanted to work, they were famous for their “brain-teaser” interview questions – Why are manhole covers round? – and, of course, they asked new university graduates about computer science theory; “Write me a binary search."
I remember reading a similar comment/article on theDailyWTF (here).
Although I personally don't like to give these kinds of questions in interviews, I personally do not think the brain-teaser questions are as bad as most people think they are. What they are is bad if executed improperly. I think most interviewers, at Microsoft or otherwise, do not know how to execute the question, the interview and judge the answers from candidates. Some examples:
A) Many interviewers want the right answer from the candidate, and will reject a candidate if they can't solve it. This is the wrong attitude. The question is trying to judge how a candidate thinks through a problem to solve it. Even arriving at the wrong answer is acceptable if the plan of attack was acceptable.
B) The question is also meant to judge your communication ability. Can you talk about how you model the problem, or want to plan to attack the problem, etc. Compared to normal programming questions, you have to speak out of your element.
C) The question also judges your ability to work under pressure and/or show your willingness to not give up. Some candidates may (do?) break down in interviews. Is this the type of employee that will break down in front of a client, partner, or co-workers if presented something difficult or stressful?
D) The brain-teaser/puzzle questions should be given along with other normal technical questions and behavioral questions. It's shouldn't only be brain-teaser/puzzle questions. I interviewed with a company straight out of college that gave me around 10 C programming "puzzle" questions. I probably got 6-7 right, which was enough for them to understand that I really knew C well and got to the next round of interviews. I've known of other people that have been given ONE C puzzle question, and that one question determined if they knew C well enough or not for the job. It's a good example of how not to balance the interview.
Update (12/6/11)
One additional thought. There are also good puzzle/brain-teaser questions and bad ones. Some, such as "Why is a manhole cover round?", are terrible questions. There is little ability to get the candidate to think through the problem and reason it out. A question such as, "How many golfballs can you fit inside a school bus?" isn't that bad.
Wednesday, May 25, 2011
Definition of Poll
So I was talking with a colleague the other day about my initial confusion over the function ibv_poll_cq() in Infiniband verbs. I initially thought/assumed that the function operated similarly to the poll() syscall and was a tad confused on where/how a timeout could be specified to ibv_poll_cq(). As I worked through things, I later realized the ibv_poll_cq() does not iterate, sleep, or wait for an event to occur. It returns immediately if any events are ready or not. It's similar in action to poll() with a timeout of 0.
My colleague and I then got into a discussion of the definition of "poll". My colleague comes from a bit more of a hardware background and considered "poll" to mean a singular check of a state (such as in a register). I on the other hand, perhaps coming from more of a generic systems background, had always considered "poll" to imply both the check of state and some waiting system with it (may it be via sleep, busy-wait, etc.). I asked my colleague how he would say he wants to check a state multiple times? He said, "That's a poll loop."
Another way to think of it, is suppose I had some generic function like:
poll_for_event()
Would the initial assumption be that this function blocks or does not block?
So I was curious about the definition and how it is used in the broader community. I started with an assumption that the term "poll" in Computer Science comes from "poll" in relation to voting. According to Websters the definition of poll is:
Now, "poll" can be twisted when moved into a different field (such as a "bug"). When I initially thought of the syscall poll(), I was thinking predominantly about how it returns to the user after a specified timeout and returns event statuses. However, perhaps it is not named "poll" for this reason. Perhaps it is named "poll" due to its management of multiple file descriptors. In some respect, poll() gathers the "opinions" of each of the file descriptors and records them. So it sort of matches the classic voting definition of poll above.
But this doesn't help our discussion. Lets go back to the case where we're talking about "polling" a state or status. Wikipedia says:
So does "poll" refer to a singular check or an active sampling? In all liklihood different niches of the technical community eventually came up with their own definitions/meanings. It's one of those funny things that just happens (Perhaps I'll write someday of the confusion I've had with colleagues over magic numbers). I bet it comes down to common programming scenarios and expectations. Lets go back to my imaginary function:
poll_for_event()
In some communities, such as network programmers or GUI programmers, the assumption might be that the function blocks. The reasoning is simple. Under most circumstances, there's not much to do until the function returns (e.g. http request arrives, GUI item is clicked). So a person in this community who says, "poll", you are likely to believe that you wait until an event occurs.
Then perhaps you have people in the kernel community, where you have many other things you would rather be doing if an event isn't ready. So the natural assumption is the function won't block.
My colleague and I then got into a discussion of the definition of "poll". My colleague comes from a bit more of a hardware background and considered "poll" to mean a singular check of a state (such as in a register). I on the other hand, perhaps coming from more of a generic systems background, had always considered "poll" to imply both the check of state and some waiting system with it (may it be via sleep, busy-wait, etc.). I asked my colleague how he would say he wants to check a state multiple times? He said, "That's a poll loop."
Another way to think of it, is suppose I had some generic function like:
poll_for_event()
Would the initial assumption be that this function blocks or does not block?
So I was curious about the definition and how it is used in the broader community. I started with an assumption that the term "poll" in Computer Science comes from "poll" in relation to voting. According to Websters the definition of poll is:
"a sampling or collection of opinions on a subject, taken from either a selected or a random group of persons, as for the purpose of analysis."The question is, can "poll" be applied to a single individual or must it be applied to a group? For example, can you say, "I want to poll a person about this vote?" Naturally, I have no background in linguistics or philology, so I'm just going on a guess here. When speaking of "poll" and voting, I think it is synonymous with gathering the opinions of multiple people and the singular case makes no sense. Otherwise, a "poll" accomplishes nothing towards determing majority vote/opinion. So in my opinion, this might lend the definition of "poll" to include the waiting/loop/whatever instead of a single status check.
Now, "poll" can be twisted when moved into a different field (such as a "bug"). When I initially thought of the syscall poll(), I was thinking predominantly about how it returns to the user after a specified timeout and returns event statuses. However, perhaps it is not named "poll" for this reason. Perhaps it is named "poll" due to its management of multiple file descriptors. In some respect, poll() gathers the "opinions" of each of the file descriptors and records them. So it sort of matches the classic voting definition of poll above.
But this doesn't help our discussion. Lets go back to the case where we're talking about "polling" a state or status. Wikipedia says:
"Polling, or polled operation, in computer science, refers to actively sampling the status of an external device by a client program as a synchronous activity."and
"Polling is sometimes used synonymously with busy-wait polling (busy waiting)."Here, it is implied that "poll" implies active multiple-checking and not a singular check of a status. However, I notice that in the above definitions from Wikipedia it is "polling" and "polled", but not "poll". In fact, as I look around the web, virtually every definition or description of "polling" in reference to this topic is listed as "polling". With rare occasion is this topic discussed using "poll" or "to poll" or "polls" (discounting the situations where it appears people are referencing poll() specifically).
So does "poll" refer to a singular check or an active sampling? In all liklihood different niches of the technical community eventually came up with their own definitions/meanings. It's one of those funny things that just happens (Perhaps I'll write someday of the confusion I've had with colleagues over magic numbers). I bet it comes down to common programming scenarios and expectations. Lets go back to my imaginary function:
poll_for_event()
In some communities, such as network programmers or GUI programmers, the assumption might be that the function blocks. The reasoning is simple. Under most circumstances, there's not much to do until the function returns (e.g. http request arrives, GUI item is clicked). So a person in this community who says, "poll", you are likely to believe that you wait until an event occurs.
Then perhaps you have people in the kernel community, where you have many other things you would rather be doing if an event isn't ready. So the natural assumption is the function won't block.
Subscribe to:
Posts (Atom)