For the tl;dr crowd, here's the key takeaway: "Most companies promote workers into managerial positions because they seemingly deserve it, rather than because they have the talent for it. This practice doesn't work."
Before I started a startup, I was a software engineer at a large firm, and it was clear they were grooming me for management because I was a strong individual contributor and had "put in my time": 3 years as an engineer. Advancement at this firm was measured by "how many reports" you had, as in "direct reports", or people managed by you, and if you just did superior individual work but had no one "under you", you weren't advancing. So they sent me to a couple of training courses about management and started prepping me for the path.
This was one of the many reasons I quit this BigCo to start my own startup.
I am now the co-founder & CTO of Parse.ly (http://parse.ly). In our first two years after starting up, I spent all my time building stuff -- which is exactly what I wanted. Ironically, because the company has grown and now has a 13-person product team, I am now technically "managing" my engineering team with 13 "direct reports". But at our company, we have completely decoupled management from individual contribution -- certainly, if a strong individual contributor shows an interest in management, we'll consider it. But becoming a "manager" is not how you "advance" here -- you advance by doing great work. Our first employee who joined in 2009 is a great programmer and he is still with the company, but he's still doing what he loves: building & shipping stuff. Based on our frank conversations on the topic, I think he would quit if I forced him to be a manager. The appropriate reward for doing great work isn't a "promotion to management" -- that's actually a punishment for a great individual contributor. The right reward is to ensure you continue to provide an environment where that great work can continue for that contributor, and where they can continue to grow their skills and apply themselves productively in the role.
That doesn't scale for motivated people. I was told the same thing when I joined FreshBooks when they were only a 20 person team. By the time they were a 45 person team the strain of lack of management (without the Github / Valve style decoupling) was obvious. Then I was tasked with hiring my boss. It sucked hard, I was doing awesome work (four raises in a year an a half) but when the writing is on the wall and you're only 25 years old the only play is to leave the company.
I'm 95% convinced that companies larger than 50 people can't acquire truly outstanding people without having a decentralized system that doesn't reward power grabs and people pyramids.
"I'm 95% convinced that companies larger than 50 people can't acquire truly outstanding people without having a decentralized system that doesn't reward power grabs and people pyramids."
I wonder if it's even possible to have a system that doesn't reward power grabs and pyramids at a certain company size. Maybe the number isn't 50; maybe it's slightly lower or slightly higher. But certainly above Dunbar's number, we start to see organizations where departmental siloing and fiefdoms emerge. Politics seems inevitable in these situations, and the people who a) want to play the game, and b) are good at playing the game are the people who win the game.
The game exists because all it takes is one or two people to will it into existence. If a power vacuum opens up, or if enough competing VPs and Directors emerge, then someone is going to try to get ahead through politics. The only way to counter that is to play politics. Office politics, as a whole, is an emergent property of the individual players' political strategies and counter-strategies.
I have yet to work for, or with, a large company where office politics wasn't a significant factor. It's a bigger problem at some companies than at others. But it's always there. It can never be completely curtailed; it can only be mitigated. The best way to mitigate politics is to implement communications, reward, promotion, and advancement policies that don't incentivize politics as much as other systems might. This is a nontrivial challenge, especially at big scale.
I wonder if the solution here is to simply not grow the company that large in the first place? Usually what happens is a company gets a new product idea or a big surge in new customers and does not have a process in place to deal with it through automation and existing systems. The easiest solution is to just hire new employees and let them work it out - it scales very well at first glance as the original employees can continue to work on improving and automating what they already have. Is it the best solution though? If the product is good, slowing down on features or customers seems fairly acceptable until you can cope with them. It's obviously not going to fly with a VC funded firm. For a bootstrapped or lifestyle business it might be the better long run approach, and I believe most people really want a lifestyle business even if they think they don't.
> I wonder if it's even possible to have a system that doesn't reward power grabs and pyramids at a certain company size.
Somewhat related: I used to believe that if some company could manage being a BigCorp and still keeping the lean startuppy feeling in terms of work conditions, individual creativity and management transparency, that would be Google. I don't know whether they ever tried, but from what I hear and see (from the outside, never been even close to being inside) they haven't succeeded and became a by-the-book BigCorp with the usual problems.
Reading about management attempts back when Google was starting, they definitely did try. I'm not sure if they'd admit it, but I think they failed spectacularly. I'd even go as far as to say that if the people trying couldn't get it to work it might actually be impossible to create a large company that isn't a 'BigCorp'. There are too many barriers - social, legal and technical.
Can you elaborate why this "sucked hard"? Hiring your boss can be a lot better than just being handed one, after all. It sounds like the company was growing quickly and running into organizational issues because of it, makes sense they might be looking to hire some people with more experience than any 25 is likely to be able to offer.
Or did you mean you were hoping for a Valve style structure, and they weren't going there?
I was going to go from being an influential person that directly reported to the CEO, CTO, and CMO to reporting to one person with his own agenda: the CDS (Chief Data Scientist).
Here is what is going to happen next: He is going to get his own ideas about what I should work on, his own theories as to how to make the company grow faster, and his own vision as to what I should make.
Prior to that it was obvious to everyone that I was killing it. I made the company a million dollars in my first month just by writing a custom classifier for adword optimization (this was back before some of this stuff was automated or startup-ified). But when he takes over what is going to happen next? He is going to take credit for his "idea" because he set me on the "path" to solving the problem or making more money. Fuck that noise, it's parasitism and par for the course for management.
Management (beyond "team lead") is a fundamental shift away from being primarily a "build things" person to a "help everyone build things better" person. It's not just an advancement down a killer contributor path--it's a different path altogether. It comes with the shift in perspective that helping everyone on the team do better dwarfs your ability to do things yourself.
You also take on the task of making sure everyone's individual skills and aspirations line up with the company's, that teams are developing well in parallel toward a unified vision, and so much more.
Do you really want that job? If what fired you up most was your ability to kill it as an individual contributor, why not stay in that role and help hire someone else to take on the management side?
It sounds like he was worried that in the best case the manager would (perhaps unintentionally) get credit for his killer work and in the worst case the manager would actually hamper his work by trying to control him too much.
It sounds somewhat petty, but I can sympathize because the company I work for is going through a similar transition and I've seen the strains that even a single extra manager can have on communication. If the CTO is the one who approves your raises, and now the CTO's opinion of you is not shaped by you but by reports of you created by an intermediate third-party, a lot of somewhat complex interacting variables just got introduced into the equation.
If you start out at the bottom of a huge company like Google, you get used to that from the beginning. If you join a company with <=25 people and watch it grow, then you can really feel the transition sometimes.
This is wonderful insight and mostly true. The other major factor is that you are no longer in control of the message. I hate being in situations where it becomes a game of relay. The message always in some form gets mangled or in the worst case misconstrued when it goes from me to someone else and then the actual stakeholders. In your case you pretty much lose a lot of power since you can't just pop in to the relevant stakeholders without going through your new gatekeeper.
Well this is why great engineers should opt more for startups—because you get the opportunity to move the needle directly and everyone can see it.
But I don't think that means management is parasitic. The fact is that at a certain size all organizations need management, and a good manager helps you be productive. Whether you are recognized for that or whether credit gets usurped by your manager is a separate question.
"Whether you are recognized for that or whether credit gets usurped by your manager is a separate question."
Seems pretty tightly coupled to me. Losing individual contributors capable of implementing million dollar AdWord campaigns, for example, is going to have a big impact on the manager's team's productivity. So I think recognition and productivity are very tightly coupled.
It's very easy to say that, but is it true? I am not so sure. Around here it's easy to piss on managers because we all have horror stories, but on the same token a lot of developers have no idea what it takes to organize and direct a large organization, so it's really no different than a suit ignorantly asking "What is so hard about programming? They just type a bit of text then hit a big red deploy button."
As a CTO I have a foot in both camps, and I have to say there's a lot about management that developers don't know. In fact, my best management is never even known by my staff, they simply deal with a metric ton less bullshit due to a thankless move on my part—ignorance is bliss. Granted, it's probably easier for NNPMs to hang around an organization than NNPPs by virtue of tangibility, but I've seen enough NNPPs to know that programming is far from the transparent, egalitarian utopia that tech folks wish for.
> In fact, my best management is never even known by my staff, they simply deal with a metric ton less bullshit due to a thankless move on my part—ignorance is bliss.
You should try to keep your staff in the loop. Hiding things just means that you end up with a far bigger mess when you aren't able to shield them from it. If you keep your staff in the loop from day 1, it becomes far easier to deal with problems later. Because they won't even be problems then, just challenges that everyone knows about.
This is the quintessential management tactic, FUD it up. "Are you sure managers are playing games and trying to manipulate things?" The answer is yes, there ae hundreds of thousands to millions of dollars in compensation in play, of course managers are going to play games, steal credit, whatever it takes to stay employed and keep the money flowing.
What are you talking about? This is not FUD, I'm telling you something that you seem to know nothing about, so maybe you should sit down and listen for a minute.
Why makes you axiomatically claim "of course" managers are going to be sociopaths? That is not a given at all. There are good actors and bad actors on all sides. Do you think there aren't developers who play games to protect their turf and do the minimum to get by while collecting a paycheck from a business that they contribute nothing meaningful to?
Did you discuss your concerns with the CxOs? They're certainly valid, and the scenario you describe is a fairly likely outcome, but it might not have been inevitable. I know that if I were hired into a position like that I would make a point of acknowledging the contributions of those who had been there already. (It wouldn't stop me from being vocal about things I thought could be done better -- I would consider that my job -- but I certainly wouldn't try to take all the credit for what was already working well.)
And after all, it sounds like you were to be involved in the interview process. You would have had an opportunity to help select a candidate you could work with. Maybe it still wouldn't have worked out, but it just seems unfortunate to me that you didn't even give it a try. Of course there could have been other factors you haven't mentioned.
I didn't really need to discuss it with the CxOs, because they'd insisted on a hierarchal company structure, while I wanted something more valve-like.
Don't get me wrong, I really appreciated my time there and the people there are all really nice, in fact the company I founded recently is with two former FreshBookers, but I just want more freedom than people are usually willing to give me.
It could have been a mistake on their part, but actual "parasitism" is pretty rare in practice. It's a shame if you haven't experienced good technical management yet.
It is typical for a company to outgrow its early hires capability to manage that growth well; approx 50 people is a fundamental transition for most. This is difficult, often painful, and is likely to go more smoothly by adding relevant experience and maturity to the team. When the dust settles it's a different company and, if done well, capable of much more than it was.
It's not necessarily true that a boss is going to take credit for your idea. The best managers pass credit for success down completely and block criticism by taking responsibility for errors. Certainly, many bosses don't act this way, but the good ones do.
The reason "hiring your boss" sucked hard is because your boss was paid a lot more than you, right? What if he/she was a great manager but was actually paid on the same scale as you, and you were all advancing in pay with years of contribution?
LOL true story: a couple of companies ago my team were tasked with hiring our new manager, because none of us wanted the job. We had one candidate who came in and said "well this is very unusual for workers to interview managers, the first thing I'll do is put a stop to that".
If how much the person you are hiring gets paid relative to you is a criterion, you should not be part of the hiring process.
I have hired people at salaries greater and lesser than mine. Occasionally, the person above me was earning less than me and in several cases the person under me was earning significantly more than me.
The only question should be: is the person in the correct position and earning the amount they are being paid.
One structure that I think could give programmers a lifetime of career growth as programmers is a partner/associates model at a software services firm. In this model partners would still code, just like law partners still practice law, even if they also take on responsibilities re sales/outreach/management/mentoring/etc. I'd love to start such a firm, if I can find one or two people I trust to start it with me.
I love this. But let me play a mild devil's advocate. Sometimes people move into management not because they want to necessarily progress in the company they're in now, but because moving into management is an overall career advancement. Leaving a position with "manager" in your title makes it more likely you'll end up in one with "manager" in the title at your next job and be able to command a better position/pay combination.
This is a chicken & egg problem. If someone is moving into management as a form of "career advancement", the way I read that is, they think they should be paid more, but they don't think companies pay individual contributors with lots of experience more than they pay managers with lots of experience. That sucks.
My belief is that management & compensation should be completely decoupled, so people wouldn't seek to do management for "career advancement", but because they actually enjoy management. For example, I hired a product manager last year and he really loves the work. It allows him to mix small engineering projects with product strategy, requirements elaboration, and his considerable people skills. But I don't see him as a "superior" to my other engineers -- he is just a contributor, like my other engineers.
The "pay scale" for management should be similar to the pay scale for advanced individual work, in my opinion. Unfortunately, that's not the market we live in, so I can see why people would choose to seek management for "advancement" reasons, but this is just an unfortunate side effect of the market and ultimately causes a lot of talented contributors to do work they don't really love. Why? Essentially, for the money & prestige that needlessly comes with it.
Well, there's another pattern that leads experienced developers into management. After a while, they realize that no matter how good they get, they can only write so much code each day. They can only increase their effectiveness by applying their experience to improving code that other people write.
One route to that is by getting out of mainline production coding and going meta: designing new systems, programming languages, tools etc. Good work if you can get it, but prone to failure. Another route is to become a manager. There's plenty of demand for managers with technical ability, a clear route for advancement and much lower risk of failure.
There's lots of reasons for wanting to get into management, and I've found that one of the main motivators is wanting to get out of direct code-slinging software development as the majority of their day and use their experience for the company good in different ways -- basically new challenges and all that...but keep a similar level of pay. And very few people these days want to stay at a single job for more than a few years. So for a very experienced developer, they may start to feel "trapped" in their career and may not even know it.
Sorry, I don't want to be contradictory or make you defend what's obviously a working system for you guys. Just food for thought.
But why should moving into management be an overall career advancement?
Imagine a carpenter who sets his sights on working hard at carpentry and being a good carpenter so that he can eventually advance his career by becoming a plumber. Makes no sense, right? These are completely unrelated skills. Maybe plumbing pays more (reverse the roles if I got that wrong) but that doesn't make it an "advancement". Certainly one could make the move, but it's a lateral move, not a logical progression.
Management is the same way. It's a different field. Yet somehow we have this idea that if you do well enough in some other field, "advancing" into management is a logical next step. It makes no sense.
> Imagine a carpenter who sets his sights on working hard at carpentry and being a good carpenter so that he can eventually advance his career by becoming a plumber.
The current way it works in trades like that is to move up to being a foreman or a site supervisor or similar. It's no different really.
Ideally companies with management gaps want to move experienced tradesmen into these roles rather than put "management professionals" who wouldn't know a 2x4 from a band saw into them.
Segregating out "management" as an entirely separate discipline makes a kind of sense, and it's why management is taught as a separate skill set with certificates and MBAs and all that. But I think the results have been mixed (90s Apple is given as a textbook example). For every professional manager who does a good job, I think it's possible to find somebody who moved into management who does as good or better because they understand the problem domain of their reports better.
Wholly agree though that it's a separate set of skills, but I think those skills usually work best when layered on top of practical experience in the field.
Sounds like you want to pick out people with aptitude for both and then promote them. Right now, it seems like management is seen as the logical progression for everybody, and somebody who doesn't go that way is seen as having "failed" even though they simply might not be suited for it and there's no sensible progression there.
> Right now, it seems like management is seen as the logical progression for everybody
Yeah, you're right in that. It obviously doesn't work that way, there are far fewer management positions than people who could be promoted up into those positions. Even in some of the most hilariously top heavy organizations I've seen, this holds true.
I guess we have a cultural model of the "career" that somebody can start "in the mail room" and work their way up to CEO. Any deviation from that as a possible path is seen as veering off course or failing or "career ending" and you just end up in mere "jobs". You're right of course that this is unfair as the vast majority of people will never be on a career path that looks like this.
There's also an old fashioned class-based hold over in organization structure: nobles and commoners. This has been held over as "management" and "workers" or in the military as "officers and enlisted" and it seems that a great deal of our organizational theory, promotional structure and cultural ideas about progression are based on this: the "organizers and communicators" and the "producers".
Is there a better way? Maybe. But I don't think current counter-approaches work well over the long run, e.g. flat org structures. As a species we seem to naturally arrange ourselves into hierarchical structures, and if one isn't imposed on a group, one will emerge.
So I guess the idea of management, and it being a career path, is complex and is simply an optimization on these issues.
I've also been in organizations with very explicit, upward moving career trajectories that didn't end up in management per se. For example, one very large R&D organization I worked in was broken down like this.
You had the "employee". They all theoretically started as a "researcher I". As you progressed into "researcher II" then "research associate" then "research scientist" you were offered two choices go into "people management" and become an "associate manager" where you did normal people management stuff, some HR functions, signed off on time cards and did promotion stuff, but otherwise didn't involve yourself in the day-to-day of an employee's work life. Employees were simply "resources".
Or go into a research track. If you went research track you would then end up as a "research scientist" then a "principle research scientist" and then a "senior research scientist" (with research fellows etc.) Around the time you became a "principle" you were then offered two choices, stay in research, or go into program management. A program manager "owned" a program and requested "resources" from associate managers who were then matrixed under you. You directed their day-to-day, but if there were employee problems, you took it up with their associate manager who then dealt with it.
However, and this was the trick, if you stayed purely research, you'd of course continue doing research, but at that level, you were more valuable assisting the PM or the sales/marketing team (even R&D firms have this) with your expertise in getting research grants, writing proposals, etc. Quite often a PM would assume all the contract management stuff and the Senior Research Scientist would end up running the day-to-day of the lower level researchers. In the aforementioned military model, this ended up looking like an officer and his sergeant major. Or in academia, the principle researcher and his post-doc, with all the grad students. In practice, you'd end up becoming a manager.
However, in the line of "mail clerk" to "ceo", you were out of the game already. Nobody viewed it as a failure, Senior Scientists were revered like high priests there. But a priest cannot become a noble or a king. Only if you were an Associate Manager, or to a lesser extent a PM, would you have a shot at the line. Progressing AMs and PMs ended up assuming other roles, a bit of sales work, and for AMs a bit of PM work. I'll let you decide on the downsides and upsides (there are actually quite a few) of this system.
Some PMs ended up floating back over to Senior Scientist level, because they were already good at doing all the administrivia, but wanted to get their knuckles dirty in research again. Unfortunately, they usually found themselves more mired in more paperwork than pure research, and nobody wanted to take the pay cut and work as a Researcher II again where your time is 100% research. The economics simply don't work out to have a Senior Scientist running lab tests and squeezing pipettes all day. But they're the only ones with enough domain knowledge to write the grant proposal that will bring in a $30m 5 year program.
> Management is the same way. It's a different field. Yet somehow we have this idea that if you do well enough in some other field, "advancing" into management is a logical next step. It makes no sense.
It can make sense.
A leader needs the respect of those she/he leads. It is easier to command respect when you are perceived as a technical expert or authority.
Promoting the Dilberts to bosses is an attempt at giving the engineers what they say they want: bosses with Dilbert's engineering skills.
I think many otherwise technical people start moving into management because of a desire to have a bigger value impact in their company, but there is a poor breakdown of responsibilities between technical positions and management positions. Modern organizational structures (esp at big companies), usually puts in non-technical management in places where they take on higher-level responsibilities driving product and business. Think product managers, or high level sales directors, etc. Technical contributors' skills are treated as "too valuable" to waste on these management duties, but paradoxically, the opportunity for a technical person to contribute at a high level or early decision points ends up as something often held separate from the engineering career ladder (until you get very high up).
I come across mentions of WWII era projects, designs of famous aircraft etc where the designs were incredibly well suited to the needs, and produced in incredibly short time-frames. Some of that is obviously the war-time focus, but I also notice that in many of those projects the lead position is not a non-technical manager, but a technical chief engineer where management functions must have been subservient. Unfortunately, there isn't a huge amount written about the organizational day-to-day project structures during WWII.
I think at least some of the appeal of startups and smaller companies for technically oriented people is that division of responsibility is not as formalized and contributions can flow more easily between different domains. But again, startups are structured where technical founders are at the levers of control, and that's inverted from how many companies end up organized as they grow.
That caliber of leadership and oversight requires immense skill, authority over capital allocation, AND trust from the next level up. Organizations that can maintain this are rare and typically have a brutal filtering process.
The old way is basically aristocratic thinking, the people who actually do stuff are scum, the people "in charge" are simply better than them.
Once you start admitting that "managing people" is just a job that you can do well or badly, and that can be really important or just administrative trivia, then that worldview shatters.
Unfortunately it seems very well embedded in the general culture, even in tech where it's not totally unthinkable for someone to earn more money (and provide more value) to the firm than the person who manages them.
I'm sure this was mentioned in The Mythical Man Month - the need to have a technical promotion track instead of just the managerial one, for exactly this reason. There needs to be a path to seniority that does not involve accumulating underlings.
How do you think this would scale if you grew to 100 employees? If the same person is with you then they would be the person with the most knowledge of the codebase and the business itself, so it would seem natural that newer employees would go to this person for guidance and defer to them for higher level decisions.
Would it still make sense to pay them as much to just write code as it would for them to take on a more decision making role?
Not a CTO, but having good knowledge of the business and assisting fellow workers can be put in other terms than just 'manager'. It can mean architect, lead developper, technical lead, new recruit's mentor or technical instructor. The choices are endless, and the title and actual work can be fitted to the person.
I was never familiar with it nor with the responsibility in detail of individuals there, but the parent comment makes me think of the old Bell Labs. (And/or parts of Xerox, etc.)
Highly capable people given and environment that fostered their production.
Not everything generated was immediately commercial. But it was a very productive environment, and this had strong commercial implications. It also created a lot of public good, immediately and/or eventually.
Not every institution can afford a Bell Labs or a PARC.  But letting people do what they are good at, is perhaps not such a bad idea.
 P.S. I suppose that from one perspective, not even Bell nor Xerox could... although I don't subscribe to the argument, at least and especially not at such a simplistic level.
I had the same exact thought. It might be that this graph represents month-by-month net income, rather than something like Net MRR. Perhaps the spike represents a large number of sign-ups for annual plans (it seems like his standard plan is $24/year) in a short period, which means he should see the same spike next year upon renewal (minus his churned customers, of course).
It might be that if he "pro-rated" the monthly payments for his annual accounts as $2/month payments for the future 12 months, he is net positive right now. It's hard for me to tell by eye from the graph, but it's probably close.
The inaugural residency ("beta test") happened in February, when an NYC writer, Jessica Gross, was given a free 39-hour ride between NYC and Chicago (and back) in a sleeper cabin. She wrote about it in The Paris Review:
Amtrak's running on a lot of very old track, which limits the top speed the trains can go on most routes. They don't have the power to upgrade the tracks because they don't own them, and the freight companies who do own the track don't have much incentive to upgrade it.
Also Amtrak can be forced to stop if a particularly heavy freight train or traffic has gone through. Heavy freight can heat up the rails enough that Amtrak has to wait for them to cool, the only time I've ever used Amtrak that happened and it took forever.
In addition to the points made by the other comments, I'd also add that "thus more stops" doesn't necessarily follow. Amtrak tends to be the subject of a lot of stupid politics, with the routes and stops determined more by what wins votes than what makes sense. As a result, a lot of Amtrak routes stop extremely frequently in pretty small towns.
As an example, the Amtrak train that runs between Washington DC and Boston (serving NYC along the way, and continuing on to Norfolk, VA) stops not only at DC's main train station, but also at New Carrollton, MD and Alexandria, VA, which are not only quite close to DC, but actually on the DC Metro system, making these stops almost completely redundant.
I count no less than thirty two stops between Boston and DC. The trip is about 9.5 hours long, so that's an average of one stop every 18 minutes.
The NYC->Chicago trip isn't quite as bad, but still has 19 stops in between. Along the way, it stops in such bustling metropolises as Elkhart, IN (population 51,152) and Sandusky, OH (population 25,493).
An even better example is the Acela, which makes fewer stops than the regular Northeast Regional trains, but stops in Wilmington, Delaware (pop. 70,000 and a 30 minute drive from Philadelphia). Joe Biden, now Vice President and formerly Senator from Delaware, used to commute on the Acela every day, and was a strong advocate for Amtrak funding.
Most of those stops between Boston and D.C. only have one train service per day.
The typical Northeast Regional between D.C. and NYC is: New York City, Newark, Metropark, Trenton, Philadelphia, Wilmington, Baltimore, BWI, New Carrolton, D.C. That's 8 intermediate stops over 3.5 hours, or one per 26 minutes. The Acela Express doesn't stop at Metropark, Trenton, BWI, or New Carrolton.
Why does even the Acela pass through Wilmington? The city only has 70,000 people, but is also a hub of corporate law firms and credit card companies. Wilmington boards about 800k passengers per yer, versus Baltimore's 1m, despite the latter being about 10x as big.
The Lake Shore Limited (NYC <-> Chicago) runs through Albany and Buffalo, so it's closer to 950 miles, instead of the 800 miles you'd expect taking I-80 straight through. So the train does average closer to 50 than 40, which is better but still not great.
Depends on where in Europe... the long-distance trains from Copenhagen (mainly CityNightLine) are closer to Amtrak speeds. For example Copenhagen to Basel is ~700 miles, 16 1/2 hours; Copenhagen to Amsterdam is ~500 miles, 15 hours.
Also, a train going between Chicago and New York is traveling through Indiana, over CSX-owned tracks, and they are notoriously terrible about prioritizing freight over passenger rail. Expect to spend an extra 1-3 hours stopped waiting for a freight train!
It's perfectly feasible to have far quicker diesel trains than is common in the US (see the British High Speed Train, from the 1970s, with a top speed in service of 125mph, or the ICE-TD from a decade ago, again 125mph). Of course, you then need to have signalling for that line-speed and have pathings that allow it.
High speed rail (typically considered 200km/h+, i.e., ~124mph) is almost always built with no at-grade crossings; on existing track upgraded for 200km/h line-speed it's normal to have lower speed limits around at-grade crossings.
They do go slow, but that's not often the point, and that's what this campaign is trying to help. They are trying to point out a different way of looking at it. They are pointing out the romantic-relax-enjoy side of trains rather than the hurry-up-and-move-move side.
Spolsky said many years ago that programmers need private offices to collaborate and be productive. When I started Parse.ly in 2009, we couldn't afford them, but our team was already split geographically, so we just built a fully distributed team, instead. Home offices can make for great private offices, home Internet is fast, and commutes suck. I describe fully distributed teams in this blog post: http://bit.ly/distributed-teams
Now, we have over 20 employees, 13 of them spread throughout the US and Canada (all programmers). I actually just gave a presentation to new employees based here, "Parse.ly's Distributed Team: Open Source meets Open Plan": http://pixelmonkey.org/pub/distributed-teams -- it discusses some of the pro's and con's of our setup.
Completely coincidentally, I just bought the novel by Gabriel García Márquez, "Chronicle of a Death Foretold" (in Spanish: "Crónica de una muerte anunciada") today.
It's a short novel by the Columbian author that I had read ~10 years ago, and thought of it again today when reflecting on the nature of journalism. The novel is a commentary on the notion of "truth". Its plot involves a murder in a small town in Columbia, and is told in a journalistic style, where you, the reader, learn new facts that reshape the perception of the "whole story" as the story itself unfolds through the narration. As the novel unfolds, you start to question the veracity of the facts presented to you, causing you to question whether the "true reality" of what happened is even knowable.
The spelling difference doesn't change the fact that this is the same word: land of Columbus. This was an early proposed name for the country of the United States, Columbia, today most famously personified in the Columbia Pictures logo (and I think in the Statue of Liberty, but I'm not sure).
I kind of wish sometimes that the US had used that name instead of appropriating the name "America" from the rest of the new world.
We're a fully distributed team (see http://bit.ly/distributed-teams for a post by me, the CTO) -- which is to say, a merit-based, technology-forward, super-bright team of Pythonistas who happen to collaborate using the same methods of major open web projects like Wikipedia, Wordpress, Ubuntu, and Mozilla.
We are well-funded with a solid SaaS business model, we are growing, and we are product-focused.
We're looking to expand our engineering team. We are primarily looking for full-stack and UI-focused engineers, especially those with expertise in front-end data visualization / interaction. You should know modern web and mobile design principles and be particularly excited by d3.js and its associated ecosystem.
You'd be joining the company at a great time. Our engineering team is still small enough that we feel like an elite task force, but unlike two years ago, we are making millions in revenue and have a ridiculous amount of data to draw insight out of on behalf of our customers.
If you join, you'd become part of a team that is building one of the web's greatest analytics companies, while also serving a strong mission: helping editors and writers at top news organizations excel in the digital medium.
Our software aggregates data on >5 billion pageviews per month of traffic, and we work with major media companies as customers, such as The Atlantic, Arstechnica, Mashable, The New Republic, MIT Technology Review, and many more.
Apply by sending a (short!) cover letter to email@example.com. Mention this HN post and say you're looking for Andrew.
Include links to online portfolio, Github, LinkedIn, or any similar services, if you have them. If you have a Python code example that you think expresses your Python coding style, that would also be a good thing to send along -- as plain attachment, Github Gist, or similar.
From the article: "Mr. Obama was acutely aware of the risks of being seen as handcuffing the security agencies. 'Whatever reforms he makes, you can be sure if there’s another incident — and the odds are there will be in our history — there’ll be someone on CNN within seconds saying if the president hadn’t hamstrung the intelligence community, this wouldn’t have happened,' Mr. Axelrod said."
If theres ever a time to do the right thing, it's in the President's second term: it's all downhill, what the pundits say doesn't matter to re-electability, since there is none (unless you plan on going to another office later on...)
If the President wants to accomplish anything in his second term -- which is the point of holding the office -- than he still needs to maintain popular support. The public can't (generally) vote him out of office any more, but they can vote out his allies in the House or local/state government.
Unless the President is just hoping to shut everything down. Almost by definition he can do that without cooperation.
Is there a tool that will take a requirements.txt file and let you know whether all the packages in that file are already Python 3 compatible (by looking up corresponding packages on PyPI)?
If not, that tool seems worth writing, and then we can do a poll of some major production codebases and see whether Python 3 support is actually missing.
As for "Python 2.8": meh. I think we should just support the development of tulip / asyncio in Python 3.4 (see docs, this is looking awesome already: http://docs.python.org/3.4/library/asyncio.html), then use our blog platforms as Pythonistas to promote all the new async programming you can do using asyncio + Futures + yield from, port over important async frameworks like Tornado/Twisted, etc.
In that case, Python 3.4 becomes the Python release that gives you all the power / convenience of Python 2.x with a complete cleanup of callback spaghetti code as demonstrated in the "hello, world" co-routine example: http://docs.python.org/3.4/library/asyncio-task.html#example... -- I think async programming is mainstream enough, especially in web/mobile/API applications, that this will be a compelling draw for people.
I think the only thing GvR and crew got wrong is the timing -- it probably won't take 5 years from release for everyone to migrate to Python 3, but it will take more like 8-10. But it'll happen.
Sounds like idiomatic Clojure has more in common with Python than it does with Java. I'm finding that to be true as I teach myself Clojure. My background is an ex-advanced-Java programmer who left that all behind and has built production systems in Python for the last ~5 years. I'm learning Clojure now because the Java ecosystem is important to me, but I simply refuse to use Java to interact with it :)
Lightweight data modeling is important and Java is truly terrible at this. I illustrated this in a gist about creating and iterating over a list and a map, and contrasting that to the equivalent Python: https://gist.github.com/amontalenti/8114359
The author says about Scala: "Due to its highly detailed static type system, Scala attracts the kind of programmers that like to carefully categorize and enumerate all the possible data structures."
It turns out, this describes expert Java programmers very well, too -- so it's no surprise that Scala is a very popular language with Java programmers. I'm finding that Clojure is the more attractive language if your sensitivities lean toward the "simplicity" and "dynamism" camp. I was reading some Scala code being used in production at Twitter and found this marvel: https://twitter.com/amontalenti/status/410977749629546496 -- you would simply never see anything like this in Clojure or Python codebases.
The point about multi-paradigm is interesting. It's very true that Clojure, unlike Python, does not support true multi-paradigm. Then again, Python does not support "true" functional programming. It's close, but no cigar, due to the lack of full-featured lambdas / blocks. If you have to pick one paradigm, functional is definitely the simpler and more essential one.
Illustration: imagine a variant of Python that forced all code to live in classes -- ick. But imagine a variant of Python without classes -- that's not so bad.
I'll add one thing to your point - multimethods are a fantastic example of how Clojure allows you to structure programs in functional way that takes a programming feature (in this case polymorphic method dispatch based on the arguments at runtime) to the nth degree.
In Java and many other languages that have polymorphic method dispatch - the dispatch value is usually the type of the object for whom the method is being called on. Functional languages like Haskell take a much more powerful and expressive approach to this and extend it to matching the dispatch values for the called function on the type or pattern matched value of any argument.
Multimethods are essentially Clojure's take on this in a dynamic language. They allow the programmer to define a function that constructs the dispatch value however it wants - usually from the arguments given as input, in any order, on any condition.
To illustrate, I'll give an example I showed my wife yesterday. She's writing a roguelike game in ClojureScript at the moment that you can play in the browser - naturally she needed a way to represent the game world and the players position as they move around.
So, for illustration I'll omit the code for the world state, but she needed to bind event listeners for the keyboard to properly dispatch the proper movement logic. So the code she wrote looked like this:
She came to me with this code with the following problem - how do I think she should organize it? Clearly the handling logic is going to be more complex than a single line per direction (:up, :down, :left, :right) could handle, she has to account for terrain differences, buildings, monsters, what have you.
So I suggested using multimethods to accomplish this. This is what the multimethod solution I cooked up would look like in this case.
Now she has room in those multimethods to handle the potentially complex logic needed to make those arrow keys move the character properly. But another effect of this is that it hides the underlying state mutation from the implementation.
Now your move functions are pure and isolated from the coords atom, in addition to the fact that multimethods made the logic more organized, at the expense of a few more lines of code.
In my experience mulltimethods get you a long way when writing Clojure code. My projects use them often and add two or three macros. That is normally the only "overhead" I have to impose over regular functions.
That said, in the example you posted I don't think you are using all the power of the multimethods, because you did not replace the case statement. You went from a case statement to a multimethod+a case statement. In this case, why not let the mutimethod dispatching to do all the routing/case functionality for you? Just use (.-keyCode e) as your dispatch function and use the different values of KeyCodes.XXX for each implementation of the multimethod. And you can even add a :default implementation that leaves the coords untouched.
In my experience the natural use of multimethods arise when you can choose the dispatch function for an element based on either some piece of data from the element or a computed value derived fron the element. But if you have to rely on case/cond/if statements the value of the multimetod is lessened, as you still have to touch your dispatch function when your hierarchy of values change.
First version here: Uses only a case statement to dispatch the proper behavior, but as a pure function.
When she begins to take the state of the map and all of the other variables into account, this case statement will prove confusing to wade through - because it's one function that is doing four related but separate tasks. So version two is what you'd likely end up doing after the code got too unwieldy.
Oh wait... that's what a multimethod is! Now you've gone full circle. I hope you can see the point I was trying to make more generally, beyond the limited example I gave here.
That's because you're not considering the fact that the complexity of handling movement in each direction will increase -dramatically- as she continues to write out the game.
If the logic would forever stay a one liner, "increment the y coord!" when the up arrow key is pressed, I would agree with you - keep the case statement and go on your merry way. But that isn't the case, and my wife anticipated that being the case, hence the motivation for her question.
Spreading out complex logic into separate functions is usually considered good form. Like every design decision, you have to be wary not to overdo it - but I think my wife was spot on in identifying the need to do so in this case.
Putting the case statement aside for a second - you're also overlooking the fact that by using functions in this way the implementation becomes pure. The functions do not mutate anything and are completely oblivious to the fact that they are being used to swap! out the current position of the player for another.
Some benefits to writing pure functions include easier testing (you don't have to supply an atom to know if your function works, just call the function) and REPL use is vastly simplified. Additionally, I don't even need a browser or a keyboard handler to see if my movement functions work.
> It turns out, this describes expert Java programmers very well, too -- so it's no surprise that Scala is a very popular language with Java programmers. I'm finding that Clojure is the more attractive language if your sensitivities lean toward the "simplicity" and "dynamism" camp. I was reading some Scala code being used in production at Twitter and found this marvel: https://twitter.com/amontalenti/status/410977749629546496 -- you would simply never see anything like this in Clojure or Python codebases.
Well done, you found some bad code written in Scala. I can assure you I've seen far worse in Python.
Well, that code exists at all for compatibility with tuples, which are a misfeature from the early days of scala. The "right" way to solve the problem is with shapeless' HLists. With HList you could write a simple generic method that would work with a HList of any length. (If you don't need to join a bunch of hetrogenously-typed futures while preserving all their type distinctions then you could just use the method that takes a Seq, above in the file)
(You could also generate exactly this code with macros, which were a new feature in scala 2.10; I imagine a newer version of the code will do that)
That's part of Clojure's implementation in Java and the alternative would be to use reflection (obviously a terrible idea). There is similar code in the Scala implementation for dealing with functions, case classes and tuples. The only difference is that the Clojure implementation reflects that it's dynamically typed. I'd even bet there's similar code in CPython.
If I understand that scala code correctly it's just enumerating a multiple arity function manually. It's not that uncommon to see that in clojure for performance reaasons, clojure.core has plenty of examples as does the java-written compiler. It's a lot faster to enumerate the common arities than to use apply like:
(defn f [& args]
(apply g args))
And it usually just takes a couple of strokes in any decent text editor anyway.
Parse.ly has been using this product for the past several months. In fact, I think we are the "smallest customer" that Jason cited, with 16 employees. We're a fully distributed team (as I described in http://bit.ly/distributed-teams), so it was a particularly good fit for us.
Our team loves the product. They loved it from the first week it was in use. It sends a weekly email rounding up what everyone is working on every week. It also has team members sharing interesting social things like favorite recipes, childhood stories, books, and movies. And the "Company Question" (a weekly question picked by management) allows us to get regular feedback from employees, which we used to do sporadically using hacked-together Wufoo surveys, but this has much less friction and actually works. One of my favorite of these questions that we recently asked was, "Is there anyone at the company you wish you could apprentice under for a few weeks?"
I don't want to reveal too much about the product because I don't want to preempt their own marketing of it, but here's a quick glimpse of how the "Questions" view of the product looks -- this is where you can see the answers from employees of past questions. In general, it has a simple, sparse, and beautiful design that achieves the goal of the product with ease.