Documentation is more important than code. He insists on documentation first.
Cool. Did not know that.
I once watch him rip a developer a new one (and ripped out code) because the developer committed code without documentation.
And that's something most would take as Theo being an asshole. I think it's totally justified if the rule is documentation first. It doesn't take much to end up with shit documentation. In my experience documenting after the fact never works. The justification is usually, "We should document what it ends up like so we don't have to rewrite it." But it just never happens. To me it's akin to a civil engineer just building something saying they'll draw up the "as-builts" at the end of the project and just work off a napkin up until then (then never do the as-builts). Definitely not professional. I know why it happens in software (squeezed budgets, tight timelines), but it's not right. I'd love to work on a project where we have top down support to do things right.
As a software developer I know that documentation often falls to the wayside (features take priority, schedule already tight etc). As a project manager it's difficult to get good documentation (staff does poor job, stakeholders don't want to pay for it etc). OpenBSD has really good documentation (in my opinion) and it was really useful when initially getting to know OpenBSD, PF etc. Most of the pay for middleware I use has documentation that is absolute shit (incomplete, wrong, not up to date etc). To me the state of documentation in OpenBSD is more impressive than "Only two remote holes in the default install, in a heck of a long time!". Of course, "You'll love our man pages!" doesn't have quite the same ring to it.
Yes he makes a ton more than his parents, but he's still the same income class. His parents were in the top quintile and so is he. He's just in a richer sub-segment of rich. If he was born middle class or lower it would be overcoming odds (lowest quintile has something like 4% chance of getting into upper or top iirc). Most people end up in the same income class as their parents. There is very little upward mobility and also very little downward for the rich.
me dreaming of sitting at a desk coding, but the actual visuals are of Vim and nothing else.
Ah, so obviously it was a nightmare
No need to turn this into a Vim vs Emacs debate.
I can understand there being completely user help focussed products like Copilot. In those situations you want something focussed and simple. In the particular case of Copilot I'm surprised that Fog Creek isn't also offering a remote management suite. They have all the pieces there to create a product that competes in remote management, plus their existing users for their main products (FogBugz and Kiln) are the type of users that may need that kind of service. Can't be bothered to roll my own or host an open source bug tracker, I probably don't have the resources to manage remote management.
I've used Goto and it's good for screen sharing, but that's about it. With logmein you can even control things like updates, view logs etc without logging into the machine. When you do log in you can share the screen (default) or you can block it from the local user and you have full admin access (if the user you log in as has it.. unlike screen sharing software that borks once you hit UAC). I primarily use the pro version on headless machines behind firewalls (where I have no control of the firewall and am lucky the end user can figure out plugging in a network cable). I'm looking at moving to neorouter or setting up something myself using vnc and vnc reflector for cost savings. That being said, pro is pretty reasonable in a business situation. I definitely wouldn't be using it for home usage though.
I'd encourage anyone who hasn't tried OpenBSD to try it. Yes, Theo is a hard to love character, but don't let that get in your way.
Used to be you could come to slashdot for an intelligent discussion. Yeah, clicks drive revenue, but when all the readers disappear there won't be anyone to click.
This risk, being a known mole is too high for a "real" spy. If I were a spy agency, I wouldn't risk any assets for such a short term gain. Once exposed, a mole will have no trustworthiness AND all associations would likely become suspect.
And the solution to that problem is easy. Money. Well money and indirection.
Most people can be bought for a price and they don't have to know it's the NSA doing the buying, it could be a terrorist group or something more benign. All that matters is there is not direct link between the code submitter and NSA. Heck, the submitter can claim the NSA made him/her do it as long as they come off as a crazy person (which they will with no direct proof.. "well this person paid me to submit this code, no they didn't say they were from the NSA.. BUT THEY HAD TO BE, I'M CERTAIN!"). Bonus points for finding some tinfoil hat wearing neckbeard that can be bought. If it ever hits the media it'll be short lived and humorous, "Crazy basement dweller claims NSA made him do it! Needed money for rare Star Wars collectibles."
I'm of course playing devil's advocate here. I think it's smarter to find holes in the existing implementation, especially one that has been audited as safe.
Maybe you use all automated organizing, but manual organizing seems pointless in 2013. I used to manually organize my MP3s.. in the 90s. I used to manually organize my email in the 00s. Now I don't have to do either and my life is better for it.
I worked at a company that sent a device to production without our own VID and PID on it (which we had, it just never made it into the image). It caused a few headaches. With a unique VID and PID you can use a generic driver (on windows you have your inf file point to it), but it gives you the ability to replace the generic serial driver or what have you with a custom driver for your device at some point in the future (without screwing up the system so everyone else's generic device has to attempt to use your driver).
That also goes hand in hand with estimation. With proper estimates non-technical people will often think you're sandbagging. "There's no way it can take that long!"
I'm lucky with my current clients. They've been through a successful project and a few failed ones and have a much better grasp on how long it takes to develop reliable software and why it's best to get it as close to right the first time. This also means they are aware of the costs of developing and maintaining software.
Some of my biggest frustrations were working in companies under people that had no clue about software. Not budgeting for maintenance (i.e. assuming once the software is released it is done, and it just makes money with 0 more input of money), dictating deadlines with 0 input from the staff that will actually be writing the software, trying to create a product based on a name and no requirements then pushing the blame on the failed project onto the developers that did anything and everything that was asked of them... heck, one company I used to work at (prior to going on my own) just fired their lead dev. Why? He had the audacity to imply a failed project was the fault of people higher up. Something along the lines of:
"You can't put the blame on us. We wrote exactly what you asked for, changing directions every time you changed your mind on what the product was."
"Well you should have pushed back if you thought this wasn't the right way to go!"
"Here are emails showing I did.."
"Well you didn't push back hard enough!"
"You said the project goes on and I don't want to hear anymore about it. Here's the email!"
"Obviously you don't understand how things work here. We're going to have to let you go."
Classic case of the leader surrounding himself in people that will agree with everything he says. He only ever wants to hear, "Yes, that's an amazing idea boss, you are so smart."