Before the launch of the XBOX 360, the company I worked for was one of their suppliers, and without going into enough detail to make me identifiable, the management of our two companies had arrived at sort of a stalemate: We didn't want to tell them exactly how our algorithms worked, and they didn't want to tell us exactly what they were doing with them-- think of it like a data compressor where, we don't want them to know the exact compression algo, and they don't want us to have their data.
So, somehow, It is arrived at that a website will be created that encodes MS's proprietary data, but doesn't store it, but also our algorithm is implemented server side, so there's no leakage of proprietary stuff.
A month later, the app is done and tested and I'm decoding data from the website on real hardware. I move on to the next project.
Three years later, the Xbox 360 is out, I decide I'm tired of filling out reimbursement forms for Heroku and its got to be a security risk with no updates in 3 years... so I take a look at the apps stats to see if its feasible to shut it down--exactly zero users. Nobody ever attempted to use it, not even once.
Ironically and unknown to me, the source code had been lost in a freak accident and when I deleted the Heroku account that was the only copy of the source left.
Even worse, a year later someone claimed to have a use for the app and where was it please? And I had to explain we no longer had the source. I remember a very long e-mail about how irresponsible we were.
The worst programming experience of my life related to lost source code.
I was working for a place that had a service running from a Java app that was customized for each customer, about 200 copies of roughly the same app. There was source control at some point, and when a new customer was being on boarded they’d just make the customizations they required, compile the app, and deploy it.
By the time I worked there (years later), all source code had been lost, and I was tasked with creating a CI/CD system that included managing these apps (they’d now decided they needed to be maintained).
For each one I had to decompile the whole thing, rewrite the code into a human readable format, redeploy and test it. They were filled with all sorts of horrible anti-patterns too, like hard coded file paths, and some of them were only used once a year (but for an absolutely business critical process).
About half way through we had a major data center failure that meant we had to do a failover, which of course broke most of these apps with all their hard coded configuration. So instead of having months to work through all of this garbage, I was asked to get them all working immediately.
I got them all working in 3 days, which I thought was quite a monumental accomplishment. But my CEO was very dissatisfied that it took so long. I quit a couple weeks later, and still almost regret putting so much effort in to saving them. A friend of mine still works there and apparently all of these applications are in exactly the same state as I left them.
Yeah I was definitely right to quit, my career has been pretty great since then.
But I did get a lot out of the few years I worked there, even though a lot of it sucked. It was my first proper job and they’d basically let me work on anything I wanted to, even though I was incredibly green and was just figuring it all out as I went. I definitely fit a lot more experience and learning into those years than you’d reasonably expect a person to. I think a lot of my success today came from turning their incompetence into opportunities.
I be also had a job early in my career where I was basically allowed to work on anything that interests me and 20 years later I’m still relying on that experience.
Maybe this is something every junior should do - try a bit of everything and see what you like.
That's why I think a good consulting agency can be a great first place to work. Lots of projects, hopefully different technologies, perhaps international clients with travel. Then once you know what you like and specialize a bit in it, it's easier to step to some product company as a senior.
Plus, in my experience consulting companies are more focused in employee well-being as it's their only asset.
> There's a certain personality type that will never appreciate or reward hard work.
Now, how would someone figure out these personality types ahead of time? Any red flags to detect people or workplaces to avoid in a professional capacity?
Ask them flatout how they reward initiative and accomplishment. If they start fumbling, there's your answer. If they don't, ask them for a concrete example. If that's when they struggle, there's your answer.
1. "...Able to work under pressure and meet deadlines.."
PASS !
2. "I(boss) coded the first version..."
50% of the time it means:
Your solutions or design decision will never be "as good as his" and you will forever hear "I did it like this and that. It should be fast to implement xyz"
On the topic of lost source code... we had a few blessed binaries that were vital to building System 8 and System 9 at Apple. There was a single build machine that could generate these binaries from other object code but the source was long gone. Oh please oh please old Quadra 700, don't give out on us! Those days are over right? Surely nothing like that is happening with OSX...
Hilarious. Why didn't you refactor the customizations into a config file, and just deploy a single jar though? If you went through the effort of rewriting the entire thing!
Instead the OP fed the old version into a tool (Disassembler) which spat out terrible source code, worse than the original with no comments and bad variable names.
This was the only way to get source at all.
Then they made the disassembled source compile in a really nice way.
Finally the boss asked them to make huge changes to this horrible source with time pressure.
A lot of the work would have been roughly equivalent to trying to de-minify some JS.
With a modern IDE the task would have been a lot easier. I don’t know if Eclipse had refactoring assistance built into back then, but if it did, I’d never even heard of the idea. I was sitting on not much more than a year of programming experience at the time.
Textually comparing disassembled code variants can be complicated because the disassembler might/will generate different names for locals.
Because of that, a better approach might be to compare the byte codes of the variants first to find out in what classes the variants differ.
Then treat the different class files as source code until you need to change any of them (so, variant 1 has foo1.class, bar.class, and baz.class, variant 2 has foo.class, bar2.class and baz.class, etc). Don’t immediately try to clean up their code, but ‘just’ try to figure out what they are doing (for many of them, that, hopefully, can be done from function names)
The issue I found when I was first looking at it was they were all a little bit different in random, and confounding ways. Also, whatever the “base version” of the application was had been undergoing development over the years when all these forks were being made.
Looking back on it, that likely would have been the best approach. But at the time the complexity of designing something like that was a bit beyond me.
I can't edit my post anymore-- before someone realizes my mistake, it was the XBox One, not the 360. Rails barely existed at the time of the XBox 360 development.
Thanks for updating! I was a little confused since Heroku wasn’t around before the 2005 launch of the Xbox 360, but figured it was shorthand for something else.
Given the Xbox One SOC had a lot more security in mind, I could see how Microsoft was more cautious about these things. [1]
Just a lapse of memory and thanks for the benefit of the doubt. Another commenter mentioned turbolinks and I was like "whoooaaaa yes I used that and this timeline doesn't line up at all." This lead to a long internal discussion about when exactly did I play Bioshock and does that line up with my memories :-)
I guess I don't mind talking about it so much-- we made a sub $1 component that could compress certain specific waveforms and play them back-- the trick was that they were highly structured, so the compressed data basically just parameterized the silicon in what might be considered to be essentially an assembly instruction-- frequency, carrier wave, data to be sent, etc. The chip then would generate the signal and you could shove it out the electromagnetic radiator of choice with a little amplification a diode and couple of resistors. The problem with these signals was they required very precise timing-- they weren't super complex, but not something a general CPU could handle-- the variability in the timing was too high.
Now yes, you could use a general purpose DAC and an amp and generate the signals, but we sold you a turnkey thing-- with 10 lines of code you could be transmitting signals and the whole thing only use a few kb of ram.
It wasn't super high tech, but our value add was high. I'd say most of the major electronics companies used our chips at one time or another.
The description sounds like software defined radio. A CPU's frequency jitter doesn't matter at all for haptic feedback. Presumably it's not for WiFi, as there are plenty of cheap well-tested WiFi chipsets, so maybe for wireless controllers.
Edit: I was wrong about the frequency range, a sibling comment to yours mentions IR, not radio. Though, their mention of "radiator of choice" sounds like this same chip (or related chip) could be fed into an RF modulator/demodulator to build a software defined radio.
Yea, we were a consumer electronics company that mostly was subcontracted out to make components or complete hardware. I remember working on products for Denon, Crestron, Roku, Samsung, LG, Direct TV, Microsoft, HP, Nintendo, Sony and Audiovox (and their subsidiaries--Monster etc), and in Europe, One For All brand. It was honestly pretty exciting.
Regarding web services, like I said, we had a library of these waveforms and that was our cash cow-- you got the chips for only a few cents over cost. You got the API that operated them for free, but access to out database cost a fair bit.
Ah, so I'd guess you were producing some chip that generated IR signals to control various consumer electronics devices, and the library is a library of control commands of thousands of devices of different manufacturers.
Basically what you need to build a universal remote control, or a remote control for a specific device that includes controlling capabilities for other manufacturers' devices.
I'm pretty sure about that, especially since One For All is a brand dedicated to universal remotes.
If I had to take another guess, I would even nail it down on him having been employed by a company called Universal Electronics, which produced a series of universal remotes called "JP1 remotes" in hardware hacker circles (see for example http://www.hifi-remote.com/files/help/The%20WHAT%20and%20WHY...) and also acted as an OEM for a lot of other companies, so their tech could be found in various remotes of different brands.
[edit] I was slightly wrong. He was working for Zilog (which sold their universal remote business to Universal Electronics Inc. in 2009 however) and probably involved with a cool-named product called "Crimzon RC Blaster": https://www.zilog.com/docs/ir/PB0171.pdf
If they were that serious about security-- the chips we made also implemented this same compression algorithm. It would have been trivial to hook one up to an arduino and feed it the data you wanted to encode. I assume someone realized this, or they never really had a need to encode their own data (we provided a extensive library of encoded data).
I strenuously disagreed with the business justification for keeping all this stuff secret. But it was my job to respect those decisions.
It was a lot of fun writing the (rails) app itself.
So, somehow, It is arrived at that a website will be created that encodes MS's proprietary data, but doesn't store it, but also our algorithm is implemented server side, so there's no leakage of proprietary stuff.
A month later, the app is done and tested and I'm decoding data from the website on real hardware. I move on to the next project.
Three years later, the Xbox 360 is out, I decide I'm tired of filling out reimbursement forms for Heroku and its got to be a security risk with no updates in 3 years... so I take a look at the apps stats to see if its feasible to shut it down--exactly zero users. Nobody ever attempted to use it, not even once.
Ironically and unknown to me, the source code had been lost in a freak accident and when I deleted the Heroku account that was the only copy of the source left.
Even worse, a year later someone claimed to have a use for the app and where was it please? And I had to explain we no longer had the source. I remember a very long e-mail about how irresponsible we were.