Neurosis is always a substitute for legitimate suffering.
The guy running the show is a total dictator, control freak and genuine a-hole.
It's when you go 2-3 levels up that a programmer may begrudgingly admit that, yeah, that guy writes good code.
There's also the whole thing with bugs. "It's not a bug, it's a feature."
There was one guy that would razz everyone else on their bugs. When he had a bug he'd quickly add a feature so he could re-release the package with a feature update rather than a bug fix. I forget the way the package naming stuff worked but it was like version.feature.something.bug. So 220.127.116.11 meant 1st version, 1st feature, 2nd something, and no bugs. The one guy would carefully re-release his stuff so the last digit was always zero.
Question is how perfect should you make it. If you make it absolutely bug free it could take too much time (inefficient). If you release things too quickly it'll be buggy (inefficient).
My bro said there were one or two programmers (apparently well known to him but total strangers the other way) who wrote basically bug-free stuff efficiently. He'd talk about them with a lot of respect, kind of like bike racers saying, "Yeah, Voigt is pretty tough".
Saw this today. Figure it fits in here:
" Theory is when you know something but it does not work. Practical is when something works, but you don't know why. Engineering combines both. Nothing works and you don't know why."
Do you think we're gonna make it? / I don't know unless we try \ you could sit here scared to move / or we could take them by surprise
definitely a good Friday quote.
So for you java experts.
How tough is it to transfer working java code to android? My final project for my programming class has me making a simulation GPS that runs on my computer. It has a standard gui with a couple of radio buttons. The code reads off a .txt file in order to get the coordinates to simulate the GPS.
Would I be able to transfer this code directly on to the android platform?
But then again, it took me 3 days to figure out the run time error I was getting was being caused by me declaring my main method as private.
I was getting this lovely error:
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.handleConstructor(ExpressionEvaluator.java:1 28)
But I couldn't figure out what it was.
I've always taken the approach that I am only the first of many people who is going to work with this code. So I work very hard at starting with a solid object oriented design. I then code in way that is very clear & straightforward with plenty of short comments. This results in code that is easy to read & follow but not the most efficient. If some inefficient code is affecting the user experience I'll spend some extra time on that piece.
"Basically" bug free doesn't mean bug free. But essentially very well written code. Folks compare it to the code that handles internet traffic.
I've lost touch with prod issues where I used to work but the software is very mature, written by the company head in 1987? (whenever banks could trade and brokers could bank) and developed from there for one of the banks (who wanted to trade). All in C, all following pretty rigid standards. As a programmer you can rely on the fact that everything will be treated the same (format, comments, etc).
Although I won't say it's bug free, especially the quick client-request-filling stuff, the basic structure is extremely, extremely robust. When I left in Dec 2007 the infrastructure could update in real time (sub millisecond) prices of 1.5 million instruments, about 275k messages a second (average load was 60-90k messages/sec at busy times in 2006, increasing from 15-40k/sec in 2003), from various feeds using at most 16 2.8 Ghz dual core Intel CPUs (I forget cache levels but they were high - 32 MB?), i.e. 4 quad CPU boxes. Relatively cheap boxes, $8-10k a box, none of those exotic F-15 96 CPU boxes (they used a bunch of those boxes to replace our system and that's when I lost my support job).
Our system could execute algorithmic trades in about 600-800 microseconds (0.8 milliseconds, not sure of what caused the wide range of time - that's about when I left) based on the feed. One of the limiting factors was distance to the exchange so we'd have machines in data centers in the same building as the exchange when possible (mainly for futures). Although I no longer work there I'm very proud of the company and the software produced there. I rarely dealt with bug issues (don't remember any), more things like hardware, network, or user errors.
Anyway my brother is one of the 4 guys that write the serious code (original guy, another senior guy, and another senior guy). The guy that hated bugs is one of them (quick, creative, buggy). Another was one of the original developers, probably the best in the company (according to my bro). Slow, methodical, and pristine, he'd work 3-4 months a year and crank out insane stuff. Boss/owner was original also, he was quick, creative, but didn't do much actual coding. My brother was a combination - he could be quick, he was more methodical than the first guy, and quickly owned up to any issues.
Everyone else is more GUI and feature-related stuff. For actual things like trading engines... it'd be one of those four guys. When he says "Oh, that programmer is really good" it's significant to me. The guy that wrote DOOM (id software) is one guy that my bro admires.
I can't code worth a subroutine. I supported the systems. As a relatively experienced support person, I was happy that we rarely dealt with our own issues. It's very unusual based on my experience at other companies (where a lot of issues were because of whoever I worked for). Most of the prod issues were with the client (hardware, wrong inputs, bad algorithm, etc).
Ah well. Another life that's passed me by.
whoa, you're speakin' my language dude. i suppose i work on a competitor's product, though funnily enough i joined my department just a couple of months before you left yours.
you might be shocked (or not) to see the avg/peak throughputs feeds are pushing now. OPRA expects to hit spikes of 4 million msgs/sec soon, which is well over what can realistically be handled by a single gigabit ethernet line and that's before line arbitration. they split across multiple channels of course (24?), but it's still an astounding rate. and anyone who can actually handle that on a single box gets bragging rights..
oh, and latency expectations have gotten quite a bit lower too
heh. I think you may work with some of the newer clients. The old client was, let's say, a blue blood type of place.
4 mil/sec is waaay over the infrastructure that I left behind. Way way way. No frickin' way way. We'd have to subscribe to selective instruments at that point or deal with some significant lag. I remember meetings where we were discussing OPRA rates. Everyone was looking at each other glumly. We were very proud of the fact that we could subscribe to everything, and going over our capacity would mean that we couldn't do that anymore. It was very depressing. I suppose parallel feeds with different data streams going into one massive infrastructure would work. Fiber lines to/from the exchange would help too, esp if you can locate the data center right next to the exchange's data center.
We were a middleware provider for a big bank until said bank got rid of all middleware providers (there were 2 significant ones, us and someone else). I supported the infrastructure in said big bank. Ironically since I had relatively high level access in the client's systems (in order to get clearances to perform support etc they put me into various groups) I had access to a lot of the plans to get rid of the middleware providers. I highly doubt it was intentional. It helped to see the writing on the wall though - the power point presentations on their exact plans were pretty fascinating.
There are other clients now but they're errr not quite as much under public scrutiny as a big bank.
I just remembered that we had free soda and snacks. When it was quiet I'd go help get the candy/chips - a full shopping cart worth, a couple hundred bucks, for 15 or so people. But our office wasn't really special and the break room wasn't fancy. We just had a ton of junk food.