BrentRitterbeck

When I left for undergrad over ten years ago, I was heavy. During my undergrad years, I walked everywhere or rode a bike everywhere. I lost about fifty pounds in two years. I put all of it back on and more once I graduated and started working at a desk all day. I feel miserable everyday now because of all this excess weight I carry, which is why I've decided to start riding a bike again everywhere when I get back to California on Monday. I'm finally going to put the car to rest.

I work in QA. I am fully able to read and write code. The engineers I work with have a background in computer science, and I have a background in the domain. The engineer is learning about the domain as he does his job. I am learning about computer science as I do my job. QA and engineering have to operate as a cohesive unit. It's not supposed to be one group against the other. Both groups are there to make the product better. The two groups are just approaching a better product from different directions.

The engineers I have the easiest time working with are the ones that leave the ego at the door, realize that both sides bring something to the table, and are simply concerned with solving the problem at hand.

Let's say that the front office (those doing the selling) start promising tons of features because they want to really sell this thing. Perhaps those features might be a little more complex than the "visionaries" first imagined. Now the expectations have been set.

The engineers try to meet those expectations. They try their best, but then it gets to QA. The people doing QA really care about their job, about the quality of what is being released, and they do a good job poking holes in things trying to get it to a quality that was promised. QA sends it back, but the developers have moved onto producing new features. Bug fixes are not cool. Sometimes doing it right is hard. Things start to slow down.

The end product is something that doesn't quite meet the expectations and is late...just a guess though.

Yeah! Figuring out the ad you are most likely to click on next is the best way forward for mankind. This is obvious.

During my time as an interest rate risk analyst, I had the displeasure of working with a horrible piece of software. It crashed at the most inopportune times, usually near the end of a run. Considering that one run could be on the order of a few hours, you could lose a significant portion of your computing time, something in short-supply when other business processes don't get you your input until seven to ten business days within a new monthly reporting cycle. When it did finish, the probability that there was a problem with the final output was much larger than it should have been. Furthermore, the software could not even be used for actually analyzing your results. You still needed to dump out the calculations to Excel before finishing your analysis.

On the surface, it would seem that the hardest part of solving this problem would be implementing the software as it's a highly specialized area of finance with lots of mathematics. When you break it down, however, what needs to be done on the software side is pretty straightforward.

I had to document this stuff for regulatory purposes at my old job. To document this stuff, I had to do a lot of "reverse engineering" of this software, basically building in Excel the same calculations performed by the software. If any person or group of people near Mountain View are looking for a problem to solve, I'd gladly sit down with you one evening and answer questions about this space.