Quick background. We receive data with different timestamps. The easiest way to work with the data is to use SimpleDateFormat and work with Date. Date holds a reference to the date as number of milliseconds since the Epoch (Jan 1 1970).
For some reason our suppliers give us formated dates form different timezones. No problem we just set the dateformatter to use a different timezone when parsing the date string. The API doc states that it "also figures out daylight savings". However it does not state that you must use the long code ("Europe/London") for the timezone and not the 3 letter code ("GMT"). List of short codes. Now we are using the long code we are getting the correct dates with daylight savings taken account of.
Tuesday, May 31, 2011
Monday, May 30, 2011
Even I have a boss
I am a bridge between two worlds. I manage the technology of the company. Everything that is not financial or administrative I am responsible for. However when it comes down to it I have to do what I am told. The good news, it just has to get done. The bad news, they don't understand what needs to happen to get it done, and usually they think that it is always easy and could be done in a matter of minutes. In practice what this means is that some times as a programmer you can do something simple that the non techie people think is amazing and should have been time consuming. Other times the opposite is true.
Either way I'm screwed, if I do something quickly that they think should take a long time, it raises their expectations for the next time. If I have something that the bosses think should be straight forward, then they simply do not understand why it is that its taking so long.
This gets in the way of my work, I have to either spend time explaining the reasons why things take time or not get them done properly. In the past when I have been required to get out a new product or even a big feature I work hard on it to make sure its done and out there working, even if its missing a few things. Then I let smaller tasks take longer as I use the time to add in all the features left out of the bigger project. In the end most things get done, other things fall by the way side, usually by that time they don't matter anyway.
My bosses aren't bad bosses, in fact quite the opposite. They just don't always get it. Looking back on things I wish I had time to build the infrastructure we work on before going live. I have built it as needed and gone live as quickly as possible. Over time new versions and bug fixes have resulted in better software. I am left wondering whether this has worked out better than creating a whole system over a long period, testing, retesting, and then going live. Would it have just taken me longer to make the same mistakes.
As my staff grows and the codebase gets larger, I can implement better development standards. Better testing, better design, better implementation. I have more man hours available to me through my team, I can get things done faster and better at the same time. That means I will spend less time coding and doing other techie things and more time managing the staff and being a bridge from the bosses to the techies. I am their protector. I know how long it will take, I have been there, when the programmers say its going to take 2 weeks, I know it will take 4. But I know that I will put the right pressure on to get it done, and my bosses will be kept at bay knowing that I am competently managing the project. They will bug me, I will be the one disturbed leaving my staff to get on with it without the added pressure. Hopefully resulting in better products at the end.
Either way I'm screwed, if I do something quickly that they think should take a long time, it raises their expectations for the next time. If I have something that the bosses think should be straight forward, then they simply do not understand why it is that its taking so long.
This gets in the way of my work, I have to either spend time explaining the reasons why things take time or not get them done properly. In the past when I have been required to get out a new product or even a big feature I work hard on it to make sure its done and out there working, even if its missing a few things. Then I let smaller tasks take longer as I use the time to add in all the features left out of the bigger project. In the end most things get done, other things fall by the way side, usually by that time they don't matter anyway.
My bosses aren't bad bosses, in fact quite the opposite. They just don't always get it. Looking back on things I wish I had time to build the infrastructure we work on before going live. I have built it as needed and gone live as quickly as possible. Over time new versions and bug fixes have resulted in better software. I am left wondering whether this has worked out better than creating a whole system over a long period, testing, retesting, and then going live. Would it have just taken me longer to make the same mistakes.
As my staff grows and the codebase gets larger, I can implement better development standards. Better testing, better design, better implementation. I have more man hours available to me through my team, I can get things done faster and better at the same time. That means I will spend less time coding and doing other techie things and more time managing the staff and being a bridge from the bosses to the techies. I am their protector. I know how long it will take, I have been there, when the programmers say its going to take 2 weeks, I know it will take 4. But I know that I will put the right pressure on to get it done, and my bosses will be kept at bay knowing that I am competently managing the project. They will bug me, I will be the one disturbed leaving my staff to get on with it without the added pressure. Hopefully resulting in better products at the end.
Wednesday, May 25, 2011
Hiring right
I saw this the other day:
http://www.inc.com/ss/7-unconventional-ways-hire-best-tech-talent#0
While I like the idea, it was truly impractical for my needs. Having said that I do feel that I could have been more thorough in my interviewing process.
Lets start at the beginning. Over the past few years I have been to a few interviews. I have had some tough questions. I have done OK in some and not so great in others. Three companies, two of which I have had multiple interviews, where I have basically been told at the end of it, "we like you but you don't have any experience in Java (or what ever it was at the time that I didn't know)".
I have to say this is particular annoying and a huge waste of both my and their time. If they were looking for a Java programmer why were they interviewing me. I didn't have it on my CV. Ok I have a few interesting things on my CV but at the time Java wasn't one of them. I said during the interview that I didn't know Java right now but I could learn. In fairness most people when they are looking for a Java programmer they are looking for someone with 3 to 5 years experience that can hit the ground running. But again they shouldn't have looked at me. So the conversation continues. "Really you can just pick it up, huh. What evidence can you present us with that would convince me?" Well for my current (at the time) job I learnt Perl Javascript and SQL and became proficient enough at them to run my own two man projects within a month. "Oh thats interesting, what about a real language?" Harsh! Though again I get it, no proof that I have an understanding of OOD, but having said that I believe it is possible to learn the basics in a week reading on the internet. The fact that this guy was so conceited that he thought learning Java was harder than the 3 languages I had to get to grips with prior to this, was a little narrow minded. Aside from reading about Perl in the week running up to the start of that job everything else was done offline. We were on a closed system with no internet in the office. That meant man pages (perldoc to be specific). Javascript and SQL had to be learned from reading pre existing code and talking to others in my office. All done with Emacs, no fancy IDE like Eclipse which does so much for you. So a little context helps when responding to answers.
So I finally landed a job, this job, I didn't know Java but I had a month to read about it before I started. I played around a little and the rest I learned as I went along. Its been two years. And you know what, I rate myself pretty highly. How do I know this. I hired someone. Someone I expected to blow me out the water in terms of coding. You know what, she has 9 years of coding experience, c, c++ and Java. As I understand it 3 years of each. She doesn't know much about Threads or Swing or Sockets. She is proficient at what she does know. But somehow after all her time doing this, I still have a greater breadth of knowledge.
(Additionally I was on track for becoming Rookie of the Year in Java on Experts Exchange but my responsibilities took up too much of my time to actually continue doing all this work for free. I will post more about EE and Stackoverflow later.)
I am the CTO, I need to know everything (not saying that I do, just that I should have a wide range of skills and knowledge). I am confident that my employee will be fine, it will start off slow and she will improve, but there is a lesson. Assuming that someone who has the experience you think is necessary is not necessarily the best indicator of whether they will do well in your company. I believe that had these companies taken a chance on me then they would have been pleasantly surprised by what I could have achieved. They weren't willing to take that chance, and why should they they have I am sure they could have found plenty of other coders out there.
This is the lesson of hiring, you never know what you are going to get. You want some one great, with experience, broad knowledge, in depth understanding and the ability to pick up things they don't already know. You try to test for this. But its still hard to know for sure.
Lets step back again, I have had some interviews where I have been asked to solve some problems, or give examples of code. Generally these have gone badly for me. Personally this is where I crack. Its not the pressure I just don't think well like this. And worst of all I don't end up thinking quickly, which is the worst part, as they not only want to see the correct solution but they want it done quickly. So I decided that I would not ask these types of questions, firstly I don't know how to interpret the results, and secondly if they know how to do this already then it doesn't show me where they are lacking, and if they don't know how to do it then it doesn't show me other areas where they are positive.
Back to my recent hire. I have spent too long going over basic Hex and Binary. This stuff should be second nature to a true CS grad, granted many coders might not be CS grads, but I have a CS grad and I wanted one specifically. The reason: because they should be able to solve problems like this. I am beginning to see the logic in some of these harder interviews and the fact that (big headedly) I may have "slipped through the net", anyone that answers the type of problems I was getting from Google, Bloomberg and Brevin Howard deserves to be there or at least get another interview. It shows a basic level of knowledge/understanding/problemsolving skills.
So for the next interview I will ask the following:
given the a byte array which has the following bits:
sfff ffnn nnnn nnnn nnnn nnnn nnnn nnnn
show me how to extract the one bit sign s, the 5bit denomenator reference f, and the 26 bit numerator n.
the answer would be pseudo code that shows a bit mask for n
a shift and a bit mask for f
and a shift for s.
In fairness to my employee she did solve the big problem that we were having that the byte array we were receiving looked different from the one we were trying to send. The problem was that we were receiving the byte fields as little endian but reading them as big endian.
So now one gets in the door with out understanding these concepts. I am going to keep track of these problems for the future. If any more crop up I will be noting them here and using them for interviewing. I propose a system by which any one incorrect answer will not be the end of the world. A scoring system will be used to decide if the candidate has a satisfactorily broad knowledge and with good problem solving skills.
More on this as time goes on.
http://www.inc.com/ss/7-unconventional-ways-hire-best-tech-talent#0
While I like the idea, it was truly impractical for my needs. Having said that I do feel that I could have been more thorough in my interviewing process.
Lets start at the beginning. Over the past few years I have been to a few interviews. I have had some tough questions. I have done OK in some and not so great in others. Three companies, two of which I have had multiple interviews, where I have basically been told at the end of it, "we like you but you don't have any experience in Java (or what ever it was at the time that I didn't know)".
I have to say this is particular annoying and a huge waste of both my and their time. If they were looking for a Java programmer why were they interviewing me. I didn't have it on my CV. Ok I have a few interesting things on my CV but at the time Java wasn't one of them. I said during the interview that I didn't know Java right now but I could learn. In fairness most people when they are looking for a Java programmer they are looking for someone with 3 to 5 years experience that can hit the ground running. But again they shouldn't have looked at me. So the conversation continues. "Really you can just pick it up, huh. What evidence can you present us with that would convince me?" Well for my current (at the time) job I learnt Perl Javascript and SQL and became proficient enough at them to run my own two man projects within a month. "Oh thats interesting, what about a real language?" Harsh! Though again I get it, no proof that I have an understanding of OOD, but having said that I believe it is possible to learn the basics in a week reading on the internet. The fact that this guy was so conceited that he thought learning Java was harder than the 3 languages I had to get to grips with prior to this, was a little narrow minded. Aside from reading about Perl in the week running up to the start of that job everything else was done offline. We were on a closed system with no internet in the office. That meant man pages (perldoc to be specific). Javascript and SQL had to be learned from reading pre existing code and talking to others in my office. All done with Emacs, no fancy IDE like Eclipse which does so much for you. So a little context helps when responding to answers.
So I finally landed a job, this job, I didn't know Java but I had a month to read about it before I started. I played around a little and the rest I learned as I went along. Its been two years. And you know what, I rate myself pretty highly. How do I know this. I hired someone. Someone I expected to blow me out the water in terms of coding. You know what, she has 9 years of coding experience, c, c++ and Java. As I understand it 3 years of each. She doesn't know much about Threads or Swing or Sockets. She is proficient at what she does know. But somehow after all her time doing this, I still have a greater breadth of knowledge.
(Additionally I was on track for becoming Rookie of the Year in Java on Experts Exchange but my responsibilities took up too much of my time to actually continue doing all this work for free. I will post more about EE and Stackoverflow later.)
I am the CTO, I need to know everything (not saying that I do, just that I should have a wide range of skills and knowledge). I am confident that my employee will be fine, it will start off slow and she will improve, but there is a lesson. Assuming that someone who has the experience you think is necessary is not necessarily the best indicator of whether they will do well in your company. I believe that had these companies taken a chance on me then they would have been pleasantly surprised by what I could have achieved. They weren't willing to take that chance, and why should they they have I am sure they could have found plenty of other coders out there.
This is the lesson of hiring, you never know what you are going to get. You want some one great, with experience, broad knowledge, in depth understanding and the ability to pick up things they don't already know. You try to test for this. But its still hard to know for sure.
Lets step back again, I have had some interviews where I have been asked to solve some problems, or give examples of code. Generally these have gone badly for me. Personally this is where I crack. Its not the pressure I just don't think well like this. And worst of all I don't end up thinking quickly, which is the worst part, as they not only want to see the correct solution but they want it done quickly. So I decided that I would not ask these types of questions, firstly I don't know how to interpret the results, and secondly if they know how to do this already then it doesn't show me where they are lacking, and if they don't know how to do it then it doesn't show me other areas where they are positive.
Back to my recent hire. I have spent too long going over basic Hex and Binary. This stuff should be second nature to a true CS grad, granted many coders might not be CS grads, but I have a CS grad and I wanted one specifically. The reason: because they should be able to solve problems like this. I am beginning to see the logic in some of these harder interviews and the fact that (big headedly) I may have "slipped through the net", anyone that answers the type of problems I was getting from Google, Bloomberg and Brevin Howard deserves to be there or at least get another interview. It shows a basic level of knowledge/understanding/problemsolving skills.
So for the next interview I will ask the following:
given the a byte array which has the following bits:
sfff ffnn nnnn nnnn nnnn nnnn nnnn nnnn
show me how to extract the one bit sign s, the 5bit denomenator reference f, and the 26 bit numerator n.
the answer would be pseudo code that shows a bit mask for n
a shift and a bit mask for f
and a shift for s.
In fairness to my employee she did solve the big problem that we were having that the byte array we were receiving looked different from the one we were trying to send. The problem was that we were receiving the byte fields as little endian but reading them as big endian.
So now one gets in the door with out understanding these concepts. I am going to keep track of these problems for the future. If any more crop up I will be noting them here and using them for interviewing. I propose a system by which any one incorrect answer will not be the end of the world. A scoring system will be used to decide if the candidate has a satisfactorily broad knowledge and with good problem solving skills.
More on this as time goes on.
Subscribe to:
Posts (Atom)