chrismaeda

It's already happening. You don't need to build a new city. You just open a satellite office in a place like Boulder or Austin. Your young, single employees would never live there in a million years, but once they marry and have kids they'll be lining up to relo there for the cheap housing, good schools, and lower cost of living.

Years ago, I was asked the C++ virtual destructor question (eg http://www.programmerinterview.com/index.php/c-cplusplus/vir...) in an interview.

My answer was, "I don't know; I would look it up in a book. Is this really relevant for an architect position?" I got the offer anyway and turned it down.

I think these technical interview questions are a silly way to evaluate developers. You almost never have to write low-level sort routines because you just call them in runtime libraries. But it's harder to evaluate the more important ability to modularize code and manage complexity.

The Information Systems literature.

If I had to choose between having kids and starting a company, I'd choose the kids with no regrets. Startup life is overrated.

This is a great post. Another path is into sales. If you have a deep understanding of technology, are able to help people use it to solve their problems, and you can communicate the value to buyers, then you can do quite well in sales. (It's also helpful if you know a thing or two about how to dress and you like to drink.)

Another friend started out in programming and IT, but he migrated to a sales engineer job where he works for [big infrastructure vendor] to design solutions for their clients.

In the more generalized roles, you deal with parallel systems made up of unreliable carbon-based computing elements. You can't just feed them electricity and order them to execute programs. You have to charm, cajole, and/or threaten them at the right time in order to get them to produce the desired outputs. This requires some amount of patience and wisdom to do well.

One data point: a good friend of mine joined [large rdbms vendor] out of college about 25 years ago and rose through the ranks in the rdbms engine group. He's now one of the senior people who knows where all the bodies are buried in the code, the forgotten bugs that resulted in the current weird algorithm in the xyz module, etc. I have no idea what he makes, but when I tried to hire him during the first internet bubble they slapped the golden handcuffs on him. These days he's rich from 25 years of stock options.

Your comp definitely plateaus if you remain an individual contributor. You become more valuable, and more highly compensated, by managing and/or mentoring people, helping evolve the technology to match the needs of the business and to find new markets, touching customers and revenue, etc. In my opinion this is required from all senior level technical people in the software industry.

Lobster is not a delicacy in New England, and eating at a lobster pound is the New England equivalent of a German biergarten. One of the reasons why the price has dropped so much is that the lobster fishery is managed for sustainability.

I think the stuff about humanely killing the lobsters is hogwash. Boiling and eating a live lobster is one of the few meals where you have to confront the fact that we kill so that we can eat. Hold them upside down, plunge the lobster headfirst into the boiling water, and give thanks for life. And make sure you have a pot with a heavy lid.

Poor analogy. The economics of software production are totally different. You can't feed the entire world with one meal.

SICP is a masterpiece. I took the old MIT 6.001 in Spring 1986 where we burned through the entire book in about 14 sleepless weeks. Sussman was the lecturer and Rod Brooks was my recitation instructor. I was like 19 years old at the time and it was the most intellectually beautiful thing I had ever experienced. I ended up acing the course and went on to get a PhD in CS. I've never read a better book on programming.

The latter. If you are a SaaS business in a state that taxes services, you only have to collect sales tax for customers in your state today. Under the new legislation, all SaaS businesses in the US would have to collect sales tax for any jurisdiction that taxes services.

The simplest way around this would be to set up your SaaS business in Canada.

Maybe, but Quill is the law of the land today.

Right. Companies with a physical presence in a state are required to collect sales taxes from buyers for all sales in the state. Businesses are not required to collect sales taxes for states where they have no presence (aka nexus); this is based on the Quill v North Dakota interpretation of the Commerce Clause of the US Constitution.

The problem with the proposed legislation is that counties, cities, and towns can each set their own tax rates. So the compliance costs are high because of the thousands of different rates. You cannot use something simple like state or zip code to determine tax rate; you have to use geolocation to get the exact jurisdiction. And governments typically levy penalties if you get your sales tax collection wrong. So who is responsible for paying the penalties if the third party tax collection service makes a mistake?

The way this was supposed to go down is that states were supposed to simplify the number of different tax rates before requiring out-of-state businesses to collect their sales taxes. You shouldn't need to subscribe to a sales tax compliance service to do business in the United States.

It depends on the state. Some states tax services (eg Ohio), while most states only tax physical goods.

I expect it to die in the House.

As a rule I never give anything to beggars in the neighborhood where my children live. Find another part of town to beg in.

But I always give money to veterans.

I've had the opposite experience. I've converted 2-3 complex build systems implemented in different flavors of make to ant. It's tedious but it's doable. And once you get to ant, it's a lot easier to maintain compared to make.

I looked at maven a couple time but could never figure out how to convert a make-based build to maven because there is always a bunch of weird hacks lurking in the makefile. However, I do see how maven would be fine for a new project.

You're supposed to realize that enlightenment is not computable by an FA.

I was one of the last Mach people at CMU. The BSD emulation on Mach 3.0 was implemented by stubs that made IPCs to the BSD emulation server, which then made additional Mach API calls to implement the UNIX semantics. This design was generally half as fast as an in-kernel implementation (e.g. Mach 2.5 or a commercial UNIX kernel). In the mid-90's we figured out how to make up the performance gap by refactoring the BSD emulation to put some code in the same address space as each application (ie in the libc .so), which allowed you to avoid the RPC to the emulation server in most cases (eg http://dl.acm.org/citation.cfm?id=168639). So I don't think it's fair to say that microkernel implementations of UNIX are inherently slow; instead I would argue that the simpleminded approach to UNIX emulation was the real problem.

None of this technology made it into a mainstream Mach distribution because the band broke up: Rick Rashid and his staff and students went off to work at Microsoft Research. Brian Bershad took over the project and then moved to University of Washington. It was also becoming clear in the mid-90's that the OS didn't really matter much anymore, since the big money was being made in Internet applications. So most of the hackers who might have worked on new operating systems during this time ended up working on application servers and web apps instead.