Around 1987 I got a job at at my first start-up (I believe it was my fourth job), at a company called CASI. If I remember correctly, CASI stood for Control Access Systems Incorporated. It was a start-up based in Boca Raton Florida, started by a fellow named Jim Baker who was previously in charge of IBM's internal controlled access systems group. When he heard IBM was planning on dissolving his group and vending out the job, Jim figured he would have a leg up on the competition because of his close ties to the decision makers at IBM, so he quit IBM after twenty years of service and founded CASI. When I started working there they had been in business a little over two years and had a healthy infusion of venture capital and were rapidly expanding. Even so, I had to force myself into the job, and took a big risk to do so.
The Director of Engineering at the time was John Hession. Hess had been an Engineering Manager for IBM at the Boca Raton site, in charge of a group that designed ICs (computer chips) and had been hired away by CASI. John was originally from New York, and we hit it off pretty well at my initial interview. Well, not exactly. I had a reputation in our small engineering community (the Boca Raton area in the 1980s) as a good coder, hard worker and a pain in the ass to work with. What I told John was that I did not want just another coding job, I could stay at Siemens for that. What I wanted was an opportunity to be an Engineering Manager. In my mind, the next logical stop on my way up the food chain. John wasn't too excited about that since he already had an Engineering Manager but he did need coders. In retrospect, John had one open spot available and I was not his first choice. He really wanted a guy named Mark because Mark was a hardware engineer and he was working at a company who made credit card terminals which CASI was planning on using as well. After my initial interview with John I came in about a week later and did my technical interview. I spoke with a fellow named Bill, another ex-IBMer and I spoke with Don (yet another ex-IBMer), the stereotypical gnarly Charlie whos back the company is usually founded on. Everything went well and as I was leaving I asked John when I might start. He said "how about two weeks from Monday" and in my youthful exuberance I shook his hand and promptly quit my job at Siemens and showed up to work "two weeks from Monday". The only problem was that when I showed up for work John was out of town and nobody knew anything about me. After several hours they finally got John on his hotel phone and handed the phone to me. I was feeling pretty squeamish by this time and realized I had not really gotten anything in writing from CASI up until this point so when John said "Hi Ken" I responded "Hi John" and we both enjoyed several moments of awkward silence before John said, "uh, Ken, usually you wait until you get an offer letter in the mail, I hadn't had time to formalize the offer yet as I have been quite busy and out of the town the last several weeks, I don't know what to tell you".
I am not a gifted genius so what came out of my mouth next was instinct, not the result of bravado, or planning. I said, "that's OK John. That's why you hired me right, to help you out in times like this. Don't worry about it - your handshake is good enough for me". Again, several moments of awkward silence (this time perhaps as much as 30 seconds). Finally John says "put Judy (the HR lady) back on the phone". I see her look at me while they are talking and when she hangs up she says, "sit right here, I'll be back in a minute". After like fifteen minutes the owner of the company, Jim Baker a slight bespectacled fellow in his mid to late forties, who always seemed to be walking around with a cup of coffee in his hands, comes out and introduces himself. We go into his office and he must have stared at me for like a solid two minutes without saying a word. When he did speak it was obvious he was perturbed. First, he asks about my time at IBM. How long, what group, who was my first line, second line, etc. He basically told me John had screwed up and that they had sent an offer out to another fellow at the same time John interviewed me. "You mean he still hasn't made up his mind yet", I asked incredulously. "looks like he didn't want the job as badly as I did" was the next thing out of my mouth. Jim Baker gave me a cold hard stare and stated matter-of-factly, "no I guess he didn't", at which point he asks me to wait outside his office.
I showed up ready to work at 7:45am that day. At around 3pm Judy the HR lady comes to get me from outside Jim's office and brings me back to her desk where she hands me the phone. Its John and I'll never forget what he said next (though its how he said it that I really remember); "Ken, (brief uneasy pause), I want to welcome you to CASI. You will be reporting to Bill initially. Judy will give you your paperwork to sign. I'll be back in town Thursday". This was the least reassuring first day on the job I have ever experienced. I purposely make sure my new hires are never treated like this. When they arrive I make sure their user accounts are set up, their hardware is running, their HR paperwork prepared. Hell, it took them three days to get me a computer and a cube at CASI.
When John got back Thursday it was obvious he was none too happy I was there, but he kept it civil and gave me a bunch of assignments which I completed successfully. Eventually he grew to trust me and would take me into his confidence (give me free tickets to the Yankee spring training games, take me to his favorite bar after work and such) and after about 6 months he made good on his promise and gave me my own group and a couple of good projects. Though I was now an Engineering Manager I had no engineers to manage because nobody at the company wanted to work for me so it was decided it would be best if I just hired new employees who had not already had the pleasure of working with me. John makes me hire Mark (the guy they wanted to hire rather than me, turns out the hold up was money) as my hardware engineer and he gives me an intern, a mechanical engineer named Joe, and he lets me hire a software programmer (though at about $20,000 below the going rate - about a 33% discount). I hired a fellow who was recommended to me from a friend at Ungermann Bass, named Adrian, who worked out well and eventually replaced me as the Engineering Manager, ultimately becoming the Director of Engineering after a company called Rusco bought CASI.
Now I have always been a bit of a hack in everything I do. I play golf, tennis, guitar and I have never taken a lesson. I enjoy playing but not practicing. Its my personality. When it comes to programming, I am what I like to think of as a special ops coder. Kind of like the US Marines. They will take any hill you order them too, just don't be too concerned about the collateral damage. My code can be a bit messy. It can be a bit unstructured and difficult to maintain. I acknowledge that, though usually its a result of the compressed time given to me on most of my projects. I usually get the difficult project, the shit work, and I have made a career out bringing them in on time. So when somebody complains that my code is ugly I don't take it too harshly, especially if I was given the impossible and a week to do it. So when it came time to manage my first project I was adamant we would do it right. As is so often the case when this type of decision is made, we quickly fell behind schedule.
Though John was technically my bosses boss, his hit and run micromanagement style effectively made him everyone's boss and so as soon as he hears my group has missed the first deadline we were given he summons me to his office. "What's the problem Ken" he demands. "I give you three resources and the best you can do is 0 for 1?". So I try to explain to John that we took longer in the design phase because we wanted to come up with a more elegant solution to the problem since we anticipated having to reuse the code extensively in the future. "Let me tell you something" John explains, "I have been in this business for over twenty years and one thing I can tell you is that elegance sucks". "I want that code delivered and debugged and working by the morning for this device for this environment and I don't give a shit if it works for anything else or anywhere else". Such is the way quality decisions were made back in the dark ages. After over thirty years in the business its not clear to me that things have changed much.
Showing posts with label software. Show all posts
Showing posts with label software. Show all posts
Monday, December 5, 2011
Wednesday, December 17, 2008
My Anti-Outsourcing Rant
I have outsourced before and let me tell you; it is not any cheaper in the long run. When an employee is within walking distance the message can be delivered quickly and succinctly, however, when you manage a group of remote engineers you must spend a significantly longer amount of time in the specification phase.
Most projects have a pre-ordained life-cyle. You can pull in any phase you want, but you will end up paying more elsewhere. For example say a class of project typically takes 12 months to complete (and we'll assume we have arrived at this number empirically). You might spend 3 months documenting requirements, 3 months designing the solution, 3 months implementing the solution and 3 months debugging the solution. If you want to pull in the implementation from say 3 months to 1 month, that's fine, but my experience shows you will just end up adding 2 months to the debug/QA cycle for a net delta of zero. The same goes for pulling in design (you'll pay more in implementation/debug, or if you want to pull in specification requirements you'll pay more downstream), etc. Most projects tend to fall into basic categories and various categories of product just seem to have a standard duration, like it or not, and so outsourcing just tends to require more time to be spent during the requirements specification and design phases.
There is an old saying (I think it comes from Brooks in the Mythical Man Month) that you can put 9 women in a room but you won't get a baby in a month. It will still take 9 months because that's typically what that project category requires. In the case of dumping more and more resource on a project there is resource communication and interface overhead which adversely affects productivity, otherwise any project could be done in one day (or more absurdly, one minute) given enough resource, but as we all know via common sense, it just doesn't work that way.
Anyway, I have attempted to manage remote engineering organizations unsuccessfully in the past so this is my little rant on outsourcing, from an attempted non-polemic perspective.
Most projects have a pre-ordained life-cyle. You can pull in any phase you want, but you will end up paying more elsewhere. For example say a class of project typically takes 12 months to complete (and we'll assume we have arrived at this number empirically). You might spend 3 months documenting requirements, 3 months designing the solution, 3 months implementing the solution and 3 months debugging the solution. If you want to pull in the implementation from say 3 months to 1 month, that's fine, but my experience shows you will just end up adding 2 months to the debug/QA cycle for a net delta of zero. The same goes for pulling in design (you'll pay more in implementation/debug, or if you want to pull in specification requirements you'll pay more downstream), etc. Most projects tend to fall into basic categories and various categories of product just seem to have a standard duration, like it or not, and so outsourcing just tends to require more time to be spent during the requirements specification and design phases.
There is an old saying (I think it comes from Brooks in the Mythical Man Month) that you can put 9 women in a room but you won't get a baby in a month. It will still take 9 months because that's typically what that project category requires. In the case of dumping more and more resource on a project there is resource communication and interface overhead which adversely affects productivity, otherwise any project could be done in one day (or more absurdly, one minute) given enough resource, but as we all know via common sense, it just doesn't work that way.
Anyway, I have attempted to manage remote engineering organizations unsuccessfully in the past so this is my little rant on outsourcing, from an attempted non-polemic perspective.
Tuesday, December 9, 2008
Rambling on Multi-Lingual Programming
Having been in the software development business for nearly 30 years I have been exposed to many different languages. I will attempt enumerate them here but I am sure I will leave out a few.
(1) Assembly Language
(2) C
(3) Fortran
(4) Pascal
(5) COBOL
(6) EDL
(7) C++
(8) Java
(9) Perl
(10) Python
(11) Lisp
(12) Javascript
(13) Ruby
Over the past 5-10 years, however, I have only worked with C, C++, Java, Perl, Python and Javascript (I have played with Ruby). What amazes me is how I continually learn new things which are not necessarily new, just new to me. I am sure if I paid more attention in my various college classes I would not be surprised so frequently, but it is hard to learn something if you are only given a few weeks or months to learn. It is also the case that real projects tend to increase comprehension more than educational exercises.
Today I discovered the concept of a coroutine. It is not so surprising to me that I did not know about this as much as that I discovered the original work done on this concept came out in 1963. The same may be said of closures which are still a relatively new concept to me though it should not be as I have programmed in Lisp before and was well aware of work done by Alonzo Church back in the 1930s.
Peterson's algorithm (which many software based mutex implementations are based on) is also a relatively new concept as I first heard of it in 1999 (remember I have been writing code since 1979) but really had no use for it until multi-processor machines became more accessible. In the old days a simple 'test and set' operation would suffice.
What concerns me most though is the fact that if a programmer is versed in a variety of languages it becomes difficult to often remember the exact syntax of a specific language which is why when I interview a candidate for a job I tend to focus more on the problem solving skills and general knowledge rather than the language specifics. I hate interviews where they ask odd questions like how many bytes does an empty C++ class occupy or what will x+++++++++; evaluate to (my answer is it evaluates to the guy who wrote it getting fired).
Isn't it more important an individual knows what a mutex is and what it might be used for rather than what **x++++++; might evaluate to? Isn't it more important an individual knows what the concept of an associative array is rather than the specific syntax like %$x? To me, a coder who knows its a hash in Perl, a dictionary in python, a map in Java gets it regardless of language.
In the end most languages support most concepts, some better than others. I think if a coder knows (or claims to know) about 3-4 different languages it is more productive to ask about the relative strengths and weaknesses of each rather than syntactically oriented questions. I also love trick questions. One of my favorites is to ask a Java coder how Java supports closures, and more recently to ask a C coder how C supports coroutines.
(1) Assembly Language
(2) C
(3) Fortran
(4) Pascal
(5) COBOL
(6) EDL
(7) C++
(8) Java
(9) Perl
(10) Python
(11) Lisp
(12) Javascript
(13) Ruby
Over the past 5-10 years, however, I have only worked with C, C++, Java, Perl, Python and Javascript (I have played with Ruby). What amazes me is how I continually learn new things which are not necessarily new, just new to me. I am sure if I paid more attention in my various college classes I would not be surprised so frequently, but it is hard to learn something if you are only given a few weeks or months to learn. It is also the case that real projects tend to increase comprehension more than educational exercises.
Today I discovered the concept of a coroutine. It is not so surprising to me that I did not know about this as much as that I discovered the original work done on this concept came out in 1963. The same may be said of closures which are still a relatively new concept to me though it should not be as I have programmed in Lisp before and was well aware of work done by Alonzo Church back in the 1930s.
Peterson's algorithm (which many software based mutex implementations are based on) is also a relatively new concept as I first heard of it in 1999 (remember I have been writing code since 1979) but really had no use for it until multi-processor machines became more accessible. In the old days a simple 'test and set' operation would suffice.
What concerns me most though is the fact that if a programmer is versed in a variety of languages it becomes difficult to often remember the exact syntax of a specific language which is why when I interview a candidate for a job I tend to focus more on the problem solving skills and general knowledge rather than the language specifics. I hate interviews where they ask odd questions like how many bytes does an empty C++ class occupy or what will x+++++++++; evaluate to (my answer is it evaluates to the guy who wrote it getting fired).
Isn't it more important an individual knows what a mutex is and what it might be used for rather than what **x++++++; might evaluate to? Isn't it more important an individual knows what the concept of an associative array is rather than the specific syntax like %$x? To me, a coder who knows its a hash in Perl, a dictionary in python, a map in Java gets it regardless of language.
In the end most languages support most concepts, some better than others. I think if a coder knows (or claims to know) about 3-4 different languages it is more productive to ask about the relative strengths and weaknesses of each rather than syntactically oriented questions. I also love trick questions. One of my favorites is to ask a Java coder how Java supports closures, and more recently to ask a C coder how C supports coroutines.
Wednesday, November 19, 2008
The Interview Process
What never ceases to amaze me is how many young engineers don't realize that a job interview is a bi-directional process. While it is true that the man with the gold makes the rules and you are attempting to convince the man to throw some of the gold your way, it is equally true that (assuming you are a good engineer who takes his role seriously) you are getting ready to contribute something more valuable than gold; namely your time. In fact in many cases you are bargaining more than half of your waking life for some of the gold and given that time is more valuable than money, the prospective employee is often dealing from the incorrect position.
It is often the case that companies during the interview process look for such intangibles as culture fit, aptitude, character references, credit scores, biological tests and a background check. It can be a long and difficult process which is OK, but in many cases it is a uni-directional process which is not OK. The prospective employee at every step during the interview process should be asking such questions as 'do I want to work here', 'how good is this company', 'does this company share my core values', 'has this company been a good corporate citizen', 'is this employee I have been subjected to someone I would enjoy working with', etc. It is also fair to request the same information from a company they have requested of you.
If a company requests a credit score from you, it should be fair to request a financial statement from the company. If a company requests a list of three references from you it should be fair of you to ask for a list (and associated contact information) of three former employees from the company, after all, if the company can't provide three former employees who have positive things to say about the company or if all former employees are happy to be former employees that says something.
Whenever I interview with a company for a position which is a replacement position (IE I am replacing someone who left as opposed to a newly created position) and they ask me why I left my previous job, after I answer their question I usually ask why the individual who I am replacing left. In a lot of cases the company will want to know why I have changed jobs so frequently (the average life expectancy of a software engineer by the way is somewhere around 18 months) and after I describe why I left various positions they are interested in, I typically request of them the average stay of an engineer while in their employ. Though the interviewer is usually surprised by this sort of thing, I am sure they are no less surprised than I am when they ask me for such strange things as a background check or a credit score; after all, what could my credit score possibly have to do with my job performance, but the average term of their former employees is relevant for me to deduce what my anticipated employment term would be with them.
Anyway, my point is that the interview process is a bi-directional process, look before you leap, ask the same of a company that it asks of you and don't give away the farm because your life is more valuable than money and in many cases it is piece of your life you are exchanging for gold.
It is often the case that companies during the interview process look for such intangibles as culture fit, aptitude, character references, credit scores, biological tests and a background check. It can be a long and difficult process which is OK, but in many cases it is a uni-directional process which is not OK. The prospective employee at every step during the interview process should be asking such questions as 'do I want to work here', 'how good is this company', 'does this company share my core values', 'has this company been a good corporate citizen', 'is this employee I have been subjected to someone I would enjoy working with', etc. It is also fair to request the same information from a company they have requested of you.
If a company requests a credit score from you, it should be fair to request a financial statement from the company. If a company requests a list of three references from you it should be fair of you to ask for a list (and associated contact information) of three former employees from the company, after all, if the company can't provide three former employees who have positive things to say about the company or if all former employees are happy to be former employees that says something.
Whenever I interview with a company for a position which is a replacement position (IE I am replacing someone who left as opposed to a newly created position) and they ask me why I left my previous job, after I answer their question I usually ask why the individual who I am replacing left. In a lot of cases the company will want to know why I have changed jobs so frequently (the average life expectancy of a software engineer by the way is somewhere around 18 months) and after I describe why I left various positions they are interested in, I typically request of them the average stay of an engineer while in their employ. Though the interviewer is usually surprised by this sort of thing, I am sure they are no less surprised than I am when they ask me for such strange things as a background check or a credit score; after all, what could my credit score possibly have to do with my job performance, but the average term of their former employees is relevant for me to deduce what my anticipated employment term would be with them.
Anyway, my point is that the interview process is a bi-directional process, look before you leap, ask the same of a company that it asks of you and don't give away the farm because your life is more valuable than money and in many cases it is piece of your life you are exchanging for gold.
Subscribe to:
Posts (Atom)
