umd

I'm sure we could swap good war stories. I can't tell you how many problems were caused by it's lack of real logical operators.

scotch

Until today, I'd forgotten what a kick-ass book Unix Power Tools is.

agoodale

Probably although the logical operators were never a big issue for me for the work I was doing. I must be getting old because sometimes I miss the simplicity of it all.

umd

Well when AND/OR/NOT don't do what you expect because they are bitwise instead of logical, it causes problems. Especially if you are calling things in other languages that don't have the same definition of the meaning of TRUE.

waterrockets 

I used to work at the gun club on step 49. My first job, and I was 14. Mostly loaded trap and skeet. Put two on the arm, throw three against the wall. There were about 12" of busted clay pigeons in the floor of the trap houses. Really sucked when they pulled while you were loading.

kudude

I don't have to ask. I know it is.

kensuf

niiice.

carpediemracing 

I never saw that before. Step 38 threw me off for a bit. Heh.

WCroadie

Yup, he said all the BF use is costing his company a lot of $$$ No and trust me no one wants to work there.

He and I would be the only ones with access to look at the report. And I don't care what anyone there does as long as they don't f up their computers and make me have to go onsite.

The guy running the show is a total dictator, control freak and genuine a-hole.

carpediemracing 

My brother is a high end programmer. I asked him about the 2-3 other high end guys at my old job (he is still there). He said that all programmers think their code is better than another "equal" programmer's code.

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 1.1.2.0 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".

wens

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."

slynkie

definitely a good Friday quote.

Blackdays

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?

Urthwhyte

You'd need to rewrite the UI bits for sure, and libraries you're using might very well be missing if it's anything like SL on the Desktop v. Silverlight on WP7. Other than telling you that, I can't be of much help

Blackdays

That's what I was thinking. I don't have much experience working with the android kit, but since it is java based I figure it shouldn't be too hard.

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.

Urthwhyte

Does the compiler or your IDE not catch that for you?

Blackdays

I was getting this lovely error:

java.lang.NoSuchMethodError: main
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at edu.rice.cs.dynamicjava.symbol.JavaClass$JavaConstructor.evaluate(JavaClass.java:298)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.handleConstructor(ExpressionEvaluator.java:1 28)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.visit(ExpressionEvaluator.java:98)
at koala.dynamicjava.tree.SimpleAllocation.acceptVisitor(SimpleAllocation.java:137)
at edu.rice.cs.dynamicjava.interpreter.ExpressionEvaluator.value(ExpressionEvaluator.java:38)

But I couldn't figure out what it was.

waterrockets 

I've never seen an interesting system with no known bugs.

agoodale

I keep a few harmless but known bugs in my software just for ol' times sake.

agoodale

I probably don't rank very high on a "coder" scale. I'm more of a analyst/manager/tech guy who can relate to users/sales guy who can code.

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.

mattm

+1 one of the hardest parts about shipping a major product is deciding which bugs you'll have to live with, and which features you'll have to live without.

carpediemracing 

"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.

cdr

slynkie

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

slynkie

if this is the company i think is, we've had some dealings with them. they had a really nice big break room with free coffee and snacks

carpediemracing 

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.