Well, the Gods of Computing briefly smiled on me, and then got all frowny and stabby....
Google called and wanted to consider me for a position once more. I had to go through another phone interview, and after apparently failing that, got a second chance, which I then failed again.
So the advice I have for folks interviewing with Google is:
Don't implement the naive solution to the problem - that appears to be less-than-acceptable. Discuss the naive solution while you think of a more elegant solution, one that uses a suitable data structure
Monday, November 05, 2012
Monday, October 08, 2012
Missing the point of education
I wonder if the US Business Managers have seen this story about Indian college students outsourcing their senior projects; or as we call it here in the US, cheating. Hell there is even a cottage industry providing these products, and the article mentions that the local costs have spiraled, so people are starting to provide the same products from cheaper areas.
But what I did not see in the article is even a hint of moral outrage or guilt about this - not from the students, not from the project providers, and not from the journalist who wrote the article.
But what I did not see in the article is even a hint of moral outrage or guilt about this - not from the students, not from the project providers, and not from the journalist who wrote the article.
Wednesday, September 12, 2012
Keeping My Chin Up
I realized two things today. First, when I take work-related classes, I get in a weird stressy, bummed out mood; and second, why I get in that mood.
I get that mood because all the neat things I learn in these classes is basically unused. I am trying to keep up with new tech, but The Job doesn't want to use new tech in the areas I work in.
It's kinda like window shopping for food.
I get that mood because all the neat things I learn in these classes is basically unused. I am trying to keep up with new tech, but The Job doesn't want to use new tech in the areas I work in.
It's kinda like window shopping for food.
Friday, August 10, 2012
Paradigm Envy
I read a lot in the past few years about Continuous Deployment, and I finally realized what about it seemed odd - I've spent most of my career working on systems that were not web-based, but installed individually at customer sites. So all those wonderful ideas about rolling out new code on the fly just don't apply to me.
And I really envy those developers who can use it - you avoid all the hassles - customers who never upgrade; customers who want fixes in the new releases backported to their current release; customers who want you to fix the problem, but not change any code, since they have to test for 6 months before deploying code.
Maybe someday I'll get the chance to work on a system that CD will be applicable
And I really envy those developers who can use it - you avoid all the hassles - customers who never upgrade; customers who want fixes in the new releases backported to their current release; customers who want you to fix the problem, but not change any code, since they have to test for 6 months before deploying code.
Maybe someday I'll get the chance to work on a system that CD will be applicable
Thursday, August 09, 2012
Naming Names
In What's In A Name? I addressed a common problem - the naming of functions. I suggested that predicate functions be named so that reading the code aloud is comprehensible.
Today, I realized that there is a corollary that applies to a common type of function, the setter.
Often you have a setter function that has a small set of values, typically a binary flag. There are two common schemes for getting/setting the flag - set(flag,. value) + getFlag(), and setFlag() , clearFlag().
From a code comprehension standpoint, the latter is better. You can read the code and no matter what the value is, know if the flag is set or clear. No more having to search back in the code when you see:
setFlag(someVar);
to see if someVar is True or False. You know immediately at that point how the flag is set.
Now, you will probably need a getter still, since you will likely need to printout the value, at least, but the cognitive easing of this will be good for you, your successors, and your code.
Today, I realized that there is a corollary that applies to a common type of function, the setter.
Often you have a setter function that has a small set of values, typically a binary flag. There are two common schemes for getting/setting the flag - set(flag,. value) + getFlag(), and setFlag() , clearFlag().
From a code comprehension standpoint, the latter is better. You can read the code and no matter what the value is, know if the flag is set or clear. No more having to search back in the code when you see:
setFlag(someVar);
to see if someVar is True or False. You know immediately at that point how the flag is set.
Now, you will probably need a getter still, since you will likely need to printout the value, at least, but the cognitive easing of this will be good for you, your successors, and your code.
Tuesday, July 03, 2012
Bullpen Bullsh*t
I really need to get promoted high enough to get a hard-wall office.
The past few weeks has been one pet peeve after another.
If I had an office with a door, I could at least shut the door and eliminate the worst of the annoyances.
Firstly, a few of my cow-orkers have voices that carry across the cube farm. I really should get an acoustical analysis to see if it could be weaponized. So throughout the day I get to listen to their insurance issues, missed appointments with cable installers, and complaints about other people in the group.
Second is the wonderful world of not using tools we already have. About once a week there is a morning conference call that involves about 10 of the nearby people, along with a number of offsite people. So everyone in the office decides to work through the call, and the Powers-That-Be do not release headsets without paperwork, so everyone on the call is using their speakerphone. As a result, I get the call in 5.1 surround sound, including the echo-delay from the further people being audible directly and via the closer phones.
Third was another case of Musical Chairs Responsibility. There was a customer issue that had been partially described by the Project Manager, and we had no reason to believe that the short description was at all accurate. So when the PM sent another email asking if Engineering had any solutions, I repeated the original case that we had no reason to believe that our area of the system was at fault. Shortly after, my boss's boss assigns the problem to me, since I foolishly spoke up. And what do I find after testing the system? The problem is not in my area, but in the data input area. So if the developers for that area had actually looked at their code, they would have found it.
The past few weeks has been one pet peeve after another.
If I had an office with a door, I could at least shut the door and eliminate the worst of the annoyances.
Firstly, a few of my cow-orkers have voices that carry across the cube farm. I really should get an acoustical analysis to see if it could be weaponized. So throughout the day I get to listen to their insurance issues, missed appointments with cable installers, and complaints about other people in the group.
Second is the wonderful world of not using tools we already have. About once a week there is a morning conference call that involves about 10 of the nearby people, along with a number of offsite people. So everyone in the office decides to work through the call, and the Powers-That-Be do not release headsets without paperwork, so everyone on the call is using their speakerphone. As a result, I get the call in 5.1 surround sound, including the echo-delay from the further people being audible directly and via the closer phones.
Third was another case of Musical Chairs Responsibility. There was a customer issue that had been partially described by the Project Manager, and we had no reason to believe that the short description was at all accurate. So when the PM sent another email asking if Engineering had any solutions, I repeated the original case that we had no reason to believe that our area of the system was at fault. Shortly after, my boss's boss assigns the problem to me, since I foolishly spoke up. And what do I find after testing the system? The problem is not in my area, but in the data input area. So if the developers for that area had actually looked at their code, they would have found it.
Wednesday, May 09, 2012
There's Never Time To Do It Right....
I got bit today by a bit of false economy.
We had a message to a piece of hardware that needed a flag sent, but there was no time to alter the existing protocol to add an explicit flag. So someone, years ago, resorted to a little bit-twiddling in an existing field. However, instead of setting that bit in the field right at the places where it was correct to set, they put the check and set in a function called later.
Fast-forward to now, when I move some code to fix another issue, and this bit setting is now hidden away from the field population, so I have a value that is mangled after I use it, and the bit is not set correctly.
The only reason I can think of for why the original developer did not just put the check and set in the places it was needed is that doing so would alter more files, and someone decided it was better to make a change in one file. In other words, a false economy, one that would have been better to have changes the multiple files and put the change near its use instead of in another function almost wholly unrelated.
So think well before you allow someone to tell you that its better to compromise proper separation of concerns.
We had a message to a piece of hardware that needed a flag sent, but there was no time to alter the existing protocol to add an explicit flag. So someone, years ago, resorted to a little bit-twiddling in an existing field. However, instead of setting that bit in the field right at the places where it was correct to set, they put the check and set in a function called later.
Fast-forward to now, when I move some code to fix another issue, and this bit setting is now hidden away from the field population, so I have a value that is mangled after I use it, and the bit is not set correctly.
The only reason I can think of for why the original developer did not just put the check and set in the places it was needed is that doing so would alter more files, and someone decided it was better to make a change in one file. In other words, a false economy, one that would have been better to have changes the multiple files and put the change near its use instead of in another function almost wholly unrelated.
So think well before you allow someone to tell you that its better to compromise proper separation of concerns.
Subscribe to:
Posts (Atom)