So in addition to the usual chaos this time of year, The Job decided to throw a curve.
Apparently, someone managed to completely ignore a feature that had been discussed several months ago, and suddenly realized that it was very close to the deadline. So instead of owning up and saying "Well, we need to postpone the drop to get his feature in", they asked me to crank out a solution. Then they nattered away 4 days of a 10 day deadline on side issues. And then I find that the interface I was to use is already implemented elsewhere, and this should have been noticed during the initial discussion!
And the owner of that subsystem is "too busy", so I get tapped to redo all my work in the new processes, in 3 days, instead of 10.
*And* all this is after getting a sub-par review.....
You can bet this is being noted for future reference in next year's review.
Tuesday, November 06, 2012
Monday, November 05, 2012
When Google Calls
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, 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.
Saturday, April 14, 2012
Do Have A Cow, Man!
It looks like I've got another "old fart" programmer rant here. Josh On Design has an open letter to language designers in which he urges them to kill a few of what he feels are sacred cows of programming language design.
Some of his points are ones that I can't disagree with (type systems, garbage collection, extending the syntax), but his points 1, 2 and 4 stick in my craw
Cow #1 is "stop storing source code as ASCII files on disk".
Cow #2 is "use an IDE that is more than a text editor"
Cow #4 is "stop using whitespace or indention or braces styles"
For #1 he suggests storing code in XML/JSON or a database, and storing the code structure, along with any metadata, and non-text resources together. This is not a bad idea, but it seems to gloss over one detail - a programmer will need to read the code to understand it, so it will end up being displayed as text in the end, even assuming it's not XML. His point is that once the structure of the code is set, having a compiler/interpreter extract that structure every time is wasteful. It is, but it gives the programmer great flexibility. The only thing like what he suggests that I can imagine is something like the visual programming languages that represent the constructs as icons with slots for the details, like a loop is an arrowed circle with the start, end, and increment values inside the circle. But what if you need to change from a loop to a recursive call? You would need to somehow remove the loop icon and replace it with another icon (drag&drop? emacs-like ctrl-meta-bucky keys?) and fill in the recursion endpoint and recursive calls. And you'd have to find a set of symbols that would be clear to all programmers, which is not an easy task. The great benefit of written languages is that they can carry a lot of meaning in a compact form.
For #2, he promotes requiring an IDE, since the source code would not be in a pure text format. IDEs are great tools - I was reminded of this recent;y in a class where Eclipse was being used, and the auto-import feature for Java code was really useful. But if the code requires an IDE to even look at it, you are adding complications - the language structure is now tied to the IDE understanding it, or you get incorrect rendering. Then you must wait for the IDE developers to update their code before you can safely work on your code. This seems a bad idea, especially if the IDEs are commercial tools, where corporate interests will have undue influence on the process. I was distressed to hear, years ago, that a C++ feature was misimplemented in the official version because one of the corporate members of the standards committee did not want to be forced to fix their broken extension of C++, and ramrodded their version into the language. Now imagine something similar, but where a good feature is rejected because a corporate member doesn't want to update their toolset!
Point #4 is superficially on target. Arguments over brace style and how many spaces a tab should be are probably the least useful, and most heated, disagreements in software. However, they are underlaid with a critical point - we need to understand the code to work on it, and different people find different layouts more suited to their mental models. But the point is a bit of a strawman - there are already tools to adjust the layout to suit - store the code in one format, and have the repository filter it to your favorite style on checkout so you see it in the style you prefer.
Basically, the point of source code is to provide the programmer with an easy-to-understand format. We have lots of computing power now, so why not use that to deduce the details, instead of making the human do the drudgework - compilation/interpretation can be done from the text much faster then understanding the code intent from a complex layout.
Now, it is still a good idea to perhaps save an intermediate step in a non-human-readable form, like Java class files or Python .pyc files, and there is always room for better ways to organize the source code of a project and its libraries, but assuming that one-size-fits-all is almost certainly going to fail.
Some of his points are ones that I can't disagree with (type systems, garbage collection, extending the syntax), but his points 1, 2 and 4 stick in my craw
Cow #1 is "stop storing source code as ASCII files on disk".
Cow #2 is "use an IDE that is more than a text editor"
Cow #4 is "stop using whitespace or indention or braces styles"
For #1 he suggests storing code in XML/JSON or a database, and storing the code structure, along with any metadata, and non-text resources together. This is not a bad idea, but it seems to gloss over one detail - a programmer will need to read the code to understand it, so it will end up being displayed as text in the end, even assuming it's not XML. His point is that once the structure of the code is set, having a compiler/interpreter extract that structure every time is wasteful. It is, but it gives the programmer great flexibility. The only thing like what he suggests that I can imagine is something like the visual programming languages that represent the constructs as icons with slots for the details, like a loop is an arrowed circle with the start, end, and increment values inside the circle. But what if you need to change from a loop to a recursive call? You would need to somehow remove the loop icon and replace it with another icon (drag&drop? emacs-like ctrl-meta-bucky keys?) and fill in the recursion endpoint and recursive calls. And you'd have to find a set of symbols that would be clear to all programmers, which is not an easy task. The great benefit of written languages is that they can carry a lot of meaning in a compact form.
For #2, he promotes requiring an IDE, since the source code would not be in a pure text format. IDEs are great tools - I was reminded of this recent;y in a class where Eclipse was being used, and the auto-import feature for Java code was really useful. But if the code requires an IDE to even look at it, you are adding complications - the language structure is now tied to the IDE understanding it, or you get incorrect rendering. Then you must wait for the IDE developers to update their code before you can safely work on your code. This seems a bad idea, especially if the IDEs are commercial tools, where corporate interests will have undue influence on the process. I was distressed to hear, years ago, that a C++ feature was misimplemented in the official version because one of the corporate members of the standards committee did not want to be forced to fix their broken extension of C++, and ramrodded their version into the language. Now imagine something similar, but where a good feature is rejected because a corporate member doesn't want to update their toolset!
Point #4 is superficially on target. Arguments over brace style and how many spaces a tab should be are probably the least useful, and most heated, disagreements in software. However, they are underlaid with a critical point - we need to understand the code to work on it, and different people find different layouts more suited to their mental models. But the point is a bit of a strawman - there are already tools to adjust the layout to suit - store the code in one format, and have the repository filter it to your favorite style on checkout so you see it in the style you prefer.
Basically, the point of source code is to provide the programmer with an easy-to-understand format. We have lots of computing power now, so why not use that to deduce the details, instead of making the human do the drudgework - compilation/interpretation can be done from the text much faster then understanding the code intent from a complex layout.
Now, it is still a good idea to perhaps save an intermediate step in a non-human-readable form, like Java class files or Python .pyc files, and there is always room for better ways to organize the source code of a project and its libraries, but assuming that one-size-fits-all is almost certainly going to fail.
Friday, April 13, 2012
The Circle Of Life
One of the funnier things about this profession is how so many things are cyclical. Language mavens are fond of saying that every programming language eventually turns into a poor copy of Lisp, and every 10 years or so there is another format for encoding data so that the machines will have some ideas of how to process it (ASN.1 was XML before XML was born)
So I was tickled to read about Taco Bell Programming, where Ted Dziuba describes how to do web crawling and MapReduce with UNIX utilities. It rang true, especially given the current situation at The Job, where new tech is being enthroned. Then I found Mike The Coder's post about his reaction and Ted's response, which was even better. I find new things about the OS every time I look, and there are great ways to do most tasks already in place. But every generation needs to invent its own set of tools before it learns that much of what they want is already there,
It's almost like the end of The Wizard of Oz, where Glinda tells Dorothy that she would not have believed that the ruby slippers would take her home before she experienced the magic in Oz.
Heck, given the number of flying monkey's I've worked with, that's more apt that I care to think about.....
So I was tickled to read about Taco Bell Programming, where Ted Dziuba describes how to do web crawling and MapReduce with UNIX utilities. It rang true, especially given the current situation at The Job, where new tech is being enthroned. Then I found Mike The Coder's post about his reaction and Ted's response, which was even better. I find new things about the OS every time I look, and there are great ways to do most tasks already in place. But every generation needs to invent its own set of tools before it learns that much of what they want is already there,
It's almost like the end of The Wizard of Oz, where Glinda tells Dorothy that she would not have believed that the ruby slippers would take her home before she experienced the magic in Oz.
Heck, given the number of flying monkey's I've worked with, that's more apt that I care to think about.....
Thursday, April 12, 2012
Why We Code (again)
(As opposed to Why We Fight)
I've always felt that there was a unique property of writing code that was not found in other professions - getting in the Zone, seeing the data in your mind, making a machine do your bidding. It's something that I always like when I get the chance to write new code (a rare occurrence these days). Debugging provides the thrill of the hunt, as an alternative to pure creation, for variety.
So I was greatly pleased to find someone else who considers himself Lucky to be a Programmer
Gustavo covers much of the same ideas that I have felt, and I'm heartened that an apparently younger programmer (or at least newer programmer) is still finding the same joys in the work.
I've always felt that there was a unique property of writing code that was not found in other professions - getting in the Zone, seeing the data in your mind, making a machine do your bidding. It's something that I always like when I get the chance to write new code (a rare occurrence these days). Debugging provides the thrill of the hunt, as an alternative to pure creation, for variety.
So I was greatly pleased to find someone else who considers himself Lucky to be a Programmer
Gustavo covers much of the same ideas that I have felt, and I'm heartened that an apparently younger programmer (or at least newer programmer) is still finding the same joys in the work.
Friday, March 23, 2012
I Can't Handle The Truth, Apparently
What a day. After spending almost three weeks digging around a test system trying to find the cause of a communications failure, someone mentions that the test endpoint is prone to locking up. Which causes the errors we were seeing. And this just after getting an email from the developers of the test endpoint asking about some new messages in the API. New, that is, 4 years ago. Which they have not implemented yet. Despite 2 revisions of the API since then.
Words fail me.
Words fail me.
Thursday, March 22, 2012
Duck, Duck, Goose!
A few weeks ago, I read this post about something called Duck Programming, and it rang a few bells.
I've run across a number of these systems in my career,and each has proven to be an abject failure. It is simply not viable to make a complex system totally flexible without programming in some form.
The first system I ran into this was one for replacing single-purpose cellphone provider consoles in stores selling cellphones. The goal of the system was to interface with the store's systems to provide all the options to sell the service without requiring a special-purpose console. It was not simple, but we were well on the way to having this when we ran into the bete noire of cell phone sales - the service plans options.
It seems that at the time, all the cellphone service companies allowed their salespeople to define almost anything as a package, to allow them to make sales. So even though I could not get just call forwarding as an option, a salesman could decide to offer just call forwarding to a customer if the salesman thought it was necessary to make the sale. So every possible option had to be allowed, but only if it was defined from the cellphone service side. And it had to be simple to set up. No programming necessary.
Needless to say, we did not succeed.
The second time I saw this, it was a special-purpose language to control telephone switches, that was supposed to not require programming. It didn't require programming, but required you understand trees and stacks, which meant that you had to have taken programming classes to get everything right. We ended up replacing it with a database and C, which had the added benefit of allowing us to hire programmers from almost anywhere, instead of those who had happened to work in that system previously.
The third time was an attempt to replace a complex control system that had 4 main sections of data, each of which had numerous relationships, with a key:value store. Everything was a tuple, and the keys connected everything in great transitive chains that taxed the system just to get the basic data out.
It failed as well.
I'm starting to believe that the Managerial class fears programmers the way that Bronze Age nomads feared blacksmiths - programmers wield mystic powers that shape reality, and are best done away with when you are done with them.
I've run across a number of these systems in my career,and each has proven to be an abject failure. It is simply not viable to make a complex system totally flexible without programming in some form.
The first system I ran into this was one for replacing single-purpose cellphone provider consoles in stores selling cellphones. The goal of the system was to interface with the store's systems to provide all the options to sell the service without requiring a special-purpose console. It was not simple, but we were well on the way to having this when we ran into the bete noire of cell phone sales - the service plans options.
It seems that at the time, all the cellphone service companies allowed their salespeople to define almost anything as a package, to allow them to make sales. So even though I could not get just call forwarding as an option, a salesman could decide to offer just call forwarding to a customer if the salesman thought it was necessary to make the sale. So every possible option had to be allowed, but only if it was defined from the cellphone service side. And it had to be simple to set up. No programming necessary.
Needless to say, we did not succeed.
The second time I saw this, it was a special-purpose language to control telephone switches, that was supposed to not require programming. It didn't require programming, but required you understand trees and stacks, which meant that you had to have taken programming classes to get everything right. We ended up replacing it with a database and C, which had the added benefit of allowing us to hire programmers from almost anywhere, instead of those who had happened to work in that system previously.
The third time was an attempt to replace a complex control system that had 4 main sections of data, each of which had numerous relationships, with a key:value store. Everything was a tuple, and the keys connected everything in great transitive chains that taxed the system just to get the basic data out.
It failed as well.
I'm starting to believe that the Managerial class fears programmers the way that Bronze Age nomads feared blacksmiths - programmers wield mystic powers that shape reality, and are best done away with when you are done with them.
Sunday, January 08, 2012
Legacy Code and New Developers
I just read this article about legacy code, and I am dumbfounded. The author seems to embody the attitude that nobody before him/her was a capable programmer.
(Warning, Old Fart Programmer Rant approaching...)
What new programmers forget is that the legacy code was written over many years with evolving needs. The original schedule was probably a Death March, there have been 4 major OS version updates, 7 compiler migrations, and a database vendor change in those years. The customers have made thousands of change requests, all of them urgent needing immediate fixes that have to be tested on the customer site because they have a configration that cannot be duplicated in-house in less than 2 weeks.
There have been 20+ developers working on this, some of them contractors with less interest in long-term maintainability, some of them fresh out of school, and most of them overworked.
One of the systems this code has to interact with is ancient and does not use a modern communications protocol, so you have to write raw socket code and parse proprietary binary streams - no well-defined XML with a DTD here, bucko!
There are no unit tests, because 1) this code was written before Agile was invented, and 2) the project managers are old-school, and testing is not part of their schedule, it's for the Test Group, so you can't waste time writing tests during Development, or you get fired.
So don't get all holier-than-thou about old code, laddy - your code will look like this someday. if it's still in use.
(Warning, Old Fart Programmer Rant approaching...)
What new programmers forget is that the legacy code was written over many years with evolving needs. The original schedule was probably a Death March, there have been 4 major OS version updates, 7 compiler migrations, and a database vendor change in those years. The customers have made thousands of change requests, all of them urgent needing immediate fixes that have to be tested on the customer site because they have a configration that cannot be duplicated in-house in less than 2 weeks.
There have been 20+ developers working on this, some of them contractors with less interest in long-term maintainability, some of them fresh out of school, and most of them overworked.
One of the systems this code has to interact with is ancient and does not use a modern communications protocol, so you have to write raw socket code and parse proprietary binary streams - no well-defined XML with a DTD here, bucko!
There are no unit tests, because 1) this code was written before Agile was invented, and 2) the project managers are old-school, and testing is not part of their schedule, it's for the Test Group, so you can't waste time writing tests during Development, or you get fired.
So don't get all holier-than-thou about old code, laddy - your code will look like this someday. if it's still in use.
Subscribe to:
Posts (Atom)