mgse

Changing MakeRoom to be inline (gcc 4.6.3) turns out to be a significant speedup.

Also appears to be a small benefit from modifying the Lev struct to have Room first.

Related to "Hire open source hackers", I'd like to work for a company that respects, and dare I say encourages, open source contributions.

I recently went through the approval process to contribute to a project on my own time. Due to its nature, the project obviously would not conflict with my business unit or any business unit within the company. Approval should have been a 5 minute conversation with my manager.

Instead, I had to write up a proposal for the open source review board. After a week or so, they agreed it was acceptable. The next step was to fill out a form and get a VP to manually sign it. This took a bit of time since the VP is 4 levels up and was, unsurprisingly, out of the country.

That experience will affect my next job search.

Land owners do care, however.

There was talk of a new rail line to the south of Rochester, MN a number of years ago and some landowners were unhappy because the proposed line would split their fields, require new fencing to protect livestock, etc.

Here in Oregon, other landowners have gotten letters from the railways demanding payment for driveways across their lines just so they can get to their property. See http://www.kval.com/news/local/Neighbors-on-edge-over-new-ra...

Would it be easier to force a half a dozen farmers/landowners to give up part of their property than thousands of house/apartment dwellers? Of course. But its still forcing people and that results in lawsuits which will drag things out.

For me, 'restart' is generally the most used operation during debug. The vast majority of the time I want to rerun through the init code to clear out the registers and any previous transactions. If I've set something up incorrectly, I can always set a breakpoint and adjust.

So I'm not seeing an immediate benefit to direct modification for my normal workflow. There may be good use cases when writing code that isn't HW dependent or if the compile/flash cycle takes a long time, but those aren't problems I've had very often over the last ~10 years.

From what I've seen at IBM/HP, interns/coops usually get paid somewhere around $20 to $25. A bit lower if a freshman, higher if grad student. And last I heard, the MECOP program at Oregon State sets a floor of $15 an hour for interns and it sounds like the vast majority, if not all companies, pay more than that.

So while not an apples to apples comparison, I'd say at $15/hour you're low assuming no equity. That said, unless you need the money to survive, I would view the job as a springboard to your future goals.

So if you're learning a lot and enjoy what you're doing, I'd recommend sticking around. Maybe you can make a play for some equity? On the other hand, if you don't feel like your skills/resume are developing, consider looking for an upgrade (pay and personal development).

On the last point, I've been out of college for almost 10 years now and I still pick up quite a bit from my coworkers. It sounds like you're developing on an island which is both good and bad. You learn a lot, but you also miss out on the expertise of others. Something else to consider.

"If you have extensive and current open source contributions, for most people it means ... you're violating your employer's contract terms."

Bingo (at least for me). Both companies I've worked for require you to submit a proposal to an open source review board for approval. I went through the process at my previous job and approximately 2 months later I was given the go-ahead. Not worth it.

I'd agree. Those ratios sound pretty reasonable for firmware. Actually, 60% was probably a good year.

I worked on i&p series servers at IBM and a vast majority of what we did wasn't really new functionality. It was more adapting the existing code base to the next gen hardware. Power on sequences had to be modified, hardware access went from GPIO to I2C and vice-versa, and the rules of what could be plugged into where under what conditions were always changing.

And once everything was working, you've got years of support to look forward to. It wasn't uncommon to get pulled into discussions for products released 5+ years ago.

As an aside, hardware enablement might not be flashy work, but it can be loads of fun even if you're not writing massive amounts of new code. Sure, the documentation stinks and the first pass of hardware is about as good as airport TP, but it is amazing feeling when it finally works.

I believe the MECOP program at Oregon State sets a floor of $16. 40 hours a week * 4 weeks gives you $2560.

I've been told almost all get more which is good because that seems quite low.

Less tax impact.

http://en.wikipedia.org/wiki/One-dollar_salary

If you mean the idealistic notion that an engineer can come in and eventually run the company, sure, if they get on the management path quickly.

Spent just under a decade with IBM working on servers and even the best people I saw (technically and politically) were taking 8+ years as engineers to make it to a senior level (band 9 for any IBMers). And at that point, you're likely just a glorified project manager. If you put together a couple decades of awesomeness, maybe you make Distinguished Engineer or even IBM Fellow. They don't end up as VPs or CEOs.

As a disclaimer, I now work at HP. With respect to the culture in the trenches, I see IBM and HP as almost identical. Some great people to work with, interesting projects, and way too much bureaucracy :)

Not a lawyer, but I didn't think non-competes were valid in California

http://law.onecle.com/california/business/16600.html

There do appear to be exceptions though. Can't speak to non-disclosure agreements.

Close garage door or verification it is closed. Turn off outlets (parasitic devices or just something I forgot). Drop water heater temperature when away assuming not tankless. Pet feeder/treats. Close/open shades depending on temperature and time of year. Water shutoff (burst pipe? leaky toilet? bad neighbor?). Watering plants (bonus if based on soil moisture). Run dehumidifier based on moisture. Control ceiling fan speed in bedrooms rather than air conditioning entire house. Turn off gas if pilot light goes out (furnace, oven). Warning on radon, CO2, smoke, etc

Of the above, the dehumidifier is one that I'd really like living in Minnesota. My dehumidifier's built in threshold for running is poor so I use a timer. It is far from optimal.

Code, code, and then code some more.

I've read quite a few similar posts over the last few months and that has been the answer almost every time. Can't say I disagree.

Going back to school will take years, cost you some good chunk of change, and when you're finished you'll likely look back and realize all the programming you learned was in your spare time anyway, not due to class.

Pick a language/framework, a project, and start learning.