Holy cow, this might be related to a design I had last week. My effort to build optical shaft encoders using simple polarization sheet. LEDs can be be used as bidirectional sensors as they work well as photodiodes. That lends itself to optical ring oscillators. Getting them synchronized across multiple encoders and/or controllers led to a control scheme that was.. interesting.
I don't know if the author was intending to be hyperbolic -- I for one prefer Python 2's print. I would've preferred keeping print the way it was and using a new keyword for the new functionality.
The change in the print statement was also what put me off from Python 3 for a long while. But back then there where also no big benefits to be had from moving to 3. Nowadays I even prefer the print function as it makes it easer to convert to log functions.
I still don't see why the print function justifies trying to keep the language alive. You don't prefer that print act as a function and not a keyword? Maybe you don't, but is the change really not worth giving up 2?
Terrific post, thanks! I am somewhat familiar with this hiring process thanks to tptacek's HN contributions (which incidentally led me to recommending a friend to Matasano). I would like to have a better feel for the context of the hiring problems involved here. I am wondering if the company's particular niche makes the hiring process unusually difficult. Or perhaps the company is in a growth phase with a corresponding shortage of employees? With such low turnover rates, how many additional employees are needed? Is it possible that the company is in a position to profitably hire every qualified applicant it receives? If so, the company is essentially losing money on every hire it doesn't make. In addition to a radically improved hiring process, what about offering remote work and/or extremely high starting salaries? Well-advertised high salaries and location flexibility might allow the company to out-compete many alternatives (e.g., Google, FB, Bootstrapped startups).
When I was at Matasano, there was always enough inbound work (sometimes more than enough) to keep the consultants utilized. So yes, a company with a full pipeline will lose money on every qualified hire it doesn't make. Perhaps this is not the case for other industries, but for infosec consulting, there seems to be more work than there are qualified workers. Matasano ran under its own steam and did not take funding. Offering extremely high starting salaries would have killed it in its early years. It was more cost effective to create a process for finding people who could actually do the work rather than rely on the 4-page CV candidates. The expensive ones.
The net result was a win-win: you get bargain candidates and they get 4-page CVs.
My policy (I'm co-in-charge of recruiting at Matasano/NCC, and a lot of folks report to me) is this:
1) Hire based on current ability, not potential. Hiring based on potential is a minefield that our whole process is designed to avoid. ("Enthusiasm," "cultural fit," talking a good game without being able to walk the walk, etc.)
2) Be aggressively fair in giving out promotions and raises. Keeping someone's salary low because they're bad at asking for raises is not a good long-term strategy, especially in consulting.
> Keeping someone's salary low because they're bad at asking for raises is not a good long-term strategy, especially in consulting.
Yes, in consulting the distance between money made and each individual employee's efforts seems shorter than in a big tech company. So keeping salaries in line with impact of contributions should be easier.
I do not know. I suppose even if I did, it's one of those things nobody is supposed to discuss. I overheard talk here and there about raises, but since it didn't pertain to me, I ignored it.
According to FutureCrypt.com, time-release encryption can be used for Sealed Bids, Competitive Proposals, and Press Releases. So things like sealed bids for government RFPs could be transmitted electronically rather than "sealed" in a FedEx envelope. Full disclosure: I own FutureCrypt.
The Hacker's Diet hinges on:
((calories in) - (calories out)) / 3500 = (l lb of weight loss)
The Hacker's Diet holds as an axiom that calories from fat, carbohydrate and protein are equivalent in this formula. This assumption neglects the powerful influence of the hormone insulin, which plays a key role in regulating fat metabolism. Insulin release is very highly correlated with carbohydrate consumption, and a diet that restricts carbohydrate will often lead to weight loss.
Problems with the Taubes' it's-all-carbs-and-insulin hypothesis:
* Protein consumption causes insulin spikes too.
* Insulin is not the only hormone involved in weight control system and energy system behaviour. Also involved: leptin, ghrelin, glucagon, cortisol and probably dozens of others neither of us will hear of in our entire lifetimes.
How about the argument that higher sugar intake causes you to be more hungry, therefore making it easier to eat less calories on a low suger (high-fat) diet. I know it's an entirely different argument from the "keto magic" argument you are ranting against, but do you object to it?
That's part of the general Taubes carbs-insulin hypothesis; that insulin affects satiety (the feeling of fullness, or no longer wanting to eat).
As I said above, there are more hormones involved than insulin. For example, one very influential hormone is leptin. It has a profound affect on appetite and satiety; but we still only understand it poorly.
And leptin can be affected by all sorts of factors. Sleep deprivation, even small amounts, really play merry hell with it. Next time you're running on fumes, you may notice both that a) you're starving and b) your ability to resist the temptation to eat anything is greatly diminished.
And so on. The body is more complex than the thermodynamic equation, but ultimately that is enough to control your mass. The additional details are worth introducing as and when they are necessary (and a good dietitian will do that), but not before. People are very good at giving themselves excuses and, of course, analysis paralysis allows them to forestall any real change.
I purchased this book and read it today. I think it's a nice collection of advice for the budding freelancer. It's a little light on the legal aspects such as business structure, taxes and contracts. I would consider it a beginner's book on freelancing.
For a little more depth on the business side of freelancing, I strongly recommend the following book: Working for Yourself: Law & Taxes for Independent Contractors, Freelancers & Consultants, by Stephen Fishman J.D.
Thanks jiffyjeff. It was tricky deciding how much detail to go into on the legal/financial details, because it's hard to write things that are globally applicable and also useful. However, the plan has always been to add support for other geographical areas in 1.0 (as well as a bunch more general topics), so thanks for the US-specific book tip -- should come in handy.
Wow, what a day... I had an ear-to-ear grin this morning when I learned of support for Go on App Engine. I'm releasing my 3rd GAE app this week (Python) and have big plans to dive into what would've been my 4th and 5th...
Now I've just finished reading the announcements about the road ahead for pricing and support, and I'm having hard time trying not to be upset...
y = mx + b
The big selling point of GAE for me was minimizing the cost of 'b'... I don't mind paying a little extra 'm' if it allows me to avoid 'b'.
For billing-enabled apps, it appears the smooth real-time transition between free and paid will no longer be supported. Now there will be a fixed cost associated with every app every month. Gone is my fantasy of launching great little apps and marketing them until one of them happens to hit the jackpot (possibly by pointing out another great idea -- "the next big thing").
This completely changes the dynamic of GAE for me. Now, If I'm going to support an app, it's going to cost me money whether it's used or not.
$9 per app per month doesn't sound like much for scalable hosting, but sometimes the best ideas stem from little baby ideas, and little baby ideas are prematurely eliminated from consideration if it costs $9 a month to host them.
I launched an almost identical service, http://savethatcall.com, in January. My prices are extremely low (50 cents + 5 cents per minute), but it's hard to compete with free! Good luck.
My margins are low and I've just started gaining traffic, so I haven't made a lot of money. However, I launched the service with a profit motive, so payment integration and realistic pricing were baked in from the start.
I built the site in about 80 hours over 3 or 4 weeks. It was a nice distraction from my master's thesis... Which actually got finished about the same time as the site went live. :)
I used Google App Engine and Twilio, but I also built an audio processing module that runs as a daemon on a Dreamhost server. (The latter was a workaround to GAE's limitations on long-running processes and insertions into the app engine datastore)
