> Women are like dogs

This is the engineering form of confirmation bias. If you make something hard to do, it's hard to like it.

At the same time, I think when you design away as much complexity as possible at the product requirements level, as 37Signals proudly does with their products, it is hard to appreciate the complexity inherent to the requirements in other codebases.

I've seen this with other developers coming into large codebases with lots of complexity and scale requirements wanting to use a simple/naive ORM solution with no caching or worry about query speed/quantity. That solution falls over and they quickly learn that the requirements are more complex than a simple app with a few dozen users.

Basecamp is obviously at a high level of traffic and scaling complexity, but they still work to reduce requirement complexity which isn't always an option if you aren't the product owner.

It's extremely useful to be able to go back in time and have full conversation history, including associated resources.

It would be nice if a Dropbox link included a hash of the file, functioning more as a magnet link than a URL (emphasis on the "L - Locator" in "URL").

Why? I don't think I've deleted a non-spam e-mail since ~2001; e-mail-scale storage is cheap.

Good commenting is no substitute for good naming. For a variable containing the number 1, "three" is a shitty name.

The function being called is directly above this declaration. It's a static function not used outside of this file. What are the chances that someone would edit this code without understanding what "three" is used for in this context? Pretty slim I wager.

It's good that people are auditing the linux source code but if you stumble upon some weird looking code (which again, is not the case here in my opinion) the right way to deal with it is not to post it on hacker news. Contact the maintainer (look at the MAINTAINER file at the root of the kernel) if possible with a patch to fix the issue.

If I adjust your comment to "for a variable whose only purpose is to be passed to another function as the parameter called 'three', 'three' is a shitty name", would you endorse that sentiment?

On the other hand, I think that this kind of definitions are not useful for C.

http://i.imgur.com/huUv09m.png

> On November 9, 2009, EA announced its acquisition of social casual games developer Playfish for US$275 million. On the same day, the company announced layoffs of 1500 employees, representing 17% of its workforce, across a number of studios including EA Tiburon, Visceral Games, Mythic and EA Black Box.

I was at Tiburon when that happened. Not a fun day. :(

[1] http://investor.zynga.com/releasedetail.cfm?ReleaseID=800274

Note that it isn't that people are being paid $100K per quarter, it is that the business generates $100K in revenue per quarter per employee. When you manage a business one generally has a model, generally that model starts with revenue - cost of goods or "gross margin", in an info business like this I tend to model the Operational expense of "operations" (the folks who run the server, the cost of IP transit service, co-location fees, etc) as the "cost of goods" (basically the amount of money you're spending to make the product available for the customer).

So you start with that Gross Margin and your business model is the formulae you use to "spend" it. In old school tech companies you'll spend x% of your gross margin on "R&D", y% on sales, z% on customer acquisition etc. And at the end of the trough is your "net profit" which some folks report as free cash flow. So lets say Zynga spends 10% of their gross margin on R&D, then the money available for R&D would be $100K * GM * R&D margin. To work an example lets say Zynga's margins are 80%, 100K * .8 * .1 is $8k/quarter available for our R&D employee during the quarter. That is not even $3k/month or $36K/year loaded cost (meaning their salary, benefits and office space).

That is why it is a useful sanity check to see what the revenue per employee is. That helps you understand how healthy (or unhealthy) the business is. In comparison Apple has 80,000 employees and a quarterly revenue of 57B for a revenue per employee of 720K (about 7x Zynga).

I know boring stuff but sometimes it helps when trying to figure out if you're making progress or not.

So let's start with Zynga, and take for our example that they "net" $95 on a $100 Facebook transaction. How often does the customer do that? Once a month? Twice? every day? So every 24 hrs you clock out a chunk of cash to power servers, cooling, operators, maybe a security guard etc. So your "factory" is this data center with a bunch of machines in it. If you turn off the data center, money stops coming in. So if you model out the transactions that data center did in a month, you have the cost of running the data center, and you have the money it generated. You take the difference and that is the money that you got to keep and that is your gross margin. So customer pays $100 facebook transaction, $5 goes to Facebook (leaving Zynga with $95) and if they happen once a month and the cost of keeping the data center up and running for a month per transaction is $55, then Zynga gets to "keep" $40 of that $100. Their gross margin is 40%, if the cost to keep that data center up for a month per transaction is only $15, they keep $80 and their gross margin is 80%.)

Now lets look at the Apple case, Apple has a factory in China making iMacs. It takes a certain amount of time, and labor, and parts to make the iMac. When someone buys an iMac the money first is used to pay off the parts suppliers and the labor and the lease on the floor space and what other costs it took to make. And that what is left over they keep as gross margin. So if they sell it for $2000, spend $1000 on parts, and $100 worth of factory time to make it, they keep $900 and have a 40% gross margin)

So at a very high level, you've got employees of Zynga in a "studio" which design a game, draw the assets, and plan the flow, and you've got a data center "factory" which ships that game to customers. None of the customers pay for the game studio directly, instead they pay for access to the game and in game tokens, and that money, once it covers the cost of the data center goes toward paying their salary and benefits.

In Apple's case you have a bunch of engineers who design a cool laptop, and an OS to run on it, and design its shape and asthetics, they are not paid directly by customers, instead they transfer that design to the factory which manufactures them and ships them to customers. The revenue from that first pays the suppliers and factory and then the salaries and costs of the design staff.

In this way the information businesses are "similar" to the goods businesses. They differ however in their ability to respond to demand. A data center can go from idle to full utilization in milliseconds, it can take weeks to have a factory go from idle for its maximum production capacity.

But in both cases, the work output of all the employees, whether they are soldering boards, being an on call sysadmin, writing an OS, or drawing attractive cartoon characters, is financed by the amount of revenue that work generates for the company.

A year ago Zynga was making 900 million gross, now it's 205 million.

I'm going to assume that they are looking at their portfolio and realizing they aren't going to go up next quarter, so the real issue is they know they can't continue at the current level, regardless of margins.

If Zynga was a stable company, making similar revenues every quarter, or slightly up/down like Apple, Intel, IBM etc., I think your points are more valid. In fact, I'm pretty sure you could make a reasonable investment in that scenario (or call, if you will).

Since Zynga is not stable, the analysis isn't very helpful, since you already know they are 2 months into the next quarter and probably already burning cash.

Hmm, I guess this is why Buffet doesn't invest in tech so much...visibility seems limited....

[1] http://www.glassdoor.com/Salary/Zynga-Salaries-E243552.htm

Depending on the business, expect 50%-150% additional costs on top of salary. HR, health insurance, benefits, taxes, payroll management, etc.

US: 30% Brazil: 98% Mexico: 102% Most of western Europe: 30-50% China: 40% India: 20%

Mexico & Brazil are far higher due in part to unionization and their respective CBAs, which guarantee such things as time-and-a-half pay for vacation, an extra month's pay as annual bonus (separate from any merit based bonus), and generous employer retirement/pension contributions. The US is really low because 1) group health insurance is actually fairly affordable, especially when a wellness program provides healthy lifestyle incentives, 2) we have been going about 3 years between salary increases for the past 7 years, and 3) equity grants and discretionary bonuses typically aren't funded below the manager level.

I think this is pretty typical of large enterprises, though generosity will depend on profitability and culture. Some obviously do a far better job of treating employees well than others.

I was working as a consultant for small firms I have a salary of X - my billable rate was ~3X.

The company had shitty insurance of which I was paying a large % of my check each month to cover my end.

I absolutely refuse to believe it "costs" a small consulting company several hundred thousand dollars per year to employ a person making 100K per year.

Employee thinks: "I make $8,000 per month. My chargeout rate is $6,000 per week. What gives?"

Consultancy thinks:

Gross revenue of this employee is $18,000 per month, not $24,000. We only count on sustaining a 75% utilization rate. We can burst to higher numbers for short periods of time, but overhead, scheduling issues, breaks/vacation/etc, and productivity counsels us to shoot for 75%.

A salary of $8,000 per month costs us +/- $12,000 for direct costs of employment. This includes healthcare, our portion of payroll taxes, 401k contribution, and the usual perk suite.

We further incur overhead, which we estimate as approximately 20% of our gross revenue. This includes rent, capital expenses (laptops/etc), professional services (accountants/lawyers/etc), marketing and sales, the fully-loaded cost of non-billable employees like our office manager, recruiting fees, etc etc. Allocating this overhead on a dollar-per-dollar basis to the gross revenue you're producing, we come up with $3,600.

This means that our anticipated profit, pre-tax, on your services is approximately $2,400 per month. The economic justification for this is that it is a premium you essentially pay for insulating you from scheduling risk, non-paymen risk, market risk, and all the other forms of risk which we absorb on your behalf. [+]

If you would like to capture the risk premium for yourself, you have a simple option to do so: quit. Hang out your own shingle. Start charging $6k per week, or more, for your services. Many former consultants have done this, and many will in the future. It's probably how we got started, too. You may find after starting the firm that the math was very different from what you had anticipated. It probably happened to us, too.

[+] Weird thing about starting consultancies: the type of people who can successfully manage a consultancy take a pay cut when starting a multi-member consultancy, since it cuts into their billing efficiency. You can model an employed consultant at 75% efficiency, but principals rarely get above 50%, and in many cases they're totally unbilled (100% utilization on business management, rainmaking, etc). This results in employees #1 through #4ish actually being a net drain on the principals' income as compared to just solo-consulting. After roughly employee #5 it starts getting really, really lucrative again.

I worked for a company that was already established as a design consultancy... so all the above that you lay out was already calc'd in their overhead...

They went after a contract for a large project and they didn't have the expertise in house to land the project.

They poached me to be able to gain the contract. They made several million on this contract, which they would have been incapable of getting without me joining and actually doing the work.

They billed me out for exceedingly profitable work; I did 100% of the work, their overhead for all the shit you mention did not increase, and they piled more work onto my efforts which they billed for.

they promised me a multi-tens-of-thousands bonus based on all this work and met with me on five separate occasions to go over documented revenue/bonus projections and confirm this amount (this was with the CEO) -- then when it came time to pay; they paid me 8% of the promised, documented bonus. and made excuses that "they weren't being paid by the client" -- and later had a seperate manager (known as "the snake") come in and tell me "tough luck - the CEO's calcs were wrong"

So, While your story sounds all nice and whatever... I can guarantee that it is not true in all cases.

David Marks; if you read this - Fuck you.

The cost per employee is not just salary, no matter how many employees you add. Taxes, healthcare, pension, equipment all scale linearly with employee count.

Of course the company then wants to make a profit on top, or they'd be better off just shutting down. Companies extract extra value from their employees, in exchange for taking on risk and providing funding and stability. In some cases that's justified, in some cases they're not adding much while extracting most of the value - as an employee that's a judgement call you make - as patio11 says above, you can always choose to start on own, and usually you'll make more money doing so.

You may well have been cheated by your former employer (we can't possibly comment sensibly on that), but there are high overheads associated with each additional employee.

- It was an established design consultancy, that takes time and money to create.

- They charge the customer 3x what they paid you, but you dont know if the customer paid up. The had a contract, but then so did you, and you only got 8% of the bonus. You got pad your wage regardless of if they got paid.

- The pulled in the big client, this is almost important as a solo contractor, its their reputation on the line if you mess up. Its really hard to get those contracts or you need to have a contact. It's not uncommon for sales people to make 30% on big sales to land the contract on good terms.

- You did all the work, but could they have employed someone else, or are you the only person that could do it?

- Did they pay for health insurance, sick days etc?

- Have you thought about suing for your bonus?

Tech people often view this almost as an abstraction problem, or one that rightly wouldn't/shouldn't exist if nerds ran the world. I don't know if it would or wouldn't if us nerds ran the world, but in our actual world, finding and maintaining those relationships is very hard and very valuable.

The basic exchange between consulting management and labor is one of risk for upside. The returns from a consulting business can get very lumpy. An employee's income cannot be. They're promised a salary, presumably at market rate (else why take the job), and everything else is the company's problem. Hit a dry spell, employees keep getting paid, and principals don't.

At a well-run consultancy in a hot market (say, software security), there's not much incentive to squeeze employees, because recruiting and retention are expensive and because when you lose a consulting employee, it's often to companies that happen to be fierce competitors. So for instance, if you were instrumental to a deal here, you'd be eligible for the same kind of bonus compensation that the sales guy who closed the deal would be eligible for.

There's room in every business model for unscrupulous managers to somehow cheat employees. But if this million dollar contract you talk about was so clearly the product of your ability and execution, why did you need to be employed by design agency to deliver it? Why did you settle for the promise of a "bonus"? Or is it that, if not for you, some other consultancy would have won the deal, and also not given any of their employees a million dollars as a result?

We've lost team members who moved on to start their own firms. Chris Rohlf, now of LeafSR, was one of our all-time best consultants (and is one of the all-time great vulnerability researchers). With a few years experience running his own shop successfully, and dealing with all that entailed, I know what he'd tell you about whether he had a square deal at Matasano.

Not for nothing, but: if you're at a point in your career where you feel like you're make-or-break for million dollar deals that you yourself could close, maybe you shouldn't be working for a consultancy, and instead be running one.

But, you also have to add in all the staff costs of various overhead employees that support the money making employees, all the cleaning staff, HR, receptionist + senior management.

But you do sound pretty talented from other posts in this thread. As someone who has run his own company in several different lifetimes, and as someone who, perhaps like you, doesn't like having a boss, I can't recommend it highly enough.

But sadly, the numbers as patrick and tqbf are saying are unfortunately true.

One set is costs directly related to employing you. Benefits, employer paid taxes, equipment, insurance, office space, a fraction of your manager, and so on. These alone are hefty.

A second set is buffer to pay you when you aren't being utilized. A well-run consulting company might expect 80% utilization, so 20% of the time you're incurring salary plus all the above costs and they are receiving absolutely nothing for it. A more typical consultancy might have even lower utilization rates.

A third set is the costs of customer acquisition and account development. There are expensive staff who do a lot of expensive things solely to get the contracts signed in the first place. And if a consultancy stops attempting to grow, it's at grave risk that a few existing customers will leave for one reason or another, and they'll be left in a terrible spot.

A fourth is the cost of finding somebody like you in the first place. If I'm hiring a junior employee it might be something like $10k direct, plus the time associated with sourcing, vetting, and interviewing candidates. For a senior employee, it could be a lot more than that.

Put all of these factors together, and the profits simply aren't nearly as hefty as you'd imagine.

When we have interesting RFPs from consulting clients, then we pull people away from the bench.

It's a great way to retain people, have flexibility in the projects we take, and have significant depth and breadth for a small firm.

[1] we also very heavily draw from a pool of highly trusted subcontractors, many of whom are former employees. Because of our experiences with them, we go to them first and they all give us first crack at their availability.

Yeah right, game developers are cheap.

Edit - only because of supply/demand, not saying anything of their worth. Developing games is fun, I have a lot of fun doing it in my spare time.

Thus when some project reaches end of life, it's time for the entire studio to go.

It's the same idea behind Facebook trying to buy Snapchat. Facebook realizes another team is much more innovative & successful than them in attracting young users, so they try and spend money to acquire that talent and invest in that team's innovative ability (pay $3B now to realize >$3B revenue in the future).

Compare this to Facebook which has some of the best talent, culture and reputation of incrementally shipping out product.

Are you seriously saying that Zynga can't follow the same line of reasoning that Facebook did in trying to acquire Snapchat? Or did you just go off on a tangent for no reason?

Specifically here, it has certainly diverted a lot of attention that would otherwise be on a negative like laying people off into something that looks far more positive for the company.

Last time Zynga laid off a large % of their workforce, wasn't it during a huge conference or the same day Apple had made an announcement about new products or something? That's another great way to minimize attention toward something like this.

If I worked at NaturalMotion I'd be polishing my resume right now.

That would be good advice even without the same-day layoffs.

The misunderstanding of when an MVC architecture is appropriate, and when to (and not to) use the framework, is the mark of someone who has not yet really understood how to use Rails effectively.

    # Try to read the configuration file.

It needn't; the example I had in mind when I wrote my earlier comment was some Perl code I wrote on Friday to automate the task of taking one database, full of relations dependent on auto-increment column values, and merge its contents into another database of identical schema but conflicting auto-increment values, while maintaining the relationships between rows. This worked out to ca. 60 lines of Perl, and unusually dense and hard-to-read lines even for that language; to this, I added about a half-dozen terse but informative comment lines to serve as guideposts for my primarily Python-hacking colleague and co-conspirator on this project.

A 10:1 code-to-comments ratio is unusually high, granted, and perhaps I could've instead written the code to use a lot more temporary variables and otherwise ballooned it out to twice or three times its length, but I don't see how that would've aided readability; on the one hand, there'd be a lot more state to keep track of, and on the other, it'd no longer fit on a single screen, and would thus require the reader to scroll hither and yon while trying to make sense of it.

Some things are inherently not simple, and I'd argue that complex manipulations of complex data structures fall well within that category -- in such cases, there's only so far you can simplify the algorithm before it ceases to work as you intend. When you write such code, you more or less have to rely on the native competence of whoever else has to work with it, because there's only so much hand-holding you can accomplish either in comments or in code.

Fortunately, in this case I can safely so rely; my colleague is at least as capable as I am, so the comments I added are the same sort I'd appreciate having when attempting to digest a complex algorithm in a language not wholly familiar to me -- for example, if he'd written this code in Python, rather than me writing it in Perl.

(Of course, the real problem is that, while both languages make it possible to perform the sort of manipulation necessary here, neither language is really well suited to it; if my colleague knew Lisp as well as I do, I could've written the bloody thing in fifteen elegant and highly readable lines, and we both could go on with our lives. But I've more or less given up hope of introducing Lisp at my place of work; even the most seasoned programmers among my colleagues, when exposed to parentheses, turn pale green and make excuses to be somewhere else in a hurry.)

  # CONFIG
  ...
  # LOCALS
  ...
  # EDGE CASES
  ...
  # REFORMAT INPUT
  ...
  # MAIN ALGORITHM
  ...

    > visually represent logical segments of the code

http://akkartik.name/post/2012-11-24-18-10-36-soc

It has little to do with how clean the code is, I can't imagine not having my way finding markers around!

I'm sure it sucks for people with hire/fire authority to have to let somebody go early on when the decision to hire turns out to have been a bad one. But when it's the other way around, and an otherwise excellent new colleague regrets their end of the decision, the effect on morale is a lot more profound and widespread.

It takes some careful introspection and forethought to figure out what those crucial questions are. If they only come to you after the interview, send an email if you have to! But for Pete's sake, ask!