Not hacked in the classic definition, but it would be "accessing a system without authority" or whatever the BS US legal term is --- highly illegal in the US. Zero tolerance, right ?

I think I'm paying my ISP to deliver bits to me. That's who is paying - ME. If I'm not supposed to be paying --- LET ME KNOW!

What we've learned about "inside out" teaching (work-sessions at school, lectures over video at home) shows the result that while _doing_, one comes up against problems and wants to ask questions. If you have someone to ask real questions, and get real insights, they will progress much faster and much better. Delivering lectures to students is best done with different tech than we have now. Students that are behind don't ask questions - they don't want to look dumb - but they will review a lecture over and over until they get a key point.

Google is making the simple mistake they did with the wifi thing.

There is _no way_ that capturing packets off open wifi networks was illegal or immoral. I know because I was doing a mobile wifi startup at the time and we investigated the legal boundaries of open wifi. Although not all points were litigated, anyone installing an AP could choose encryption, it was likely illegal to use an open AP without asking, but the packets were more like shouting across the back fence than the privacy afforded a cell phone conversation.

Google assumed that the obvious law would be enforced .... obviously.

With Glass, Google is taking the road that cameras, and cell phones, do all of this today anyway. Anyone who has Glass on their face is just like someone holding a cell phone to their face (either taking a picture or talking or using navigation), and using Glass has the exact same privacy problem as a cell phone, and cell phones are already a known quantity (it's illegal to record most audio, legal to record most video, legal to record police). It's just so freaking obvious, even if a republican congressman from texas writes a letter on behalf of his committee on privacy.

Google will now make the same mistake, and assume that the obvious law will be enforced as it obviously should be.

It won't.

Instead, we are grappling with this social aspect of giving individuals the power that governments and businesses have already (CCTV). The obvious answer is to give the people the same power as businesses and government. But, instead, we seem more afraid of our neighbor than these other folks --- which is just crazy.

Maybe, however, Google has the right idea this time. Seeing 1500 influential people will start the conversation, before they put this beast to retail and get slammed. Maybe they're doing something clever. Good, Google.

I agree with this. I'm seeing more and more code that's short because it calls a lot of subroutines, all called things like Foo.Add(x) with little description of what "Add" might do, saying it's OK to be terse because you know what type X is, except, oops, the programming language just says it's a List and doesn't have "meaning" .... but maybe I'm cranky. Readable does not mean short!

I see several different kinds of quality in my co-workers' code.

I see problems that are called sloppiness, like bad variable names, and "ugly" looking loops. These are not worth worrying about. I find that many new programmers - programmers raised looking at open source code that is coded without comments with the fewest possible lines - find "ugly". Even the use of Gotos and similar, use of variables without accessor functions. The refactoring is to make functions shorter, to remove comments (since now the code is self-documenting). This kind of quality problem you should overlook, because it's more stylistic than you think.

From your description, I think you're horrified by this lack of "neatness", and if so, you should get over that. (You talk about needing to "clean up" constantly - making me think this is simply moving lines around).

There's another quality problem, which is incorrect modularization and abstraction. When I see code that is going around external provided APIs, not creating APIs but simply objects called "Object" and similar. PUtting functionality into a higher level module when a lower level module should be expanded so other people can use the same functionality - but it's "a pain" because you have to write test code and update documentation. Code that is incorrectly modularized is technical debit that will always be hard to remove.

This kind of quality problem needs to be discussed. In your situation, the answer is always to ask questions. If your partner is always busy or blows you off, you go to another senior person and say "Joe doesn't have time for me, and I don't understand X way he factored the code, can you give me 5 minutes to explain this style?" If it really is as bad as you say, another senior person will grimace in horror, and tell you he'll go deal with it. You should expect to get reassigned to a better project in a few weeks.

This. I remember one group I managed where two people privately came up to me and said "That guy is a problem and writing problem code". As a good manager I looked a level down, made up my own mind, and managed him out. I got credit for improving the company, rightly so. Don't go on a warpath. Just drop a hint to your manager in a non-confrontational way and leave it alone. They'll take it from there, or they won't.

Let me tell you a story. On the founding week of a company, where 80 programmers were hired (some of the best I've ever met, it was a strange situation), I was told to write a filesystem in 3 days. In order to succeed at this, I didn't do full POSIX, figured out why we were doing a filesystem, what the special twists were, and built the thing. The code had to be extremely reliable (multimonth uptime delivered in days of coding, so the code has to be "provable" and "inspectable". I did this thing. Three times in the next 4 years different people walked into my office and said, effectively, "I found this POS in the bottom layer of our product and it's creating all these problems". I said "is the interface and layering right?" "Yes", they always said. I would say "I wrote it in three days and it's exactly hit the design goal I was aiming for. The code's never crashed, never lost data, has a great interface, and it's slow as dead dog meat. If the requirements have changed, rewrite the code. Spend a whole week on it this time. But don't say I wrote POS code - it was code exactly to spec." Every time, the person wandered out of my office, and the project manager said "we've put off changing that module", and no one ever touched the code. Apparently it was a POS, and it was a simple well defined module, but when push came to shove they wouldn't do anything better. I have other stories like this, an expert programmer will often do something a beginner won't - like cut a corner and write known-ugly code to win business, ship a product, keep a company alive, and are more than capable of writing beautiful code, too.

Although you know yourself, I've found that attempting to program for an hour a day doesn't work. There's a reason programmers - even marginally competent ones - are paid well above $100/hour on contract. Learning to program is hard. You need to dedicate chunks of time to programming, like 5 or 6 hours in one go, in a week. It's also hard to remember what you're doing if there are 6 days between your programming days. If this is all the time you have, don't curse yourself if you don't get to proficiency. You wouldn't expect to learn being an engine repair mechanic in one hour a day, because most interesting repair tasks take a few hours. This is the nature of the thing, not your fault. I'll give you an example. I was trying to place irregular stones in a path, and I had all the sizes of the stones, and I wanted to find the optimal placement. I did it by eye but didn't think the result was optimal, but couldn't find a better solution. I stopped my gardening task and wrote a program. I hadn't programmed in python for a year, so I had to dust off my knowledge, then wrote the program a couple of different ways, and used a method of config files I hadn't used before. The task took about 3 hours by the time I was done, and I found that my initial eyeball solution was optimal (but now I knew) - and I'm a lifetime programmer of just about every language. Instead, set your goals lower - expect to write a few nice scripts for your own fun. _make it fun_. Consider automating tasks you would do in your everyday work, and write the automation on the weekend - like if you're taking backups, what does an rsync script look like that emails you when it's done, or does more copies in parallel, or whatever you can think of?

I have a LiveScribe, I never look at the notes, and no one reads my summaries. It's not much better than a pen and paper. Last conference I took my Android Asus Transformer. I was very happy with the solution. Benefits: 1) small keyboard, but a full keyboard, I could touch type, thus still think about the preso 2) I could immediately send my notes to colleagues at home 3) I used an editor that supports Word format, which also supports google docs, so they would push and pull automatically 4) I like the android touch oriented UI most importantly: **) 18 hour battery life, no looking around for a plug

Replying to self: our Citrusleaf database does amazing parallel operations on Sandy Bridge i5 (2400) machines. Single socket machines have the best interrupt processing and lowest memory latency. Going to Xeon architectures is, price performance, a HUGE decrease. There was a great post somewhere about $/speed in CPUs, and of course the true consumer grade stuff (i5 and Phenom II) were 10x better than "datacenter" grade machines. This is especially true for Supermicro. As much as I like them, you can save 4x money by going Asus and using a physically larger box - if you're not going into a data center. Another cost savings is running the project at home - you'll get more bandwidth for $50/month then you'll ever get from a data center.

Even though the application is parallel, your bottleneck can easily be the memory bus. Adding tesla cores won't solve memory bus issues. For a number of apps, Intel i5 quad cores stacked up increase memory bandwidth on the cheap. 10 500$ machines, or 5 1000$ machines with a cheap NVidia GPU, may very will outperform anything that can be put in a single "box" - because there is 10x or 5x more memory bandwidth. That means you need software to write not just parallel code, but multimachine parallel code - in which case you should get in bed with a computation fabric like Hadoop or one of a million others (raw OpenMP is another example, if you're a GPU hacker type).

Look, I get it about being overcommitted.

I don't get how you got into this in the first place. You sell handbuilt systems, but you provide free support for people who don't have your systems. As a friend, apparently, but these people aren't friends. I've got friends too - I fix their computers - and when I had deaths in the family, they put me up and took care of me, and didn't ask me to fix their computers.

The way to get yourself out of this situation is always to give them someone else to call. There's a million nice ways to do it. In this case maybe you say, I'll give you a hand when I have time, but this week's bad and next week doesn't look good either. If you want it done quick, a buddy of mine had a good experience with the help guys at X store, if you need it done quickly, give them a call - but let me know how it goes, eh?

Recently I had to duck out of a contract job after an introductory meeting because I didn't like the smell of the job. Sounded like too much work and not enough money, and not interesting. So I asked around and got two names of friends who were hungry (so I was doing them a favor) and contacted the contractee - they didn't like those guys, some of the best people I know (better, for this job, than me). So I said I'd keep asking around, but I'm not going to bother. They can't tell quality when they see it, which means they'll be a problem customer. I've kept a good odor, though, and if I do get hungry, I can come back to them.